Port-m88k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD/luna88k

> 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://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.


> 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

Home | Main Index | Thread Index | Old Index