Atari ROM port ISA

Atari ROM port ISA

[Geert Uytterhoeven]

	Hi Michael,

arch/m68k/include/asm/io_mm.h:

| #define enec_isa_read_base  0xfffa0000
| #define enec_isa_write_base 0xfffb0000
|
| #define ENEC_ISA_IO_B(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
| #define ENEC_ISA_IO_W(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
| #define ENEC_ISA_MEM_B(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))
| #define ENEC_ISA_MEM_W(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))

So ISA memory space accesses (isa_readX()) are implemented the same as ISA I/O
space accesses? That can't work. Or are they not supported?

If they're not supported, I think it's better to implement dummies instead.

arch/m68k/include/asm/raw_io.h

| /*
|  * Atari ROM port (cartridge port) ISA adapter, used for the EtherNEC NE2000
|  * network card driver.
|  * The ISA adapter connects address lines A9-A13 to ISA address lines A0-A4,

That's handled via isa_[im]t[bwl](), which uses ENEC_ISA_{IO,MEM}_[BW]
internally. OK

|  * and hardwires the rest of the ISA addresses for a base address of 0x300.
|  *
|  * Data lines D8-D15 are connected to ISA data lines D0-D7 for reading.
|  * For writes, address lines A1-A8 are latched to ISA data lines D0-D7
|  * (meaning the bit pattern on A1-A8 can be read back as byte).

So writes are done using reads.

|  *
|  * Reads and writes are byte only.
|  */

Hence 8-bit access only, ...

|
| #if defined(CONFIG_ATARI_ROM_ISA)
| #define rom_in_8(addr) \
|         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
| #define rom_in_be16(addr) \
|         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
| #define rom_in_be32(addr) \
|         ({ u32 __v = (*(__force volatile u32 *) (addr)); __v >>= 8; __v; })
| #define rom_in_le16(addr) \
|         ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
| #define rom_in_le32(addr) \
|         ({ u32 __v = le32_to_cpu(*(__force volatile u32 *) (addr)); __v >>= 8; __v; })

So the above four can't work? Remove them?

| #define rom_out_8(addr, b)      ({u8 __w, __v = (b); __w = ((*(__force volatile u8 *)  ((addr) + 0x10000 + (__v<<1)))); })

The 0x10000 is due to the different bases for reading and writing
(i.e. enec_isa_write_base - enec_isa_read_base), right?

| #define rom_out_be16(addr, w)   ({u16 __w, __v = (w); __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
| #define rom_out_be32(addr, l)   ({u32 __w, __v = (l); __w = ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
| #define rom_out_le16(addr, w)   ({u16 __w, __v = cpu_to_le16(w); __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
| #define rom_out_le32(addr, l)   ({u32 __w, __v = cpu_to_le32(l); __w = ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })

The above four also can't work. Remove them?

| #define raw_rom_inb rom_in_8
| #define raw_rom_inw rom_in_be16
| #define raw_rom_inl rom_in_be32

The above two also can't work. Remove them?

| #define raw_rom_outb(val, port) rom_out_8((port), (val))
| #define raw_rom_outw(val, port) rom_out_be16((port), (val))
| #define raw_rom_outl(val, port) rom_out_be32((port), (val))

The above two also can't work. Remove them?

| #endif /* CONFIG_ATARI_ROM_ISA */

If all of these are removed, the CONFIG_ATARI_ROM_ISA sections in
arch/m68k/include/asm/io_mm.h can be simplified a lot, too.

Does all of this make sense?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Atari ROM port ISA

[Michael Schmitz]

Hi Geert,

> arch/m68k/include/asm/io_mm.h:
>
> | #define enec_isa_read_base  0xfffa0000
> | #define enec_isa_write_base 0xfffb0000
> |
> | #define ENEC_ISA_IO_B(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
> | #define ENEC_ISA_IO_W(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
> | #define ENEC_ISA_MEM_B(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))
> | #define ENEC_ISA_MEM_W(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))
>
> So ISA memory space accesses (isa_readX()) are implemented the same as ISA I/O
> space accesses? That can't work. Or are they not supported?

There's no distinct 'IO' or 'memory' space on the ROM port adapter, it's 
all memory mapped on ROM port addresses. How does access to ISA card mem 
regions work on ix86? Different address range, or different instructions?

> If they're not supported, I think it's better to implement dummies instead.

