grub as coreboot payload

grub as coreboot payload

[Andreas B. Mundt]

Hi,

first, congratulations to the 1.97-release!

I vainly tried to run the latest grub2 (Revision: 2663) as payload to
coreboot (Revision: 4852) following the wikipage: 

	  http://grub.enbug.org/CoreBoot

Is this page still up to date and does anybody use grub2 as payload
successfully? How? 

The latest lines in qemu's serial console (from coreboot) I get are:
    [...]
    Jumping to boot code at 8200
    entry = 0x00008200
    [...]
    elf_boot_notes = 0x00011b78
    adjusted_boot_notes = 0x07fe7b78  

So it looks to me as if grub (the payload) is found but nothing more
happens. Any hints are appreciated.   

Thanks,

	Andi

Re: grub as coreboot payload

[Robert Millan]

On Mon, Oct 26, 2009 at 09:20:53PM +0100, Andreas B. Mundt wrote:
> Hi,
> 
> first, congratulations to the 1.97-release!
> 
> I vainly tried to run the latest grub2 (Revision: 2663) as payload to
> coreboot (Revision: 4852)

Is that coreboot v2 or v3?

> following the wikipage: 
> 	  http://grub.enbug.org/CoreBoot

Which module selection?

> The latest lines in qemu's serial console (from coreboot) I get are:
>     [...]
>     Jumping to boot code at 8200
>     entry = 0x00008200
>     [...]
>     elf_boot_notes = 0x00011b78
>     adjusted_boot_notes = 0x07fe7b78  

Did you check the local console? :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: grub as coreboot payload

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Mon, Oct 26, 2009 at 09:20:53PM +0100, Andreas B. Mundt wrote:
> Hi,
> 
> first, congratulations to the 1.97-release!
> 
> I vainly tried to run the latest grub2 (Revision: 2663) as payload to
> coreboot (Revision: 4852) following the wikipage: 
> 
> 	  http://grub.enbug.org/CoreBoot
> 
> Is this page still up to date and does anybody use grub2 as payload
> successfully? How? 

Hi,

It appears that since r4534 (move to Kconfig), Multiboot information is no
longer built in by default.  You have to enable it in "System tables" /
"Generate Multiboot tables (for GRUB2)", then GRUB works fine (at least
on QEMU, which I just tested).

Coreboot developers: would you consider enabling it again?  The overhead
is minimal, and it would make this less confusing for users.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[-- Attachment #2: multiboot.diff --]
[-- Type: text/x-diff, Size: 376 bytes --]


Signed-off-by: Robert Millan <rmh.grub@aybabtu.com>

Index: src/Kconfig
===================================================================
--- src/Kconfig	(revision 4887)
+++ src/Kconfig	(working copy)
@@ -319,7 +319,7 @@
 
 config MULTIBOOT
 	bool "Generate Multiboot tables (for GRUB2)"
-	default n
+	default y
 
 config GENERATE_ACPI_TABLES
 	depends on HAVE_ACPI_TABLES

Re: [coreboot] grub as coreboot payload

[Robert Millan]

On Thu, Oct 29, 2009 at 09:58:30AM +0100, Stefan Reinauer wrote:
> Robert Millan wrote:
> > On Mon, Oct 26, 2009 at 09:20:53PM +0100, Andreas B. Mundt wrote:
> >   
> >> Hi,
> >>
> >> first, congratulations to the 1.97-release!
> >>
> >> I vainly tried to run the latest grub2 (Revision: 2663) as payload to
> >> coreboot (Revision: 4852) following the wikipage: 
> >>
> >> 	  http://grub.enbug.org/CoreBoot
> >>
> >> Is this page still up to date and does anybody use grub2 as payload
> >> successfully? How? 
> >>     
> >
> > Hi,
> >
> > It appears that since r4534 (move to Kconfig), Multiboot information is no
> > longer built in by default.  You have to enable it in "System tables" /
> > "Generate Multiboot tables (for GRUB2)", then GRUB works fine (at least
> > on QEMU, which I just tested).
> >
> > Coreboot developers: would you consider enabling it again?  The overhead
> > is minimal, and it would make this less confusing for users.
> >
> >   
> 
> Just checked, they're placed somewhere in the F segment.
> 
> That means they'll be overwritten when SeaBIOS is used as payload. Not
> tragic, but is there a better place we can put them? or would this even
> be unhealthy or useless?

It is useless.  It would become useful when SeaBIOS supports Multiboot.

But then, in order to get the main benefit of that (being loadable from
PC/BIOS + GRUB stack), it can't be linked in F segment anyway.

(Btw, I think a Multiboot SeaBIOS would be really interesting, specially
on non-BIOS x86 platforms like OFW or EFI)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."