[U-Boot] [PATCH v3] AT91SAM9*: Change kernel address in dataflash to match u-boot's size

[Ulf Samuelsson]

28 feb 2012 kl. 23:57 skrev Alexandre Belloni <alexandre.belloni at piout.net>:

> On Mon, Feb 27, 2012 at 04:25:02PM +0100, Ulf Samuelsson wrote :
>> On 2012-02-20 17:40, Alexandre Belloni wrote:
>>> On at91sam platforms, u-boot grew larger than the allocated size in
>>> dataflash, the layout was:
>>> bootstrap  0x00000000
>>> ubootenv   0x00004200
>>> uboot      0x00008400
>>> kernel     0x00042000
>>> 
>>> u-boot with the defconfig doesn't seem to fit in 0x42000 - 0x8400 =
>>> 0x39C00 bytes anymore.
>>> 
>>> Now, the layout is:
>>> bootstrap  0x00000000
>>> uboot      0x00004000
>>> ubootenv   0x00084000
>>> ubootenv2  0x00088000
>>> kernel     0x0008C000
>>> 
>> 
>> 
>> NAK!
>> 
>> 1. You need to be aware of the page size of dataflashes.
>>    Each page is 1056 bytes, not 1024 bytes.
>>    Your patch will make the U-Boot image start in the middle of a page.
> 
> Ok, I couldn't find a clear spec on that dataflash...

maybe you should have tried to look at the Atmel homepage...

> 
>> 2. 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.




>> 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+}


> 
> Regards,
> 
> -- 
> Alexandre Belloni


Best Regards
Ulf Samuelsson
ulf at emagii.com