Re: MTX604-010A status

David Brownlee <[email protected]> Mon, 14 Dec 2009 12:12:42 +0000
Newsgroups gmane.os.netbsd.ports.prep
Message-ID <[email protected]>
2009/12/13 John D. Baker <[email protected]>:
>
> As seems to have always been the case, the boot procedure is fragile
> and it can take as much as an hour to finally get a kernel running.
> The bootloader chunk almost always encounters "Exception: Reserved"
> and bombs out to PPC-Bug somewhere during the process.  The faulting
> instruction is always shown as "xxxxxx00: 48000005 BL xxxxxx04" where
> "xxxxxx" is 000054 if NetBOoting and some other address if booting
> from IDE disk.  Every so often it gets "Floating Point Not Available".
>
> Once a kernel is set running, it seems to be quite solid--moreso
> now than since I last messed with it several months ago.  I used to
> see the slide0 lose interrupts and hang the machine.  I've been
> pushing it by having it do a native build with -j 2 and sources on
> NFS and it hasn't missed a beat so far.
>
> It would be nice to figure out how to make booting less/not broken.
> Might have to dig at some of the ancient Debian stuff I have lying
> around for ideas.  I don't recall it failing to boot.

That sounds like a very worthwhile quest - few people would have
enough patience to sit for an hour retying a boot procedure :/

> Then maybe revisit how to get the second CPU running.  Again, some of
> the old Debian stuff might give ideas--kernel 2.2.13, IIRC, had working
> SMP on this box.  Just for the record, it appears that if one switches
> active CPU in PPC-Bug ("RUN 1") before booting, the kernel bootload
> seems not to run at all.
>
> Or perhaps a side-trip into wscons (and Xorg) land(s).  My board has
> a CirrusLogic CLGD-543x-based video card in it.  PPC-Bug knows how
> to set up these cards for text mode and will use it if a keyboard is
> present.
>
> Somewhere in my Debian stuff I have "Xbh" which is an X server built
> for penguin-OS on the Motorola BlackHawk embedded PPC boards which have
> a CLGD-543x chip on board.  I could use it in 8-bit mode.  It could
> almost work in 16-bit mode, but the display had vertical banding and
> other distortions that made it unusuable.  Unfortunately the "Xbh" I
> have is a monolithic binary executable only, but was supposedly built
> from XFree86 3.3.0 "SVGA" driver sources, IIRC.

If you can get PPC-Bug to leave the card in graphics mode then an
easy-ish first step might be to just attach it as genfb() - assuming a
mapped linear framebuffer all you need is the base address, width,
height, & bitdepth and you should be able to use it as a graphical
console plus run an Xwsfb X server.

Obviously a specific driver which could change modes and use any
hardware acceleration would be even better, but its its always nice to
have an easier first stage :)