ke...@us... (Ken Yap) writes:
> >Ken posted a message about updates required to the drivers for the 5.1
> >branch for relocation. Can someone expand on the details for me? I am
> >developing the driver based on a cvs update pre Eric's directories
> >restructure. Is there something special that needs to be done for 5.1
> >because of relocation?
>
> Eric will correct my mistakes when he gets back but I believe the story
> is like this:
I am not quite back but this is a good question that need to get documented.
>
> Etherboot runs at virtual address 0x20000 upwards (see
> arch/i386/Makefile). However this actually corresponds to a physical
> address somewhere at the top of memory due to address translation.
>
> Within Etherboot itself there is no problem using the virtual addresses,
> memory references will come out ok.
>
> However when you give the address to hardware, say for DMA or something,
> you have to convert them to physical addresses or the hardware will try
> to access the wrong locations. The function virt_to_phys or virt_to_bus
> (same thing) will do this for you.
Only the same on x86. Other architectures may have a difference
bus and physical addresses. Though I can't see why they would.
Drivers should not need to use physical addressees.
virt_to_bus, and bus_to_virt, and ioremap are all drivers should need
to use.
> In some cases you have to call the reverse function phys_to_virt, when
> the hardware contains shared memory, e.g. WD8013 NICs, so that Etherboot
> will address the correct hardware address. Typically this is in places
> where you load address registers of the NIC.
I believe this is where you need ioremap. virt_to_bus should
only be valid for memory used in etherboot. bus_to_virt is simply
the inverse function of virt_to_bus. ioremap works on arbitrary
device shared memory. The e1000 and FA311 drivers have used ioremap.
Eric
|