The section above is the address translation only - that one definitely 
is right. ne.c only uses inb/outb so we won't need readb/writeb support. 
The only other potential user of this glue (USB chipset in the NetUSBee) 
similarly only uses inb/outb so memory space access looks unnecessary.

> arch/m68k/include/asm/raw_io.h
>
> | /*
> |  * Atari ROM port (cartridge port) ISA adapter, used for the EtherNEC NE2000
> |  * network card driver.
> |  * The ISA adapter connects address lines A9-A13 to ISA address lines A0-A4,
>
> That's handled via isa_[im]t[bwl](), which uses ENEC_ISA_{IO,MEM}_[BW]
> internally. OK
>
> |  * and hardwires the rest of the ISA addresses for a base address of 0x300.
> |  *
> |  * Data lines D8-D15 are connected to ISA data lines D0-D7 for reading.
> |  * For writes, address lines A1-A8 are latched to ISA data lines D0-D7
> |  * (meaning the bit pattern on A1-A8 can be read back as byte).
>
> So writes are done using reads.

Yup. Ugly but that's how it works.

> |  *
> |  * Reads and writes are byte only.
> |  */
>
> Hence 8-bit access only, ...

Right. Not sure how many data and address lines the ROM port has, but 
the way the adapter is designed it's 8 bit only because of the 
read/write bit shift.

> |
> | #if defined(CONFIG_ATARI_ROM_ISA)
> | #define rom_in_8(addr) \
> |         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
> | #define rom_in_be16(addr) \
> |         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
> | #define rom_in_be32(addr) \
> |         ({ u32 __v = (*(__force volatile u32 *) (addr)); __v >>= 8; __v; })
> | #define rom_in_le16(addr) \
> |         ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
> | #define rom_in_le32(addr) \
> |         ({ u32 __v = le32_to_cpu(*(__force volatile u32 *) (addr)); __v >>= 8; __v; })
>
> So the above four can't work? Remove them?

They'd ever only read 8 bit wide data. That's probably not what you'd 
expect, so I guess they could be removed or turned into dummies. I 
included them to safeguard against drivers using multibyte access, but 
it might be better to warn in that case.

Only inb and outb are used in ne.c so it should be safe to remove these.

> | #define rom_out_8(addr, b)      ({u8 __w, __v = (b); __w = ((*(__force volatile u8 *)  ((addr) + 0x10000 + (__v<<1)))); })
>
> The 0x10000 is due to the different bases for reading and writing
> (i.e. enec_isa_write_base - enec_isa_read_base), right?

Right.

> | #define rom_out_be16(addr, w)   ({u16 __w, __v = (w); __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
> | #define rom_out_be32(addr, l)   ({u32 __w, __v = (l); __w = ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
> | #define rom_out_le16(addr, w)   ({u16 __w, __v = cpu_to_le16(w); __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
> | #define rom_out_le32(addr, l)   ({u32 __w, __v = cpu_to_le32(l); __w = ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
>
> The above four also can't work. Remove them?

Probably - not sure what the behavior will be if writing more than one 
byte (might not be safe to use). Using dummies (potentially to generate 
compiler warnings or  runtime warnings) might be safer.

>
> | #define raw_rom_inb rom_in_8
> | #define raw_rom_inw rom_in_be16
> | #define raw_rom_inl rom_in_be32
>
> The above two also can't work. Remove them?
>
> | #define raw_rom_outb(val, port) rom_out_8((port), (val))
> | #define raw_rom_outw(val, port) rom_out_be16((port), (val))
> | #define raw_rom_outl(val, port) rom_out_be32((port), (val))
>
> The above two also can't work. Remove them?
>
> | #endif /* CONFIG_ATARI_ROM_ISA */
>
> If all of these are removed, the CONFIG_ATARI_ROM_ISA sections in
> arch/m68k/include/asm/io_mm.h can be simplified a lot, too.
>
> Does all of this make sense?

It does - seems I implemented a lot of unused and potentially dangerous 
stuff there. Do you want me to test these changes up front (not that I 
think there should be surprises)?

Cheers,

   Michael

Re: Atari ROM port ISA

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> Right. Not sure how many data and address lines the ROM port has,

16 data and 16 address lines (68000 compatible, ie. A1-15 + UDS/LDS).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari ROM port ISA

[Geert Uytterhoeven]

