Re: CDROM booting issues for Linux on Sparc
On Thu, May 23, 2002 at 09:07:11PM -0400, Ben Collins wrote:
| On Thu, May 23, 2002 at 05:15:15PM -0500, Phil Howard wrote:
| > What is the issue that makes booting Linux from a CDROM on Sparc
| > so complicated? I'm told by Jörg Schilling that mkisofs from
| > cdrtools can make a CD that boots Solaris just fine. He points
| > out that SILO "misbehaves", but as yet I don't know what that
| > mishaviour actually is.
| >
| > What will it take to make a CDROM that can boot Linux on Sparc
| > without modifying mkisofs? Or can someone show that this is
| > not the case?
| >
| > I want to get this long problem resolved once and for all, but
| > with so many people holding back on information, it has been so
| > far hard to do. Does anyone here have information that they are
| > willing to share on the matter?
|
| There is no holding back on information. You just need to read the SILO
| docs that explains it all. Basically, SILO uses cd.b as the "boot
| sector" in mkisofs, munging the solaris way of having a different slice
| for each arch (sun4c/sun4d/sun4e/sun4u/sun4d/etc) to all point to this
| one boot block.
The information I want to get is the foundation information that forms
the basis for writing boot loaders such as SILO. Specifically I'd like
to know things like what information is available, and where, to the
boot loader and/or kernel after PROM hands off control. For example,
can it be determined which device was the boot device? If so, then I
don't need SILO at all, as I could patch the kernel (maintaining a
kernel patch seems to be a lot easier than maintaining a mkisofs patch)
to just mount the CDROM as / to start up, and let init pivot to some
other root if it wants to (such as tmpfs).
| After that, it loads up the second.b, which in turn reads silo.conf, and
| continues the bootup.
|
| Now, for cd.b to read in and execute second.b from the cdrom, it needs
| to know which physical sector second.b starts on.
Why can't these be sequentially layed out in a slice located after the
ISO image? Then each stage would know that the next stage follows and
the vectors for initial ramdisk and kernel would follow that. Doing
it this way would mean a program to piece this all together to make a
"slice image" which unpatched mkisofs would then see as the kernel.
| Now, the way SILO has always done this is with some special options in
| mkhybrid/mkisofs so that cd.b gets "patched" up with the sector for
| second.b. That's all there is to it. We could use the "..." method, if
| only there was a way to patch up cd.b afterwards.
I don't know what "..." refers to.
I know space is tight in the few reserved blocks of ISO-9660 at the
front. But as long as the image has room to expand at the back, why
not there? Why can't cd.b read the slice/partition table to get the
sector number for the rest, and put cd.b + second.b + initrd + kernel
after the ISO image, with all slices overlayed to the same thing?
| This is exactly how things work on a regular disk for SILO (the sector
| patching).
|
| This could all be made into a seperate tool from mkisofs, which would
| work like:
|
| ### Setup the iso image
| # mkdir sparc-iso/boot sparc-iso/etc
| # cp /boot/vmlinux /boot/second.b sparc-iso/boot
| # cp silo-initrd.conf sparc-iso/etc/silo.conf
| # cp initrd-image sparc-iso/boot
|
| ### Create the ISO using normal sparc boot options
| # mkisofs -G /boot/cd.b -B ... -o sparc-bootable.iso sparc-iso/
|
| ### Make the image bootable
| # silo-mkcdboot --second /boot/second.b --config /etc/silo.conf sparc-bootable.iso
|
| The second tool has yet to be developed. I have in fact already begun
| checking out how to do this and including it with SILO. It would
| alleviate all the needed things in mkisofs. You are more than welcome to
| complete it if you want.
I'd have to make sure I have access to technical info. So far I've never
been able to come close to having the foundation hardware infor for Sparc
as I have for Intel PC and IBM S/370/390 mainframes (but I don't do those
at this time).
For example, as soon as SILO starts, it has to be able to do I/O. I want
to get the info that describes how a program like a boot loader which has
been started by PROM will be able to do I/O and read from devices, and
even find out what device it was loaded from initially (so it can read
more from the same device). I know this stuff for the other 2 platforms
I mentioned. But I'm not at all good at extrapolating an API from code
someone else wrote, so I really can't figure it out from the SILO code
itself; documentation is what I need. Everything (lots) I've found on
the Sun documentation site regarding PROM told about the commands, the
device name space, and the Forth language it can run, but nothing about
assembly language API to do any I/O and retrieve info. Frustrating.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: