Timeline for Why isn't the BIOS' ROM chip made using CMOS technology?
Current License: CC BY-SA 4.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 13, 2018 at 23:35 | comment | added | Chris Stratton | @AliChen - on embedded systems, the initial transfer is typically a built-in function of the chip, presumably either a state machine or a small fixed boot routine in on-chip ROM. Typically this would transfer a fixed sized block which should contain a custom loader stub, which would typically configure DRAM and then transfer the rest of a full-capability bootloader or bios or the operating system kernel. Many modern FPGAs can do this too, automatically operating an SPI flash to read their configuration bitstream. | |
Jul 13, 2018 at 23:24 | comment | added | Ale..chenski | Chris Stratton, "but rather use serial NOR flash and transfer the contents into faster RAM for execution" And how exactly do you envision this "transfer of content" other than executing some initial "data move" code directly from SPI? | |
Jul 12, 2018 at 2:30 | comment | added | forest | Please see stackoverflow.com/questions/5300527/… which explains this in more detail. In particular, how the BIOS boot block is executed directly over SPI. This is possible by mapping that area of the BIOS to memory (of course, before memory is actually initialized, so it's just like MMIO). So it's not just likely to be true, it is true. | |
Jul 12, 2018 at 2:25 | comment | added | forest | Yes, once the main memory is initialized, the IVT, BDA, EBDA, etc are copied over there. Before that however, it is executed directly. It is not executed in cache (that would be CAR mode, Cache-As-RAM, which requires explicit initialization by the BIOS). | |
Jul 11, 2018 at 4:07 | comment | added | Chris Stratton | @forest - that's unlikely to be true, and is not actually supported by the rather broad description at your link. It may end up executing out of some repurposed cache ram or something, but execution directly from SPI just doesn't work very well, and it's extremely likely to be avoided. It's then quite obvious that once the main system RAM is up the bios is going to execute out of that - such shadowing was common even in the days of parallel EPROM bios. | |
Jul 10, 2018 at 3:54 | comment | added | forest | When the CPU is first starting up, the RAM isn't even initialized (DRAM init is complex). All it does is execute code at a specific location (usually it's the BIOS chip over SPI, but supposedly you can program subsequent boots to look for the BIOS over legacy PCI or LPC for debugging reasons). The only thing that is put into RAM is stuff like the IVT (Interrupt Vector Table) and related code that's only useful before switching out of real mode. The actual BIOS execution when the CPU is booting does not happen in memory. See wiki.osdev.org/System_Initialization_(x86) for more details. | |
Jul 8, 2018 at 19:01 | history | edited | Chris Stratton | CC BY-SA 4.0 |
added 166 characters in body
|
Jul 8, 2018 at 18:59 | history | rollback | Chris Stratton |
Rollback to Revision 2
|
|
Jul 8, 2018 at 18:08 | vote | accept | user6039980 | ||
Jul 8, 2018 at 17:32 | history | edited | Jack Creasey | CC BY-SA 4.0 |
added 4 characters in body
|
Jul 8, 2018 at 17:05 | history | edited | Chris Stratton | CC BY-SA 4.0 |
deleted 1 character in body
|
Jul 8, 2018 at 16:59 | history | answered | Chris Stratton | CC BY-SA 4.0 |