Experimental Physics and
Industrial Control System

Michael Abbott <[email protected]> · Thu, 8 Jul 2010 09:54:10 +0100 (BST)

On Wed, 7 Jul 2010, Rod Nussbaumer wrote:
> [email protected] wrote:
> > From: Rod Nussbaumer [mailto:[email protected]] 
> > > Did you develop your own root filesystem for ARM? What toolchain are 
> > > you using? Did you create that in-house?
> > One complication in the linux-arm architecture is that the floating 
> > point format (implemented by the Netwinder Floating Point emulation 
> > library, NWFP) for doubles is not IEEE format on a little-endian 
> > architecture (which I presume you're using), so this requires a 
> > special hack in the network format adapter of EPICS.  You're almost 
> > certainly using this, and one of the huge advantages of EABI is that 
> > you can throw NWFP straight in the bin.
> 
> Yes, I'm using that. Old ABI, NWFP, little-endian.
> 
> > Subsequently however I have put together a complete build system 
> > in-house. This was rather more work than expected, but at least the 
> > result is quite nice and should be reusable if you're interested.  
> > Putting together a complete system from scratch involves:
> > 
> > 1. Compiler, toolchain and libraries.  I recommend crosstool-ng if you 
> > are willing to build your toolchain from scratch -- it works very 
> > nicely and allows you to precisely target the configuration of your 
> > final system.  I have detailed instructions and wrapper scripts.  
> > This toolchain is supported by the linux-arm_el EPICS target 
> > architecture which differs essentially in not requring the NWFP hack.
> 
> Yes, I'm using that, too. I've built my toolchain using CT-NG 1.5.3, the 
> newest version that still supports my kernel and glibc. Do you have a 
> .config file you'd be willing to share?

Surely.  I'll put together something public, today hopefully, and let you 
know.

> > 2. Bootloader (or you can just use your existing bootloader if it's up 
> > to scratch).  I think all I did was enable the hush shell on u-boot 
> > using the vendor's original u-boot patches.  This will be *very* 
> > target system dependent -- what *is* your target processor?  ARM has a 
> > surprising number of variations.
> 
> I'm using a Technologics-Systems TS-7350 SBC with their custom 
> bootloader, booting from SD flash, but aim to change that to network 
> boot. For now, booting from flash is fine. Actually, a requirement for 
> the first deployment. The CPU is a Cirrus EP9302.

Hmm.  Interesting processor, an ARM9 (either ARMv4T or ARMv5TE 
architecture, can't really tell from the description) with hardware 
floating point that is absolutely panned in the Wikipedia article:
	http://en.wikipedia.org/wiki/MaverickCrunch

I guess that's why you're using NWFP!

Anyhow, this architecture definitely needs the updated NPTL with kernel 
support for "compare and set" for completely reliable operation.

Network booting is invaluable for kernel and rootfs development.  If your 
bootloaded supports loading two separate memory images into RAM it's even 
easier to do ramfs booting with the kernel command line
	root=/dev/ram initrd=0xa2000000,2714854
where, unfortunately, the last number has to match the ramfs image 
precisely!

> > 3. Kernel.  I'm sure your 2.6.21 kernel is recent enough to support 
> > NPTL, but you may need to check that EABI support is compiled into the 
> > kernel (if you care; we did, I recommend it highly).
> 
> That was to be a longer term plan, and hoping to avoid it right now. 
> EABI seems too attractive to not use it, eventually. The kernel I'm 
> using includes binary-only modules for vendor-custom hardware, so 
> upgrading isn't just a kernel build. Running 'getconf 
> GNU_LIBPTHREAD_VERSION' on my target says I have linuxthreads.

Binary only modules.  Oh dear.  Are they tied to the particular kernel 
version?  Also, has the vendor given you a config for the kernel, or, at 
least, does /proc/config.gz exist?

I'm thinking along these lines:

1. If the binary modules are structured as a binary blob with a kernel 
independent interface and separately compiled bindings to the kernel then 
you can hope to recompile for your choice of kernel.

2. If not ... then the vendor is almost certainly violating the GPL.

At the very least, the vendor is absolutely obliged to give you the kernel 
configuration and all patches required to build it.

> > 4. Finally assembling the target rootfs, which in our case is glibc + 
> > busybox + ntp + a handful of other utilities.  I have a configurable 
> > (and somewhat overcomplicated) collection of build scripts and 
> > makefiles to automate all this, which you can try if you're 
> > interested...
>
> Yes, I'm interested. I've tried buildroot, openembedded, and a couple of 
> others. Again, in the near term I plan to use the root filesystem 
> provided by the vendor. Eventually, though, I want to use something 
> smaller and simpler, and tailored to our requirements.

Yes I also played with openembedded which was interesting and powerful, 
but huge and hard to understand -- does much more than we need, at least I 
found it so; I should have spent some time looking at buildroot, as my 
rootfs builder does something similar, but I haven't.

Again, I'll prepare something public and make a little announcement, today 
or tomorrow.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System