Hello, Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
Also is there any status update on GRUB2 booting UHCI?
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
bug #96 on our tracker (assigned to me) is about being able to configure the default location for grub.cfg. I'll work on it, once I got USB storage done. which brings me to..
Also is there any status update on GRUB2 booting UHCI?
GRUB2 read disk size and sectors from (QEmu emulated) usb storage devices for the first time this morning. This was just some test on device initialization, but still. My next step is to make it available from grub2 as normal disk, which might happen before saturday evening.
For the time being, that code still profits from qemu's emulation being relaxed in some areas, so it will take some more days to make it ready for general consumption (ie. real hardware).
Regards, Patrick
On Thu, 8 May 2008 19:43:47 +0200, Patrick Georgi patrick@georgi-clan.de wrote:
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
bug #96 on our tracker (assigned to me) is about being able to configure the default location for grub.cfg. I'll work on it, once I got USB storage done. which brings me to..
Also is there any status update on GRUB2 booting UHCI?
GRUB2 read disk size and sectors from (QEmu emulated) usb storage devices for the first time this morning. This was just some test on device initialization, but still. My next step is to make it available from grub2 as normal disk, which might happen before saturday evening.
For the time being, that code still profits from qemu's emulation being relaxed in some areas, so it will take some more days to make it ready for general consumption (ie. real hardware).
Exellent! Great to hear Patrick:-) Keep up the great work! If there is anything I can do to help out let me know.
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Also is there any status update on GRUB2 booting UHCI?
ask, and you shall receive ;-)
http://openbios.org/~oxygene/usb/
Explanation what happens there:
Screen 1: first, there were only a few devices: ata in various forms, and memdisk second (an invisible step), I added the usb device (usb_add disk:img) third, I ran lsusb, which is currently responsible for device probing
Screen 2: I ran ls again, and yay, there are (usb0) and (usb0,1) (disk&partition)
Screen 3: Let's see, what's on there: (usb0,1) is of type FAT, labelled FREEDOS9RC5 It contains the various files shown above
Screen 4: Let's take a look into autoexec.bat
I committed the code in the usb.experiment branch and merged it back to the usb branch. See http://www.coreboot.org/viewmtn/
It very likely won't work on real hardware, because I didn't implement all parts of the USB spec yet - notably toggle bit handling (flow control mechanism) and error handling. Toggle bits are next, and with that, it might work in an "error free" environment already.
Regards, Patrick
Patrick Georgi wrote:
http://openbios.org/~oxygene/usb/
Explanation what happens there:
Screen 1: first, there were only a few devices: ata in various forms, and memdisk second (an invisible step), I added the usb device (usb_add disk:img) third, I ran lsusb, which is currently responsible for device probing
Screen 2: I ran ls again, and yay, there are (usb0) and (usb0,1) (disk&partition)
Screen 3: Let's see, what's on there: (usb0,1) is of type FAT, labelled FREEDOS9RC5 It contains the various files shown above
Screen 4: Let's take a look into autoexec.bat
Thank you, Patrick!
This is excellent work.
On Thu, 08 May 2008 22:18:44 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Patrick Georgi wrote:
http://openbios.org/~oxygene/usb/
Explanation what happens there:
Screen 1: first, there were only a few devices: ata in various forms, and memdisk second (an invisible step), I added the usb device (usb_add disk:img) third, I ran lsusb, which is currently responsible for device probing
Screen 2: I ran ls again, and yay, there are (usb0) and (usb0,1) (disk&partition)
Screen 3: Let's see, what's on there: (usb0,1) is of type FAT, labelled FREEDOS9RC5 It contains the various files shown above
Screen 4: Let's take a look into autoexec.bat
Thank you, Patrick!
This is excellent work.
Yes, yes, excellent work! I am very excited about this!
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
After some discussion with Stefan, we agreed that it would be more flexible to stick to (memdisk)/grub.cfg as default.
This configfile could then pass control to some other config, by writing "configfile (ata0,1)/grub.cfg" in it.
This is more flexible because you don't have to recompile grub to change the target (just add a new grub.cfg in coreboot v3, or redo mkdiskimage/mkimage for coreboot v2).
This is also more flexible, because you could (with some effort) have the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them. That way, it doesn't matter, if you have it on (ata0,1), (ata0,5), (ata2,17), or (usb0,1).
Is that okay for you?
Regards, Patrick
On Fri, May 09, 2008 at 03:31:35PM +0200, Patrick Georgi wrote:
(memdisk)/grub.cfg
Is (memdisk) the LAR? Could we harmonize the names in that case?
I think this is rather important.
//Peter
Patrick Georgi wrote:
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
After some discussion with Stefan, we agreed that it would be more flexible to stick to (memdisk)/grub.cfg as default.
This configfile could then pass control to some other config, by writing "configfile (ata0,1)/grub.cfg" in it.
also, you can add the command "coreboot" before the configfile command and have grub2 parse your serial port config with that from the coreboot table.
Stefan
Peter Stuge wrote:
On Fri, May 09, 2008 at 03:31:35PM +0200, Patrick Georgi wrote:
(memdisk)/grub.cfg
Is (memdisk) the LAR? Could we harmonize the names in that case?
I think grub2 splits this up.. There is a larfs, and a memdisk device. It used to be (lar) iirc but Patrick adapted it to existing grub2 behavior. Not sure if I get this right. memdisk might also only be the grub2 compiled in "memdisk", while (lar) at least used to be the hunk that was found in the rom.
On Fri, 9 May 2008 15:31:35 +0200, Patrick Georgi patrick@georgi-clan.de wrote:
Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe joe@settoplinux.org:
Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader.
After some discussion with Stefan, we agreed that it would be more flexible to stick to (memdisk)/grub.cfg as default.
This configfile could then pass control to some other config, by writing "configfile (ata0,1)/grub.cfg" in it.
This is more flexible because you don't have to recompile grub to change the target (just add a new grub.cfg in coreboot v3, or redo mkdiskimage/mkimage for coreboot v2).
This is also more flexible, because you could (with some effort) have the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them. That way, it doesn't matter, if you have it on (ata0,1), (ata0,5), (ata2,17), or (usb0,1).
Is that okay for you?
Yes, I think that would work out fine. What kind of effort would it take for "the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them" ?? I think this would kind of neat, almost like looking for the boot/partition table on the mbr of each drive.
Am Fri, 09 May 2008 16:00:42 +0200 schrieb Stefan Reinauer stepan@coresystems.de:
Peter Stuge wrote:
Is (memdisk) the LAR? Could we harmonize the names in that case?
I think grub2 splits this up.. There is a larfs, and a memdisk device. It used to be (lar) iirc but Patrick adapted it to existing grub2 behavior. Not sure if I get this right. memdisk might also only be the grub2 compiled in "memdisk", while (lar) at least used to be the hunk that was found in the rom.
(lar) existed only in the gsoc tree. After the grub2 team reimplemented the linuxbios support, I adopted their tree and continued work from there. As they have their own ramdisk mechanism now, I adopted it (6 lines patch vs. several new files).
The situation on the i386-linuxbios platform is now as follows:
(memdisk) points to the ROM area by default (currently hardcoded to 4gb - 256kb or so, eventually this should be read out from the ROM), so together with lar (which implements lar as filesystem), you get instant access to the archive structure of a coreboot v3 firmware.
If you're on coreboot v2, or if you use coreboot v3 and don't want to add files to the archive for some reason, you can use a diskimage module, as created by grub-mkdiskimage, to redirect (memdisk) to a different memory location - one inside the diskimage module, which carries the data you passed to grub-mkdiskimage.
So (memdisk) is supposed to Do The Right Thing on v3, and provide a sensible way to have a ramdisk with v2. As it's an abstraction, neither (firmware), nor (lar) (it could be cpio formatted, as well) fits well.
And given that the other platforms use (memdisk), reusing that name can't hurt.
Patrick
Am Fri, 09 May 2008 10:51:01 -0400 schrieb Joseph Smith joe@settoplinux.org:
Yes, I think that would work out fine. What kind of effort would it take for "the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them" ?? I think this would kind of neat, almost like looking for the boot/partition table on the mbr of each drive.
a crude variant of it would be adding the "search" module, then having a (memdisk)/grub.cfg like:
search -f -s /grub.cfg configfile /grub.cfg
search looks for the file (-s) called (/grub.cfg) on all devices, and set a variable (-s) to the first one that carries that file. If no variable name is given, "root" is used, which is used as default device, so configfile /grub.cfg uses that.
the search command should probably be extended to be able to omit devices (eg. memdisk - no endless loop possible), and to find the second, third, ... device.
Patrick
On Fri, 9 May 2008 21:09:20 +0200, Patrick Georgi patrick@georgi-clan.de wrote:
Am Fri, 09 May 2008 10:51:01 -0400 schrieb Joseph Smith joe@settoplinux.org:
Yes, I think that would work out fine. What kind of effort would it take for "the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them" ?? I think this would kind of neat, almost like looking for the boot/partition table on the mbr of each drive.
a crude variant of it would be adding the "search" module, then having a (memdisk)/grub.cfg like:
search -f -s /grub.cfg configfile /grub.cfg
search looks for the file (-s) called (/grub.cfg) on all devices, and set a variable (-s) to the first one that carries that file. If no variable name is given, "root" is used, which is used as default device, so configfile /grub.cfg uses that.
the search command should probably be extended to be able to omit devices (eg. memdisk - no endless loop possible), and to find the second, third, ... device.
That sounds pretty cool. I like it :-)
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Friday, May 09, 2008 3:09 PM To: joe@settoplinux.org Cc: Coreboot Subject: Re: [coreboot] GRUB2 Questions
Am Fri, 09 May 2008 10:51:01 -0400 schrieb Joseph Smith joe@settoplinux.org:
Yes, I think that would work out fine. What kind of effort would it take for "the (memdisk)/grub.cfg look up the available devices and search for grub.cfg files there, passing control to them" ?? I think this would kind of neat, almost like looking for the boot/partition table on the mbr of each drive.
a crude variant of it would be adding the "search" module, then having a (memdisk)/grub.cfg like:
search -f -s /grub.cfg configfile /grub.cfg
search looks for the file (-s) called (/grub.cfg) on all devices, and set a variable (-s) to the first one that carries that file. If no variable name is given, "root" is used, which is used as default device, so configfile /grub.cfg uses that.
the search command should probably be extended to be able to omit devices (eg. memdisk - no endless loop possible), and to find the second, third, ... device.
Why would searching memdisk create a endless loop?? You could just create a search_disk() function with a for or while loop and a break when it reaches a certain point, right?
Here is a thought. Before searching, is it possible to count how many files there are in the current directory? And, then it could run the for or while loop for that many times and if it doesn't find grub.conf, break and move on?
We could even specify only a few directories to search in to speed the search process up.
Joe schrieb:
Why would searching memdisk create a endless loop??
If memdisk comes first (for whatever reason), and (memdisk)/grub.cfg looks for first occurrence of /grub.cfg on any device, it will find (memdisk)/grub.cfg, enter it, search again, enter itself, ... Of course, it could be protected by a variable (similar to the #ifndef/#define stuff in C headers). But then, where should it look next, if it called itself?
We could even specify only a few directories to search in to speed the search process up.
"search" searches for an absolute path, and I think that makes sense. (You could, of course, search for both /grub.cfg and /boot/grub/grub.cfg)
Patrick
On Sat, May 10, 2008 at 12:44 AM, Patrick Georgi patrick@georgi-clan.de wrote:
If memdisk comes first (for whatever reason), and (memdisk)/grub.cfg looks for first occurrence of /grub.cfg on any device, it will find (memdisk)/grub.cfg, enter it, search again, enter itself, ...
if it's that badly designed then it ought to be fixed.
ron
ron minnich wrote:
On Sat, May 10, 2008 at 12:44 AM, Patrick Georgi patrick@georgi-clan.de wrote:
If memdisk comes first (for whatever reason), and (memdisk)/grub.cfg looks for first occurrence of /grub.cfg on any device, it will find (memdisk)/grub.cfg, enter it, search again, enter itself, ...
if it's that badly designed then it ought to be fixed.
It's nothing that is builtin to grub2... it's just a small script hacked up to allow looking on any device for a "real" config.
The fix is probably easy. Just don't look in (memdisk) for grub.cfg, because that's the script that is already executed.
Stefan
On Sat, May 10, 2008 at 10:29:29PM +0200, Stefan Reinauer wrote:
if it's that badly designed then it ought to be fixed.
The fix is probably easy. Just don't look in (memdisk) for grub.cfg, because that's the script that is already executed.
That script could be somewhere else too I guess, better skip ($SELF) than a fixed device.
//Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of ron minnich Sent: Saturday, May 10, 2008 4:15 PM To: Patrick Georgi Cc: joe@settoplinux.org; Coreboot Subject: Re: [coreboot] GRUB2 Questions
On Sat, May 10, 2008 at 12:44 AM, Patrick Georgi patrick@georgi-clan.de wrote:
If memdisk comes first (for whatever reason), and (memdisk)/grub.cfg looks for first occurrence of /grub.cfg on any device, it will find (memdisk)/grub.cfg, enter it, search again, enter itself, ...
if it's that badly designed then it ought to be fixed.
I don't think anything is written in stone yet. I think the creative juices are still flowing. But I agree, any code that has any kind of an open end allowing the ever dreaded endless loop is only the result of poor coding. That is one of the first things they taught us in c++ 101.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Peter Stuge wrote:
On Sat, May 10, 2008 at 10:29:29PM +0200, Stefan Reinauer wrote:
if it's that badly designed then it ought to be fixed.
The fix is probably easy. Just don't look in (memdisk) for grub.cfg, because that's the script that is already executed.
That script could be somewhere else too I guess, better skip ($SELF) than a fixed device.
Sure. Any patches, scripts, ideas are welcome.
-
Joe -
Joseph Smith
-
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer