[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