[flashrom] [RFC] Address space alignment of flash

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed Jul 14 17:21:29 CEST 2010


with the pending support of multiple architectures for internal
flashing, we have to decide how to do flash mapping properly. Right now
we have a number of ad-hoc hacks, and some of them work only by
accident. Code snippets follow.

{ ...
base = flashbase ? flashbase : (0xffffffff - size + 1);
... }

{ ...
flash->virtual_registers = (chipaddr)programmer_map_flash_region("flash chip registers", (0xFFFFFFFF - 0x400000 - size + 1), size);
... }

flashbase is only set for the AMD Elan SC520, and it is completely
ignored for register mapping. Fortunately the SC520 supports no chips
which would need register mapping.

Some systems have bottom-aligned flash (fixed base address, variable end
address). The ICT Loongson 2F processor and the AMD Elan SC520 are
examples of that.
Other systems have top-aligned flash (variable base address, fixed end
address). Pretty much every x86 out there follows that model.

It gets worse. Some flash chips have no register space (easy to handle),
some have their register space 8 MB below content space (SST49LF040),
some have their register space 4 MB below content space, and AFAIK some
chips have their register space above content space.

And sometimes people may want to specify an alternative location for a
secondary flash chip (e.g. stacked/dual BIOS chips for LPC/FWH).

Throw in cases where flash addresses are memory mapped at the address
seen by the flash chip (most x86), memory mapped at an address different
from the one seen by the flash chip (gfxnvidia, drkaiser), or accessed
indirectly (nic3com etc.).

I propose to have two global variables (or two local variables with
global set/get functions):
flashbase and flashtop.
Exactly one of the variables has to be set by the programmer init
function, and the one being nonzero is used. For flash chips without
separate register space, no additional complexity is required.
For flash chips with register space, FEATURE_REGISTERMAP would be
replaced by FEATURE_REGISTER_4M_BELOW (a blanket change would probably
be correct for 95% of all chips) and complemented with
flashrom would refuse to handle chips with "below" register space on
bottom-aligned systems and refuse chips with "above" register space on
top-aligned systems (well, it could do something sensible, but I have no
idea what that would be).

gfxnvidia and drkaiser would use flashbase (unless flashtop makes more
sense there, but both programmers seem to support only non-register
flash anyway), and programmers with indirect access can use either
flashbase or flashtop depending on whether flash registers are above or
below flash contents.

This proposal breaks down once we want to support both register
locations in the same flashrom run (in that case we have to specify both
flashbase and flashtop), and it breaks down for systems where flash is
bottom-aligned at address zero (flashbase would be valid but zero). We
could add two additional variables flashbase_valid and flashtop_valid,
and pick the one we want based on FEATURE_REGISTER_*. That should work




More information about the flashrom mailing list