[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new installer

Le Fri, Oct 03, 2003 at 11:29:43 +0200, Sven Luther a écrit:
> On Fri, Oct 03, 2003 at 09:12:56AM +0000, simon raven wrote:
> > Le Wed, Oct 01, 2003 at 23:52:58 -0800, Ethan Benson a écrit:
> > > On Thu, Oct 02, 2003 at 09:16:52AM +0200, Sven Luther wrote:
> > > 
> > > 
> > > also .coff kernels don't even work until 2.4.23 (maybe).
> > 
> > ask ben herrenschmidt about that actually. seems that they do work.
> Mmm, since you obviously care about oldworld pmacs, would you care of
> sending us an overview of the different ways of booting on oldworld
> pmacs, and where you get the kernels from for each of them. I gueesed
> already the following :
>   BootX : uses a macos (non-X) bootx program to boot the kernel, no idea
>   which kernel that is, where you get it from and if it supports an
>   initrd.

non-X == 'classic' in the parlance.

any kernel that lies in the startup System\ Folder/$some_sub_dir on the mockos classic
partition; as long as it recognises it as a linux.bin (this name can be
changed in the application resources) it'll boot.

>   Quik : supports uncompressed kernels (the same as is used with yaboot)
>   and is used to boot oldworld systems from the harddisk. It seems that
>   the Performa 6360 does not work with Quik.

there are issues with various oldworlds; quik won't work on nubus pmacs
at all, as it relies on a working OF - but debian doesn't support nubus,
so that's moot.

>   miboot: is also a macos (non-X) ROM based tool, can boot compressed
>   kernels from a floppy, but no idea which kernel this is, and what is
>   used for initrd. Is this the arch/ppc/boot/images/miboot.image ?

i think so. i haven't used an miboot.image before.

>   plain OF : uses the .coff kernel, and apparently only works over a
>   serial OF console.

hrm, maybe, maybe not. if you can manage to get to a screen based OF
console (i.e., change input- and output-device) you don't need to do it
through serial; though making that change has to be done through some
means - a floppy running a Forth/FCode script or something like that, or
changing it manually from an OS of some sort (as far away from mockos
version anything if possible). i'm allergic to mockos ;)

if memory serves me well, benh and i briefly discussed the possibility
of netbooting OWs; this depends on the OF version, as 1.0.5 is pretty
crippled in this dept., but there may be a way around this somehow.
netbooting depends pretty much 100% on a working .coff image, and TMK,
.coff on PPC has been fixed as of 2.4.22 (therein lies the problem; i
saw some traffic on this list re: 2.4.21...), though we can prolly port
the code to 2.4.21, since it seems pretty uncomplicated (it's like
chaning a total of ~10 lines of code IIRC).

> Is this right, and would you care to test these different setup and fill
> in the gaps of our knowledge about this ? 

pretty much right according to what i know.

> And how do you think half of the open source contributors started ? Just
> buy yourself a good C book, or use one of the numerous online tutorials,
> and learn :)))

yes, true enough *blush*

> > and bootloader issue, or is there something more to this i need to be
> > aware of?
> Well, there are actually various parts to the arch/subarch specific
> stuff :
> --- Stage 0 ---
> 1) The initial booting, which uses the kernel-image udeb, but is not
> really part of the debian-installer, as far as i can tell.
> --- Stage 1 ---
> 2) Initial hardware detection in stage 1, searches for the CDROM, or an
> alternate way of loading in the udebs.
> 3) Anna loads in the udebs, and has support for per arch/subarch udebs
> list.
> --- Stage 2 ---
> 4) The keyboard chooser will propose keyboards accordying to your
> arch/subarch.
> 5) Second stage hardware detection.
> 6) Partitioning and preparation of the filesystems.
> 7) boot-loader and kernel installation
> --- Stage 3 ---
> 8) We reboot and run the normal base-install stuff, everything
> arch/subarch specific should have been solved here, and this is not the
> job of the debian-installer anyway.
> Mmm, Peter, maybe you or someone could post or document what you showed
> us on the Oldenburg blackboard.
> Anyway, i am doing kernel stuff, so i am mostly interested in 1) as well
> as 7). I suppose 4), 5) and 6) should be ok for oldworld pmacs, as well
> as 3). 2) maybe problematic if the oldworld pmacs are not able to load
> udebs from the cdrom drive.

as long as there's a driver for it, it can read the .udeb off the cdrom.
it's the booting from cdrom that's the issue, not reading from cdroms


> Friendly,
> Sven Luther

| ,''`.   http://www.debian.org/  | http://www.nuit.ca/             |
| : :' :  Debian GNU/Linux        | http://simonraven.nuit.ca/      |
| `. `'                           | PGP key ID: 6169 BE0C 0891 A038 |
|  `-                             |                                 |

Reply to: