[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Andreas Pretzsch]

In a nit-picking moment trying to save some flash storage, I looked at
the current typical flash layout of U-Boot and came up with below RFC.

Before I start to implement anything, I'd like to hear your comments
about this, especially from the architecture maintainers. Given that you
have some spare time to look into this, of course.
Sorry in case this was discussed before, did only a coarse list archive
search.

I'd volunteer to provide an implementation for the architectures I have
close at hand today (Blackfin, ARM11), as time permits. For other
architectures, I'd need some assistance.


Abstract
--------

Approach to utilize flashes with different block sizes to reduce U-Boot
flash footprint.
In general only relevant for boards with environment in flash.


Prerequisites
-------------

Quite a few NOR flashes are divided into different block sizes.
For example, the widespread Intel/Numonyx/Micron P30 series is divided
into 4 blocks of 32 kByte, followed by n blocks of 128 kByte. Depending
on variant, the smaller blocks are the first blocks (bottom) or the last
blocks (top). The bottom variant is more common, as it allows flexible
total sizes without a change in the location of the small blocks.

Given a not uncommon U-Boot size of around 128kB (+/- a few 10kB),
accompanied by a separate flash block for a configurable environment, it
would make sense to make use of this layout.

All below statements are focused on NOR flashes like above, with
environment in flash. Also things like standalone applications,
out-of-binary graphics data, etc. are not taken into account.
Hence this RFC, as I probably miss some requirements and/or problems.


Flash layouts
-------------

Current best-case layout:
 32kB U-Boot
 32kB U-Boot
 32kB U-Boot
 32kB U-Boot
128kB U-Boot environment
=> 256kB flash used

Current worst-case layout:
 32kB U-Boot
 32kB U-Boot
 32kB U-Boot
 32kB U-Boot
128kB U-Boot (given U-Boot is >128kB)
128kB U-Boot environment
128kB optional: VPD
=> 384kB to 512kB flash used

Suggested layout:
 32kB U-Boot environment
 32kB U-Boot or optional VPD
 32kB U-Boot
 32kB U-Boot
128kB U-Boot
=> 256kB flash used with 192kB/224kB room for U-Boot

VPD: Vital Product Data (board type, MAC addresses, serial number,
licenses, certificates, etc.), which are not to be (solely) saved in
U-Boot environment, for whatever reason.


Current status
--------------

A quick grep indicates that most, if not all boards locate U-Boot at the
start of the flash.

The U-Boot environment is written to the start of the configured flash
block. Prior to that, this block is erased, its content is lost.


Possible approach
-----------------

Most CPUs start execution at flash address 0 or somewhere in this region
at the reset ISR vector.

In case U-Boot is not located there but some flash sectors later, at
this reset vector there has to be some architecture specific code block,
which could be a
  - simple jump to U-Boot entry
  - dummy ISR table with reset vector pointing to U-Boot
  - specific trampoline code
  - ...

In other words, a few bytes (up to e.g. 1kB) of (static) binary data,
generated at compile time.

This has to be put before the environment, either implicit or included
at the start of "struct environment_s".
The latter would of course break backward compatibility, at least
without some additional code.

The variant of including this code into a specific block would again
waste a flash block resp. mandate the presence of a VPD or similar.


Things to define / check
------------------------

  - U-Boot entry point on non-PIC builds
    (U-Boot start != CONFIG_SYS_FLASH_BASE)
  - U-Boot on architectures not capable of a single jump forward
    by e.g. 32kB or 64kB
  - redundant environment
  - mixed flash/external environment
  - ...


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Albert ARIBAUD]

Hi Andreas,

Le 27/09/2010 07:15, Andreas Pretzsch a ?crit :
> In a nit-picking moment trying to save some flash storage, I looked at
> the current typical flash layout of U-Boot and came up with below RFC.
>
> Before I start to implement anything, I'd like to hear your comments
> about this, especially from the architecture maintainers. Given that you
> have some spare time to look into this, of course.
> Sorry in case this was discussed before, did only a coarse list archive
> search.
>
> I'd volunteer to provide an implementation for the architectures I have
> close at hand today (Blackfin, ARM11), as time permits. For other
> architectures, I'd need some assistance.

