Mitch Bradley wrote:
Booting Windows is not supported in the PC demonstration build, but is possible with a fair amount of effort. It requires ACPI and numerous other accomodations for Windows' use of conventional BIOS. We support it on the One Laptop Per Child systems.
At present things I'm likely to want to boot are Linux and DOS, although I'm currently trying to evaluate ReactOS and Sanos so I can report back to another group of developers.
DOS and ReactOS are going to have the same problem as Windows, namely that they expect to do conventional 16-bit BIOS calls. The OFW demo version does not support that.
Are you considering using OFW on both x86 and ARM systems, or is the x86 work just for exploration?
x86 really just for exploration, but I could say much the same for ARM.
Bearing in mind that I've not really used Forth since doing my Masters [mumble] years ago, and that my use of Sun's implementation was mostly pretty trivial, I think I need an idiot's guide as to what can be done from the command line e.g. how to get aliases populated. At the very least so that I can ask questions intelligently.
Thanks, I'd missed that and had been working through the IEEE doc.
I've really only got OFW working today, I tried (on some different systems) a few months ago but I suspect that the "Making a Prototype Floppy Image with Linux Commands" didn't work properly for me.
Now that I am able to run successfully on a PC, is there a standard config that I can use which will allow me to dump boot sectors etc. on BIOS-supported discs (i.e. preferably both IDE and SCSI)?
I'm hoping to eventually put it on some ARM-based development boards as an interactive layer before they boot Linux (etc.) from disc.
My current work at One Laptop Per Child is ARM-based, so the OFW ARM port is being actively maintained and enhanced. I have versions that you can load from uboot and others that run directly with no underlying firmware. The latter, of course, requires that you take responsibility for the low-level issues of memory controller and DRAM initialization.
If you are a consumer of the board, then it's probably better to use whatever firmware is already there as the initial loader, using OFW as the boot manager as you say. If you are developing your own hardware, it starts to make sense to use OFW from the ground up.
Feel free to contact me directly if you need additional guidance. At this point I'm more interested in the ARM version than the x86 version, so the sooner you get onto ARM, the more help I'll be able to offer.
Bear in mind that I'm doing this on spec,
Effectively, so am I. The existence of other open source firmware solutions such as uboot and coreboot (formerly linuxbios) and bootloaders like GRUB have made it difficult bordering on impossible to make money with Open Firmware, except via consulting, and the market for that is rather limited.
Although I think that OFW is about the only one that has the potential for doing things like listing the partition table (and associated code).
Mark Morgan Lloyd wrote:
Thanks, I'd missed that and had been working through the IEEE doc.
OK, really trying baby steps here. Accepting that OFW doesn't implement or allow access to a PC-style BIOS, so can't be used to load any OS that makes BIOS calls (even if only during initialisation), how can I use it to examine the partition table, boot sectors, and possibly filesystems on an IDE disc?
Specifically, on one of my development systems I can see a node /pci/pci-ide@1f,1/ide@0/disk@0, but what comes next?
I'm traveling now and will be home tomorrow. I'll tell you more when I get home, but for now, you can try this:
ok devalias c /pci/pci-ide@1f,1/ide@0/disk@0 ok .partitions c ok dir c:\
On 3/16/2011 3:57 AM, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Thanks, I'd missed that and had been working through the IEEE doc.
OK, really trying baby steps here. Accepting that OFW doesn't implement or allow access to a PC-style BIOS, so can't be used to load any OS that makes BIOS calls (even if only during initialisation), how can I use it to examine the partition table, boot sectors, and possibly filesystems on an IDE disc?
Specifically, on one of my development systems I can see a node /pci/pci-ide@1f,1/ide@0/disk@0, but what comes next?
No rush, obviously.
OK, that's working. What is c actually representing here- the entire disc?
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? What is disk@0- a reference to a block?
What do I need to do to look in the Linux filesystem, including identifying what file in /boot can be booted? Can I then boot/load it?
Mitch Bradley wrote:
I'm traveling now and will be home tomorrow. I'll tell you more when I get home, but for now, you can try this:
ok devalias c /pci/pci-ide@1f,1/ide@0/disk@0 ok .partitions c ok dir c:\
On 3/16/2011 3:57 AM, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Thanks, I'd missed that and had been working through the IEEE doc.
OK, really trying baby steps here. Accepting that OFW doesn't implement or allow access to a PC-style BIOS, so can't be used to load any OS that makes BIOS calls (even if only during initialisation), how can I use it to examine the partition table, boot sectors, and possibly filesystems on an IDE disc?
Specifically, on one of my development systems I can see a node /pci/pci-ide@1f,1/ide@0/disk@0, but what comes next?
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
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?
/pci/pci-ide@1f,1/ide@0/disk@0:2
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
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\
Alternatively:
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
Mitch Bradley wrote:
I'm traveling now and will be home tomorrow. I'll tell you more when I get home, but for now, you can try this:
ok devalias c /pci/pci-ide@1f,1/ide@0/disk@0 ok .partitions c ok dir c:\
On 3/16/2011 3:57 AM, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Thanks, I'd missed that and had been working through the IEEE doc.
OK, really trying baby steps here. Accepting that OFW doesn't implement or allow access to a PC-style BIOS, so can't be used to load any OS that makes BIOS calls (even if only during initialisation), how can I use it to examine the partition table, boot sectors, and possibly filesystems on an IDE disc?
Specifically, on one of my development systems I can see a node /pci/pci-ide@1f,1/ide@0/disk@0, but what comes next?
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
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?
/pci/pci-ide@1f,1/ide@0/disk@0:2
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 :-)
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,\
I get
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. 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?
Alternatively:
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".
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.
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.
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?
/pci/pci-ide@1f,1/ide@0/disk@0:2
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,\
I get
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.
Alternatively:
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.
On 3/18/2011 12:27 PM, Mitch Bradley wrote:
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.
FYI, I have (old) FCode drivers for Adaptec 7897, 7890, and 7860. I don't have a driver for 2940. Adaptec's Linux driver supports at least 7860 and 2940, but I haven't studied it to see if there is much commonality between them.
Thanks Mitch, generally noted. I've still got problems reading ext2 (Linux) filesystems, below reordered and truncated to focus on this.
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,\
I get
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.
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.
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@1f,1/ide@0/disk@0:1,\ ok dir /pci/pci-ide@1f,1/ide@0/disk@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@1f,1/ide@0/disk@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.
So that leaves a possible issue with partition tables on some systems but apart from that looks pretty good.
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@1f,1/ide@0/disk@0:1,\ ok dir /pci/pci-ide@1f,1/ide@0/disk@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@1f,1/ide@0/disk@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.
Thanks Mitch, noted.
Mitch Bradley wrote: [...]
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'm very suspicious about the partition layout in the example I cited, which is the result of running DOS fdisk followed by Linux fdisk- I normally try to only run one fdisk implementation per drive. It looked badly out of order to me, but Linux's fdisk didn't think it needed correcting. So I agree with your unease about Linux's general behaviour, and I'm sure that I needn't comment about the way that unlike MS OSes it doesn't leave a gap between the partition table and filesystem.
Thanks very much for all your help. I'll be back.
On 3/19/2011 6:32 AM, Mitch Bradley wrote:
The solution is to do this before executing boot:
ok setenv initrd c:\boot\initrd.img
Oops, typo. Should be:
ok setenv ramdisk c:\boot\initrd.img
Mitch Bradley wrote:
On 3/19/2011 6:32 AM, Mitch Bradley wrote:
The solution is to do this before executing boot:
ok setenv initrd c:\boot\initrd.img
Oops, typo. Should be:
ok setenv ramdisk c:\boot\initrd.img
I think that some of that stuff- how to locate devices, how to look in a filesystem, how to boot- could usefully be appended to your notes at http://www.firmworks.com/QuickRef.html Presumably device aliases, nvram contents etc. can be predefined on the development system.
openfirmware@openfirmware.info
-
Mark Morgan Lloyd -
Mitch Bradley