On Mon, Apr 20, 2020 at 10:15:33AM +0900, rgc wrote: > On Thu, Apr 16, 2020 at 12:11:43PM +0200, Peter J. Philipp wrote: > > On Thu, Apr 16, 2020 at 05:06:25AM +0900, rgc wrote: > > > disabling scca probably will not work ... console uses this device > > > > > There you'll see the difference. I'll report back if my patch works. > > > > looking forward to your results
The mission is to get openbios compiled, but it uses a program called "toke" that I couldn't locate in OpenBSD ports. It also uses a script that gets executed before gmaking. I think if it were easy to build openbios on OpenBSD it would have been done in the ports. So my end result was that I stalled on this. I tried replacing the GNU Makefiles with BSD Makefiles but that didn't work. In a rage yesterday I deleted those and wasn't able to recover it. I think I'm giving up on this. > 1 now something nasty reared it's head on 6.7-beta :-( RAMDISK kernel > (used by bsd.rd) will not boot on qemu-4.2. > > openpic0 at macobio0 offset 0x40000: version 0x0 feature 3f0002 LE > panic: trap type 300 srr1 9032 at 2b9648 (0+0x2b9648) lr 2ddae0 > halted > > EXIT > 0 > > > sadly i've seen something similar when i was playing around with clang. > the error only occurs on qemu. and i never figured how to fix it. > (macppc 6.7-beta uses clang by default now) Hmm. That doesn't sound good. > 2 networking (SLIRP) > > -netdev user,id=network01 \ > -device sungem,netdev=network01 \ > > works. i could do a sysupgrade of an old 6.6-current image and > download the 6.7-beta files but then the system can not boot from > the qemu disk image. It's amazing how creative people get to just run qemu. I don't know if this is all worth it. I'm glad I have a G5 to back me up but not everyone is that lucky. I read that Amiga PPC's are booted by U-Boot not openbios, but doing the work is more than a weekend on my laptop and I don't have much time beyond that at the moment. Plus OpenBSD/macppc expects openfirmware not FDT as far as I know. Also getting both functionality into the kernel just for qemu can't really be justified, can it? > regards, > rgc Best Regards, -peter