I am willing to provide some assistance, as I recently posted (then 
withdrew in order to take Heiko's reloc patches into account) a patch 
that would maximize use of the topmost flash block for systems that boot 
at a high address yet fat from the topmost address.

Find my comments interspersed with your RFC.

> Abstract
> --------
>
> Approach to utilize flashes with different block sizes to reduce U-Boot
> flash footprint.
> In general only relevant for boards with environment in flash.
>
>
> Prerequisites
> -------------
>
> Quite a few NOR flashes are divided into different block sizes.
> For example, the widespread Intel/Numonyx/Micron P30 series is divided
> into 4 blocks of 32 kByte, followed by n blocks of 128 kByte. Depending
> on variant, the smaller blocks are the first blocks (bottom) or the last
> blocks (top). The bottom variant is more common, as it allows flexible
> total sizes without a change in the location of the small blocks.

This is considering about a single case of FLASH block layout. On my 
systems, I have two cases, a 29LV400 with 1x16, 2x8, 1x32, 7x64 KB 
layout; and a uniform Spansion s29gl with 64 KB sectors -- and even the 
uniform case could handle some optimizing.

> Given a not uncommon U-Boot size of around 128kB (+/- a few 10kB),
> accompanied by a separate flash block for a configurable environment, it
> would make sense to make use of this layout.
>
> All below statements are focused on NOR flashes like above, with
> environment in flash. Also things like standalone applications,
> out-of-binary graphics data, etc. are not taken into account.
> Hence this RFC, as I probably miss some requirements and/or problems.
>
>
> Flash layouts
> -------------
>
> Current best-case layout:
>   32kB U-Boot
>   32kB U-Boot
>   32kB U-Boot
>   32kB U-Boot
> 128kB U-Boot environment
> =>  256kB flash used
>
> Current worst-case layout:
>   32kB U-Boot
>   32kB U-Boot
>   32kB U-Boot
>   32kB U-Boot
> 128kB U-Boot (given U-Boot is>128kB)
> 128kB U-Boot environment
> 128kB optional: VPD
> =>  384kB to 512kB flash used
>
> Suggested layout:
>   32kB U-Boot environment
>   32kB U-Boot or optional VPD
>   32kB U-Boot
>   32kB U-Boot
> 128kB U-Boot
> =>  256kB flash used with 192kB/224kB room for U-Boot

This is actualy what is done by Lacie when using the 29LV400: they put 
the environment in one of the 8K sectors.

> VPD: Vital Product Data (board type, MAC addresses, serial number,
> licenses, certificates, etc.), which are not to be (solely) saved in
> U-Boot environment, for whatever reason.
>
>
> Current status
> --------------
>
> A quick grep indicates that most, if not all boards locate U-Boot at the
> start of the flash.

Not all, definitely -- the net5big has a big flash, yet places u-boot 
rather high (still, not high enough for me as it wastes 64 KB out of 512 
on my edmini, so I'd done a patch to use that, but it does not work with 
Heiko's reloc patches).

> The U-Boot environment is written to the start of the configured flash
> block. Prior to that, this block is erased, its content is lost.
>
>
> Possible approach
> -----------------
>
> Most CPUs start execution at flash address 0 or somewhere in this region
> at the reset ISR vector.

Hmm... Wrong for the two boards I use: they boot at 0xffff0000, with 
flash areas starting at fff80000 and ffc00000 respectively.  I suspect 
many ARM926 based boards boot to ffff0000 too.

> In case U-Boot is not located there but some flash sectors later, at
> this reset vector there has to be some architecture specific code block,
> which could be a
>    - simple jump to U-Boot entry
>    - dummy ISR table with reset vector pointing to U-Boot
>    - specific trampoline code
>    - ...

This point applies to the boards I use: they reset at ffff0000 but the 
u-boot code is never put there; instead, a small block of code does some 
checks then branches to fff90000, where u-boot's _start entry point resides.

> In other words, a few bytes (up to e.g. 1kB) of (static) binary data,
> generated at compile time.
>
> This has to be put before the environment, either implicit or included
> at the start of "struct environment_s".

This would work only for cases where booting is at the start of the 
flash. In my case, the small booting code is at the top, wasting 64 KB.

> The latter would of course break backward compatibility, at least
> without some additional code.
>
> The variant of including this code into a specific block would again
> waste a flash block resp. mandate the presence of a VPD or similar.
>
>
> Things to define / check
> ------------------------
>
>    - U-Boot entry point on non-PIC builds
>      (U-Boot start != CONFIG_SYS_FLASH_BASE)
>    - U-Boot on architectures not capable of a single jump forward
>      by e.g. 32kB or 64kB
>    - redundant environment
>    - mixed flash/external environment
>    - ...

The obvious issue in your design is that if there is a loss of power 
while the environment is written into, then the boot code runs the risk 
of being erased; making the board boot again properly will then require 
technical operations far beyond customer abilities if this board is used 
in production.

However I see a solution to your problem and mine in a single unified 
design.

My 'top 64KB' patch would work by putting the start of u-boot (the part 
that would run from flash) in the top 64 KB so that _sttart would end up 
exactly at ffff0000,  then putting the rest of the u-boot code below 
this, not touching the environment.

Now in your case, you want (unlike me) to have u-boot in the lowest 
possible area of a bootom boot FLASH.

Bottom boot flashes always have several smaller sectors which add up in 
size to a big sector so that big sectors are properly aligned. U-boot 
environment takes only one. So what if u-boot _start is located in the 
lowest sector along with some more of u-boot's code, then the 
environment in the next sector, the the rest of u-boot in susbequent ones?

That's where our designs could meet: define a set of configuration 
options which indicate where part 1 and part 2 of the u-boot code should 
go in FLASH. In my case part 1 would go to the upper 64 KB; in your 
case, it would go to the lower sector and size.

One important note: I don't mean to manually map code to these two parts 
at link time by fine-tuning the linker file as Wolfgang suggested, 
because I think this is pretty sensitive to any change in the code which 
would make the mapping over- or under-fill one area.

What I intend to do is build an u-boot which has its text+data in the 
usual single linear part (it could be linked for some RAM location), 
then split the .bin up into part 1 and 2, and flash each part in its own 
FLASH area. The startup code would fetch parts 1 and 2 and assemble them 
back in RAM.

This of course requires making the startup code really 
position-independent so that it could run from anywhere within the 
FLASH, and that it all resides in part 1.

The second point is what Heiko's patches made more difficult, because 
they full in much code for FLASH execution that was run from RAM before 
in arm926 systems.

Solving this will probably require that code and data intended for FLASH 
execution be marked with a specific attribute similar to the __init one 
in Linux; this attribute will put the code and data in separate sections 
(.text.flash and .data.flash, for instance) which the linker file would 
then output before the others (.text, .*data*).

Amicalement,
-- 
Albert.

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Albert ARIBAUD]

Le 27/09/2010 08:37, Albert ARIBAUD a ?crit :

> The second point is what Heiko's patches made more difficult, because
> they full in much code for FLASH execution that was run from RAM before
> in arm926 systems.

s/full/pull/

Apologies,
-- 
Albert.

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Wolfgang Denk]

