Kernel 5.15 Amiga PCMCIA apne driver not working

[Michael Schmitz]

Carlos,

Hi again everyone,
While I figure out how to build a snapshot NETINST ISO, I decided to
give a try to the "nativehd" initrd. This is a interesting one, as it
brings up network on the very first stage of the d-i and download
installer components from the network. I wonder why is called
"nativehd" and not "netinstall" or something like that.
Anyway, on this initrd, the image is also broken because is missing
the Amiga (and Atari) network drivers [1], provided by
"nic-modules-${kernel:Version}", so I added that line to the cfg file
and built a new initrd. After booting the image on the real hardware,
d-i goes directly to network setup, but is not able to detect my
NE2000 PCMCIA cards [2]. If I manually select "apne" the kernel says
it has not found any PCMCIA card.
D-Link DE660+ 10 MBit Fiberline FL-4680 10 MBit
Both of them working fine on AmigaOS cnet.device and NetBSD/amiga
9.2; reported as compatible on [3]. I don't think the driver is
broken in current kernels as I am experiencing the very same on
Debian Sarge install with kernel 2.4. Maybe something is wrong with
my setup? Any ideas?

I know d-i is doing its level best to hide kernel log output from the
user, but is there a way to look at the kernel log from the installer at
all? I seem to recall log output was displayed on one of the virtual
terminal screens.

Without seeing the kernel log messages from the module load attempt,
it's impossible to tell what went wrong.

Look for a line containing "Looking for PCMCIA ethernet card : " in the
kernel log messages.

The DE660+ is listed as 'should be supported' on the Amiga PCMCIA
ethernet page you gave. The FL-4680 is listed as working in 2.4 so I
wonder if something in the multiplatform ISA support breaks these cards.

Try building your installer kernel without support for Atari and Q40.

Cheers,

Michael

[1]
https://salsa.debian.org/installer-team/debian-installer/-/blob/master/build/pkg-lists/nativehd/m68k.cfg

[2] Loading Image...

[3] http://www.g-mb.de/pcmcia_e.html
Carlos Milán Figueredo HispaMSX System Operator -
http://www.hispamsx.org - telnet://bbs.hispamsx.org -
https://calnus.com

[Michael Schmitz]

Hi Carlos,

Merry Christmas to you, too!

Merry Christmas! I could finally make the tests.
Sent: lunes, 13 de diciembre de 2021 7:52

Post by Michael Schmitz
Look for a line containing "Looking for PCMCIA ethernet card : " in the
kernel log messages.

FL-4680
=======
Looking for PCMCIA ethernet card: ethernet PCMCIA card inserted
(unnamed net_device) (uninitialized): PCMCIA NE**00 ethercard probe not found

That's from apne_probe1 - the MAC address prefix does not match what is
expected (NE2000 or Ctron).

If you can tell me your cards' MAC addresses, I can add those prefixes
to the ones known to the driver, and send a patch for you to test. Might
need some more adjustments though (start and end address of ring buffer).

You said the cards are supported by BSD? There might be information
about the ring buffer in the source there.

Cheers,

Michael

modprobe: ERROR: could not insert 'apne': No such device or address
ethdetect: insmod /lib/modules/5.15.0-2-m68k/kernel/drviers/net/ethernet/8390/8390.ko
ethdetect: insmod /lib/modules/5.15.0-2-m68k/kernel/drviers/net/ethernet/8390/apne.ko
main-menu[205]: INFO: Menu item 'ethdetect' succeeded but requested to be left unconfigured
D-Link D660+ (same messages as FL-4680)
============
Looking for PCMCIA ethernet card: ethernet PCMCIA card inserted
(unnamed net_device) (uninitialized): PCMCIA NE**00 ethercard probe not found
modprobe: ERROR: could not insert 'apne': No such device or address
ethdetect: insmod /lib/modules/5.15.0-2-m68k/kernel/drviers/net/ethernet/8390/8390.ko
ethdetect: insmod /lib/modules/5.15.0-2-m68k/kernel/drviers/net/ethernet/8390/apne.ko
main-menu[205]: INFO: Menu item 'ethdetect' succeeded but requested to be left unconfigured
Regards,
Carlos
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | telnet://bbs.hispamsx.org | https://calnus.com

