[PATCH] Generate multiboot tables after and from coreboot tables

[Juhana Helovuo]

Hello,

The attached patch adds all the memory memory ranges in the coreboot
tables also to the multiboot tables. It is useful e.g. when booting
Linux with Grub2 payload, since then Linux gets the Coreboot memory map
via multiboot tables.

This patch causes multiboot table to be located in memory before
coreboot tables, but it seemed to cause no harm for me.

Signed-off-by: Juhana Helovuo

Best regards,
Juhana Helovuo

[PATCH] Generate multiboot tables after and from coreboot tables

[Patrick Georgi]

Am 30.08.2010 20:54, schrieb Juhana Helovuo:
> Hello,
>
> The attached patch adds all the memory memory ranges in the coreboot
> tables also to the multiboot tables. It is useful e.g. when booting
> Linux with Grub2 payload, since then Linux gets the Coreboot memory map
> via multiboot tables.
>
> This patch causes multiboot table to be located in memory before
> coreboot tables, but it seemed to cause no harm for me.
>
> Signed-off-by: Juhana Helovuo

I like the change, except for the #if 0 section. Could that code be
removed entirely, or is there a reason for keeping it?
Also, what's up with reserved_mem_count? Does that serve any purpose
other than dumping the multiboot tables?

Regards,
Patrick

[PATCH] Generate multiboot tables after and from coreboot tables

[Juhana Helovuo]

Patrick Georgi kirjoitti:
> Am 30.08.2010 20:54, schrieb Juhana Helovuo:
> > Hello,
> >
> > The attached patch adds all the memory memory ranges in the coreboot
> > tables also to the multiboot tables. It is useful e.g. when booting
> > Linux with Grub2 payload, since then Linux gets the Coreboot memory map
> > via multiboot tables.
> >
> > This patch causes multiboot table to be located in memory before
> > coreboot tables, but it seemed to cause no harm for me.
> >
> > Signed-off-by: Juhana Helovuo
>
> I like the change, except for the #if 0 section. Could that code be
> removed entirely, or is there a reason for keeping it?

That section is AFAIK cleaning up in case some memory ranges overlap. 
Currently it is not used, because coreboot tables already do similar 
cleaning. I did not dare to remove it altogether, because some future 
extension may need to insert other memory ranges than those from 
coreboot tables.

If that is not a concern, I think there are two reasonable choices: (1) 
insert all entries to multiboot table via that cleanup routine, 
including ones copied from coreboot table, or (2) just copy everything 
from coreboot table and remove cleanup routines. Also remove the two 
built-in entries from multiboot table code, since those seem to be 
duplicated in coreboot table.

Option (2) results in much simpler code, but then multiboot table is 
entirely dependent on coreboot table. Is that ok as a design?
> Also, what's up with reserved_mem_count? Does that serve any purpose
> other than dumping the multiboot tables?

Not at the moment, since cleanup code is commented out. It is also 
needed in the cleanup routine.

Best regards,
Juhana Helovuo

[PATCH] version 2, Generate multiboot tables after and from coreboot tables

[Juhana Helovuo]

On Mon, 2010-08-30 at 21:46 +0200, Patrick Georgi wrote:
> Am 30.08.2010 20:54, schrieb Juhana Helovuo:
> > Hello,
> >
> > The attached patch adds all the memory memory ranges in the coreboot
> > tables also to the multiboot tables. It is useful e.g. when booting
> > Linux with Grub2 payload, since then Linux gets the Coreboot memory map
> > via multiboot tables.
> >
> > This patch causes multiboot table to be located in memory before
> > coreboot tables, but it seemed to cause no harm for me.
> >
> > Signed-off-by: Juhana Helovuo
>
> I like the change, except for the #if 0 section. Could that code be
> removed entirely, or is there a reason for keeping it?
> Also, what's up with reserved_mem_count? Does that serve any purpose
> other than dumping the multiboot tables?

Ok, here is attached 2nd version of the patch. It is the simpler
alternative (#2) outlined in my previous mail.

Signed-off-by: Juhana Helovuo

Best Regards,
Juhana Helovuo

[PATCH] version 2, Generate multiboot tables after and from coreboot tables

[Myles Watson]

On Tue, Aug 31, 2010 at 9:27 AM, Juhana Helovuo  wrote:
> On Mon, 2010-08-30 at 21:46 +0200, Patrick Georgi wrote:
> > Am 30.08.2010 20:54, schrieb Juhana Helovuo:
> > > Hello,
> > >
> > > The attached patch adds all the memory memory ranges in the coreboot
> > > tables also to the multiboot tables. It is useful e.g. when booting
> > > Linux with Grub2 payload, since then Linux gets the Coreboot memory map
> > > via multiboot tables.
> > >
> > > This patch causes multiboot table to be located in memory before
> > > coreboot tables, but it seemed to cause no harm for me.
> > >
> > > Signed-off-by: Juhana Helovuo
> >
> > I like the change, except for the #if 0 section. Could that code be
> > removed entirely, or is there a reason for keeping it?
> > Also, what's up with reserved_mem_count? Does that serve any purpose
> > other than dumping the multiboot tables?

I don't think we should keep the name reserved_mem_count if we
increment it for all regions.
> Ok, here is attached 2nd version of the patch. It is the simpler
> alternative (#2) outlined in my previous mail.

I simplified a little more.  It would be even simpler if we dumped the
table while it was being built.

Signed-off-by: Myles Watson

Thanks,
Myles