[OpenBIOS] Solaris 9: failed boot with strange device names

[Mark Cave-Ayland]

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 at 400/scsi at 3/disk at 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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs