MitchBradley / openfirmware

Open Firmware (IEE1275-1994) implementation by its inventor.
63 stars 16 forks source link

Extracting a driver for an existing OpenBoot 2 host ? #10

Open rdolbeau opened 3 years ago

rdolbeau commented 3 years ago

Hello,

Not really an issue, more of a question: could it be possible to extract an OFW driver to integrate it in a peripheral for an OpenBoot 2 host ? Or will they be too integrated with the whole infrastucture and modern for such an old system ? (I'm aware they are 25+years old by now :-) )

Specifically, I've put a OHCI USB Host Controller in a FPGA connected as a SBus card in a SPARCstation 20. After writing the SBus->OHCI driver (very close to the PCI->OHCI one), NetBSD is now willing to use a mouse or mount a FS from a UBS key (... though not very reliably yet) using the standard OHCI / USB drivers. So now I'm looking for a way to enable boot from a USB mass storage device, and I don't have the Forth skill to write the full USB stack. So I was wondering if I could somehow reuse the driver from OpenFirmware...

Thanks & cordially,

MitchBradley commented 3 years ago

I suspect, but am not sure, that it would be possible but tricky. FirmWorks and Sun did separate USB stacks after we stopped sharing code. (The reason we stopped was not because of any big decision or schism, it was more that we were focused on different things.)

rdolbeau commented 3 years ago

Thanks for the answer.

I tried integrating the existing code directly, but it requires a lot of support files (with some minor word conflicts) and eventually choked on missing push-package/pop-package (among others). Then I saw there were some configuration files for building and wondered if there were some pre-existing 'device-only' configuration...

I suppose nowadays OFW is mostly used in 'embedded' contexts where the configuration is known at firmware-generation time, and the ability to create device firmware is less critical? (don't think there's been a lot of SBus devices designed in the 21st century :-) )

MitchBradley commented 3 years ago

Plug-in drivers with FCode in the device ROM stopped being important when PCI started fading away as laptops took over a lot of the market. Also when Apple switched over to Intel.

push-package and pop-package are fairly simple encapsulations of stuff that basically exists in all Open Boot systems. Here is the code:

: >parent  ( node -- parent-node )  phandle>voc >voc-link  link@ voc>phandle  ;
: parent-device  ( -- parent-node )  current-device >parent  ;

: (select-package)  ( phandle -- )  phandle>voc execute  ;
: (push-package)  ( phandle -- )  also (select-package)  ;
: (pop-package)  ( phandle -- )  previous  ;
: push-package  ( phandle -- )
   dup  0=  if  ." Attempting to push null package!!!" abort  then
   (push-package)  definitions
;
: pop-package  ( -- )  (pop-package) definitions  ;
rdolbeau commented 3 years ago

I think part of the problem is that I was trying to include the OFW code in mine, which I am tokenizing with fcode-utils toke. But it predefines a lot of words that conflicts with OFW support files. I probably should try to use OFW forth, though I'm unsure what will happen with the SBus-specific stuff in this case.

rdolbeau commented 3 years ago

@MitchBradley Dumb question; is it possible to find the byte-code value(s) for a word inside the PROM monitor? I can use 'see' to see the definition, but it doesn't give me the byte-code I should emit to call a specific word.

My reason (perhaps misguided...): I've successfully switched to building my PROM using OFW's forth, but when I try to build a 'compatibility layer' to avoid generating V3/VFW opcodes, I get missing definitions such as v2compat.fth:8: a@ ?. a@ is defined as assembly in the various kerncode.fth, and I can see it as such in my SPARCstation. So I think I can probably simply define it as the proper emit-byte, but I have no idea how to figure out the proper FCode to emit.

Thanks for the help & cordially