Hi Len,
thanks,
i have almost the sending part of the driver up and running, with some
small changes,
but as you said, it is written to work with little endian cpu.
It is not a problem of "bit" ordering, as in your diagram below.
Endianness here mean "byte-ordering" of the data in the memory, done
from the cpu.
A byte cross-wiring, without any bit-swapping, should solve the issue,
to allow the driver to be used as is:
D0:D7 cpu wired -> D24:D31 dm9000
D8:D15 cpu wired -> D16:D23 dm9000
D16:D23 cpu wired -> D8:D15 dm9000
D24:D31 cpu wired -> D0:D7 dm9000
I probably should try it in a next version of the board.
What i do is to use "writel" instade of "writeb", and i have magically
the byte out on dm9000 D0:D7. Then, DMA writings are configured through
a dm9000 bootstrap pin as 32bit. Here the byte swapping is required, and
i use le32_to_cpu() kernel function.
What still not work is the receiving part, and probably i am not
understanding very well the
dm9000 resource structure, here it is finally:
#define INT_IRQ7 31
static struct resource dm9000_resources[] = {
/* physical address of the address register (CMD [A2] to 0)*/
[0] = {
.start = MCF5307_CS1,
.end = MCF5307_CS1,
.flags = IORESOURCE_MEM,
},
/* physical address of the data register (CMD [A2] to 1)*/
[1] = {
.start = MCF5307_CS1 + 0x4,
.end = MCF5307_CS1 + 0x4 + 03,
.flags = IORESOURCE_MEM,
},
/* IRQ line the device's interrupt pin is connected to */
[2] = {
.start = INT_IRQ7,
.end = INT_IRQ7,
.flags = (IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE),
},
};
Irq vector for HW IRQ7 should be @ offset 31.
But who write there int the table the address of the dm9000 routine ? Is
it done automatically at dm9000 driver startup ?
any help is appreciated.
thanks,
Angelo
On 02/06/2010 18:07, Lennart Sorensen wrote:
On Wed, Jun 02, 2010 at 02:40:41PM +0200, angelo wrote:
many thanks,
i did some key steps forward:
- created my 5307/boards/amcore.c with platform_device/resources structures.
Now the dm9000_probe is executed correctly.
- had some problems in setting correct .start / .end addresses, but now
i get them working correctly (done debug through scope).
- finally, when the CMD is issued (IO_W# asserted + CMD low), trying to
read VIDL (vendor id, register 28h), the 0x28 is present, but from
D24:D31, so seems there is an endiannes problem.
So you seen right from the start one critical issue.
Probably, i can manage this inside the driver with some swaps, and have
it working, but i don't think it is the right way to go ahead, since i
would like my changes to be pubblic and commited someday.
Also it would probably hurt performance if you have to byte swap in the
driver. The real fix would be to hook up the chip correctly (assuming
that is even possible).
As I said before, I believe every user of that chip is little endian
so far. It might just be ugly to use on a big endian system.
Now you can have a look at how IDE for compact flash is handled on
the mpc8360mds board for example. That is a big endian cpu and IDE is
little endian. It seems to have been hooked up in a way that is fairly
efficient and doesn't involve very much byte swapping. I think they
have the schematics available if you need to see what pin order they
used to connect the compact flash to the CPU bus.
As far as I can tell from the schematic the way compact flash gets
connected is:
CPU pin | compact flash pin
--------+------------------
AD0 | D7
AD1 | D6
AD2 | D5
AD3 | D4
AD4 | D3
AD5 | D2
AD6 | D1
AD7 | D0
AD8 | D15
AD9 | D14
AD10 | D13
AD11 | D12
AD12 | D11
AD13 | D10
AD14 | D9
AD15 | D8
So whatever that means in the end. It certainly works with the localbus
IDE implementation that is in the linux kernel already for the MPC8360,
and doesn't seem to involve very much swapping in general. There is a
bit of 8bit versus 16bit stuff that has to be dealt with, but at least
the 16bit transfers that are done most of the time seem to go through
with no swapping required.
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
