[openbeos] Re: Stage 1 Bootloader
- From: "Jeremiah Poling" <jeremiah@xxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Mon, 25 Nov 2002 22:40:26 -0600
Wow, um.. that seemed kinda excessive.
-Jeremiah
---- Original Message -----
From: "D" <triphid@xxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Monday, November 25, 2002 10:26 PM
Subject: [openbeos] Re: Stage 1 Bootloader
> Cool Axel, well done Axel. Go on not doing stuff just for the fuck of it
Axel.
> May you write something better Axel, and choke on it, Axel.
>
> Goddammit. You just lost another user. 2000 down, 3 left. Go Axel Go!
>
> ________________________________________
> On Monday 25 November 2002 17:38, you wrote:
> > Eike Dehling <e.e.dehling@xxxxxxxxxxxxxxxxxx> wrote:
> > > Ok. So it's at least a little more intelligent than some standard
> > > blocklist
> > > loader :)
> >
> > Sure - and it's very flexible, too :-)
> >
> > > Grub does have support for about 5 or 10 different filesystems, so
> > > there
> > > are enough examples to look at when implementing BFS.
> >
> > Well, as I said, I won't do this.
> >
> > > Also it can load with blocklists instead of from a filesystem, so it
> > > could
> > > already now load zbeos (maybe not pass parameters in the correct way
> > > ...)
> >
> > Theoretically, it could, yes.
> >
> > > But i don't see where your lack of real mode compilers comes from ...
> > > borlands turbo C (available for free from the borland museum), MS
> > > quick C
> > > (still commercial i guess) are just some examples. of course they are
> > > DOS
> > > programs ... Although making it in assembly is probably easier since
> > > compilers tend to make rather big code, and 800 bytes is not very
> > > much.
> >
> > Anyway, thanks for the hint, we might make some use out of it (I
> > haven't spend time searching for them, yet :-).
> >
> > > >I will have a closer look at the multiboot standard before defining
> > > > the
> > > >protocol between stage 2 and the kernel. If it's not too much work,
> > > > I
> > > >would try to be compliant, just to not have to change the protocol
> > > >again in the forseeable future.
> > >
> > > It is actually quite simple: your code is loaded in 32 bit mode with
> > > linear
> > > 4gig segements and a20 enabled.
> > > The code should be in a.out (requires a multiboot structure somewhere
> > > in
> > > the code) or in elf.
> > > You get passed a pointer to a structure with parameters in one of the
> > > registers. (memory map, command line, loaded modules, etc.)
> >
> > Well, as I said, I will have a look at it. If it is very similar to
> > what we need and want to have, I will make it compliant, but I (myself)
> > won't spend any time at improving GRUB to be able to load from a BFS
> > partition.
> > Which means that you'd have to copy the files needed to a special
> > partition that GRUB can access, too, to boot with it, if you don't want
> > to use our stage 2 boot loader. Anyway, being multiboot compliant (even
> > if we are) won't mean that you can boot with GRUB the same way as with
> > the native loader. BFS is one reason, the driver settings are another,
> > and there might even be more.
> >
> > Adios...
> > Axel.
>
>
>
Other related posts:
