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

[Ulf Samuelsson]

On 2012-02-29 09:58, Alexandre Belloni wrote:
> On Wed, Feb 29, 2012 at 01:50:18AM +0100, Ulf Samuelsson wrote :
>>> SIZE
>>>> 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.
>>
>>
> 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.
>
The size of the image loaded by at91bootstrap
can be configured by the user using KConfig.

The load address cannot be changed in KConfig
For this, you have to modify the source code - bad idea.

I think it would be good, if the u-boot image contained its own size 
somewhere.
(Maybe it does already) marked with some magic key, so that the size can be
determined during run time.

I don't like the idea to move the environment as the default.
There are people that try to fit the complete kernel + file system
into a single 8 MB dataflash and you are using way too much space
for U-Boot.  If you want to have environment in the high memory,
then this should be an option, and not enabled by default.

Also, you are putting the environment into the same block as the kernel.

 From the datasheet:
"Each page within a sector must be updated/rewritten at least once 
within every
10,000 cumulative page erase/program operations in that sector."

So updating the environment, may corrupt the kernel.

With a large environment = 32 kB this will happen 4 times faster
than with an 8 kB environement.
I.E: instead of within every 1250 "saveenv", it must happen
within every 312 "saveenv" which is "danger close".

The environment should thus be as small as acceptable.-

To avoid the problem fully, you have to allocate a 256 KB sector for 
each environment,
which means that U-Boot will use 1 MB. Maybe a single 256 kB sector will do.
This will cause a significant addition to programming time and is real 
wasteful
in terms of memory-

Better to localize the problem and put the 2 x 8 kB environment and 
U-Boot in the first sector
with U-Boot overlapping into the second sector.
This will allow people to choose exactly where the kernel starts.

The kernel should start at sector 3 (page 512) = 0x84000 to avoid
problems, if you keep reprogramming u-boot.
Sector 0 = 8 kB, 1 = 248 kB, 2 = 256 kB (with 1 kB = 1056 bytes in this 
case)

People which wants to optimize memory can then still put the kernel at a 
lower location.

Did not study the size issue, fully, but I would not be surprised if you
could, by removing features, still fit u-boot within sector 1, so moving 
"kernel" to
0x84000 should be an option, enabled in those configs, which do result in
growing beyond 0x42000.


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


-- 
Best Regards
Ulf Samuelsson