[Michael Schmitz]

Hi Carlos,

Hi Michael,
Sent: miércoles, 29 de diciembre de 2021 21:31

Post by Michael Schmitz

Looking for PCMCIA ethernet card: ethernet PCMCIA card inserted
(unnamed net_device) (uninitialized): PCMCIA NE**00 ethercard probe not found

That's from apne_probe1 - the MAC address prefix does not match what is
expected (NE2000 or Ctron).
If you can tell me your cards' MAC addresses, I can add those prefixes
to the ones known to the driver, and send a patch for you to test. Might
need some more adjustments though (start and end address of ring buffer).

- D-Link DE-660+: 00:50:BA:87:C9:27
- FL-4680: 00:E0:98:34:07:DA

Thanks, I'll check the prefix size and send a patch by PM.

Post by Michael Schmitz
You said the cards are supported by BSD? There might be information
about the ring buffer in the source there.

==== D-Link DE-660+
pccard0 at mainbus0
pcmcia0 at pccard0
ne0 at pcmcia0 function 0: <D-Link, DE-660+, A, 0004743118001>
ne0: Ethernet address 00:50:ba:87:c9:27
==== FL-4680
pccard0 at mainbus0
pcmcia0 at pccard0
ne0 at pcmcia0 function 0: <Ethernet, Adapter, 2.0>
ne0: Ethernet address 00:e0:98:34:07:dA

Doesn't print the ring buffer addresses - might need a patch to the BSD
source to do that (I haven't looked at BSD source in over 20 years). Or
maybe some equivalent of ethtool reports the addresses, or they show up
in ifconfig output?

But what I meant is to check whether the ne driver source hard-codes the
ring buffer addresses for these cards?

Is there support in BSD to parse the PCMCIA CIS tuple data? The ring
buffer address might be in the CIS data ...

There's a patch of mine floating around that uses CIS data to figure out
8 or 16 bit IO width (submitted to linux-m68k and netdev a while ago).
With that one applied, dumping the CIS data and hand-parsing the result
might be one way to obtain the necessary data.

Let's see how far you get with a simple patch to add the new MAC
prefixes. DaveM is going to hate me for this ...

Cheers,

Michael

Regards,
Carlos
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | telnet://bbs.hispamsx.org | https://calnus.com

[Michael Schmitz]

Hi Carlos,

Hi Michael, happy new year!
Sent: viernes, 31 de diciembre de 2021 8:51

Post by Michael Schmitz
Thanks, I'll check the prefix size and send a patch by PM.

I will need also some help for testing it, as I do not have a Linux working install on my Amiga because I need hd-media initrd and network support :) I am able to boot a kernel with an initrd.

I was under the impression that you could (cross-)build your own kernel
and initrd? If that's not an option, testing is going to be much harder.

Any required patches can be added to the list of patches applied as part
of the Debian kernel build procedure as far as I remember - is that
still so, Adrian?

