[flashrom] [PATCH v2] serprog: Fix FWH/LPC by implementing serprog_map

Urja Rannikko urjaman at gmail.com
Mon Jun 29 12:46:00 CEST 2015


On Mon, Jun 29, 2015 at 2:38 AM, Stefan Tauner
<stefan.tauner at alumni.tuwien.ac.at> wrote:
> On Sun, 8 Mar 2015 07:54:11 +0000
> Urja Rannikko <urjaman at gmail.com> wrote:
>
>> also make serprog_map report if mapping doesnt fit
>> in the 24-bit address space of serprog.
>>
>
> Hi,
>
> what exactly happens without this fake mapping? I think I don't
> completely understand how non-spi serprog handles chip addresses...

For parallel it was essentially that address bits past the chip size
wouldnt be connected in hardware since chips dont have(/look at) more
address lines than their size. So the chip would always be addressed and the
address space would be as many mirrors of the chip as would fit (in 24bit/16M).

For LPC/FWH they have a real 32/28-bit address space, within
which the chip will natively be mapped to the highest addresses (at 4G
- chip size)
 - below which they can have lock regs etc.
The serprog (libfrser) LPC/FWH maps the 24-bit address
space to the highest 16M of the 4G space since thats where the chips are.
If you used the null mapping and tried to access eg addr 0 of 512k LPC
chip, it'd
try to access 0xFF000000 instead of 4G - 512k = 0xFFF80000.
The chip would just ignore the accesses since that isnt the address it
listens to.
Also, the lock regs would get the same null mapping and nope.

Essentially this is a bug in the original serprog because the
mapping just wasnt thought about at the time (worked without).

I think it is also a bug of fallback_map in returning NULL always
- that does the lock regs and chip at same address so it just cant
work for all things,
but I'm not sure if some programmer relies on that by now,
and serprog has an use for a map function: reporting about the attempted
mappings if they're outside the 24bit space it has.

>
> BTW the documentation on non-spi stuff especially the opbuf handling in
> Documentation/serprog-protocol.txt has some room for improvements ;)
I'll look at this later.

-- 
Urja Rannikko




More information about the flashrom mailing list