Hi,
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.
probe_flash() { ... base = flashbase ? flashbase : (0xffffffff - size + 1); ... }
map_flash_registers() { ... 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 FEATURE_REGISTER_8M_BELOW and FEATURE_REGISTER_xM_ABOVE. 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 everywhere.
Comments?
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger