[flashrom] [RFC] Layout handling...

[Stefan Tauner]

On Sat, 17 Sep 2011 23:52:39 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:

> As a followup to the layout usage scenarios I'd like to suggest a
> structure for hardware restrictions.
> 
> struct chipaccess {
>     unsigned int start;
>     unsigned int len;
>     unsigned int perms;
> };
> 
> struct chipaccess chipaccess_flash[32];
> struct chipaccess chipaccess_controller[32];
> struct chipaccess chipaccess[32]; //merged

is using a list here an option? i.e. adding a struct chipaccess *next
to the struct?

> start and len should be self-explanatory. perms has two bits:
> WRITE_ALLOWED and READ_ALLOWED (preferably with a better name).

_EN or _ENABLE?
i'd prefer bit-fields (or two distinct variables) to store the perms
actually. why combine them in one variable?
an optional char* name would be nice, this could be used for layout
file writing later and UI.
and of course "unsigned int" is not specific enough.

> The chipaccess* arrays MUST (in the RFC 2119 sense of the word) cover
> the whole flash chip, holes are not allowed.

why? just define a default (probably RW) and be happy (or at least do
not have problems like you outlined below :)

> This presents a unique challenge for controller restrictions because
> those restrictions are detected before the flash chip is known. As such,
> it is not obvious how to store controller restrictions. One way would be
> to set chip size as maximum chip size supported by the controller and
> store the alignment direction (i.e. upper alignment in x86). The
> chipaccess array for the flash chip itself (chipaccess_flash) would be
> separate from the chipaccess array for the controller
> (chipaccess_controller) and after detection of the flash chip both would
> be merged into chipaccess, taking alignment direction into account.

what about overlapping regions? i guess you want to merge them. i dont
thank that is a good idea. they should be addressable separately.

my ich-based laptop uses normal regions and one PR:
0x54: 0x00000000 (FREG0: Flash Descriptor)
0x00000000-0x00000fff is read-only
0x58: 0x07ff0500 (FREG1: BIOS)
0x00500000-0x007fffff is read-write
0x5C: 0x04ff0003 (FREG2: Management Engine)
0x00003000-0x004fffff is locked
0x60: 0x00020001 (FREG3: Gigabit Ethernet)
0x00001000-0x00002fff is read-write
0x64: 0x00000fff (FREG4: Platform Data)
Platform Data region is unused.
0x74: 0x9fff07d0 (PR0)
0x007d0000-0x01ffffff is read-only

PR0 seems to be some kind of boot block protection or so... it starts
in the middle of the bios region and spans till the end of the
universe^Hflash chip. i would still like to be able to read the whole
bios region, but without the rest of the chip (in the case the bios
region would be r/o too).
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner