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

Ulf Samuelsson
2012-02-29T00:50:18Z

28 feb 2012 kl. 23:57 skrev Alexandre Belloni <alexandre.belloni@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