On 3/18/2011 8:18 AM, Mark Morgan Lloyd wrote:
Mitch Bradley wrote:
On 3/16/2011 7:43 AM, Mark Morgan Lloyd wrote:
No rush, obviously.
OK, that's working. What is c actually representing here- the entire disc?
It represents the default partition, except in the case of ".partitions", which explicitly adds the "whole disk" partition specifier.
/pci/pci-ide@1f,1/ide@0/disk@0 means the default partition /pci/pci-ide@1f,1/ide@0/disk@0:0 means the whole disk /pci/pci-ide@1f,1/ide@0/disk@0:1 means the first partition /pci/pci-ide@1f,1/ide@0/disk@0:2 means the second partition /pci/pci-ide@1f,1/ide@0/disk@0:1,\foo means the file "foo" on the first partition
Right. So your previous example
ok devalias c /pci/pci-ide@1f,1/ide@0/disk@0
can be equally-well written as
ok devalias c /pci/pci-ide@1f,1/ide@0/disk@0:1
The difference is that "default partition" takes into account the "bootable" flag. If a partition is marked bootable, that one is the default; otherwise the first partition is the default.
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
That final partition isn't right, it's actually filling all the otherwise-unused space on a 6Gb disc, but let's skip that for the moment.
What do I define d as so I can look at the content of the second FAT partition?
ok devalias d /pci/pci-ide@1f,1/ide@0/disk@0:2
Got that, working.
What is disk@0- a reference to a block?
ide@0 means the primary IDE string. ide@1 means the secondary string disk@0 means the master disk on the string. disk@1 means the slave disk
OK, noting the distinction between that and the earlier part that specifies the port address.
So by extension, I can do
ok devalias a /pci/isa@1f/fdc@i3f0/disk ok dir a:\
Let me guess: I can't see the SCSI devices because the 2940 ROM doesn't contain fcode :-)
Correct. You would need to add a driver for your SCSI chip/card in the OFW build.
What do I need to do to look in the Linux filesystem, including identifying what file in /boot can be booted?
ok dir /pci/pci-ide@1f,1/ide@0/disk@0:2,\boot\
0:2 is the second FAT partition, do you mean 0:3 there? If I do
ok dir /pci/pci-ide@1f,1/ide@0/disk@0:2,\
I see the content of the second FAT filesystem, if I do
ok dir /pci/pci-ide@1f,1/ide@0/disk@0:3,\
Error: Unknown file system Can't open disk label package Can't open directory
OFW was built using the instructions from http://www.openfirmware.info/Building_OFW_to_Run_Under_BIOS which worked without problems.
Those instructions say to use config-virtualbox.fth, which doesn't include linux support. Just add a "create linux-support" line to config.fth. That will cause fw.bth to include the ext2 filesystem module.
I'd note however that when I tried a year or so ago using an older compiler I had problems and had to fall back to mkdosfs and still had problems: is that block count correct for a 1.44Mb disc?
I'm not sure. It's been awhile since I tested this setup. I no longer have all the stuff on my system so duplicating it would take longer than I have to spend on this at the moment.
ok dir /ide/disk:2,\boot\
You can omit path components that are unnecessary for disambiguation, because OFW will look for anything that matches.
Can I then boot/load it?
ok boot /ide/disk:2,\boot\vmlinuz
Can't get there yet pending sorting out dir problem above. I assume that OFW specifically knows about the compressed kernel format, since it's already (I presume) in protected mode it can't go via the standard boot sectors. If my understanding is correct I think those instructions might be better headed "Building OFW to be Loaded by BIOS".
Page renamed to "Building OFW to Load from BIOS"
If I can ask one further question, expecting only the sketchiest reply: if I attach a partitioned IDE disk (or insert an unpartitioned floppy) containing an alien unix-style filesystem (specifically, Sanos's DFS as described at http://www.jbox.dk/sanos/source/include/os/dfs.h.html), where would this get patched into OFW? I presume that it would have a driver very similar to that for ext2.
The support for the minix filesystem is a good starting point, because it is relatively simple, so you won't have to wade through much detail to see the key interface points. ofw/fs/minix.fth . The key interface methods are open, close, read,seek, size, load, and next-file-info . To implement write support you also need write, $create, $delete, and $delete! . If the filesystem has symlinks, you also need $readlink .
See also disklabel/methods.fth to see how to hook the dfs support into the partition type decoding - search for "minix".
I'm interested to sort out accessing the Linux disc as discussed above, but will then probably be going quiet for a few weeks while I clear some other jobs (and stuff relating to Open Source) off my desk. Then I'll be asking all sorts of awkward questions about putting OFW on the ARM boards I have here.