Dear Andreas Pretzsch,

In message <1285564526.21734.187.camel@ws-apr.office.loc> you wrote:
> In a nit-picking moment trying to save some flash storage, I looked at
> the current typical flash layout of U-Boot and came up with below RFC.

Thanks.

> I'd volunteer to provide an implementation for the architectures I have
> close at hand today (Blackfin, ARM11), as time permits. For other
> architectures, I'd need some assistance.

You design a big and somewhat complicate solution for a problem which
does not exist, because it has already been solved more than a decase
ago, i. e. right with the very first versions of U-Boot (or PPCBoot, as
it was called by then).

We call this feature "embedded environment", and all what it takes to
use it oin a machine is a somehwat hand-crafted version of the linker
script which aligns the location of the environmentin the right
(small) flash sectors.

This works like a charm, and I recommend you have a look into this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
NOTE: The  Most  Fundamental  Particles  in  This  Product  Are  Held
Together  by  a  "Gluing" Force About Which Little is Currently Known
and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed.

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Andreas Pretzsch]

Am Montag, den 27.09.2010, 10:59 +0200 schrieb Wolfgang Denk:
> You design a big and somewhat complicate solution for a problem which

ACK. Had the linker approach also in mind, but didn't want to touch each
and every lds. But definitively the more elegant solution.

> does not exist, because it has already been solved more than a decase
> ago, i. e. right with the very first versions of U-Boot (or PPCBoot, as
> it was called by then).
> 
> We call this feature "embedded environment", and all what it takes to
> use it oin a machine is a somehwat hand-crafted version of the linker
> script which aligns the location of the environmentin the right
> (small) flash sectors.
> 
> This works like a charm, and I recommend you have a look into this.

Sigh. Big brown paper bag for me.

