Tarl Neustaedter wrote:
[resurrecting a very old thread]
Hi all,
So given that the Fcode evaluator is sorted for Solaris 10, I thought I'd try my original Solaris 9 disk image again and was surprised to find that it didn't boot.
Further investigation seems to show that strangely encoded device names are being passed into cif-open which is failing: [...] 3 > 2dup type cdrom:a,|platform|OpenBiosTeam,OpenBIOS|ufsboot ok [...] 3 > 2dup type cdrom:a,|platform|sun4u|ufsboot ok [...] It looks as if a special type of device-specifier is being passed into cif-open consisting of a device and argument, a comma, then the actual filename required with /s replaced by |s.
Is this some kind of special syntax that needs to be taught to the dev word and/or cif-open words?
Ah, yes. The issue here is that the full pathname is something like:
/pci@400/scsi@3/disk@0:a|platform|sun4u|ufsboot
An argument (the stuff after ":") cannot contain a slash (or it would become a path element), so ufs filenames have the slashes replaced with vertical bars. But this should have been entirely between the secondary booter and Solaris - I'm not sure why you are tripping over it.
So I've just had a little play with my Solaris 9 disk image again, and I can confirm that the reason the kernel is unable to load is because of the arguments being passed to the CIF open method. Here is the trace using the Forth debugger:
: do-boot ( Empty ) 00000000ffe36838: sign-on ( Empty ) 00000000ffe36840: real-devname ( Empty ) 00000000ffe36848: halt? ( Empty ) 00000000ffe36850: do?branch ( ) 00000000ffe368a0: loader-base ( Empty ) 00000000ffe368a8: plat-booter$ ( ffe356f8 27 ) 00000000ffe368b0: diagnostic-mode? ( ffe356f8 27 0 ) 00000000ffe368b8: do?branch ( ffe356f8 27 ) 00000000ffe36908: get-file ( Empty ) 00000000ffe36910: do?branch ( ) 00000000ffe36920: loader-base ( Empty ) 00000000ffe36928: def-booter$ ( ffe356f8 17 ) 00000000ffe36930: diagnostic-mode? ( ffe356f8 17 0 ) 00000000ffe36938: do?branch ( ffe356f8 17 ) 00000000ffe36988: get-file : get-file ( ffe356f8 17 ) 00000000ffe36200: fname>devname$ ( ffe35d70 1c ) 00000000ffe36208: ufs-fopen Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
2 > 2dup type disk,|platform|sun4u|ufsboot ok 2 > resume ok ( ffe35d70 1c ) 00000000ffe36208: ufs-fopen : ufs-fopen ( ffe35d70 1c ) 00000000ffe35f70: drop ( ffe35d70 ) 00000000ffe35f78: cif-open ( 0 ) 00000000ffe35f80: (semis) [ Finished ufs-fopen ] ( 0 ) 00000000ffe36210: ?dup ( 0 ) 00000000ffe36218: do?branch ( Empty ) 00000000ffe362e0: drop ( ) 00000000ffe362e8: -1 ( Empty ) 00000000ffe362f0: (semis) [ Finished get-file ] ( Empty ) 00000000ffe36990: do?branch ( ) 00000000ffe369a0: (") ( 11 ) 00000000ffe369c8: type Boot load failed. ( ) 00000000ffe369d0: cr ( ) 00000000ffe369d8: exit Stack Underflow. 0 >
I took the liberty of using GDB to dump out the Fcode to a file and run it through detok so I could get a better idea of the Forth being executed.
The interesting part is that I can see the code to decode the arguments is all present in /packages/ufs-file-system in the "open" word, which makes me wonder if cif-open should somehow be calling this method instead. However, the OpenBIOS definition of cif-open currently looks like this:
: open ( dev_spec -- ihandle|0 ) dup cstrlen open-dev ;
So with an argument string of "disk,|platform|sun4u|ufsboot", OpenBIOS goes and opens the "disk" device passing in an argument string of "|platform|sun4u|ufsboot" which is doomed to fail because it is not a valid file reference.
The part I'm missing is how Fcode calling the CIF "open" word can invoke the "open" word within the /packages/ufs-file-system package which should do the right thing - anyone have any bright ideas?
ATB,
Mark.