Auf 04.02.2011 10:23, Carl-Daniel Hailfinger schrieb:
> Auf 04.02.2011 11:01, Michael Karcher schrieb:
>
>> Am Freitag, den 04.02.2011, 02:35 +0100 schrieb Carl-Daniel Hailfinger:
>>
>>
>>> + /* Get I/O BAR location. */
>>> + tmp = pci_read_long(pcidev_dev, PCI_BASE_ADDRESS_2) &
>>> + PCI_BASE_ADDRESS_IO_MASK;
>>> + /* Truncate to reachable range.
>>> + * FIXME: Check if the I/O BAR is actually reachable.
>>> + * This is an arch specific check.
>>> + */
>>> + mv_iobar = tmp & 0xffff;
>>>
>>>
>> [...]
>>
>>
>>> +/* BAR2 (MEM) can map NVRAM and flash. We set it to flash in the init
>>> function.
>>> + * If BAR2 is disabled, it still can be accessed indirectly via BAR1 (I/O).
>>> + * This code only supports indirect accesses for now.
>>> + */
>>> +
>>> +/* Indirect access to via the I/O BAR1. */
>>> +static void satamv_indirect_chip_writeb(uint8_t val, chipaddr addr)
>>> +{
>>> + /* 0x80000000 selects BAR2 for remapping. */
>>> + OUTL(((uint32_t)addr | 0x80000000) & 0xfffffffc, mv_iobar);
>>> + OUTB(val, mv_iobar + 0x80 + (addr & 0x3));
>>> +}
>>>
>>>
>> Do we need to call the I/O address region "BAR1" if its address is
>> stored at PCI_BASE_ADDRESS2? That sounds confusing.
>>
>>
> Ah yes, that's a good question. BAR0 (MEM) is a 64-bit BAR, so it
> occupies the BAR0 and BAR1 slots in PCI config space. BAR1 (I/O)
> occupies the next slot (BAR2), and BAR2 (MEM) is 64-bit again and
> occupies the BAR3 and BAR4 slots. The datasheet just calls them BAR0,
> BAR1, BAR2 and that's what I mirrored in my code to make comparisons
> between code and datasheet and lspci output easier.
>
> Should I just add my explanation above as comment to the file?
>
I still have to add a man page entry for this, and could include my
explanation above in the satamv.c file to make things clearer. Would
that be OK with you?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
_______________________________________________
flashrom mailing list
[email protected]
http://www.flashrom.org/mailman/listinfo/flashrom