On Mon, Apr 16, 2012 at 09:50, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>> | #define rom_out_be16(addr, w)   ({u16 __w, __v = (w); __w = ((*(__force
>> volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
>> | #define rom_out_be32(addr, l)   ({u32 __w, __v = (l); __w = ((*(__force
>> volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
>> | #define rom_out_le16(addr, w)   ({u16 __w, __v = cpu_to_le16(w); __w =
>> ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
>> | #define rom_out_le32(addr, l)   ({u32 __w, __v = cpu_to_le32(l); __w =
>> ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
>>
>> The above four also can't work. Remove them?
>
> Probably - not sure what the behavior will be if writing more than one byte
> (might not be safe to use). Using dummies (potentially to generate compiler
> warnings or  runtime warnings) might be safer.

As soon as the value you're writing is bigger than 0x7fff, you'll get out of the
64 KiB write window.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Atari ROM port ISA

[Michael Schmitz]

Hi Geert,

On Mon, Apr 16, 2012 at 9:42 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Apr 16, 2012 at 09:50, Michael Schmitz
> <schmitzmic@googlemail.com> wrote:
>>> | #define rom_out_be16(addr, w)   ({u16 __w, __v = (w); __w = ((*(__force
>>> volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
>>> | #define rom_out_be32(addr, l)   ({u32 __w, __v = (l); __w = ((*(__force
>>> volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
>>> | #define rom_out_le16(addr, w)   ({u16 __w, __v = cpu_to_le16(w); __w =
>>> ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
>>> | #define rom_out_le32(addr, l)   ({u32 __w, __v = cpu_to_le32(l); __w =
>>> ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); })
>>>
>>> The above four also can't work. Remove them?
>>
>> Probably - not sure what the behavior will be if writing more than one byte
>> (might not be safe to use). Using dummies (potentially to generate compiler
>> warnings or  runtime warnings) might be safer.
>
> As soon as the value you're writing is bigger than 0x7fff, you'll get out of the
> 64 KiB write window.

That's correct - on the ISA side only eight bits are wired up anyway
so ((addr) + 0x10000 + (( __v & 0xFF )<<1)) is making sure we only
write what's possible to write. The only side effect of the le[16,32]
versions is to put a different byte in the one-byte write aperture.
That's purely academic so let's lose it.

As Andreas has confirmed, there's no way the adapter hardware could be
extended to write full 16 bit words even if the design was changed to
use the full data bus width (by using tri-state latches so the same
ISA data lines can be wired to both data and address lines of the ROM
port, possibly) - since we need the A0 bit as read/write select we
only have 15 address bits left for writes.

Does this make sense? Either way, we only need byte reads and writes
so please remove the rest.

Cheers,

  Michael

Re: Atari ROM port ISA

[Brad Boyer]

On Mon, Apr 16, 2012 at 07:50:33PM +1200, Michael Schmitz wrote:
> >arch/m68k/include/asm/io_mm.h:
> >
> >| #define enec_isa_read_base  0xfffa0000
> >| #define enec_isa_write_base 0xfffb0000
> >|
> >| #define ENEC_ISA_IO_B(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
> >| #define ENEC_ISA_IO_W(ioaddr)   (enec_isa_read_base+((((unsigned long)(ioaddr))&0x1F)<<9))
> >| #define ENEC_ISA_MEM_B(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))
> >| #define ENEC_ISA_MEM_W(madr)    (enec_isa_read_base+((((unsigned long)(madr))&0x1F)<<9))
> >
> >So ISA memory space accesses (isa_readX()) are implemented the same as ISA I/O
> >space accesses? That can't work. Or are they not supported?
> 
> There's no distinct 'IO' or 'memory' space on the ROM port adapter,
> it's all memory mapped on ROM port addresses. How does access to ISA
> card mem regions work on ix86? Different address range, or different
> instructions?

The real x86 instruction set has separate instructions to access any
ports in the IO space (in and out). The instruction also has an access
width field, which most assemblers encode into the instruction (leading
to the inb,inw,outb,outw in assembly listings). This carried forward
into PCI as well, which allows for separate IO and memory access.

Most non-x86 implementations of ISA (and PCI) just map the IO ports
onto some otherwise unused address range in the normal memory space.

	Brad Boyer
	flar@allandria.com

Re: Atari ROM port ISA

[Thorsten Glaser]

Brad Boyer <flar <at> allandria.com> writes:

