[openfirmware] Using Open Firmware as a boot manager

Mitch Bradley wmb at laptop.org
Sat Mar 19 17:32:40 CET 2011



On 3/19/2011 12:36 AM, Mark Morgan Lloyd wrote:
> Thanks Mitch, generally noted. I've still got problems reading ext2
> (Linux) filesystems, below reordered and truncated to focus on this.
>
>
> Doing that builds OK, but I still can't read the directory. I'm
> suspicious about the partition table layout on the drive I'm using:
>
>  >>>> I've set myself up a disk with DOS and Linux which .partitions c
>  >>>> describes as
>  >>>>
>  >>>> 1 Primary Yes FAT-16>32M 37
>  >>>> 2 Primary No Extended 2252
>  >>>> 2 Logical No FAT-16>32M 2045
>  >>>> 3 Logical No 0x82 207
>
> Linux's fdisk -l shows this to have start cylinders
>
> /dev/hda1 1 6, FAT16
> /dev/hda2 6 5, Extended
> /dev/hda3 311 83, Linux
> /dev/hda5 6 6, FAT16
> /dev/hda6 283 82, Linux swap
>
> I think one fair question here is how to tell .partitions to display all
> available, rather than stopping after four.


.partitions only displays the four partition entries that are directly 
contained in the partition map in the Master Boot Record.  To make it 
decode logical partitions correctly, it would be necessary to improve 
the code of (.1partition) in ofw/fs/fatfs/fdisk2.fth .  That code would 
need to be recursive, reading the subordinate disk block containing the
extra partition map info that subdivides the extended entry into 4 
logical sub-partitions.

(find-partition in ofw/fs/fatfs/partition.fth is recursive in that way, 
so it handles logical partitions.  (find-partition is used when you 
choose a partition with a device specifier.

Admittedly, the current behavior of .partitions is sub-optimal.  On the 
other hand, the primary use case of .partitions in the past has been as 
a quick check to see if the disk is basically readable, independent of 
whether it contains a supported filesystem.

One problem you might be having is that OFW and Linux probably disagree 
about partition numbering in the face of extended partitions.  OFW does 
a depth-first recursion, counting only the leaf nodes.  Conversely, at 
least according to the example above, Linux does a breadth-first 
recursion and appears to count the intermediate nodes (extended entries) 
as first-class partitions.

Given the layout above, here is my swag at how the numbering works. 
Indentation represents inclusion in an extended partition.

   hda1 - OFW 1
   hda2 - (OFW doesn't count this as a selectable device)
     hda5 - OFW 2
     hda6 - OFW 3
   hda3 - OFW 4

I tend to format disks using only primary partitions, just to keep 
things simple.

Linux's largely-unwritten policies for numbering disks and other devices 
have been a source of confusion forever.


>
> I've just put Debian onto another disk, which Linux's fdisk -l shows as
>
> /dev/hda1 1 83, Linux
> /dev/hda2 248 5, Extended
> /dev/hda5 248 82, Linux swap
>
> ok dir /pci/pci-ide at 1f,1/ide at 0/disk at 0:1,\
> ok dir /pci/pci-ide at 1f,1/ide at 0/disk at 0:1,\boot\
>
> both get me directory listings. Almost there now :-)
>
> Setting up symlinks in /boot to save typing, and working on my
> experience with Sun systems that parameters get passed through,
>
> ok boot /pci/pci-ide at 1f,1/ide at 0/disk at 0:1,\boot\vmlinuz
> initrd=/boot/initrd.img root=/dev/hda1
>
> That (plus a few variants) doesn't work, I think I need to have the
> initrd "piggybacked" onto the kernel, or quite simply use a kernel that
> doesn't rely heavily on modules... yes, testing with a Slackware kernel
> works fine.

You need to tell OFW to read the initrd into memory; OFW does not parse 
the Linux command line to slurp out the initrd specifier.  And Linux 
typically can't read it itself, due to the chicken-and-egg problem of 
needing to execute code from inside initrd in order to set up the 
necessary mounts to create the illusion of a uniform hierarchical file 
system in the face of multiple physical volumes.  What does "/boot" mean 
before you have mounted anything?

The solution is to do this before executing boot:

ok setenv initrd c:\boot\initrd.img

(Assuming a suitable devalias for c)


>
> So that leaves a possible issue with partition tables on some systems
> but apart from that looks pretty good.
>



More information about the openfirmware mailing list