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

[Ulf Samuelsson]

On 2012-04-09 10:15, Wolfgang Denk wrote:
> Dear Andreas,
>
> In message<4F82835F.2030201 at googlemail.com>  you wrote:
>>> Where are these odd sizes like
>>>
>>>>   #define CONFIG_ENV_SIZE		0x4200
>>> coming from?  Has a size of 0x4200 any special maning on these
>>> systems?
>> please read Ulfs mail:
>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123862/focus=125897
> Thanks for the pointer.
>
>> I think it is OK to apply this patch.
> I did not intend to object against this patch; I just wonered about
> the odd numbers,
>
>> I think another point is that these Atmel devices became less important
>> than before in U-Boot (I see not really much users here even though a
>> lot of people use it):
>>   a) a lot of users favor the at91bootstrap SPL to boot linux (no need
>> for u-boot)

While AT91bootstrap supports booting linux, this is real minimal support.
Everything is hard-wired so for development it really sucks.
It is really only useful for production work.
I personally never used this capability.

This functionality is pretty new in AT91boostrap,
and the Atmel (non) presence in the mailing list is an older problem.

While I no longer work for Atmel, I have a feeling that the problem is 
as follows:

Users are using the Atmel version of U-Boot, not mainstream.
If not using the Atmel version, then they maybe using a build system
like OpenEmbedded where u-boot is built as a part of the build process
and people have very little incentive in modifying that part

There is very little incentive at Atmel to upgrade because
1. Patches provided by Atmel are ignored.
2. Patches are applied to mainline which keeps breaking the AT91 support.
3. All possible fixes to boot problem are rejected (discussion with 
Haavard).
4. It is considered more important to have a "clean" implementation, 
than a working implementation.
     (Choice of NOR Flash Driver)

Atmel does not want to continuously spend effort on unbreaking other 
peoples work.

Problems are not fixed in the mainline due to problem (1).
Instead the problems are fixed in the buildsystem and it is not considered
worthwhile to submit such fixes to the mailinglist.

The action by the project to "solve" the problem by removing the boards 
from
the MAKEALL scripts and also to remove BSPs is not encouraging.

There used to be a rule that patches should not break board support, but
that rule seems to have gone down the drains.

The Atmel code is (IIRC) based on 0.3.4 so it is very old, so an update 
is really needed
but before U-Boot becomes "developer-friendly", I doubt that will happen.
If the project wants to have Atmel "on-board", then fixing problem (1) 
is key.



> This could probably be changed if they were converted to using
> U-Boot's SPL mechanism instead - but then, I also realize that there
> is only very low interest for them.
>
>

I think you are right. Atmel wants control over this part.

>>   b) they have well-hung cores

Still plenty of ARM9 users out there, but a new core would be an obvious
way forward for the 2012 model AT91 application processors.
Don't see many reasons for updating the current SAM9Gx5 family.

"http://www.mscbp.hu/Documents/Atmel Q-Touch.pdf"
seems to hint at a Cortex-A5, but this document is from 2010,
so plans may have changed.

> Indeed.
>
> Best regards,
>
> Wolfgang Denk
>
-- 
Best Regards
Ulf Samuelsson
ulf at emagii.com