On 06/24/2013 10:22 AM, Bo Shen wrote: > Hi Larry Baker, > > On 6/24/2013 16:02, Larry Baker wrote: >> I have found why the latest U-Boot does not work on my Glomation >> GESBC-9G20 board. Two causes: a bad code text segment address >> (prevents U-Boot from executing) and bad flash partition offsets >> (prevents U-Boot from reading its environment variables). The latter >> I assume is common, as the flash partition layout can vary. The >> former has to do with where the primary boot loader expects to find >> U-Boot's entry point. The primary boot loader comes from Atmel, I >> believe, and I assume does not change. Yet, the 2011.06 release of >> U-Boot changed that address. (FYI: the two immediately preceding >> releases, 2010.12 and 2011.03, fail to compile with configuration >> errors. There were definitely changes taking place during that time >> with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know >> who the authority on that question would be. If it is decided the >> U-Boot code text segment address is incorrect, it wold be nice to fix >> that in the upcoming release. (If there is time > .) > > For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, > the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the > text base, there is only 1MiB reserved for u-boot use. So, we move down > to let more space for u-boot. > > For the NAND partition, as to the u-boot grow bigger and bigger, so we > reserve more space for it. > > BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we > always keep the update bootstrap work with mainline u-boot properly.
... we really should force SPL for at91 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
