On 12/31/05, Marco Gerards <address@hidden> wrote:
Noah yan <address@hidden> writes:
>> Cool, but I wonder if it can be applied. Mainly because it is most
>> likely not multiboot compliant because multiboot is x86 only, or am I
>> misunderstanding something?
>
> Yes, you are right, multiboot for ppc is not exactly correct concerning
> about the multiboot specification.
> What I mean something-compliant is mainly an agreement between a loader and
> the code being loaded(kernel in most cases). The patch is created mainly
> based on multiboot protocol, so we steal the term "multiboot compliant".
Right. Have you considered just waiting for multiboot 2 instead of
using a standard that is not a standard? I assume multiboot 2 will be
there in some months or so...
currently, it is enough that grub2 can load a kernel and jump to it (whether multiboot or not), saving efforts for coding in low-level devices, fs and open firmware. When grub2 and multiboot is ready, we definitely want to make it multiboot compliant. we also hope that network support is available in grub2 soon.
This is just my thoughts, and other guys from polaris developers may have other comments.
>> 1. should the multiboot strap trust the multiboot_info passed from grub?
>> x86
>> > multiboot only use the cmdline of it and multiboot is changing as from
>> grub
>> > developers. If use it, it may save some coding efforts.
>>
>> Can you please elaborate?
>
>
> As specified in the multiboot spec, os can use or ignore the multiboot_info
> passed from the loader. So here should the Solaris/ppc use the
> multiboot-info or not. In current Solaris x86 multiboot, as far as I check
> out, the kernel code only use the cmdline field, and collect other info
> (such as mem region, etc) by itself. Use the loader info saves porting
> efforts.
Oh, right. It is something we can think about for multiboot 2. The
main idea behind multiboot is providing information the kernel can not
get in another sane way or do things otherwise not really possible.
So that is what you have to keep in mind.
That is good, but to use them will make the kernel not to be loaded by other non-multiboot loader (I am not 100% confident of this comment). So in multiboot standard, it would be great that the mulitboot-compliant kernel can be standardalone (if posibble).
> Concerning about the multiboot, I just have such a impression that multiboot
> spec may be upgraded as I reading through the grub wiki and mailinglist as
> the progress towards ppc and sparc of grub.
The plan is to introduce a new multiboot. This new standard should be
better and portable. It's something that is actively being worked on.
>> 2. if multiboot strap collect system information by itself, should it use
>> > GRUB ieee1275 functions or Solaris's own code(mainly in
>> psm/promif/ieee1275,
>> > but would have to port to ppc). Using Grub2's code saves efforts to port
>> > Solaris code.
>>
>> Please explain what you mean with multiboot strap. It certainly isn't
>> GRUB related terminology I have heard of.
>
> Hope that you already understand what I mean after Cyril's answer. It is a
> multiboot compliant code loaded by grub and it loads the real os kernel. It
> is a solution to migrate some os to use grub. It is strange to me too(why
> not just chainloader), but it is used in this way in some cases.
Ok.
> Unfortunately I fail to understand a big part of your email. Can you
>> please describe which project you are working on and what you are
>> trying to accomplish? And please use the terminology we are used to,
>> otherwise it is hard to understand you.
>
> I am working on porting solaris to ppc, and the loader is grub. I am sorry
> for any confusion and it is sometimes hard for me to find the right terms
> (my poor english). I wrote mainly for solaris-ppc port and CCed to grub
> mainly for people interested in ppc loader (the first part of the mail).
Don't worry about your English. For most people on this list,
including myself, English is not the native language.
If you really have requirements for the new multiboot or problems with
GRUB 2, please tell us. :-)
Hum, I do have problems and questions currently. I tried to cross-compile the grub2 on a solaris x86 for ppc architecture and cannot make it.
It seems that some codes use standard system and libc headers that cause the compilig fail. I clean some of them (such as stdint.h to types.h, alloca.h to grub_alloca.h), but I cannot clean the code that is generated by yacc on
normal.py, so is grub2 going to clean up those usage?
On my mahcine(PowerMac G4) that have two IDE disks, the grub ls command lists some devices, such as ide@, (hd,0), ... (hd, 5), (ultra0,0), ... (ultra0, 5), (ultra1, 0), (ultra1, 1), .... and I can access the "hd" device and fs (they are ext2), but I cannot access the second one, which has a Solaris2 partiton with solaris disklabel, is the ultra1 the second disk in the list output? Is the solaris disk label supported currently so that I can access via something like (hd1, 0, a)?
Thanks very much