GNU/Linux on NXP ARM Processors
From Buici
Logic Product Development sells several develop development kits for Sharp ARM processors, the LH79520, the LH79524, the LH7A400 and the LH7A404. These processors combine an ARM7 or ARM9 core with sufficient peripherals to build complete systems with very little glue logic.
The Sharp Board Support Package includes the kernel patch described here as well as software to demonstrate the boards.
If you haven't already looked into it, the http://www.sharpsma.com/sma/Products/mcu_soc/Registration/Arm-Bluestreak-Library.htm Sharp website has many useful resources and links.
Updates
- 2007.10.09
- New patch for LH processors and Linux-2.6.22.
- 2006.04.06
- Mediawiki page created.
- 2006.02.23
- Wiki documentation merged for Sharp ARM cores on Linux.
- Linux kernel patch for 2.6.16-rc4 patch.
Kernel Patch
There is one patch for all of the LH processors. Eventually, all of this work will make it's way into the main kernel sources. For the time being, you can get it with the Sharp Board Support Package, or you can [[ftp://ftp.buici.com/pub/arm/patch-linux-2.6.22 download the latest patches.]]
LH79520
The 2.6 kernel series includes support for:
- Color LCD controller & several LogicPD CLCD panels
- Touch screen controller
- Audio codec
- CompactFlash
- SMC91x Ethernet controller
- NOR flash
There also exists a 2.4 kernel for the LH79520 with drivers for a couple of perhiperals not yet included in the 2.6 port. While the older kernel is not actively maintained, the Sharp Board Support Package does include a method for building it.
LH79524
The 2.6 kernel series includes support for:
- Color LCD controller & several LogicPD CLCD panels
- Touch screen controller
- Audio codec
- CompactFlash
- LH79524 core Ethernet controller
- NOR flash
- NAND flash
- USB device controller (UDC)
LH7A400
The 2.6 kernel series includes support for:
- Color LCD controller & several LogicPD CLCD panels
- Touch screen controller
- Audio codec
- CompactFlash
- SMC91x Ethernet controller
- NOR flash
LH7A404
The 2.6 kernel series includes support for:
- Color LCD controller & several LogicPD CLCD panels
- Touch screen controller
- Audio codec
- CompactFlash
- SMC91x Ethernet controller
- NOR flash
- USB host controller (OHCI)
- USB device controller (UDC)
Getting Started
The first thing to do is make sure that the CardEngine runs. The LogicPD SDKs ships with Logic's BOLO/LOLO loader in flash. The LPD7A400 SDK board I received had the JTAG jumpers both set to '-'. In this configuration, LOLO will configure it's console for 19200. Setting the jumpers to '+' which is the setting shown in the QuickStart Guide for the LPD7A400 makes LOLO configure the console for 115200 baud. Refer to the SDK documentation for how your CardEngine configures the console.
Connect a terminal to the serial port and configure it for the appropriate speed and without hardware handshaking. Attach the 5V power supply to the board. You should see something similar to the following. However, if you have an old LPD7A400 CPU board, you may need to press the wake-up button. And, you might want to contact Logic to get a more recent revision for the sake of development.
sharp a400
jumping to ea04000c @ 40000
x
sharp a400
*****************************************************************
LogicLoader
. Copyright 2002-2003, Logic Product Development, Inc.
All Rights Reserved.
Version 1.2.0
*****************************************************************
Available commands:
load - download a binary image of type 'elf', or 'srec'
burn - burns the already-loaded image into flash device 'device'
erase - erases 'device' from start_address for length bytes
jump - jump to a loaded image, or [address]
exec - disable cache & ints, then jump to a loaded OS, or to [addr]
source - execute a series of losh commands stored in <filename>
w - write memory [of specified width] at addr
x - examine memory with [width][format] at an addr for a [len]
date - display the number of seconds since boot
info - print information about: version, arch, mem, net, cpu
help - print help for a single command or a group of commands.
losh>
Congratulations, you've verified that the CardEngine boots from flash.
JTAG and Abatron's BDI 2000
Rule of thumb: money spent on high-quality tools gives an excellent return on investment. Abatron, a Swiss company, sells one of the best JTAG emulators on the market, but it is expensive. It can be controlled by telnet as well as through GDB. It can be scripted by writing GDB macros to automate testing and development. Most developers won't need anthing this sophisticated, but it is wise to have some sort of JTAG adapter available in case you clobber the boot loader and cannot recover.
BDI2000 configuration files for the various LPD boards are available on this FTP server. These configurations enable flash programming by setting the appropriate VPEN control bit in the CPLD for each target board.
For JTAG operation, The CardEngines require that TEST jumpers be properly set. The LPD7A400 SDK boards control this with the J6-2.4.6 jumper. Setting it to '-' grounds TEST1, enabling JTAG. Leave J6-1.3.5 at the '+' setting. Refer to your specific documentation for the right setting for your board.
For people with old CPU boards (LPD7A400's) that require you to press wake-up after a reset, the following recipe appears to reliably gain control of the CPU after a reset. Abatron support could not explain why this works.
- Configure BDI2000 to STARTUP RUN and RESET NONE. Reboot BDI2000.
- Press CPU reset button.
- Enter HALT command at BDI2000 prompt.
- Press CPU wakeup button.
Building an ARM Cross-compiling Toolchain
In short, use crosstool. You can download my old crosstool scripts as well as a script for invoking the compiler. Or, you can use the Sharp Board Support Package which has prebuilt toolchains.
The APEX Boot Loader
BLOB is superceeded by the Apex Bootloader. There have been many complaints that BLOB is difficult to build, to modify, and to understand. APEX was written from scratch and is designed to be easier and smaller than BLOB. It has all of the features of BLOB with many features that BLOB doesn't support.
Flash Memory Layout
| CardEngine | Erase Block | Total Flash |
|---|---|---|
| lpd79520 | 64 KiB | 8 MiB |
| lpd79524 | 64 KiB | 16 MiB |
| lpd7a400 | 256 KiB (128*2) | 16 MiB |
| lpd7a404 | 256 KiB (128*2) | 16 MiB |
The BLOB booted systems had a memory map that was built into the boot loader. APEX eliminates this hard-coding. Instead, it uses an environment with default settings to move data from flash into RAM.
The LPD7a40x is implemented with two 16 bit Intel Strata flash parts in parallel for a 32 bit data bus. This means that the erase block size is 256KiB instead of 128KiB. BLOB organizes flash on these parts as follows.
0x00000000 256 KiB BLOB bootloader 0x00040000 256 KiB BLOB parameters 0x00080000 1.5 MiB kernel 0x00200000 14 MiB root filesystem
While it isn't efficient, it does allow for each partition to be erased and rewritten without clobbering the others.
Linux Kernel 2.6.x
Not all kernel patches have made their way into the kernel source archives. Some features will never be included, for example, the IDE driver for CompactFlash must be applied.
The latest kernel patche is available by ftp, ftp://ftp.buici.com/pub/arm/patch-linux-2.6.16.
This kernel can boot to either a JFFS2 image in flash, an NFS root using kernel IP autoconfiguration, or a root filesystem in CompactFlash.
BTW, the build system for linux-2.6 rocks.
Flash Filesystem as Rootfs
The on-board flash is 16MiB, 2MiB taken by the bootloader and the Linux kernel. The remaining 14MiB is available as a root filesystem. A basic root filesystem spans about 10MiB as a JFFS2 filesystem. Make sure to specify a 256KiB erase size when creating your JFFS2 filesystem.
Given a directory ./root that contains the desired root filesystem, use mkfs.jffs2 to build an image that may be written to flash.
mkfs.jffs2 -e 262144 -r root -o root.jffs2
At version 1.19, mkfs.jffs2 does not honor hard links. This will be a problem if you depend on hard links (think busybox) to reduce the disk usage of your filesystem. Symbolic links are a satisfactory substitute for the time being.
Then, write it to the flash at address 0x00200000. When booting, specify the fourth mtd partition as well as the filesystem type.
This is someone inaccurate as the partitions must be specified on the command line as well.
apex> boot console=ttyAM1 root=/dev/mtdblock3 rootfstype=jffs2
NFS Root Performance
Using NFS as a root filesystem may pose a couple of challenges. There has been some mailing list traffic about poor performance at kernel version 2.6.5 when compared to version 2.4.x. There may also performance implications under high NFS loads.
There seems to be some concern that NFS performance has degraded in the 2.6.x kernels. The maintainer believes that this is bunk and that the main reason for poor NFS performance is the unreliability of UDP. My timing tests show that UDP is faster than TCP by about 7%--not much. On a busy network, it is possible that packet loss will degrade UDP performance than TCP. It may also necesasry to isolate the development network from the rest of the LAN.
By default, NFS root mounts protocol 2 over UDP. You can change this by using the 'nfsroot=' kernel parameter. Refer to Documentation/nfsroot.txt for more details. A command line to use TCP and protocol three might look something like this:
apex> boot console=ttyAM1 root=/dev/nfs ip=rarp nfsroot=192.168.1.1:/tftpboot/192.168.1.2,v3,tcp
High NFS loads pose a different sort of problem. Heavy filesystem traffic may fill system RAM with IO cache buffers. Once full, the VM subsystem may elect to unmap code pages such as those of your application. With an NFS root this situation may be particularly troublesome since the pressure on the buffer cache will be persistent. You can change the tendency of the system to release mapped pages by setting a /proc/sys parameter.
echo 0 > /proc/sys/vm/swappiness
The default value is 60. A value of zero means (in kernel 2.6.5) that the VM subsystem won't free mapped pages until half RAM is in use as mapped pages.
MTD Driver/Partitions
The kernel MTD driver allows partitions to be specified on the command line. The best place to find documentation on this command line option is in the kernel documentation. For example, this message on the mailing list.
In a nutshell, the command looks something like this:
mtdparts=phys_mapped_flash:512k(boot)ro,1536k(kernel),-(root)
According to Ezban Robertson, this has changed to the following: mtdparts=physmap-flash.0:512k(boot)ro,1536k(kernel),-(root)
In this example, the first 2 MiB of flash are reserved for boot code, the loader, loader parameters, and the kernel. The rest of flash is allocated to the root partition which might be a JFFS2 filesystem.
At runtime, the MTD driver requires device notes to access the flash partitions. You may need to create them
mknod /dev/mtd0 c 90 0 mknod /dev/mtd1 c 90 1 mknod /dev/mtd2 c 90 2 mknod /dev/mtd3 c 90 3 mknod /dev/mtdblock0 b 31 0 mknod /dev/mtdblock1 b 31 1 mknod /dev/mtdblock2 b 31 2 mknod /dev/mtdblock3 b 31 3
From the target already running Linux, copying the kernel to the second partition would look like this:
dd if=zImage of=/dev/mtdblock1
Using CONFIG_ZBOOT_ROM
A compressed kernel can be executed directly from ROM without first copying it to RAM.
The head.S function that decompresses the kernel requires RAM buffers to execute. When the zImage is copied to RAM the code can make an educated guess about where to find RAM. When running from ROM it must be told where to locate its buffers.
Once the kernel is configured for ZBOOT_ROM it must be executed at the specified TEXT address.
CONFIG_ZBOOT_ROM=y CONFIG_ZBOOT_ROM_TEXT=0x00080000 CONFIG_ZBOOT_ROM_BSS=0xc0200000
The TEXT option describes the base of the zImage in ROM. It tells the decompressor where to find the GOT which it will relocate to RAM. The BSS option describes a piece of RAM at least 64KiB long to be used for decompression buffers. It must not be in the region of memory where the decompressed kernel will reside. It can be put in internal SRAM but that may be slower than SDRAM.
Disabling Console Blanking
If you've booted your system using a CLCD console, you may want to disabled console blanking. To do this, you need to send the sequence
ESC[9;0]
to the console. You can do this with echo
echo -e '\033[9;0]' > /dev/ttyy
or something similar from a C program.
--Elf 15:33, 6 April 2006 (PDT)