> On Mon, Apr 16, 2012 at 07:50:33PM +1200, Michael Schmitz wrote:

> > >So ISA memory space accesses (isa_readX()) are implemented the same as ISA 
I/O
> > >space accesses? That can't work. Or are they not supported?
> > 
> > There's no distinct 'IO' or 'memory' space on the ROM port adapter,
> > it's all memory mapped on ROM port addresses. How does access to ISA
> > card mem regions work on ix86? Different address range, or different
> > instructions?
> 
> The real x86 instruction set has separate instructions to access any
> ports in the IO space (in and out). The instruction also has an access

This maps to different lines being driven on the ISA side, see:
https://upload.wikimedia.org/wikipedia/commons/3/3d/XT_Bus_pins.png

There are I/O read/write and MEM read/write lines (B11‥B14).
So you need these that are actually wired up in the adapter.

Bascially, “PC” I/O ports have a separate 16-bit¹ address space
from the main (originally) 20-bit address space of the main
memory (RAM, ROM) which are addressed with different instructions
and may behave different when accessed as 8-bit vs. 16-bit slots.

① IIRC, only 12 bit were originally wired or used before the era
  of the various Local Buses, although according to the 8086 docs
  that seems to not have been a CPU issue but mainboard design.

bye,
//mirabilos

Re: Atari ROM port ISA

[Michael Schmitz]

Hi Thorsten,

On Fri, Apr 20, 2012 at 3:00 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> Brad Boyer <flar <at> allandria.com> writes:
>
>> On Mon, Apr 16, 2012 at 07:50:33PM +1200, Michael Schmitz wrote:
>
>> > >So ISA memory space accesses (isa_readX()) are implemented the same as ISA
> I/O
>> > >space accesses? That can't work. Or are they not supported?
>> >
>> > There's no distinct 'IO' or 'memory' space on the ROM port adapter,
>> > it's all memory mapped on ROM port addresses. How does access to ISA
>> > card mem regions work on ix86? Different address range, or different
>> > instructions?
>>
>> The real x86 instruction set has separate instructions to access any
>> ports in the IO space (in and out). The instruction also has an access
>
> This maps to different lines being driven on the ISA side, see:
> https://upload.wikimedia.org/wikipedia/commons/3/3d/XT_Bus_pins.png
>
> There are I/O read/write and MEM read/write lines (B11‥B14).
> So you need these that are actually wired up in the adapter.

Thanks for explaining this to me - to be honest I've never cared too
much about ISA and friends.

I'll check the layout - my guess would be that there's no memory
read/write selects wired up on the adapter. The RTL8019 doesn't need
them, the ISP1160  on the NetUSBee doesn't need them either.

If someone ever comes up with a way to hook up a fully featured ISA
slot to the ROM port (mapping ports 0x00 to 0x7f to IO and above to
mem access should be possible) we might revisit the code. For now,
anything except for 8 bit IO can be turned into dummy functions or
compile warnings.

Cheers,

  Michael

Re: Atari ROM port ISA

[Thorsten Glaser]

Michael Schmitz dixit:

>Thanks for explaining this to me - to be honest I've never cared too
>much about ISA and friends.

No problem. (I practically grew up with them, so while the knowledge
isn’t fresh, some is there.)

>I'll check the layout - my guess would be that there's no memory
>read/write selects wired up on the adapter. The RTL8019 doesn't need
>them, the ISP1160  on the NetUSBee doesn't need them either.

I’d guess the same. You’d need them for things like an ISA graphics
card, but not (most) I/O devices.

>If someone ever comes up with a way to hook up a fully featured ISA
>slot to the ROM port (mapping ports 0x00 to 0x7f to IO and above to
>mem access should be possible) we might revisit the code. For now,
>anything except for 8 bit IO can be turned into dummy functions or
>compile warnings.

Might be nice, if possible. But for now, that would indeed be
the way to go (and clean up code).

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: Atari ROM port ISA

[Michael Schmitz]

