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
_______________________________________________
support mailing list
[email protected]
https://lists.openmoko.org/mailman/listinfo/support
