From: <fh...@at...> - 2000-07-17 01:47:33
|
Hi, I posted a message on the Linux SCSI mailing list about the problems I am having with the 53c770 driver. The current maitainor Gerard Rondier replied. Is there any reason the APUS kernel would not allow 32 bit access to the Amiga Hardware or memory especially on the PowerUP board? > The reason I ask, is that when the driver puts the "pc" value into the > DSP register it is bf2fe50, but when the value is read back out it is > "bf2". Weird ... 16 bit reversed in a DWORD + 16 bit lost. Or the BUS access reads 16 bits instead of 32 bits. > To my logic it seems that either the correct value may not have > got into the register due to an alignment problem, or the read back value > cannot be guaranteed to be > correct due to properties of the particular register. If you write 32 bits at a given IO (MMIO) address and read back the same location and width, you should get all the 4 bytes, possibly in a different order if the glue that does IO is not endian-consistent. Fred |
From: <gri...@ps...> - 2000-07-17 05:43:08
|
> Is there any reason the APUS kernel would not allow 32 bit access to the > Amiga Hardware or memory especially on the PowerUP board? No. The only thing I can imagine is that the 604e always tries to do 64-bit read and write access to the hardware instead of 32bit. Don't know if it can be forced to 32 bit.. The rest of the interfaceing to the Amiga is 'converted' by hardware. So access to ZORRO-II devices 'automagically' results in 16 bit return values. The rest of the hardware in the A3/4000 is pretty much fully 32 bit (except the custom-chips of course) > > The reason I ask, is that when the driver puts the "pc" value into the > > DSP register it is bf2fe50, but when the value is read back out it is > > "bf2". > > Weird ... 16 bit reversed in a DWORD + 16 bit lost. > Or the BUS access reads 16 bits instead of 32 bits. Can't imagine that to be true. The CV-PPC (also on the turboboard bus directly) works just fine except for some strange 640e related problem in the XAA code in the X server. Timing? Have you tried adding a delay-loop before reading the data again? The chip may not like being hit again too quickly. We know Phase5 liked to cut a few corners here and there in the design, so they may not have made it self-regulating. You may need to poll some sort of 'status' bit to see if the chip is ready to accept new read/write requests. > > To my logic it seems that either the correct value may not have > > got into the register due to an alignment problem, or the read back value > > cannot be guaranteed to be > > correct due to properties of the particular register. > > If you write 32 bits at a given IO (MMIO) address and read back the same > location and width, you should get all the 4 bytes, possibly in a > different order if the glue that does IO is not endian-consistent. Or if the device you write to immediately processes the input and in the process mangles the external view of the register. It is a read/write register I hope.. (just checking..) Bye, Arno. -- PSINetworks Europe Fax: +31-23-5699841 | One disk to rule them all, Siriusdreef 34 Tel: +31-23-5699840 | One disk to bind them, 2132WT Hoofddorp+--------------------------------+ One disk to hold the files The Netherlands | * Musical Interlude * | And in the darkness grind 'em ----------------+--------------------------------+------------------------------ We say Retribution, We say Vengeance is bliss, We say Revolution, With a Cast-Iron fist! (Megadeth, 'The Disintegrators') -------------------------------------------------------------------------------- |
From: Geert U. <ge...@li...> - 2000-07-17 13:08:07
|
On Mon, 17 Jul 2000, Arno Griffioen wrote: > > > The reason I ask, is that when the driver puts the "pc" value into the > > > DSP register it is bf2fe50, but when the value is read back out it is > > > "bf2". > > > > Weird ... 16 bit reversed in a DWORD + 16 bit lost. > > Or the BUS access reads 16 bits instead of 32 bits. > > Can't imagine that to be true. The CV-PPC (also on the turboboard > bus directly) works just fine except for some strange 640e related > problem in the XAA code in the X server. > > Timing? Have you tried adding a delay-loop before reading the data again? > The chip may not like being hit again too quickly. > > We know Phase5 liked to cut a few corners here and there in the design, > so they may not have made it self-regulating. You may need to poll > some sort of 'status' bit to see if the chip is ready to accept > new read/write requests. Anyone who disassembled the AmigaOS driver? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: <fh...@at...> - 2000-07-18 10:40:33
|
In <200...@su...>, on 07/17/00 at 07:42 AM, gri...@ps... (Arno Griffioen) said: >Or if the device you write to immediately processes the input and in the >process mangles the external view of the register. >It is a read/write register I hope.. (just checking..) The register is listed in the docs as R/W. Whether that means it does not mangle; I don't know. Maybe I should try writing the register in two 16 bit chunks. The only problem I see with that is that I think the SCSI chip starts execution of the script upon filling of that register with the address. Fred |