Issues
ARM boot partition limitations (Beagle and Panda)
(We need to provide a complete list of requirements, and an example solution)
- The first partition must be of even size, and marked active.
- These boards need a special TI "MLO" loader in the first sector of the microSD to boot.
No persistent MAC address (Beagle and Panda)
The smsc95xx driver used on the Panda board currently generates a new random MAC address every time the interface is brought up. As a result, the board gets a new IP address on each boot from DHCP, and confuses dynamic DNS setups linked to DHCP.
(to be addressed using device tree; work in progress)
USB flash/network performance issue (Panda - smsc95xx)
If you connect storage to a Panda board USB port (flash or sata), you get about 5 MB/sec throughput. If you "ping -i 0.001" the Panda board from another host, you can increase the *storage* performance to 22 MB/sec.
Note: The Ethernet device is itself also on the same USB hub (on chip) as the device storage.
kernel 2.6.38 was experiencing random hangs on Panda boards.
This was related to a power regulator issue. (fixed by applying a patch from kernel-2.6.39)
Using 1-GB memory on the Panda board
(kernel config, other changes, TI video blob issues?)
- to enable support in the kernel, configure:
CONFIG_HIGHMEM=y CONFIG_BOUNCE=y CONFIG_MMC_SPI=m
To test this memory, as root run memtester, for example:
$ memtester 920M 1
If you run "memtester 1G" it tells you how much it can allocate and lock. Ctrl-C from that, subtract 30M or so from that amount, and run again. Otherwise, the OOM killer might strike during the testing.
Standard partitioning scheme for flash cards
There does not appear to be a standard partitioning scheme for flash cards used for Beagle and Panda boards (root, boot, swap, etc.)
Standard partitioning scheme for boot
There does not appear to be a standard partitioning scheme for locating the kernel for booting from flash (location for uImage and uInitrd, and associated U-Boot scripts and configuration files).