[coreboot] [PATCH] flashrom: clean up SPI probing, bus handling

Stefan Reinauer stepan at coresystems.de
Sun Jun 29 12:35:36 CEST 2008


Carl-Daniel Hailfinger wrote:
>> Yes, something along the line. Alongside with this I want to clean up
>> use of struct flashchip
>> for flashes[] but I would really like to get the current change in the
>> tree yet.
>>     
>
> I'm not a fan of committing code which will be changed shortly
> afterwards, but...
>   
Release early, release often, yes? ;-) I can keep this in our internal
repository for a while until it's ripened, but I fear it will decay if
it's only floating around as a patch and not in the repo (see Rudolf's
SPI patch, though that can still easily be applied for VIA systems)

>> struct flashchip {
>>        const char *vendor;
>>        const char *name;
>>        /* With 32bit manufacture_id and model_id we can cover IDs up to
>>         * (including) the 4th bank of JEDEC JEP106W Standard
>> Manufacturer's
>>         * Identification code.
>>         */
>>        uint32_t manufacture_id;
>>        uint32_t model_id;
>>
>>        int total_size;
>>        int page_size;
>>
>>        /* Indicate if flashrom has been tested with this flash chip
>> and if
>>         * everything worked correctly.
>>         */
>>        uint32_t tested;
>>
>>        int (*probe) (struct flashchip *flash);
>>        int (*erase) (struct flashchip *flash);
>>        int (*write) (struct flashchip *flash, uint8_t *buf);
>>        int (*read) (struct flashchip *flash, uint8_t *buf);
>>     
>
> Maybe change struct flashchip to struct flashchip_instance for the 4
> functions above?
>   
The parameter? Yes, of course.


>>        uint32_t compatible_busses;
>> }
>>
>>
>> //  now this is what flashes is going to be:
>> struct flashchip_instance {
>>        struct flashchip *flash;
>>
>>        flashbus_t bus;
>>          /* Some flash devices have an additional register space. */
>>        volatile uint8_t *virtual_memory;
>>        volatile uint8_t *virtual_registers;
>>
>>       unsigned long physical_memory;
>>     
>
> What does that struct member mean?
>
>   
physical address of the flash chip. we'll need that to determine where
to look for flash chips in our memory maps. The virtual addresses are
not sufficient

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866





More information about the coreboot mailing list