Post by Michael Schmitz
Doesn't print the ring buffer addresses - might need a patch to the BSD
source to do that (I haven't looked at BSD source in over 20 years). Or
maybe some equivalent of ethtool reports the addresses, or they show up
in ifconfig output?

I am afraid ifconfig doesn't print anything about the ring buffer, and -to my knowledge- there is not equivalent ethtool.

Post by Michael Schmitz
But what I meant is to check whether the ne driver source hard-codes the
ring buffer addresses for these cards?

1. Gayle PCMCIA driver [1].

That's the Gayle specific code, but IO and memory space for the PCMCIA
interface are hardcoded there. The low level access functions use the
bus size (8 or 16 bit) but nothing in there detects that. Must be part
of the PCMCIA CIS code then.

2. ne2000.c [2], ne2000reg.h [3], ne2000var.h [4]
3. dp8390reg.h [5], dp8390var.h [6]
I don't have the needed knowledge about the NE2000 driver or the kernel, but to my untrained eye it doesn't look like there is anything hardcoded for these cards.

Might be passed in from the generic driver support code (which likely
obtains that info from CIS).

Post by Michael Schmitz
There's a patch of mine floating around that uses CIS data to figure out
8 or 16 bit IO width (submitted to linux-m68k and netdev a while ago).
With that one applied, dumping the CIS data and hand-parsing the result
might be one way to obtain the necessary data.

In [2] there is a function called ne2000_detect_8bit() that is used for that. It looks like it reads the card ROM to figure out. I don't know if the CIS is considered a ROM or not.

No, that only figures out what mode is set in the 8390 chip - AFAIK
needed to support NE1000 type cards. With 16 bit NE2000 type cards, you
can still use 8 bit IO to access the chip, which is what the 10 Mbit
cards supported by the apne driver do. 100 Mbit cards need 16 bit IO.

I'll have to create another patch to look for mem resources in the CIS
data, and get that tested on the already supported cards. Then use that
for new cards.

Cheers,

Michael

[1] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amiga/dev/gayle_pcmcia.c?rev=1.34&content-type=text/x-cvsweb-markup
[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ne2000.c?rev=1.77&content-type=text/x-cvsweb-markup
[3] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ne2000reg.h?rev=1.3.8.1&content-type=text/x-cvsweb-markup
[4] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ne2000var.h?rev=1.27.30.1&content-type=text/x-cvsweb-markup
[5] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/dp8390reg.h?rev=1.8.116.1&content-type=text/x-cvsweb-markup
[6] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/dp8390var.h?rev=1.36&content-type=text/x-cvsweb-markup
Regards,
Carlos
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | telnet://bbs.hispamsx.org | https://calnus.com

[Michael Schmitz]

Hi Carlos,

Hi Michael,
Sent: sábado, 1 de enero de 2022 23:36

Post by Michael Schmitz
I was under the impression that you could (cross-)build your own kernel
and initrd? If that's not an option, testing is going to be much harder.

I am afraid not, I am building Debian Installer kernel images and initrd from Aranym following the building instructions here [1]. If there is documentation for installing a cross-compiler toolchain I will gladly give a try.

ARAnyM should work, too. You just need to add the attached patch to the
list of patches applied (compile tested on 5.16-rc2) on top of the
mainstream kernel source - as far as I remember, Debian applies any
number of patches, and there is a file in the kernel image source
package that describes which patches are needed for a given
architecture. Haven't built a Debian kernel package in many years, so
can't be more specific than that, sorry.

Post by Michael Schmitz

In [2] there is a function called ne2000_detect_8bit() that is used

for that. It looks like it reads the card ROM to figure out. I don't
know if the CIS is considered a ROM or not.
No, that only figures out what mode is set in the 8390 chip - AFAIK
needed to support NE1000 type cards. With 16 bit NE2000 type cards, you
can still use 8 bit IO to access the chip, which is what the 10 Mbit
cards supported by the apne driver do. 100 Mbit cards need 16 bit IO.

I see. I seemed to me that useword var controlled the IO size and there was a part on the code where it assumed 16 bit, but later call the ne2000_detect_8bit() to determine if useword should be kept to 8 bit. Again, I am not familiar with this :)
---------------
/* not an NE1000 - try NE2000 */
/* try 16 bit mode first */
useword = 1;
#ifdef NE2000_DETECT_8BIT
/*
* Check bus type in EEPROM first because some NE2000 compatible wedges
* on 16 bit DMA access if the chip is configured in 8 bit mode.
*/
if (ne2000_detect_8bit(nict, nich, asict, asich))
useword = 0;
#endif
---------------

That's the access size for ring buffer memory access by the 8390 - even
the 8 bit PCMCIA cards use word size 2 (16 bit).

Accessing that ring buffer by the host processor is a different matter.

Post by Michael Schmitz
I'll have to create another patch to look for mem resources in the CIS
data, and get that tested on the already supported cards. Then use that
for new cards.

I will be glad to test on real hardware, provided I have some means to build a kernel and an initrd that allows me at least to boot a BusyBox :)