Solves exactly the "issue" I described and works perfectly. And is
documented very well in the README. As usual, things are already solved
in U-Boot. Thanks for the pointer.

Really had blinkers on, no idea why I didn't see it. Respectively, saw
it but somehow mixed it up with hardcoded, read-only environment.
Lession learned: Get some sleep before scribbling senseless RFCs.

Sorry for the noise, case closed.


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Andreas Pretzsch]

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.

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.

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.

Best regards,
  Andreas


Am Montag, den 27.09.2010, 08:37 +0200 schrieb Albert ARIBAUD:
> Hi Andreas,
> 
> Le 27/09/2010 07:15, Andreas Pretzsch a ?crit :
> > In a nit-picking moment trying to save some flash storage, I looked at
> > the current typical flash layout of U-Boot and came up with below RFC.
> >
> > Before I start to implement anything, I'd like to hear your comments
> > about this, especially from the architecture maintainers. Given that you
> > have some spare time to look into this, of course.
> > Sorry in case this was discussed before, did only a coarse list archive
> > search.
> >
> > I'd volunteer to provide an implementation for the architectures I have
> > close at hand today (Blackfin, ARM11), as time permits. For other
> > architectures, I'd need some assistance.
> 
> I am willing to provide some assistance, as I recently posted (then 
> withdrew in order to take Heiko's reloc patches into account) a patch 
> that would maximize use of the topmost flash block for systems that boot 
> at a high address yet fat from the topmost address.
> 
> Find my comments interspersed with your RFC.
> 
> > Abstract
> > --------
> >
> > Approach to utilize flashes with different block sizes to reduce U-Boot
> > flash footprint.
> > In general only relevant for boards with environment in flash.
> >
> >
> > Prerequisites
> > -------------
> >
> > Quite a few NOR flashes are divided into different block sizes.
> > For example, the widespread Intel/Numonyx/Micron P30 series is divided
> > into 4 blocks of 32 kByte, followed by n blocks of 128 kByte. Depending
> > on variant, the smaller blocks are the first blocks (bottom) or the last
> > blocks (top). The bottom variant is more common, as it allows flexible
> > total sizes without a change in the location of the small blocks.
> 
> This is considering about a single case of FLASH block layout. On my 
> systems, I have two cases, a 29LV400 with 1x16, 2x8, 1x32, 7x64 KB 
> layout; and a uniform Spansion s29gl with 64 KB sectors -- and even the 
> uniform case could handle some optimizing.
> 
> > Given a not uncommon U-Boot size of around 128kB (+/- a few 10kB),
> > accompanied by a separate flash block for a configurable environment, it
> > would make sense to make use of this layout.
> >
> > All below statements are focused on NOR flashes like above, with
> > environment in flash. Also things like standalone applications,
> > out-of-binary graphics data, etc. are not taken into account.
> > Hence this RFC, as I probably miss some requirements and/or problems.
> >
> >
> > Flash layouts
> > -------------
> >
> > Current best-case layout:
> >   32kB U-Boot
> >   32kB U-Boot
> >   32kB U-Boot
> >   32kB U-Boot
> > 128kB U-Boot environment
> > =>  256kB flash used
> >
> > Current worst-case layout:
> >   32kB U-Boot
> >   32kB U-Boot
> >   32kB U-Boot
> >   32kB U-Boot
> > 128kB U-Boot (given U-Boot is>128kB)
> > 128kB U-Boot environment
> > 128kB optional: VPD
> > =>  384kB to 512kB flash used
> >
> > Suggested layout:
> >   32kB U-Boot environment
> >   32kB U-Boot or optional VPD
> >   32kB U-Boot
> >   32kB U-Boot
> > 128kB U-Boot
> > =>  256kB flash used with 192kB/224kB room for U-Boot
> 
> This is actualy what is done by Lacie when using the 29LV400: they put 
> the environment in one of the 8K sectors.
> 
> > VPD: Vital Product Data (board type, MAC addresses, serial number,
> > licenses, certificates, etc.), which are not to be (solely) saved in
> > U-Boot environment, for whatever reason.
> >
> >
> > Current status
> > --------------
> >
> > A quick grep indicates that most, if not all boards locate U-Boot at the
> > start of the flash.
> 
> Not all, definitely -- the net5big has a big flash, yet places u-boot 
> rather high (still, not high enough for me as it wastes 64 KB out of 512 
> on my edmini, so I'd done a patch to use that, but it does not work with 
> Heiko's reloc patches).
> 
> > The U-Boot environment is written to the start of the configured flash
> > block. Prior to that, this block is erased, its content is lost.
> >
> >
> > Possible approach
> > -----------------
> >
> > Most CPUs start execution at flash address 0 or somewhere in this region
> > at the reset ISR vector.
> 
> Hmm... Wrong for the two boards I use: they boot at 0xffff0000, with 
> flash areas starting at fff80000 and ffc00000 respectively.  I suspect 
> many ARM926 based boards boot to ffff0000 too.
> 
> > In case U-Boot is not located there but some flash sectors later, at
> > this reset vector there has to be some architecture specific code block,
> > which could be a
> >    - simple jump to U-Boot entry
> >    - dummy ISR table with reset vector pointing to U-Boot
> >    - specific trampoline code
> >    - ...
> 
> This point applies to the boards I use: they reset at ffff0000 but the 
> u-boot code is never put there; instead, a small block of code does some 
> checks then branches to fff90000, where u-boot's _start entry point resides.
> 
> > In other words, a few bytes (up to e.g. 1kB) of (static) binary data,
> > generated at compile time.
> >
> > This has to be put before the environment, either implicit or included
> > at the start of "struct environment_s".
> 
> This would work only for cases where booting is at the start of the 
> flash. In my case, the small booting code is at the top, wasting 64 KB.
> 
> > The latter would of course break backward compatibility, at least
> > without some additional code.
> >
> > The variant of including this code into a specific block would again
> > waste a flash block resp. mandate the presence of a VPD or similar.
> >
> >
> > Things to define / check
> > ------------------------
> >
> >    - U-Boot entry point on non-PIC builds
> >      (U-Boot start != CONFIG_SYS_FLASH_BASE)
> >    - U-Boot on architectures not capable of a single jump forward
> >      by e.g. 32kB or 64kB
> >    - redundant environment
> >    - mixed flash/external environment
> >    - ...
> 
> The obvious issue in your design is that if there is a loss of power 
> while the environment is written into, then the boot code runs the risk 
> of being erased; making the board boot again properly will then require 
> technical operations far beyond customer abilities if this board is used 
> in production.
> 
> However I see a solution to your problem and mine in a single unified 
> design.
> 
> My 'top 64KB' patch would work by putting the start of u-boot (the part 
> that would run from flash) in the top 64 KB so that _sttart would end up 
> exactly at ffff0000,  then putting the rest of the u-boot code below 
> this, not touching the environment.
> 
> Now in your case, you want (unlike me) to have u-boot in the lowest 
> possible area of a bootom boot FLASH.
> 
> Bottom boot flashes always have several smaller sectors which add up in 
> size to a big sector so that big sectors are properly aligned. U-boot 
> environment takes only one. So what if u-boot _start is located in the 
> lowest sector along with some more of u-boot's code, then the 
> environment in the next sector, the the rest of u-boot in susbequent ones?
> 
> That's where our designs could meet: define a set of configuration 
> options which indicate where part 1 and part 2 of the u-boot code should 
> go in FLASH. In my case part 1 would go to the upper 64 KB; in your 
> case, it would go to the lower sector and size.
> 
> One important note: I don't mean to manually map code to these two parts 
> at link time by fine-tuning the linker file as Wolfgang suggested, 
> because I think this is pretty sensitive to any change in the code which 
> would make the mapping over- or under-fill one area.
> 
> What I intend to do is build an u-boot which has its text+data in the 
> usual single linear part (it could be linked for some RAM location), 
> then split the .bin up into part 1 and 2, and flash each part in its own 
> FLASH area. The startup code would fetch parts 1 and 2 and assemble them 
> back in RAM.
> 
> This of course requires making the startup code really 
> position-independent so that it could run from anywhere within the 
> FLASH, and that it all resides in part 1.
> 
> The second point is what Heiko's patches made more difficult, because 
> they full in much code for FLASH execution that was run from RAM before 
> in arm926 systems.
> 
> Solving this will probably require that code and data intended for FLASH 
> execution be marked with a specific attribute similar to the __init one 
> in Linux; this attribute will put the code and data in separate sections 
> (.text.flash and .data.flash, for instance) which the linker file would 
> then output before the others (.text, .*data*).
> 
> Amicalement,
> -- 
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] utilize flash small block sizes to reduce flash footprint

[Albert ARIBAUD]

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,
-- 
Albert.