Handling multiple cores by GRUB

Handling multiple cores by GRUB

[Swapnil Pimpale]

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

*Hi All,

I am trying to understand the grub code (GRUB-0.97). I have a specific query
regarding SMP systems. How are multiple cores handled by grub? Are multiple
cores active in the grub initially or only one core is active when GRUB
takes charge from the BIOS?

Also, can anyone suggest any tools to live debug the GRUB code?

Thanks in advance.*

[-- Attachment #2: Type: text/html, Size: 377 bytes --]

Re: Handling multiple cores by GRUB

[Felix Zielcke]

Am Mittwoch, den 07.10.2009, 19:22 +0530 schrieb Swapnil Pimpale:
> Hi All,
> 
> I am trying to understand the grub code (GRUB-0.97). 

GRUB Legacy is dead for us.
But your questions also apply to GRUB 2 so I answer them.

> I have a specific query regarding SMP systems. How are multiple cores
> handled by grub? Are multiple cores active in the grub initially or
> only one core is active when GRUB takes charge from the BIOS?

Only 1, just as in DOS or similar systems, which mainly rely on BIOS.

> Also, can anyone suggest any tools to live debug the GRUB code?

http://grub.enbug.org/DebuggingWithGDB
But the pages there are outdated and even with them updated I myself
couldn't figure out how to debug code in the modules.
Only the code in the kernel worked.

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: Handling multiple cores by GRUB

[Swapnil Pimpale]

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

Hi,

Thanks Felix for your quick reply.

Actually we are doing an academic project in which we need to have two cores
of Intel Core 2 Duo, running inside the GRUB simultaneously. For that we
need to send an IPI from primary core to the secondary core.  Can you
suggest any pointers to implement this? Has someone done anything similar to
this before?

Thanks in advance,
Swapnil Pimpale.

On Wed, Oct 7, 2009 at 8:08 PM, Felix Zielcke <fzielcke@z-51.de> wrote:

> Am Mittwoch, den 07.10.2009, 19:22 +0530 schrieb Swapnil Pimpale:
> > Hi All,
> >
> > I am trying to understand the grub code (GRUB-0.97).
>
> GRUB Legacy is dead for us.
> But your questions also apply to GRUB 2 so I answer them.
>
> > I have a specific query regarding SMP systems. How are multiple cores
> > handled by grub? Are multiple cores active in the grub initially or
> > only one core is active when GRUB takes charge from the BIOS?
>
> Only 1, just as in DOS or similar systems, which mainly rely on BIOS.
>
> > Also, can anyone suggest any tools to live debug the GRUB code?
>
> http://grub.enbug.org/DebuggingWithGDB
> But the pages there are outdated and even with them updated I myself
> couldn't figure out how to debug code in the modules.
> Only the code in the kernel worked.
>
> --
> Felix Zielcke
> Proud Debian Maintainer and GNU GRUB developer
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2153 bytes --]

Re: Handling multiple cores by GRUB

[Brendan Trotter]

Hi,

On Mon, Oct 12, 2009 at 10:51 PM, Swapnil Pimpale
<swapnil.pict@gmail.com> wrote:
> Actually we are doing an academic project in which we need to have two cores
> of Intel Core 2 Duo, running inside the GRUB simultaneously. For that we
> need to send an IPI from primary core to the secondary core.  Can you
> suggest any pointers to implement this? Has someone done anything similar to
> this before?

