Re: NetBSD/luna88k

[Timothy McIntosh <tkmcintosh%me.com@localhost>]

> It would be great if we can get svn repo data on your work.

FYI - The old SVN repository should be accessible again at any of the following URLs:

http://trac.gds.radiofreeomaha.net/NetBSD/
http://hoth.radiofreeomaha.net/svn/NetBSD/
http://hoth.radiofreeomaha.net:3000/svn/NetBSD/ - deprecated

Please let me know if it doesn’t work.  I have a rather convoluted legacy network configuration that needs reworked.  It will be rather slow, as this is going through a proxy server hosted in a VM on a slow machine, with the SVN sever residing on an even slower machine that is mounting an NFS share containing the SVN repository from the machine that hosts the proxy server.

Thanks,
Tim

> On Jul 29, 2022, at 11:13 AM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
>> Cool!
> 
> Thanks, and I'm really glad you are still on port-m88k :-)
> 
>> I always wanted to get back to the m88k projects, but sadly
>> haven't been able to work on it since that time. I didn't
>> realize my m88k/NetBSD website was offline. I'll have to
>> check into that when I get a chance.
> 
> It would be great if we can get svn repo data on your work.
> 
> It looks there are only one major problem around syscall stub in libc
> to get single user with /bin/sh, i.e. your NetBSD/m88k work seems
> almost complete.
> 
> 
> On NetBSD, src/lib/libc/sys/Makefile.inc has ${NOERR} definitions
> for syscalls that never fail, and in that case conditional branches
> to cerror() are omitted.
> 
> On the other hand OpenBSD doesn't have ${NOERR} handling and its
> kernel syscall functions unconditionally adjust return addresses
> to skip branch instruction after tb0.
> 
> NetBSD/m88k kernel uses the sililar systemcall implementation
> with OpenBSD/m88k, then all syscalls from libc that never fail
> (like getpid(2) and getuid(2) etc.) don't work properly.
> https://github.com/tsutsui/netbsd-src/commit/4dbb521ef229070854eed8ca46375a7dba7ddce6
> 
> It looks this fix solves the following problems you noted in your Trac:
> * init(8) exits with code 1
> -> caused by getuid(2) failure in sbin/init/init.c
> * debug serial garbage output problem with /bin/sh 
> -> maybe unexpected syscalls (write(2)?) were invoked
>    after a wrong return of ${NOERR} syscalls
> 
> Another notable fix is snooping settings for m88200:
> https://github.com/tsutsui/netbsd-src/commit/4bc83f175d1e0213f9032b7db90d506ca73b8b95
> but I'm not sure this is related to your CPU error exception issue
> on youe MVME187.  Maybe several DMA and cache issue remains, but
> fortunately luna88k devices don't use DMA.
> 
> 
> After one more fix around vunmapbuf(9)
> https://github.com/tsutsui/netbsd-src/commit/54e4f8d48a8e0220a5bdd949daab0b107ab34ef0
> now NetBSD/luna88k almost gets multi user login shell, but
> it looks there is something wrong around /usr/bin/login binary.
> https://www.youtube.com/watch?v=xtp4LDtDgxc
> 
> 
> Note Kenji Aoyama, a maintainer of OpenBSD/luna88k, reported
> my NetBSD/luna88k kernel (that worked on nono) didn't boot
> on his (real) LUNA-88K2 with three CPUs.
> https://twitter.com/ao_kenji/status/1548619367906430976
> 
> I'm not sure it's K2 specific, multi CPU specific, or differences
> between emulators and real hardware.
> 
>> Would be nice if it could be brought up to date. I see there's
>> this now: https://github.com/redstar/llvm-m88k
> 
> Yeah, several people also say that. Maybe we should make NetBSD/m88k
> stable first as OpenBSD/m88k, then worth to try next toolchains.
> 
> Again thanks,
> ---
> Izumi Tsutsui