Hi Michael,

>> I've been too busy with the other problems to work on the bootloader stuff
>> for a while.
>Me too - this interrupt problem gets on my nerves. Sure, I don't really
>need the audio board, but >deadlocks like that should just not happen.
>Besides that, the MPEG video IO board sits in the same bus, >thus sharing
>the same interrupt and would likely need an interrupt priority level
>higher than IPL_BIO too.
>

Probably not too much I can help with there. I'm going to try to get
somewhere on the mace issue.

>> I have also not decided if I want to go with adding pdisk
>> support to the bootloader or to make sure MBR support is up to date in
>> NetBSD/macppc. Old World Macs, which I do my testing on, appear to be quite
>> comfortable with MBR and it would eliminate bootxx for these models if one
>> didn't want to dual boot with MacOS on the same hard drive.
>I have NetBSD alone on a drive and I wouldn't like an MSDOS partition just
>for the boot loader.

Yes, this is a downside. It takes one of the four available MBR partitions.
On the plus side, I've noticed that when booted into OS X on my G4, it will
see the MSDOS MBR partition on the disk that contains my OpenBSD stuff
(which I'm trying to preserve but migrate to NetBSD). It won't see the FFS
stuff, at least not by default. Sometimes it'd be nice to be able to move
files from MacOS to *BSD and vice-versa, so a common MSDOS partition might
be useful. There is also a lot of opposition to MBR, though. For me, since
I do a lot of bootloader testing it makes sense though.

>> Using MBR
>> support instead gives me more options regarding testing bootloaders, as I
>> feel that as much hardware as possible should be configured before the
>> kernel sees it (somewhat like an extension to OF, which is what would
>> normally enable L2 and L3 caches).
>Agreed, the ethernet portion of the E100 card would be another candidate (
>OF doesn't see it for some >reason ), but that would pretty
>likely get too complex pretty soon.

Yes, if I understand your previous email regarding this, your card does not
contain any OF, in which case OF will only assign a node and basic
addresses.

>> I also swap CPUs from time to time and
>> I'd rather have the L2 configuring not hard coded into the kernel.
>Sure. I only did it because it was the only way to get the L2 cache
>enabled at all.

I had to write the code because I have a XLR8 ZIF Carrier card that lets me
swap in raw CPU chips, but it doesn't have any L2 information in OF with
it, obviously. I can probably advise someone on how to implement it in
ofwboot. It made a huge difference in boot speed, epecially on gz'd MD and
INSTALL images.

tim