1. Linux on ARM7TDMI or Nothing is as easy as it looks Helicon technologies Ltd. How to run uClinux on NXP LPC22xx

2. Target hardware ● A low cost electronic card. ● RAM should be as small as possible. ● Flash is cheaper but should still be small. ● No network. ● No disk. ● CPU NXP (formerly PHILIPS) LPC22xx. ● ARM7TDMI core ● No MMU.

3. Why run Linux? ● Easier to develop software for. ● Debugged multitasking operating system. ● Programmers are used to Linux. ● Similar software would run in other hardware. ● Using several operating system in products creates maintenance problems.

4. Why not run Linux ● Linux is a big system thus needs a lot of RAM. ● No commercial support for this hardware. ● Setting Linux to run on this platform takes a lot of time (we knew this only later on). ● First time I recommended NOT TO RUN LINUX.

5. Beginning research ● google for LPC22xx Linux ● Found a detailed document on uClinux for LPC22xx ● Seemed to be straight forward ● Studying uClinux ● Studying LPC22xx

6. uClinux ● LPC22xx has no MMU and Linux usually needs MMU ● uClinux implemented nommu patches for Linux ● nommu patches integrated into main kernel since 2.6.x ● uClinux now provides Linux 2.6.x kernel and a file system (romfs)

7. Linux boot loader ● There is a U-boot implementation for LPC22xx ● U-boot was recommended by the Philips application note. ● Philips supplied a patch for U-boot to support LPC22xx ● Download U-boot 1.1.3, apply the patch, compile... ● Download to target (using JTAG)

8. Running U-boot ● JTAG refuses to program u-boot ● Look at u-boot.hex file ● U-boot seemed to be loaded on address: 0x81400000 ● This is a RAM address, not flash address ● Manually change address in u-boot.hex file to: 0x80000000 (Flash base) ● Programming u-boot.hex using JTAG ● Running...

9. Testing U-boot on target ● Trying to use network, network does not work. ● Loading S-record file to program flash, does not work either. ● Means this U-boot can only boot and can not be used to program Linux and file system on Flash memory.

10. Compiling uClinux ● Downloading uClinux. ● Download Linux 2.6.11. ● Apply patches (ARM7TDMI and LPC22xx). ● LPC22xx patch copyrighted by Philips but not supported. ● Configuring uClinux and Linux (standard make menuconfig). ● Compiling uClinux and Linux ● Result was linux image and romfs image (binary).

11. Preparing to program Linux ● Since our U-boot can not program, we need to create a.hex file so JTAG can program it. ● objcopy does not support changing base address of result Intel hex file. ● Wrote our own program to convert from binary to Intel hex file supporting different base address. ● Built u-boot images and converted them to Intel hex.

12. Programming and Running? ● Used JTAG again to program Linux and the file system ● Running, asking U-boot to run Linux ● No response from kernel... ● We have no symbolic debugging, but tried a breakpoint using JTAG debugger ● We are nowhere near a valid address... ● Seems we programmed the wrong file... ● But this was the file according to the AP...

13. Finding the right file ● Research the uClinux build system and Linux build system ● Found linux.bin in linux directory ● Converted to a u-boot image and translated to Intel hex ● Program it ● The kernel responds but panics since it can't find a file system ● It seems the file system was not loaded to the right address.

14. Mounting the file system ● After a research in kernel sources we found that it ignores the parameters passed by U-boot and uses a predefined address (from the kernel command line). ● Loaded the file system to that address. ● File system mounts but panics again (unable to find init). ● Recompiling, trying to pass init=/bin/sh did not help.

15. Running init ● Searching for help on the Internet did not help (first time in my life...) ● Contacting Philips and after a lot of effort (since they officially do not support Linux) we found a contact person in China... ● He looked at our kernel configuration and found that we did not include support for flat binaries, no one told us to do so... ● Added support for flat binaries and... ● Let there be light...

16. Is our work done? ● Our work is far from being done, we ran uClinux on an evaluation board only ● Hardware guys never build a similar board... ● We need to modify U-boot for our new board ● Board specific code is coded in ARM assembly so we had to learn ARM assembly.

17. Re-running Linux ● After U-boot modifications are done and working. ● Trying to run Linux... ● No success again. ● Maybe we need to change Linux startup code? ● Yes, we do need to change Linux startup code to fit our hardware. ● No success, Linux is not running.

18. Returning to evaluation board ● Retrying to run on evaluation board... ● No success... ● We should minimize our changes in Linux code... ● Ok, it runs but it is unstable... ● Took us about 3 weeks to find out a minor change in Linux configuration (ARM clock).

19. Running on our board ● Redoing the changes to run on our board ● Kernel runs but unable to mount file system. ● It seems it does not have enough memory ● Customer decided Running Linux is important enough and increased memory to 4Mb ● This has done the job: Linux is finally running and the file system mounts.

20. Summary ● This talk contains only the highlights, we had much more problems, some of them our our mistakes. ● What do we learn from this? – Nothing is as easy as it looks. – Try to avoid changing the Linux kernel, the kernel programmers know what they are doing. – Do not attempt porting if you are not absolutely familiar with target architecture.