OK Peter and Jordan...you have prevoked a challenge. Would eithor of you care to put a wager on the fact I bet I can get to the GRUB menu based on the MBR's data without using any kind of real mode interrupt handler with FILO???
Joseph Smith wrote:
Would eithor of you care to put a wager on the fact I bet I can get to the GRUB menu based on the MBR's data without using any kind of real mode interrupt handler with FILO???
I am not interested.
You will certainly not come anywhere near GRUB stage 1.5 without some number of real mode BIOS interrupts.
If you don't use any GRUB code but only FILO code you can certainly try to find GRUB's menu.lst by emulating what GRUB stage 1 does, but because device names are assigned differently in BIOS (which is the abstraction used by GRUB) and FILO, the file is useless unless it is adjusted for FILO's device names. (Then it becomes useless for GRUB of course.)
This is pointless. But let's talk that new boot spec.
//Peter
On 11/09/08 18:56 -0400, Joseph Smith wrote:
OK Peter and Jordan...you have prevoked a challenge. Would eithor of you care to put a wager on the fact I bet I can get to the GRUB menu based on the MBR's data without using any kind of real mode interrupt handler with FILO???
Seeing as how grub-legacy stage1 makes a int 13 call 19 instructions from the start, I am skeptical.
What you would have to answer is how you expect GRUB to be able to read the disk(s) in order to construct the information without int 13 support. GRUB does not come with any disk drivers of its own.
Furthermore what you are trying to do is something that grub-legacy and FILO already do - both operate in pretty much the same fashion - they both access drives looking for a configuration file of a certain name, which they read and parse. The only difference is that FILO has the disk driver code built in (and it executes in 32 bit flat mode), whereas GRUB starts execution in real mode and uses software services to accomplish what it needs.
The idea that paths and names and numbers don't match across all the components of the boot is an age old problem that everybody has. Legacy BIOS numbering runs smack into bootable SATA and USB drives which runs smack into a kernel naming scheme is that not very logical. Yes, this is a pretty darn big problem, and GRUB2 has had to address it as well. They have chosen to rely more on drive IDs and disk labels, which may or may not be a good solution for us. Time and experimentation will tell.
But what you are doing is probably not the way to go about what you want to accomplish. If you want to play with SeaBIOS, then I'm sure Kevin would be happy to have the help. If you want to experiment with a coherent naming scheme, then FILO knows how to access ATA and USB drives in a number of filesystem formats (and I'm sure you could probably add more if you wanted to). That, I believe is a better use of your time and energy.
Jordan
-
Jordan Crouse -
Joseph Smith -
Peter Stuge