Hi Thorsten,
>> Thanks for explaining this to me - to be honest I've never cared too
>> much about ISA and friends.
> No problem. (I practically grew up with them, so while the knowledge
> isn’t fresh, some is there.)
I grew up without computers - the first I used was a TR440 mainframe :-)
>> I'll check the layout - my guess would be that there's no memory
>> read/write selects wired up on the adapter. The RTL8019 doesn't need
>> them, the ISP1160  on the NetUSBee doesn't need them either.
> I’d guess the same. You’d need them for things like an ISA graphics
> card, but not (most) I/O devices.
Only /IOW and /IOR are wired up. Only A0 through A4 are wired up (from 
A9-A13).
>> If someone ever comes up with a way to hook up a fully featured ISA
>> slot to the ROM port (mapping ports 0x00 to 0x7f to IO and above to
>> mem access should be possible) we might revisit the code. For now,
>> anything except for 8 bit IO can be turned into dummy functions or
>> compile warnings.
> Might be nice, if possible. But for now, that would indeed be
> the way to go (and clean up code).
I've had a look at the NetUSBee docs and see that the USB part of it 
does require 8 bit writes but little endian 16 bit reads. So we will 
need to retain the 16 bit reads for potential USB support there.

Cheers,

   Michael

Re: Atari ROM port ISA

[Geert Uytterhoeven]

On Sat, Apr 21, 2012 at 17:44, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>>> If someone ever comes up with a way to hook up a fully featured ISA
>>> slot to the ROM port (mapping ports 0x00 to 0x7f to IO and above to
>>> mem access should be possible) we might revisit the code. For now,
>>> anything except for 8 bit IO can be turned into dummy functions or
>>> compile warnings.
>>
>> Might be nice, if possible. But for now, that would indeed be
>> the way to go (and clean up code).
>
> I've had a look at the NetUSBee docs and see that the USB part of it does
> require 8 bit writes but little endian 16 bit reads. So we will need to
> retain the 16 bit reads for potential USB support there.

OK. But you ain't gonna get the right 16 bits using

#define rom_in_be16(addr) \
        ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
#define rom_in_le16(addr) \
        ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr));
__v >>= 8; __v; })

as they both do a 16-bit read and shift the result.
Perhaps it should just be a 32-bit read instead?
Are the schematics publicly available?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Atari ROM port ISA

[Geert Uytterhoeven]

On Sat, Apr 21, 2012 at 10:20, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> I've had a look at the NetUSBee docs and see that the USB part of it does
>> require 8 bit writes but little endian 16 bit reads. So we will need to
>> retain the 16 bit reads for potential USB support there.
>
> OK. But you ain't gonna get the right 16 bits using
>
> #define rom_in_be16(addr) \
>        ({ u16 __v = (*(__force volatile u16 *) (addr)); __v >>= 8; __v; })
> #define rom_in_le16(addr) \
>        ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr));
> __v >>= 8; __v; })
>
> as they both do a 16-bit read and shift the result.
> Perhaps it should just be a 32-bit read instead?
> Are the schematics publicly available?

I found netusbee.zip.
Unfortunately I (my computer) can't grok the schematics files.

However, program_spec.txt says (a.o., I encourage all interested
parties to read it in full):

| USB Data Reads
| ==============
|
| Data Reads from USB are done at base address 0xFA8000 (activating a read
| cycle) as a 16bit word.  Data appears on D8-15 as most significant byte, and
| D0-7 as least significant byte.  Notice how A15 has to be set to 1 to make it
| a USB cycle.

So inw() should just do a 16-bit big-endian read.

| USB Data Writes
| ===============
|
| Data reads at base address 0xFB8000 actually cause data to be written.  As
| the write interface is only 8 bits wide, the 16bits of data must be passed
| through this "8 bit window".  The Least Signifant Byte is transferred first
| by left shifting data once and added to 0xFA8000.  This is followed by the
| Most significant byte, transferred by left shifting data once and then added
| to 0xFB8000.  On this last cycle is where the transfer is actually done.
| Notice how A15 has to be set to 1 to make it a USB cycle.

So outw() should do 2 byte reads.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Atari ROM port ISA

[Michael Schmitz]

