This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Bus space vs PCI space vs CPU space
- From: Chuck McManis <ecos at mcmanis dot com>
- To: ECOS Discussion Group <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 15 Feb 2006 21:45:56 -0800
- Subject: [ECOS] Bus space vs PCI space vs CPU space
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