GRUB2 Sparc

GRUB2 Sparc

[Bart Grantham]

I am interested in the development of the Sparc port of GRUB2 and was 
wondering who I could contact about doing some testing, etc.  Would the 
maintainer please contact me so I could find out current status, if 
there are any ways that I could help out, etc.

Thank you,

Bart

Re: GRUB2 Sparc

[Vincent Pelletier]

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

Bart Grantham a écrit :
> I am interested in the development of the Sparc port of GRUB2 and was
> wondering who I could contact about doing some testing, etc.  Would the
> maintainer please contact me so I could find out current status, if
> there are any ways that I could help out, etc.

Hi.

Current status (on CVS) :
Grub 2 boots to rescue mode, ls is buggy.
Only tested in netboot environment (my U10 can boot grubof
straightforward, it's an ELF64 file).

Current status (on my disk) :
Grub 2 has module support, ls is still buggy, I tested some modules and
they work - loaded from disk. It still can't boot anything.

I have to make a patch, but i have few time now (and no internet at
home, and almost no "home" for now...). I haven't moved my U10 yet, so I
can't work on it now. I think everything will be ok around the middle of
october.

I'm sorry not to have synced the cvs to my current progress on the port,
module loading is quite blocking. What you can still work on is that ls
problem : it loops forever, listing drives and throwing some OpenBoot
errors. I think the problem is in disk/ieee1275/ofdisk.c, but I haven't
 searched much. Same symptoms in normal mode (when module loading works).

Vincent Pelletier


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GRUB2 Sparc

[Bart Grantham]

Vincent Pelletier wrote:

> Current status (on CVS) :
> Grub 2 boots to rescue mode, ls is buggy.
> Only tested in netboot environment (my U10 can boot grubof
> straightforward, it's an ELF64 file).
> 
> Current status (on my disk) :
> Grub 2 has module support, ls is still buggy, I tested some modules and
> they work - loaded from disk. It still can't boot anything.
> 
...
> 
> I'm sorry not to have synced the cvs to my current progress on the port,


No problem at all.  I'm still not sure if I'll have time to really get 
into this long-term, myself.

Thanks for the heads up on the current status.  I've downloaded the code 
and have been looking through it.  Turns out that the installation of 
gcc that I have on my Ultra5 (gentoo stage 3) doesn't support 64bit 
binaries, so I think I'll have to rebuild gcc to really get underway. 
In the meantime I have a number of questions if you have any time to 
answer them, that would be very helpful.

- It looks like the Sparc port piggybacks on the powerpc port a bit for 
the open firmware bits.  Is that correct, or am I missing something?  If 
so, I suppose a good goal would be to try to move any OF-specific code 
into it's own module?

- My (admittedly somewhat hazy) understanding of how an Ultrasparc 
machine boots from disk (any IEEE1275 machine?) is that it reads the 
first sector on the given partition as OF bytecode, which then loads up 
a secondary bootloader or kernel.  Please correct me if I'm wrong on 
this.  Is the GRUB2 project intended to provide a standard bytecode 
sector for this as well, or will platform specific bootsector code 
continue to be used?  And if it's the latter, how does the team envision 
the interface between the boot loader and GRUB2 working?  Will something 
like SILO load up GRUB2 like it currently does the linux kernel and then 
GRUB2 takes over from there, leveraging OF for keyboard, mouse, display 
drivers?

I apologize for the list-wide reply, but I figured that if Vincent is 
unavailable, perhaps someone else could help me.  Thanks for any 
filling-in (or corrections :) ) that anyone can provide.

Bart

Re: GRUB2 Sparc

[Marco Gerards]

Bart Grantham <bart-grubdevel@bartgrantham.com> writes:

> - It looks like the Sparc port piggybacks on the powerpc port a bit
> for the open firmware bits.  Is that correct, or am I missing
> something?  If so, I suppose a good goal would be to try to move any
> OF-specific code into it's own module?

The OF code is already shared between both ports, so both ports are
equal if you look at it that way.  We could make a module out of the
OF code some day, but that is not really important now.

> - My (admittedly somewhat hazy) understanding of how an Ultrasparc
> machine boots from disk (any IEEE1275 machine?) is that it reads the
> first sector on the given partition as OF bytecode, which then loads
> up a secondary bootloader or kernel.  Please correct me if I'm wrong
> on this.  Is the GRUB2 project intended to provide a standard bytecode
> sector for this as well, or will platform specific bootsector code
> continue to be used?  And if it's the latter, how does the team
> envision the interface between the boot loader and GRUB2 working?
> Will something like SILO load up GRUB2 like it currently does the
> linux kernel and then GRUB2 takes over from there, leveraging OF for
> keyboard, mouse, display drivers?

I would prefer our own loader to do this.  It would be silly if GRUB
needs another bootloader I guess. :)

