Le 27/09/2010 18:16, Andreas Pretzsch a écrit :
Dear Albert,
first, thanks for reading through my RFC. I agree that there are a couple of simplifications in there, e.g. reset vectors. Written after about 12 hours of hacking...
:)
I see you're struggling with a comparable, yet a bit more complicated issue. I have to admit that I only skimmed over the threads, but it looks to me that most of it could be done also with linkers help.
As I said, linker file tweaking can provide a non-perfectly-optimal solution (as you can hardly perfectly fill the sector which contains _start), for one specific system, i.e. one SoC model with one FLASH model, and a given configuration (i.e. set of object files to link together), but if you change either, or you change the configuration, there is a risk, however small, that the manual mapping become even more non-optimal by creating more unused space (one can live with that) or infeasible by overfilling the sector (and that is more problematic).
OTOH, the patch I'm envisioning would have the advantage of optimally filling all sectors used for code and data (except one obviously), working out-of-the-box over a large set of (ARM[926]) systems and configurations -- the location and size of the two .bin parts would be the only thing to adapt for each board, once and for all as long as the type of FLASH remains unchanged.
(I realize there is also a marginal advantage to the patch: as I said, it requires separating the code and data that is needed when running from FLASH from the one that is needed only when running from RAM. This could be further improved to copy from FLASH to RAM only what is needed for running from RAM. When u-boot is used to launch OSes, it won't make a difference ; when it launches standalone apps, that's a bit more RAM available to the apps. Not much, mind.)
Personally, I'm fine with a tuned linker file. Preparations are already there in U-Boot and the real life block allocation is pretty static, too. So following the KISS principle, I'd go with that approach.
I understand perfectly -- I'm all for everyone choosing the solution they see fit. :)
For the specific case of mixed-sector-size flashes with linear allocation (which is all the RFC was about in the first place), Wolfgang pointed to embedded environment resp. linker adaption. Which solves the issue perfectly. Therefore I see "my" case as closed and the RFC as redundant.
As time permits, I'll have a look at your points again later. But honestly, the stack on my desk piles up a bit too much right now... Sorry.
No problems. I'll post a patch anyway; reading your RFC simply made me aware that the patch should be more generic than it is right now, so as to cover your needs as I understand them. :)
Best regards, Andreas
Amicalement,