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. -- Len Sorensen _______________________________________________ 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