Let's try with this simple patch - the two cards are treated as NE2000
clones even though they fail the station address PROM signature check.
If that doesn't result in a working driver, we'll have to dump the
entire station address PROM contents, and the CIS data. The original
ne.c driver has a few more 'bad clone' signatures to compare the PROM
data to.

Cheers,

Michael

Regards,
Carlos
[1] https://salsa.debian.org/installer-team/debian-installer/
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | telnet://bbs.hispamsx.org | https://calnus.com

[Michael Schmitz]

Hi Carlos,

Hi Michael,
Many thanks for the patch! Let see if I can test on my Amiga somehow.
Sent: lunes, 3 de enero de 2022 8:24

Post by Michael Schmitz
ARAnyM should work, too. You just need to add the attached patch to the
list of patches applied (compile tested on 5.16-rc2) on top of the
mainstream kernel source - as far as I remember, Debian applies any
number of patches, and there is a file in the kernel image source
package that describes which patches are needed for a given
architecture. Haven't built a Debian kernel package in many years, so
can't be more specific than that, sorry.

It looks the Debian Installer build process retrieves the kernel from the Debian repository itself, but I don't find any documentation reference to apply a patch to it, maybe it is just not possible so I have to build my own kernel and inject it in the d-i build process; but I don't know how to do that. Maybe someone highly familiar with Debian can shed a bit of light? Adrian? It would be ideal to try the patch with the nativehd initrd, as the first thing the Debian Installer does in that image is to bring the network up.

You'll have to build your own kernel image binary package with the patch
included, and override the repository debian-installer uses for the
kernel image. As I've said, my exposure to building debian-installer is
minimal, and someone else (perhaps Adrian) would know a lot more about
this process.

Cheers,

Michael

Regards,
Carlos
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | telnet://bbs.hispamsx.org | https://calnus.com

[Michael Schmitz]

Hi Carlos,

I think you have to point your sources.list to the main Debian package
repository, not the debian-ports one. Source packages are shared by all
architectures, regardless of release or ports status.

Try

deb-src http://deb.debian.org/debian/ sid main

in your sources.list.

(untested, but can't do much damage if you try...)

Cheers,

Michael

Hi Michael,
Sent: miércoles, 5 de enero de 2022 7:39

Post by Michael Schmitz
You'll have to build your own kernel image binary package with the patch
included, and override the repository debian-installer uses for the
kernel image. As I've said, my exposure to building debian-installer is
minimal, and someone else (perhaps Adrian) would know a lot more about
this process.

-----
aranym:~# apt-get update
Get:1 http://deb.debian.org/debian-ports sid InRelease [65.8 kB]
Get:2 http://deb.debian.org/debian-ports unreleased InRelease [47.1 kB]
Get:3 http://deb.debian.org/debian-ports sid/main m68k Packages [22.1 MB]
Fetched 22.2 MB in 3min 35s (103 kB/s)
Reading package lists... Done
W: Skipping acquire of configured file 'main/source/Sources' as repository 'http://deb.debian.org/debian-ports sid InRelease' does not seem to provide it (sources.list entry misspelt?)
-----
-----
deb http://deb.debian.org/debian-ports/ sid main
deb http://deb.debian.org/debian-ports/ unreleased main
deb-src http://deb.debian.org/debian-ports/ sid main
# 'unreleased' does not support sources yet
# deb-src http://deb.debian.org/debian-ports/ unreleased main
-----
Is there a valid deb-src source for sid in Debian Ports? Where should my deb-src in sources.list point to?
Regards,
Carlos
[1] https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
Carlos Milán Figueredo | HispaMSX System Operator | http://www.hispamsx.org | | telnet://bbs.hispamsx.org | https://calnus.com

[Eero Tamminen]

Hi,

I wanted to make a quick update on this.
Sent: domingo, 9 de enero de 2022 0:43

Post by Michael Schmitz
Try
deb-src http://deb.debian.org/debian/ sid main

While this worked nicely, I were not able to build a custom kernel with the patch following the steps at [1], "4.2.2. Simple patching and building". As I didn't have enough time for further research, I had to halt at this step.
If there is any other way such as a cross-compiler toolchain that would allow me to patch the kernel and build it for m68k along with the d-i initrd, I will be more than glad to test it. I really appreciate the patch, Linux on Amiga (or on ANY platform) wouldn't be fun at all without networking.

Just build it directly?


This is how I build m68k kernels from upstream relases (for Atari
emulator) on my Debian PC:

0. Install generic build tools:
$ sudo apt install bc bison flex

1. Install compiler:
$ sudo apt install gcc-m68k-linux-gnu

2. Get latest upstream kernel release sources (without history):
$ git clone --depth 1 --branch v5.16 \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux

3. Apply Linux issue workaround patches:
$ git am /path/to/000*.patch

4. Use suitable configuration:
$ cp /path/to/kernel.config .config

5. Compile configured kernel:
$ ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- make -j4 vmlinux


- Eero

[Michael Schmitz]

Hi Carlos,

even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).

