I've long through that linuxbios was a good idea; one needs a mechanism to bootstrap the computer from a ROM, and I liked the Sun model of using Openfirmware: put a little Forth interpreter on a ROM somewhere and have a uProc drive it to start up the big chip; devices strap themselves by putting a little forth program in ROM at some known address. The monitor probes those, loads and executes them. Much better than a BIOS, that existed for a machine that was crippled from the start. Sad, man.
I wonder what would have happened if IBM had used the MC68K instead of the 8088 for the original PC.... One could have had a ROM mapped to address 0, had a 4- or 8-bit shift register hang off the address strobe line to load the initial PC and SP, and top the shiftreg into a D-flipflop that remapped the ROM to a high address; load a teeny kernel from the ROM's new address and then use that to boot an OS that could remap interrupts etc. Tie the RESET line to reset said flip-flop; it would have been a superior design. On Thu, Aug 4, 2016 at 4:01 PM, ron minnich <[email protected]> wrote: > > This quote, from Linux, was an early inspiration for linuxbios (now > coreboot). The idea was that the kernel could take on tasks that firmware > did, or at least ignore all the mistakes firmware made. For a time, we even > showed how to do real SMP startup in Linux, not firmware, until the K7 made > a mess of things. (today's SMP startup is not even close to what you really > have to do ...) > > So in 1999 we envisioned a world in which the kernel took on more and more > startup tasks, and the firmware did less and less. Of course this is not > how it worked out. Linux is more dependent on firmware than ever. Firmware > (at least the UEFI kind) is as large and complex, at least, as Linux. In > fact in 4.x, Linux requires/assumes that the work defined below is done by > firmware or bootloader, or it will silently hang or fail on startup. It's > less capable than the Linux of the 90s. A pity. > > This is from 2.2 arch/i386/entry.S > > ! well, that went ok, I hope. Now we have to reprogram the interrupts :-( > ! we put them right after the intel-reserved hardware interrupts, at > ! int 0x20-0x2F. There they won't mess up anything. Sadly IBM really > ! messed this up with the original PC, and they haven't been able to > ! rectify it afterwards. Thus the bios puts interrupts at 0x08-0x0f, > ! which is used for the internal hardware interrupts as well. We just > ! have to reprogram the 8259's, and it isn't fun. > > mov al,#0x11 ! initialization sequence > out #0x20,al ! send it to 8259A-1 > call delay > out #0xA0,al ! and to 8259A-2 > call delay > mov al,#0x20 ! start of hardware int's (0x20) > out #0x21,al > call delay > mov al,#0x28 ! start of hardware int's 2 (0x28) > out #0xA1,al > call delay > mov al,#0x04 ! 8259-1 is master > out #0x21,al > call delay > mov al,#0x02 ! 8259-2 is slave > out #0xA1,al > call delay > mov al,#0x01 ! 8086 mode for both > out #0x21,al > call delay > out #0xA1,al > call delay > mov al,#0xFF ! mask off all interrupts for now > out #0xA1,al > call delay > mov al,#0xFB ! mask all irq's but irq2 which > out #0x21,al ! is cascaded > > ! Well, that certainly wasn't fun :-(. Hopefully it works, and we don't > ! need no steenking BIOS anyway (except for the initial loading :-). > ! The BIOS routine wants lots of unnecessary data, and it's less > ! "interesting" anyway. This is how REAL programmers do it. > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
