[coreboot] [PATCH] flashrom: clean up SPI probing, bus handling
c-d.hailfinger.devel.2006 at gmx.net
Sun Jun 29 15:16:21 CEST 2008
On 29.06.2008 13:26, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> On 29.06.2008 12:35, Stefan Reinauer wrote:
>>> 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)
>> Actually, to give Rudolf the chance to adapt VIA chipset support in
>> flashrom to the new code I'd like to keep big commits away from ichspi.c
>> until VIA support is merged.
> I have his changes in my tree. If this is going in, I can commit his
> stuff right afterwards.
Do you have them integrated into ichspi.c? IIRC Rudolf wanted to merge
his ICH7/VT8237S code into ichspi.c, but the patch he sent had it as a
separate file due to time constraints.
>> I always thought that virtual_memory is exactly the location of the
>> flash chip in the memory map. If not, what's the point of virtual_memory?
> * virtual_memory is the flash chip mapped into the flashrom process'
> memory map. It's an arbitrary address valid for that one process.
> * physical_memory is the address on the "outside" memory bus of the cpu.
> that's where all the PCI bars live etc.
> Those are completely distinct address spaces, and usually nothing
> (except some memory chunks) from the physical address space is visible
> in the virtual address space. flashrom can not access the flashchip,
> unless it maps a piece of physical memory (0xfff00000-0xffffffff for
> example) to its virtual address space. That's why we need to mmap to
> actually see it. But the address we get from mmap does not have any
> descriptive character, it's a mere handle for us to access that physical
I thought we use mmap(,,,MAP_FIXED,,) which would have ensured
virtual_memory and physical_memory being identical. Looking at the
source it seems that I misremembered the actual mmap call, so your
statement makes a lot of sense and I agree with it.
Thanks for the explanation.
More information about the coreboot