[ECOS] Bus space vs PCI space vs CPU space

[Chuck McManis <ecos at mcmanis dot com>]

Another evening, another confusment as my daughter would say.

So a few of the ethernet drivers (including the old Rhine driver) define a 
macro HAL_PCI_CPU_TO_BUS. The purpose of which is to map virtual addresses 
into physical addresses to pass to the chip. However in eCos on the x86 HAL 
that macro maps to basically (x) because there is a 1:1 relationship 
between physical and virtual addresses.

So here is the question, "Do you care?" or more specifically this driver 
I'm working on will be available to the eCos community at large but it is 
targeted at a very specific piece of hardware that pretty much only runs on 
a x86 system (unlike the Rhine driver which can run on different kinds of 
systems). So I'm wondering how much time and effort I should spend after 
this thing is running the way I need it to work on things like endianess 
and bus space macros, neither of which are an issue in the chips 'native' 
environment.

On the debugging front, i've discovered that I was smashing 
(unintentionally) some bytes into the ESA for the chip. By disabling all 
writes to those registers (I'll get to the root cause of why hardwire_esa 
is set in a bit) the chip comes up with the same MAC address in Redboot and 
in FreeBSD (which is a good sign). It still doesn't receive packets that 
aren't broadcast packets (rewriting the receive descriptor code, hence the 
first discussion) but the hints here have been tremendously helpful in 
getting closer to the source of problems.

--Chuck


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss