Re: [flashrom] Hardware Sequencing for ichspi.c

[Stefan Tauner]

On Thu, 26 May 2011 03:15:02 +0200
Stefan Tauner  wrote:
> == IMPLEMENTATION ==
> the very simple access model of hw seq is too simple for flashrom, or
> put in another way: flashrom is too sophisticated to integrate hw seq
> easily. in hw seq the target device is not a single flashchip from the
> flashchips table, but a contiguous address space which we can access by
> just setting an address, filling in the data (like in sw seq) and then
> committing the command by setting the read/write or erase mode and the
> go-flag in HSFC.

i successfully read out the 4kB descriptor region with hardware
sequencing today. of course i had to cheat a bit, but as proof of
concept i am quite pleased with this quick success :)

my first approach was to add a new spi programmer to ichspi and
register it in ich_init_spi:
    	extern struct flash_descriptor fdbar;
    	if (ichspi_lock || fdbar.NC != 0)
    		register_spi_programmer(&spi_programmer_ich_hwseq);
    	else {
    		register_spi_programmer(&spi_programmer_ich9);
    		ich_init_opcodes();
    	}

i then added a special device to flashchips.c which points to new
probe, read, write functions in ichspi.c (without solving the const
problem).

the probing just checks if the special spi programmer is the
current/registered one.

reading is currently done by a simple 4byte-reading loop which
certainly could be improved (and maybe refactored together with the
existing run_opcode methods (which should be refactored anyway imho)).

writing is not implemented yet... and i certainly wont test it on my
hardware. if someone with an ICH (>=9)/PCH and a good way to recover
wants to test it later please step forward.
best would be if there is already a descriptor available for that
board. else we would have a nice opportunity to enhance the
ich_descriptor_tool... not on my schedule though.

i discovered another minor problem: the programmer has to have the
generic spi programmer functions implemented, that is:
    int (*command)(unsigned int writecnt, unsigned int readcnt,
    	   const unsigned char *writearr, unsigned char *readarr);
    int (*multicommand)(struct spi_command *cmds);

this is (at least) needed to get correct probing output else you will
get something like:
Probing for Winbond W25Q80, 1024 kB: spi_send_command called, but SPI is unsupported on this hardware. Please report a bug at [e-mail]

i tried to circumvent this problem by adding a new chip bus type, but
it is not trivial (register_spi_programmer sets the bus to SPI
explicitly etc) and imho not worth it.

to sum up: i think the second problem can be considered solved, but the
first one namely the constant flashchip array needs a solution. i will
probably come up with a hack later when i try to add erase and write
functions.. and probably with new problems too (erase sizes etc...).
will keep you updated ofc.