Re: Is the Technologic Systems TS-7200 still supported?

["Kulesa, Craig A - (ckulesa)" <ckulesa%email.arizona.edu@localhost>]

> On Oct 20, 2019, at 11:22 AM, Kulesa, Craig A - (ckulesa) <ckulesa%email.arizona.edu@localhost> wrote:
> 
> 
> 
>> On Oct 19, 2019, at 8:54 PM, John Rash <johnrash%gmail.com@localhost> wrote:
>> 
>> Is the Technologic Systems TS-7200 still supported in NetBSD 8? The
>> install and gzimg files referenced in the install doc don't seem to
>> exist on the FTP server for NetBSD 8 or 8.1. I see the files in some
>> recent snapshots of -current but maybe the gzimg files are too big to
>> fit in the onboard flash?
> 
> I can confirm that the TS-7200 works well in NetBSD 8.1.  I've been doing my own EABI builds for armv4 with a trimmed, modular kernel here:
> 

And from the ''better late than never'' department -- another data point for anyone still running the venerable TS-7200 with any version of NetBSD.

Historically, a few of us noted an occasional hang either prior to executing the kernel, or an occasional VM-related kernel panic after doing the first memory-intensive operation after boot.

The issue appears to be related to garbage on the ethernet registers in Redboot.  The problem can be most reliably reproduced by loading a kernel over the network via Redboot and attempting to boot from it.  Some fraction of the time it will either hang immediately at Redboot, or it will boot but cause a panic as soon as you try to do anything vaguely memory-intensive (which is not hard on a 32 MB system).

This can be avoided by pulling the ethernet jack after loading the kernel image over the network, but before booting from it.  As this is not helpful for remote systems, a software reset of the ethernet phy can be done by setting the RESET bit of the SelfCtl register.  From the kernel sources, the epe0 driver does this during initialization but by then it is apparently too late.

For ethernet users, the solution in Redboot is to add a line to the startup script in fconfig:

mfill -b 0x80010020 -l 4 -p 0x1 -4
go 0x60660000

I have a few NetBSD 7.x systems in continuous use that routinely have >1 year uptimes with this fix.   I can submit a patch to the Installation documentation, if there is not a more elegant or appropriate solution.

Best,
-Craig