[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Successful install of a current NetBSD/bebox system
On Sun, 1 Jun 2014 23:46:38 +0100
David Brownlee <abs%absd.org@localhost> wrote:
> > 1. Reboot. All blinken lights (left and right) are activated. Then the
> > system hangs, until I manually press the reset buttons.
> Linux ran on the BeBox at one point - I wonder if it would be easy to
> check what it did to reboot?
I was unable to find the source for Linux on BeBox. And in recent source
archives it is no longer present.
But I guess there is no way to reset the system in software. There is a
board register to assert /HRESET and /SRESET to CPU 1, but not to CPU 0.
Maybe I can reset as many hardware registers as possible and then jump
into the boot ROM's reset vector?
> > 3. Similar problem when booting from disk. There is always one read
> > error, and it's always the same. No matter which disk or kernel:
> > func: F_READ
> > st0 = 0x44
> > st1 = 0x4
> > st2 = 0x10
> > c = 0x3
> > h = 0x1
> > r = 0x3
> > n = 0x2
> > The kernel loads nevertheless.
> What happens with the boot loader - does it get an error and
> automatically retry the request?
I guess so. The install kernel is stored using ustarfs, and libsa/ustarfs.c
retries the DEVSTRATEGY three times. So I guess it worked on the second
> I wonder it it could be something not initialised in the hardware?
> When you say "3.. from disk" is that IDE?
No. Floppy disk. :)
> > 4. Audio, wss(4), doesn't work. There is no crash or other malfunction,
> > but the internal speaker and the external audio connectors remain
> > silent
> Nothing that can be tweaked in mixerctl?
No, there are no "outputs". "mixerctl -a" shows the same variables as
in the example from the mixerctl(1) man page.
But "vmstat -i" shows that the audio interrupts are triggered, when
> > 6. mcclock(4) doesn't work correctly. The time after a cold-start is
> > wrong (e.g. "WARNING: preposterous TOD clock time"). Maybe I need a
> > new battery, but IIRC it worked under BeOS.
> It could be oddly parsed. If NetBSD writes something back to the TOD
> does BeOS see it as gibberish?
I have to replace the disk to start BeOS. Didn't have the time to do that.
I inserted some debugging output into sys/dev/ic/mc146818.c and saw
the driver was reading a time like 20:17:87. Maybe there is a problem
with a mis-detected BCD mode (87 would be 0x57)?
But before investigating any further I should check the RTC under BeOS
again and replace the battery.
> > 7. X11/Xorg doesn't work yet. Cannot map I/O space. But the correct
> > driver (S3) is recognized:
> > [ 888.123] (WW) xf86EnableIO -1
> > [ 888.126] (II) xf86EnableIO: ffffffff
> > [ 888.128] (WW) Can't map IO space!
> > [...]
> Wouldn't it be mem space rather than io space on a powerpc?
Sounds sensible. Probaby macallan@ would bring up X11 in no time. ;)
> > 9. Multiprocessor support. I compiled the GENERIC.MP kernel, but the
> > boot loader doesn't want to load it. A renamed GENERIC kernel works,
> > which is strange.
> > Boot: /dev/disk/scsi/000/0_0:netbsdmp
> > Loading /dev/disk/scsi/000/0_0:netbsdmp
> > illegal request, data = 0 0 0 0 24 0 0 cb 0 1 0 0 0 0 0 0 ff ff ff
> > ff 0 0 0 0
> > PHASE MSGIN: siop_clearfifo...
> > invalid status code 128
> > generic HBA error
> > siop_intr: I shouldn't be there !
> Could this be related to kernel size? Could you strip stuff out of
> GENERIC.MP until its smaller than GENERIC as a quick test?
Tried that, but didn't help. Now I even got this error when loading
a modified single-CPU kernel. :|
I noticed in siop.c that the siop_clearfifo() function was not yet
implemented. Probably this is the reason for all the following errors.
After implementing it, it looks like this:
illegal request, data = 0 0 0 0 24 0 0 cb 0 1 0 0 0 0 0 0 ff ff ff ff 0 0 0 0
DMA FIFO not empty!
illegal request, data = 0 0 0 0 24 0 0 ce 0 3 0 0 0 0 0 0 ff ff ff ff 0 0 0 0
open /dev/disk/scsi/000/0_0:netbsdtst: Input/ouput error
That's better (I'm printing "DMA FIFO not empty" inside siop_clearfifo)
although there is still a problem.
> > Something which would be very nice for the future: Support for APM
> > (Apple Partition Map) partitioned disks. So we could add a minimal Be_FS
> > partition with the boot loader, and there is no more need for the boot
> > disk. It might also be possible to co-exist with BeOS on one disk.
> Both mac68k and macppc have "some" support for APM - sounds like its
> part time being abstracted out to something more MI.
I have no idea about the other points yet. So no comment from me at this
time. I will continue my investigations whenever I find some time for it.
Main Index |
Thread Index |