Geert,
> On Sat, Apr 21, 2012 at 10:20, Geert Uytterhoeven<geert@linux-m68k.org>  wrote:
>>> I've had a look at the NetUSBee docs and see that the USB part of it does
>>> require 8 bit writes but little endian 16 bit reads. So we will need to
>>> retain the 16 bit reads for potential USB support there.
>> OK. But you ain't gonna get the right 16 bits using
>>
>> #define rom_in_be16(addr) \
>>         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v>>= 8; __v; })
>> #define rom_in_le16(addr) \
>>         ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr));
>> __v>>= 8; __v; })
>>
>> as they both do a 16-bit read and shift the result.
>> Perhaps it should just be a 32-bit read instead?
Correct - the 16 bit read should not do any shifts instead.
>> Are the schematics publicly available?
> I found netusbee.zip.
> Unfortunately I (my computer) can't grok the schematics files.
Same here - I'm sure software to read these is available somewhere. I 
did not look closely though.
> However, program_spec.txt says (a.o., I encourage all interested
> parties to read it in full):
DId that ...
> | USB Data Reads
> | ==============
> |
> | Data Reads from USB are done at base address 0xFA8000 (activating a read
> | cycle) as a 16bit word.  Data appears on D8-15 as most significant byte, and
> | D0-7 as least significant byte.  Notice how A15 has to be set to 1 to make it
> | a USB cycle.
>
> So inw() should just do a 16-bit big-endian read.
You're right - I got my big vs. little endian mixed up. The ISP1160 
driver is a little-endian beast but the byte swap has been done in 
hardware here if I read the paragraph right.
> | USB Data Writes
> | ===============
> |
> | Data reads at base address 0xFB8000 actually cause data to be written.  As
> | the write interface is only 8 bits wide, the 16bits of data must be passed
> | through this "8 bit window".  The Least Signifant Byte is transferred first
> | by left shifting data once and added to 0xFA8000.  This is followed by the
> | Most significant byte, transferred by left shifting data once and then added
> | to 0xFB8000.  On this last cycle is where the transfer is actually done.
> | Notice how A15 has to be set to 1 to make it a USB cycle.
>
> So outw() should do 2 byte reads.
Correct again  - the A15 we can implement via the address field itself 
(just as the USB command vs. data cycle on A14). The ISP1160 driver has 
provisions to use two 8-bit writes in place of a 16 bit one but it might 
be cleaner to implement the 16 bit write the way the USB driver needs it.

Now - does anyone here on this list or on debian-68k own such hardware 
and would be in a position to test a USB driver written to this spec? Is 
the hardware still for sale?
(Not that I am at all sure whether the ISP1160 driver will run in a 
timer polled mode at all ...)

Cheers,

   Michael

Re: Atari ROM port ISA

[David Gálvez]

2012/4/22 Michael Schmitz <schmitzmic@googlemail.com>:
>
> Correct again  - the A15 we can implement via the address field itself (just
> as the USB command vs. data cycle on A14). The ISP1160 driver has provisions
> to use two 8-bit writes in place of a 16 bit one but it might be cleaner to
> implement the 16 bit write the way the USB driver needs it.
>
> Now - does anyone here on this list or on debian-68k own such hardware and
> would be in a position to test a USB driver written to this spec? Is the
> hardware still for sale?
> (Not that I am at all sure whether the ISP1160 driver will run in a timer
> polled mode at all ...)
>

Hi, I would like to help to make those tests, although my only
experience with Linux is as Ubuntu user. I have a CT060 Falcon with a
NetUSBee and also an Ethernat and I've just installed Linux in it. I
did some work for FreeMiNT's USB drivers for both cards. Under MiNT
the Ethernat driver is working but I have problems with the NetUSBee
one, it isn't working reliable. I hope that the Linux driver for the
NetUSBee enlighten me to see where is the problem with the MiNT
driver.

About if it's still possible to buy the NetUSBee, The last week there
was a thread in atari-forum.com talking about it, it looks like nobody
knows anybody who is making them right now:

http://www.atari-forum.com/viewtopic.php?f=15&t=23362

I bought mine last year from one person in Germany I can send you an
email with his address if you're interested, just to try.

Regards

David

Re: Atari ROM port ISA

[Michael Schmitz]

Hi David,

On Sun, May 13, 2012 at 10:33 PM, David Gálvez <dgalvez75@gmail.com> wrote:
> 2012/4/22 Michael Schmitz <schmitzmic@googlemail.com>:
>> Now - does anyone here on this list or on debian-68k own such hardware and
>> would be in a position to test a USB driver written to this spec? Is the
>> hardware still for sale?
>> (Not that I am at all sure whether the ISP1160 driver will run in a timer
>> polled mode at all ...)
>>
>
> Hi, I would like to help to make those tests, although my only
> experience with Linux is as Ubuntu user. I have a CT060 Falcon with a
> NetUSBee and also an Ethernat and I've just installed Linux in it. I