--
Marco

Re: GRUB2 Sparc

[Bart Grantham]

Marco Gerards wrote:
> Bart Grantham <bart@chumps.net> writes:
> 
>>Didn't want to pollute the list with my dumb questions, so this is
>>addressed only to you. :)
> 
> 
> You can send anything related to GRUB2 to grub-devel, don't worry
> about that.  The advantage of a mailinglist is that everyone can
> reply.

Ok.  Replied to list.

>>Is this to say that an f-code bootsector is underway (or maybe even
>>complete)?
> 
> At the moment only Vincent is working on the sparc specific part of
> GRUB 2.  I think making GRUB 2 actually useful on the sparc is of
> higher priority to him (for example writing a linux loader).  Would
> you like to help us writing a f-code bootsector?

Well, I did halfway learn Forth a couple years ago in an attempt to port 
my hobby OS over to sparc, and I have both an Ultra 5 and a Blue&White 
Mac G3, so I can do some cross-platform testing.  Desite this, I find it 
hard to believe I'm the most qualified of this crowd to do this. ;)

Let me think about it some.  I'd be in WAY over my head, as I haven't 
really thought through how the f-code<->grub2 interface would be 
structured.  Are there any docs or thoughts on this from the group?  How 
is the direct stage1 -> stage2 process being handled on x86 without the 
stage1.5 middleman?  Specifically, how are you handling different 
filesystem structures in the boot sector?

Bart

Re: GRUB2 Sparc

[Marco Gerards]

Bart Grantham <bart-grubdevel@bartgrantham.com> writes:

>>>Is this to say that an f-code bootsector is underway (or maybe even
>>>complete)?
>> At the moment only Vincent is working on the sparc specific part of
>> GRUB 2.  I think making GRUB 2 actually useful on the sparc is of
>> higher priority to him (for example writing a linux loader).  Would
>> you like to help us writing a f-code bootsector?
>
> Well, I did halfway learn Forth a couple years ago in an attempt to
> port my hobby OS over to sparc, and I have both an Ultra 5 and a
> Blue&White Mac G3, so I can do some cross-platform testing.  Desite
> this, I find it hard to believe I'm the most qualified of this crowd
> to do this. ;)

This crowd is not really a crowd.  There are not that many GRUB2
developers and only Vincent (AFAIK) has a sparc.  For the PPC port we
can just load an ELF binary.

> Let me think about it some.  I'd be in WAY over my head, as I haven't
> really thought through how the f-code<->grub2 interface would be
> structured.  Are there any docs or thoughts on this from the group?
> How is the direct stage1 -> stage2 process being handled on x86
> without the stage1.5 middleman?  Specifically, how are you handling
> different filesystem structures in the boot sector?

On the PC the bootblock (512 bytes) load the GRUB kernel.  This is a
binary image with a maximum size of 32KB (IIRC).  This is loaded from
a fixed location and no filesystem specific code is involved.

After this GRUB2 is loaded.  The rest of the modules are loaded from
the filesystem.

