At 6:10 PM -0500 9/4/2000, Peter wrote:
[...]
>So if the bootloader uses the system ROM to download and run on-card ROM then
>at least the card should stop annoying the system?, thus allowing a peaceful
>netbsd loading ;)

Except that the ROM drivers are often very buggy. For example, the ROM
driver for the built-in video on the IIsi (perhaps other models, I don't
recall off the top of my head) will crash when you call the slot int set
function. Since MacOS never uses that call, it was never properly debugged.
Some other ROM drivers just don't do anything when you call the slot int
set call (built-in SONIC driver, for example).


[...]
>>Like calling system functions, accessing low-memory globals, etc.
>
>But these accesses, are they not controllable .. ?, a function in kernel space
>can do many nasty things but they won't because they are designed what to do,
>and so it should be possible to do with these things too.
>A computer does what it is instructed to. (Maybe exception for Mac's then :-)

Well, there's really two ways to call non-native-os code. The first is to
make the native OS (bsd in this case) look enough like the os the code is
expecting for it to execute and exit without incident. I belive this is
what MRG does. It tends to be a big big hack, and much more trouble than
it's worth.

The other way is to write an 'emulator' of sorts that reads in and
reinterprets the instructions, following them in a way that's more
appropriate for the native OS. This method can be summed up conviniently in
5 letters: B L O A T.


>Anyway, is there any other caveats to controll the Mac at boot time,
>except for
>annoying interrupts?, any stuff that will mess a running program,
>if the program can't controll anything is another story.

Video mode switching comes to mind. I know there's no mode switching code
in Linux (except maybe for the Valkyrie video), and I don't recall there
being any in BSD or I would have stolen it by now. ;) The rom sets the
video mode to whatever is specified in the PRAM on startup. Changing that
would require booting into MacOS or reverse engineering more drivers, so
having the computer boot directly into BSD/Linux would make that much less
convinient.

IOP systems (IIfx, 9x0) would suffer, since there were many microcode
updates for that subsystem that fix huge bugs that the version loaded from
ROM contains.

I don't think PSC systems (660, 840) are well enough understood to say for
sure that something evil won't happen if an early-booter were used. Lots of
DMA voodoo there.


>What I know only IRQ, NMI, DMA. Can disturb a running computer program in a
>normal enviroemnt. So if IRQ's are told to shut up. DMA is nonexistent. And
>hopefully nothing triggers NMI except for things like parity error on RAM or
>similar. One should have a working instruction execution.

"IRQ" and "NMI" are treated identically on M68k, they're both just
interrupts. DMA can (and does) do evil things to the kernel on AV macs if
not switched off before loading the kernel. (Penguin has code to deal with
this, I don't know if the BSD booter does or not)


All in all, it's a whole lot of work for not much gain. Feel free to put in
the effort if you feel it's worth it though.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/