Is there any sane reason for this? None of GRUB's code is designed for
multiple CPUs, and I'd assume that no firmware is designed to handle
multiple CPUs either (I know that "PC BIOS" isn't), and I expect that
if you wasted your time and got multiple CPUs running inside GRUB then
one of the CPUs would do everything while any extra CPU/s would do
nothing (until an OS is started and you need to shut down the "do
nothing" CPU/s).

The method for starting extra CPUs (for 80x86 only) is:
- find the ACPI "APIC" table and get the address of the local APIC and
the APIC ID for the CPU/s you want to start
- if there's no ACPI, use the "Multi-Processor Specification" tables
to find the address of the local APIC and the APIC ID for the CPU/s
you want to start (you shouldn't need to do this on modern systems)
- get the local APIC version (from either ACPI, MP spec or directly
from the BSP's local APIC) and determine what type of APIC it is
- (for "xAPIC" only) send an INIT IPI
- (for "xAPIC" only) wait 10 ms
- (for "xAPIC" only) send a SIPI IPI
- (for "xAPIC" only) wait for up to 200 us for the other CPU to set a
"I started" flag
- (for "xAPIC" only) if the "I started" flag wasn't set in time, send
another SIPI IPI
- (for "xAPIC" only) if the "I started" flag wasn't set in time, wait
for a while (at least 200 s, but typically several seconds for the
other CPU to set a "I started" flag

The SIPI IPI includes the address that you want the other CPU to start
executing. This needs to be on a page boundary and must be below
0x00100000. The other CPU will start in real mode, and one of the
first things it should do is set some sort of "I started" flag (to
tell the first CPU that it can stop waiting and that there hasn't been
some sort of "CPU failed to start" error).

For different types of local APIC there's variations, but you probably
don't need to care about the old 82489DX local APICs (only used on
80486 and early Pentium); and the new "x2APIC" is compatible with the
"xAPIC" (unless there's a very large number of CPUs present and the
APIC ID for the CPU/s you want to start is above 0x000000FF).

For reference materials, see Intel's System Programming Guide, Intel's
Multi-Processor Specification (even if you're using ACPI), the ACPI
specification, and generic OS development resources (e.g.
http://www.osdev.org/, the #osdev IRC channel, etc).


Cheers,

Brendan

Re: Handling multiple cores by GRUB

[Robert Millan]

On Tue, Oct 13, 2009 at 10:06:59AM +1030, Brendan Trotter wrote:
> Hi,
> 
> On Mon, Oct 12, 2009 at 10:51 PM, Swapnil Pimpale
> <swapnil.pict@gmail.com> wrote:
> > Actually we are doing an academic project in which we need to have two cores
> > of Intel Core 2 Duo, running inside the GRUB simultaneously. For that we
> > need to send an IPI from primary core to the secondary core.  Can you
> > suggest any pointers to implement this? Has someone done anything similar to
> > this before?
> 
> Is there any sane reason for this? None of GRUB's code is designed for
> multiple CPUs, and I'd assume that no firmware is designed to handle
> multiple CPUs either (I know that "PC BIOS" isn't), and I expect that
> if you wasted your time and got multiple CPUs running inside GRUB then
> one of the CPUs would do everything while any extra CPU/s would do
> nothing (until an OS is started and you need to shut down the "do
> nothing" CPU/s).

I don't buy the idea of GRUB having multi-thread;  we're a bootloader,
not the kernel of an OS.  However, support for multiple CPUs could be
useful if we treat secondary CPUs as a co-processor (i.e. without
preemption) and sync with it the same way we do with other hardware,
e.g.:

  int end = 0;
  void foo () { do_stuff1 ();  end = 1; }
  do_stuff_in_cpu2 (foo);
  do_stuff2 ();
  while (! end);

But I don't think this would be desireable except in very specific situations,
and I'm not sure which ones.  Perhaps loading a compressed file would be an
example (so that uncompression and disk poll can be done in parallel).

-- 
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: Handling multiple cores by GRUB

[James Courtier-Dutton]

2009/10/14 Robert Millan <rmh@aybabtu.com>:
> But I don't think this would be desireable except in very specific situations,
> and I'm not sure which ones.  Perhaps loading a compressed file would be an
> example (so that uncompression and disk poll can be done in parallel).
>

Not specifically related, but why is grub reading a file from a USB
stick so slow when compared with say reading the HD.
I mean slow, it is about 20 times slower here.

Re: Handling multiple cores by GRUB

[richardvoigt]

On Thu, Oct 15, 2009 at 11:44 AM, James Courtier-Dutton
<james.dutton@gmail.com> wrote:
> 2009/10/14 Robert Millan <rmh@aybabtu.com>:
>> But I don't think this would be desireable except in very specific situations,
>> and I'm not sure which ones.  Perhaps loading a compressed file would be an
>> example (so that uncompression and disk poll can be done in parallel).
>>
>
> Not specifically related, but why is grub reading a file from a USB
> stick so slow when compared with say reading the HD.
> I mean slow, it is about 20 times slower here.

What model USB stick?  Consumer-grade NAND flash controllers really
are 10-15x slower than a recent SATA hard disk.  (7MB/s vs 110MB/s on
read).  Only the expensive SSD, which access many NAND flash chips in
parallel, can meet or exceed hard disk speeds.  And USB 2.0 High Speed
maxes out at about 1/3 of hard disk speed, Firewire 800 or USB 3.0
Ultra or eSATA would overcome that.  But most likely you are just
using slow flash memory with a cheap controller.

>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Handling multiple cores by GRUB

[Robert Millan]

On Thu, Oct 15, 2009 at 05:44:03PM +0100, James Courtier-Dutton wrote:
> 2009/10/14 Robert Millan <rmh@aybabtu.com>:
> > But I don't think this would be desireable except in very specific situations,
> > and I'm not sure which ones.  Perhaps loading a compressed file would be an
> > example (so that uncompression and disk poll can be done in parallel).
> >
> 
> Not specifically related, but why is grub reading a file from a USB
> stick so slow when compared with say reading the HD.
> I mean slow, it is about 20 times slower here.

Are you using our own driver, or the BIOS' one?

-- 
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."