On 2012-04-09 10:15, Wolfgang Denk wrote:
Dear Andreas,
In message4F82835F.2030201@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