Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rdolbeau opened this issue Jun 27, 2021 · 5 comments
Open

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

rdolbeau opened this issue Jun 27, 2021 · 5 comments

Comments

@rdolbeau
Copy link

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants