---------- Original Message -------------
Subject: Re: macppc boot process.
Date: Fri, 27 Aug 2004 05:11:21 +0900
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: port-macppc@netbsd.org

>>
What do you mean "not get sysinst to properly accept an msdos partition?"
Do you mean msdos partition is not appeared in output of disklabel(8)?
If so it's not sysinst problem but kernel problem.
(though I don't think sysinst for macppc can handle fdisk parititions..)
>>

I was trying to establish a 2M msdos partition at offset 0, with other partitions following it. The most productive way I found was to use a partition letter higher than the g partition, which would get close, but I would run into errors such as file systems running out of space. I never got an msdos partition to take. As I said, I'm pretty sure I was making the mistake.
>>
In this case, bootpath is used only to get device path
(not filename or path in filesystem) used for loaded ofwboot itself.
This code assumes that the device path used to load ofwboot
can be used to load other files with OF routines, I think.
>>

It closely couples the two, as far as I can tell. I haven't found exactly where the bootargs path gets reduced to just the kernel name, but hfs_open appears to add that kernel name to the device node of the bootloader. I could be missing something, though.

>>
Well, I think this strategy for HFS with OpenFirmware is
a just workaround to access files on HFS which we don't have
actual support. If we have real filesystem support for HFS,
we don't have to use OF to access it and the restriction
that kernel should be placed on the same dir with ofwboot.
>>

I was able to figure out a way to do some initial decoupling and test it. My response to the thread "new 8600 motherboard" has an explanation with a link to a bootloader that decouples the kernel from the bootloader location. All that is required is that OF can read both media. 

I also added your suggestion about using a local stack in the bootloader. Thanks!

>>
What is "some code in libsa"? macppc/stand/ofwboot/hfs.c?
It seems passed kernel path in bootargs is preserved in boot.c:main().
>>

But by the time it gets passed to hfs_open it appears to have been stripped of its full path and is concatenated to the bootloader's device node. I could be wrong - I'm still trying to get up to speed on NetBSD's version.

>>
You mean that you want to make ofwboot.xcf on msdosfs load
a kernel on ffs (which is in the secondary partition of fdisk)?
I think it should work with current code.
(though I have not checked if current MBR handling in ofdev.c
 works properly)
>>

That would be good, then, because that could limit Open Firmware's requirements to only having to be able to read the media the bootloader is on. 

I'm not suggesting NetBSD change anything, by the way. I'm trying to understand how NetBSD's process works and see if there is any way to expand on those features independently. It helps me get a better feel for the OS community and code.

thanks,
tim
--