On Wed, Feb 29, 2012 at 01:50:18AM +0100, Ulf Samuelsson wrote :
- Std AT91bootstrap loads U-Boot from 0x8400 so your patch breaks 99% of all SAM9 boards.
Those boards are broken anyway !
No they are not. The partitioning gives you some hint on where to store the kernel, but you can store the kernel at any suitable address. you lose some conveniance, but thats all.
Storing U-boot at any other address than 0x8400, means that AT91bootstrap must be modified, and there is significant disadvantages in having two possible u-boot locations. if you have an at91bootstrap binary, will this use the old or new location? I fail to see any benefit in moving, so that
As u-boot is bigger than the load size of at91bootstrap (0x33900 by default). So, not changing means that you are screwed after flashing a new u-boot
IIRC, The latest bootstrap with Kconfig has configurable size. Changing size is OK, changing location is not.
Doesn't that mean that you then have to recompile/reflash at91bootstrap and so that the boards are broken using the latest ut-boot ? I couldn't get my board working with the stock at91bootstrap because it cannot load u-boot.
It has to be fixed or I don't see the point in keeping those configs. If we don't want to change the location, and I can understand the reasons why, then was my first patch ok ?
http://lists.denx.de/pipermail/u-boot/2012-January/114485.html
I'd like to see that fixed so that I could integrate it properly in buildroot...
If you want to grow U-Boot, then
bootstrap 0x00000000 ; 16 kB ubootenv 0x00004200 ; 16 kB - Should be plenty uboot 0x00008400 ; kernel 0x00063000 ; Why waste space...
What about the redundant env ? Why shouldn't we reorder u-boot and its env ?
Because it adds problems without any benefits. When I looked the last time, the environment is only 8 pages, So you can fit a redundant environment anyway in 16 kB+}