Thanks for your offer - what kernel version does your Falcon Linux
installation currently use?

My development is based on 3.4-rc3, if your Linux system is a recent
enough one there should not be any problems with booting 3.4 kernels.
I will send a kernel image file and a modules archive by separate
mail.

The kernel and modules I can provide won't come nicely packaged as in
Ubuntu or Debian kernel image packages. You will have to extract the
modules archive in the root of your file system, and then run 'depmod
-a 3.4.0-rc3-atari-35598-gf7ff2b8-dirty' (all as root) before booting
the 3.4 kernel.

Once the new kernel has booted, please try loading the EtherNAT
drivers (called smc91x for the network and isp116x-hcd for the USB
driver). Check the kernel message log (command 'dmesg') for any
messages relating to the modules loading. The smc91x should load OK, I
run into problems later on when the corresponding network interface is
brought up. The USB one balks at the initial hardware checks on my
Falcon.

If you happen to get kernel panic messages these should be possible to
catch with a serial nullmodem cable between your Falcon and another
computer.

> did some work for FreeMiNT's USB drivers for both cards. Under MiNT
> the Ethernat driver is working but I have problems with the NetUSBee
> one, it isn't working reliable. I hope that the Linux driver for the
> NetUSBee enlighten me to see where is the problem with the MiNT
> driver.

We don't have a USB driver for the NetUSBee right now - though it
should not be too hard to pull off (I need to write a bit of ROM port
access glue for that). I will have to send a new kernel image for that
kind of change but most of the modules should be possible to reuse.

The Ethernet part of the NetUSBee should work using the atari_ethernec
driver in currrent kernels. The driver has been renamed to 'ne' in my
development branch.

The USB driver is named isp116x-hcd for the EtherNAT. I'll try to use
the same driver name for the NetUSBee if that's possible (it's easy
enough if you only have one of the two installed, but may be a bit
difficult if you've got them both).

> About if it's still possible to buy the NetUSBee, The last week there
> was a thread in atari-forum.com talking about it, it looks like nobody
> knows anybody who is making them right now:
>
> http://www.atari-forum.com/viewtopic.php?f=15&t=23362
>
> I bought mine last year from one person in Germany I can send you an
> email with his address if you're interested, just to try.

All I would do with the hardware is test a Linux driver on it - I'm OK
with the EtherNEC at the moment. Others may make better use of the
scarce hardware.

Stay tuned for the kernel and modules - I'll send them off right away.

Regards,

  Michael Schmitz

Re: Atari ROM port ISA

[David Gálvez]

2012/5/14 Michael Schmitz <schmitzmic@googlemail.com>:
> Hi David,
>
> On Sun, May 13, 2012 at 10:33 PM, David Gálvez <dgalvez75@gmail.com> wrote:
>> Hi, I would like to help to make those tests, although my only
>> experience with Linux is as Ubuntu user. I have a CT060 Falcon with a
>> NetUSBee and also an Ethernat and I've just installed Linux in it. I
>
> Thanks for your offer - what kernel version does your Falcon Linux
> installation currently use?
>

3.4-rc5, I've cloned Geert's tree and compiled the kernel using
atari_defcofig, then I should enable the configuration option
"Maintain a devtmpfs filesystem to mount at /dev" to make the kernel
to finish the boot process.

> My development is based on 3.4-rc3, if your Linux system is a recent
> enough one there should not be any problems with booting 3.4 kernels.
> I will send a kernel image file and a modules archive by separate
> mail.
>

OK, my installation is based on this https://wiki.debian.org/Aranym/Quick

> The kernel and modules I can provide won't come nicely packaged as in
> Ubuntu or Debian kernel image packages. You will have to extract the
> modules archive in the root of your file system, and then run 'depmod
> -a 3.4.0-rc3-atari-35598-gf7ff2b8-dirty' (all as root) before booting
> the 3.4 kernel.
>

OK, no problem, thanks for the explanation.

> Once the new kernel has booted, please try loading the EtherNAT
> drivers (called smc91x for the network and isp116x-hcd for the USB
> driver). Check the kernel message log (command 'dmesg') for any
> messages relating to the modules loading. The smc91x should load OK, I
> run into problems later on when the corresponding network interface is
> brought up. The USB one balks at the initial hardware checks on my
> Falcon.
>
> If you happen to get kernel panic messages these should be possible to
> catch with a serial nullmodem cable between your Falcon and another
> computer.
>