So basically you need to load some blocks to memory and jump to it.
For open firmware that means you need to pass the OF entry point to
GRUB.

--
Marco

Re: GRUB2 Sparc

[Vincent Pelletier]

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

Bart Grantham a écrit :
> Turns out that the installation of
> gcc that I have on my Ultra5 (gentoo stage 3) doesn't support 64bit
> binaries, so I think I'll have to rebuild gcc to really get underway.

Building a working 32bits binary could be another task, to make it
easier to build from 32bits userspace - I think OF can boot from 32bits
code, and I don't think 64bits are needed.

> - My (admittedly somewhat hazy) understanding of how an Ultrasparc
> machine boots from disk (any IEEE1275 machine?) is that it reads the
> first sector on the given partition as OF bytecode, which then loads up
> a secondary bootloader or kernel.

I think you're right. But I haven't had time to try this (problems
booting from floppy, problems writing an OF-valid partition table to a
disk...).

> I apologize for the list-wide reply, but I figured that if Vincent is
> unavailable, perhaps someone else could help me.  Thanks for any
> filling-in (or corrections :) ) that anyone can provide.

Sorry, I had a big problem with my yahoo mail account, so I just
received ~100 mails for the last week, including this list.

Vincent Pelletier


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GRUB2 Sparc

[Vincent Pelletier]

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

>> Would you like to help us writing a f-code bootsector?
> 
> Well, I did halfway learn Forth a couple years ago in an attempt to port
> my hobby OS over to sparc, and I have both an Ultra 5 and a Blue&White
> Mac G3, so I can do some cross-platform testing.  Desite this, I find it
> hard to believe I'm the most qualified of this crowd to do this. ;)

I now have an iBook, so I will do some cross platform testing too. That
is, as soon as my sparc will come to Lille where I'm now, along with my
other boxes.
I know almost nothing about fcode, but I had the idea earlier in the
port process to write an fcode loader.

Vincent Pelletier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GRUB2 Sparc

[Bart Grantham]

Marco Gerards wrote:

>>Specifically, how are you handling
>>different filesystem structures in the boot sector?
>
> On the PC the bootblock (512 bytes) load the GRUB kernel.  This is a
> binary image with a maximum size of 32KB (IIRC).  This is loaded from
> a fixed location and no filesystem specific code is involved.

I suppose that the consequences of this are that filesystems that don't 
store the kernel contiguously (ie. compression, small-file consolidation 
  tricks) on disk will be incompatible with GRUB2?  Don't get me wrong, 
I think it's a reasonable tradeoff, I just want to make sure I 
understand correctly.

BTW, how does one force a filesystem to store a file contiguously on 
installation of the GRUB kernel?

BG

Re: GRUB2 Sparc

[Marco Gerards]

Bart Grantham <bart-grubdevel@bartgrantham.com> writes:

> Marco Gerards wrote:
>
>>>Specifically, how are you handling
>>>different filesystem structures in the boot sector?
>>
>> On the PC the bootblock (512 bytes) load the GRUB kernel.  This is a
>> binary image with a maximum size of 32KB (IIRC).  This is loaded from
>> a fixed location and no filesystem specific code is involved.
>
> I suppose that the consequences of this are that filesystems that
> don't store the kernel contiguously (ie. compression, small-file
> consolidation tricks) on disk will be incompatible with GRUB2?  Don't
> get me wrong, I think it's a reasonable tradeoff, I just want to make
> sure I understand correctly.

On the PC GRUB is installed right after the MBR, there you have a
space of 32KB.  You could also store GRUB in some filesystems that
have reserved space for GRUB.  This is filesystem specific.

So GRUB is either installed in a reserved region related to the
partitioning layout or a reserved region related to the filesystem.

There is a third way, that is storing a block list.  In that case you
have very little space, just enough to store a block list.  In that
case GRUB can be stored inside the filesystem and GRUB is not stored
contiguously.  I think this is what lilo does.

--
Marco