[FSO] milestone V on GTA01 - U-Boot updates

[Rask Ingemann Lambertsen]

On Tue, Apr 07, 2009 at 09:42:44PM +0200, Peter Rasmussen wrote:
> Too bad, but it raises some questions:
> 
> 1.Is it only the GTA01 you don't have a debug board for?

   The only debug board sold to the general public works on both GTA01 and
GTA02.

> 2.Otherwise, how can you at all develop for it,

   You don't need a debug board to develop on a Neo. Since I have Debian
installed, I just installed the usual packages such as GCC, binutils, make
and such.

> because that must mean that all your development must be made without any testing?

   What makes you think I don't test my changes?

   In the particular case of loading the kernel, failure won't be subtle
because the CRC check will fail. The uImage.bin that I normally use ended up
about 4.5 GB into the card, so U-Boot loaded the wrong blocks, causing the
kernel to not pass the CRC check. With the patch, the kernel passes the CRC
check.

> 3.Or do you have some tricks that are unknown to the rest of us?

   It helps a little to read the Debian installer script. It shows how to
edit the U-Boot environment from a running system (fso-utils) as well as how
to read/erase/write the NAND flash (mtd-utils).

> 4.I have never understood why it should be possible to brick the Neo1973 for any reason, because if you have prepared at least one 'safe' entry point you should always be able to at least get to that. Or what is the problem?

   On the GTA01, the the debug board _is_ that safe entry point. I have once
managed to corrupt NAND flash U-Boot[1], but just used NOR flash U-Boot to
get going again. GTA01 doesn't have the NOR flash to get you out of trouble.

[1] I tried to flash U-Boot directly with flash_eraseall and nand_write, but
I must have flashed the wrong file, because the display was corrupted when I
tried to run the new U-Boot.

> 5.Then, I would like to know what exactly your new uboot does, as it must be more than just being able to boot from a +4GB positioned partition?

   No, I just modified the code path in the glamo-mmc driver slightly such
that if loading from an SDHC card, the block numbers passed to mmc_bread()
are kept as block numbers all the way to the card, thereby eliminating the
overflow that would happen when converting the block number to a byte offset
(and back to block number since that's what SDHC cards use). A 32-bit byte
offset can address at most 4 GB, hence the need to keep the block number
until the type of card is known.

> Ad.5 I would hope that it would be able to boot from a selectable set of kernels, that would then be able to continue booting a selectable set of root partitions? Can you please elaborate?

   What I use isn't all that special. I simply cleaned up my U-Boot
environment somewhat from the default, then added two new entries. These are
the non-default lines:

bootargs_base=console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
bootcmd=setenv bootargs ${bootargs_base} ${mtdparts} rootfstype=jffs2 root=/dev/mtdblock6; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000
bootdelay=1
menu_1=Boot from microSD (part1 FAT+part2): setenv bootargs ${bootargs_base} ${mtdparts} root=/dev/mmcblk0p2 rootdelay=0 ro; mmcinit; fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000
menu_2=Boot from microSD (part2 EXT2): setenv bootargs ${bootargs_base} ${mtdparts} root=/dev/mmcblk0p2 rootdelay=0 ro; mmcinit; ext2load mmc 1:2 0x32000000 ${sd_image_name}; bootm 0x32000000
menu_3=Boot from microSD (part3 EXT2): setenv bootargs ${bootargs_base} ${mtdparts} root=/dev/mmcblk0p3 rootdelay=0 ro; mmcinit; ext2load mmc 1:3 0x32000000 ${sd_image_name}; bootm 0x32000000

   There's no need to specify rootfstype for SD cards, so I moved
'rootfstype=jffs2' out of boot_args base, which in turn means the
'rootfstype=ext2' band-aid could be removed. Menu_1 keeps the default
kernel+rootfs setup while menu_2 and menu_3 allows me to boot with the
kernel on the rootfs for partitions two and three.

   Additionally I added this so U-Boot doesn't just boot from flash ROM when
unattended:

stop_in_menu=yes

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year