OK, I have the cable and I've already tested debugging this way.

> We don't have a USB driver for the NetUSBee right now - though it
> should not be too hard to pull off (I need to write a bit of ROM port
> access glue for that). I will have to send a new kernel image for that
> kind of change but most of the modules should be possible to reuse.
>
> The Ethernet part of the NetUSBee should work using the atari_ethernec
> driver in currrent kernels. The driver has been renamed to 'ne' in my
> development branch.
>
> The USB driver is named isp116x-hcd for the EtherNAT. I'll try to use
> the same driver name for the NetUSBee if that's possible (it's easy
> enough if you only have one of the two installed, but may be a bit
> difficult if you've got them both).
>
>
> Stay tuned for the kernel and modules - I'll send them off right away.
>

I'll report back here as soon as I'm done with the tests.

Thanks.

Re: Atari ROM port ISA

[David Gálvez]

2012/5/14 Michael Schmitz <schmitzmic@googlemail.com>:
> Hi David,
>
> On Sun, May 13, 2012 at 10:33 PM, David Gálvez <dgalvez75@gmail.com> wrote:
>> 2012/4/22 Michael Schmitz <schmitzmic@googlemail.com>:
>>> Now - does anyone here on this list or on debian-68k own such hardware and
>>> would be in a position to test a USB driver written to this spec? Is the
>>> hardware still for sale?
>>> (Not that I am at all sure whether the ISP1160 driver will run in a timer
>>> polled mode at all ...)
>>>
>>
>> Hi, I would like to help to make those tests, although my only
>> experience with Linux is as Ubuntu user. I have a CT060 Falcon with a
>> NetUSBee and also an Ethernat and I've just installed Linux in it. I
>
> Thanks for your offer - what kernel version does your Falcon Linux
> installation currently use?
>
> My development is based on 3.4-rc3, if your Linux system is a recent
> enough one there should not be any problems with booting 3.4 kernels.
> I will send a kernel image file and a modules archive by separate
> mail.
>
> The kernel and modules I can provide won't come nicely packaged as in
> Ubuntu or Debian kernel image packages. You will have to extract the
> modules archive in the root of your file system, and then run 'depmod
> -a 3.4.0-rc3-atari-35598-gf7ff2b8-dirty' (all as root) before booting
> the 3.4 kernel.
>
> Once the new kernel has booted, please try loading the EtherNAT
> drivers (called smc91x for the network and isp116x-hcd for the USB
> driver). Check the kernel message log (command 'dmesg') for any
> messages relating to the modules loading. The smc91x should load OK, I
> run into problems later on when the corresponding network interface is
> brought up. The USB one balks at the initial hardware checks on my
> Falcon.
>
> If you happen to get kernel panic messages these should be possible to
> catch with a serial nullmodem cable between your Falcon and another
> computer.
>

EtherNat's nertwork driver is working fine.

When loading the USB driver I'm getting this:

usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
isp116x-hcd isp116x-hcd: ISP116x Host Controller
isp116x-hcd isp116x-hcd: new USB bus registered, assigned bus number 1
116x: Clock not ready after 15ms
116x: Please make sure that the H_WAKEUP pin is pulled low!
isp116x-hcd isp116x-hcd: can't setup
isp116x-hcd isp116x-hcd: USB bus 1 deregistered
116x: init error, -19


Regards

Re: Atari ROM port ISA

[Michael Schmitz]

On 17/05/12 18:10, David Gálvez wrote:
> EtherNat's nertwork driver is working fine.
That's good to know. Well, not entirely - it does mean my EtherNAT is 
dead ...

What interrupt does it report it uses? Do you see the card interrupts 
accumulate in /proc/interrupts?
> When loading the USB driver I'm getting this:
>
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> isp116x-hcd isp116x-hcd: ISP116x Host Controller
> isp116x-hcd isp116x-hcd: new USB bus registered, assigned bus number 1
> 116x: Clock not ready after 15ms
> 116x: Please make sure that the H_WAKEUP pin is pulled low!
> isp116x-hcd isp116x-hcd: can't setup
> isp116x-hcd isp116x-hcd: USB bus 1 deregistered
> 116x: init error, -19
Just what I'm getting as well. Back to the drawing board. I'll have to 
get confirmation on the exact addresses being used from the EtherNAT 
designer.

Thanks a lot,

   Michael