If you can send me your .config (or a link to download the kernel image
package), I'll compare with what I've used for v5.15.

The tricky part might be generating the initrd image in the cross build
setup - the script does not have an option to search for kernel image
and modules outside the cross build hosts' root fs AFAICS. You may have
to hack mkinitramfs or manually extract an existing initrd (cpio
archiive format) and repack after replacing the modules directory.

Cheers,

Michael

Hi,
de 2022 0:20

Post by Eero Tamminen
This is how I build m68k kernels from upstream relases (for Atari

Thanks for the clear steps, they worked nicely. I cloned the 5.15
branch instead of 5.16 to match my Aranym install which I also used
to get a .config for the kernel source (/boot/config-5.15.0-2-m68k).
However, after compiling I get a 114 MB vmlinux (or 63 MB if gziped),
that is way too big for the Amiga. The kernel images I use in Aranym
are just about 7 MB uncompressed. In kernel configuration,
CONFIG_CC_OPTIMIZE_FOR_SIZE is already enabled. Am I missing
something?
Carlos Milán Figueredo | HispaMSX System Operator |
http://www.hispamsx.org | telnet://bbs.hispamsx.org |
https://calnus.com

[Finn Thain]

Post by Michael Schmitz
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).

Maybe CONFIG_DEBUG_INFO needs to be disabled:
$ ./scripts/config -d CONFIG_DEBUG_INFO

An alternative approach would be,
$ make ARCH=m68k amiga_defconfig

Post by Michael Schmitz
If you can send me your .config (or a link to download the kernel image
package), I'll compare with what I've used for v5.15.
The tricky part might be generating the initrd image in the cross build
setup - the script does not have an option to search for kernel image
and modules outside the cross build hosts' root fs AFAICS. You may have
to hack mkinitramfs or manually extract an existing initrd (cpio
archiive format) and repack after replacing the modules directory.

If you're building your own, you can arrange to have the critical drivers
built-in i.e. just what's necessary to mount the rootfs. After that
modules can be loaded automatically.

[Michael Schmitz]

Hi Finn,

Post by Finn Thain

Post by Michael Schmitz
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).

$ ./scripts/config -d CONFIG_DEBUG_INFO

That appears to be the cause, yes.

But the size of the original vmlinux file (88 MB in my case with Carlos'
.config) is a red herring - what matters is the size of the uncompressed
kernel as loaded by the boot loader (after stripping off symbols and
debug info). My kernel build command does generate a 'vmlinux.gz' file
of 2.6 MB from the 88 MB original, which comes to 5.1 MB uncompressed.
That's perfectly OK.

I suspect the difference in size (7 MB vs. 5.1 MB) is due to gcc
versions. Either way, the solution is to use the vmlinux.gz file (and
eventually unzip that if amiboot can't load compressed images) instead
of vmlinux.

Post by Finn Thain
An alternative approach would be,
$ make ARCH=m68k amiga_defconfig

Post by Michael Schmitz
If you can send me your .config (or a link to download the kernel image
package), I'll compare with what I've used for v5.15.
The tricky part might be generating the initrd image in the cross build
setup - the script does not have an option to search for kernel image
and modules outside the cross build hosts' root fs AFAICS. You may have
to hack mkinitramfs or manually extract an existing initrd (cpio
archiive format) and repack after replacing the modules directory.

If you're building your own, you can arrange to have the critical drivers
built-in i.e. just what's necessary to mount the rootfs. After that
modules can be loaded automatically.

True - building udeb packages on a cross compile platform (as Carlos
would like to do) might be a little too tricky.

The problem with debian-installer is that the initial root filesystem is
the initrd, and the persistent root filesystem is populated from udebs
and regular packages fetched from the package repositories.

Having the apne driver (along with disk drivers, partition support and
filesystems required) built-in ought to allow that initial step to
complete, but this will leave you with kernel image and modules from the
udeb kernel packages installed on the disk root filesystem. You'd have
to copy the custom-built modules from the AmigaOS partition and install
them by hand at the end of the install.

The installer will attempt to load modules from the initrd to get to a
known sane system state before beginning the install AFAIR, so replacing
the modules on the initrd very likely will still be required.

I'll try replacing modules on an old initrd image using cpio to see how
far that gets me ...

Cheers,

Michael

[Michael Schmitz]

Hi Carlos

Post by Michael Schmitz
Hi Finn,

Post by Finn Thain

Post by Michael Schmitz
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).

$ ./scripts/config -d CONFIG_DEBUG_INFO

That appears to be the cause, yes.

Goes for the modules as well. Over 250 MB modules is a little tough to
load on any system. Definitely disable DEBUG_INFO as Finn suggested.

Post by Michael Schmitz
The installer will attempt to load modules from the initrd to get to a
known sane system state before beginning the install AFAIR, so replacing
the modules on the initrd very likely will still be required.
I'll try replacing modules on an old initrd image using cpio to see how
far that gets me ...

A few simple steps appear to be sufficient (assuming a tar archive of
the result of make modules_install is present in your current directory):

$ mkdir initrd-root/

$ cd initrd-root/

$ gunzip -c ../initrd-old.img.gz | cpio -i

$ rm -rf lib/modules/<whatever>

$ tar xpfz ../modules-<new_kernel_version>.tar.gz

$ find . | cpio -R 0:0 -o -H newc | gzip -c > ../initrd-new.img.gz

$ cd ..

Tested using ARAnyM and a .config of mine that doesn't have all required
code built as modules that the installer would expect. I saw a few
modules load before busybox ran into unexpected results so even though I
never got to see a proper installer prompt, I'm confident using the
correct .config will get you there.

I'll send a shell script I use to pack up kernel image and modules later.

Cheers,

Michael

[Michael Schmitz]

Hi Andreas,

Hello Michael,

Post by Michael Schmitz

Merry Christmas! I could finally make the tests.
Sent: lunes, 13 de diciembre de 2021 7:52

Post by Michael Schmitz
Look for a line containing "Looking for PCMCIA ethernet card : " in the
kernel log messages.

FL-4680
=======
Looking for PCMCIA ethernet card: ethernet PCMCIA card inserted
(unnamed net_device) (uninitialized): PCMCIA NE**00 ethercard probe not found

That's from apne_probe1 - the MAC address prefix does not match what
is expected (NE2000 or Ctron).
If you can tell me your cards' MAC addresses, I can add those prefixes
to the ones known to the driver, and send a patch for you to test.
Might need some more adjustments though (start and end address of ring
buffer).
You said the cards are supported by BSD? There might be information
about the ring buffer in the source there.

oh, where the Gayle memory map issues on the Amiga 1200 addressed, or is
this still not 16-bit, but 8-bit access?

Will still be 8-bit access - my patch series to autoprobe IO width and
enable 16-bit access is still under review by the netdev crowd.

This feels very familiar to where I got stuck like two years ago or so,
and then stopped pushing further because I'm still building an Amiga
4000 as proper development machine to also address other Amiga/A1200
issues while I'm at it ...

Oh dear - I'd get nowhere at all without cross compilation ...

I'd be happy to hear that was redone already!

I lost track how many respins that took... Version 13 of my patches is
where we're at now. Both the linux-m68k and netdev lists have them
(November 20th).

Have a good start into the new year, all of you on the list!

You, too - 3 hours to go, on this side of the planet!

Cheers,

Michael

count