usb driver to support usb keyboard
Hello, I'm trying to improve the emulation of new world Macs (mac99) in QEMU and noticed that OpenBIOS does not support usb keyboards thus it currently cannot be used with qemu-system-ppc64 -machine mac99 and still uses an ADB keyboard for new world G4 mac that usually have USB keyboards. Because of this I have looked at adding a usb driver to OpenBIOS. I was looking for other open source drivers to adapt but most I could find were GPLv3 (Grub), LGPLv3 (SeaBios) which are incompatible with the current OpenBIOS license or too difficult to adapt (Linux). This mostly left the driver in Coreboot's libpayload library (http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=payloads/libpayloa...) which is BSD licensed that I gave a try. It wasn't too difficult to port to OpenBIOS but when I tried to use it it turned out that it does not handle the device being little endian on a big endian host and thus does not work correctly with ppc (but it might work on little endian hosts, I didn't test that; Coreboot libpayload seems to only support x86 and armv7.) Fixing this is a bit tedious that I don't feel like doing now, I'd rather work on other problems towards my goal of running MorphOS on QEMU instead but I'd like to share the results so far in case someone wants to look at it, has any idea how to easily fix the endianness problem or maybe help with finishing it. Or if someone knows about another simple boot time driver that could be adapted instead and works correctly on big endian hosts please let me know. The current work in progress version can be found here: http://goliat.eik.bme.hu/~balaton/openbios-usbhid-driver-wip.tar.xz Any comments/help are welcome. Regards, BALATON Zoltan
Have you looked at Openfirmware's Forth USB driver? http://tracker.coreboot.org/trac/openfirmware/browser/dev/usb2 It's USB2, ehci, uhci and ohci (that last for USB1 also). Doesn't have xhci for USB3, though. It works on big-endian, this is the driver that Sun's implementation is based on. On 2014-May-2, 06:59 , BALATON Zoltan wrote:
Hello,
I'm trying to improve the emulation of new world Macs (mac99) in QEMU and noticed that OpenBIOS does not support usb keyboards thus it currently cannot be used with qemu-system-ppc64 -machine mac99 and still uses an ADB keyboard for new world G4 mac that usually have USB keyboards. Because of this I have looked at adding a usb driver to OpenBIOS.
I was looking for other open source drivers to adapt but most I could find were GPLv3 (Grub), LGPLv3 (SeaBios) which are incompatible with the current OpenBIOS license or too difficult to adapt (Linux). This mostly left the driver in Coreboot's libpayload library (http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=payloads/libpayloa...) which is BSD licensed that I gave a try. It wasn't too difficult to port to OpenBIOS but when I tried to use it it turned out that it does not handle the device being little endian on a big endian host and thus does not work correctly with ppc (but it might work on little endian hosts, I didn't test that; Coreboot libpayload seems to only support x86 and armv7.)
Fixing this is a bit tedious that I don't feel like doing now, I'd rather work on other problems towards my goal of running MorphOS on QEMU instead but I'd like to share the results so far in case someone wants to look at it, has any idea how to easily fix the endianness problem or maybe help with finishing it. Or if someone knows about another simple boot time driver that could be adapted instead and works correctly on big endian hosts please let me know.
The current work in progress version can be found here: http://goliat.eik.bme.hu/~balaton/openbios-usbhid-driver-wip.tar.xz
Any comments/help are welcome.
On May 2, 2014, at 6:59 AM, BALATON Zoltan wrote:
Hello,
I'm trying to improve the emulation of new world Macs (mac99) in QEMU and noticed that OpenBIOS does not support usb keyboards thus it currently cannot be used with qemu-system-ppc64 -machine mac99 and still uses an ADB keyboard for new world G4 mac that usually have USB keyboards. Because of this I have looked at adding a usb driver to OpenBIOS.
I was looking for other open source drivers to adapt but most I could find were GPLv3 (Grub), LGPLv3 (SeaBios) which are incompatible with the current OpenBIOS license or too difficult to adapt (Linux). This mostly left the driver in Coreboot's libpayload library (http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=payloads/libpayloa...) which is BSD licensed that I gave a try. It wasn't too difficult to port to OpenBIOS but when I tried to use it it turned out that it does not handle the device being little endian on a big endian host and thus does not work correctly with ppc (but it might work on little endian hosts, I didn't test that; Coreboot libpayload seems to only support x86 and armv7.)
Fixing this is a bit tedious that I don't feel like doing now, I'd rather work on other problems towards my goal of running MorphOS on QEMU instead but I'd like to share the results so far in case someone wants to look at it, has any idea how to easily fix the endianness problem or maybe help with finishing it. Or if someone knows about another simple boot time driver that could be adapted instead and works correctly on big endian hosts please let me know.
The current work in progress version can be found here: http://goliat.eik.bme.hu/~balaton/openbios-usbhid-driver-wip.tar.xz
Any comments/help are welcome.
Regards, BALATON Zoltan
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Thank you for trying to improve the Power Macintosh emulator. I wanted to open the file you provided in the link, but I can't open a xz file. Could you provide a zip file? I think I found a way to use the GPLv3 code. According to the licensing section at the openfirmware.info site, the license applied to OpenBIOS is GPLv2 or later. Here is my source: http://www.openfirmware.info/About:License Here is the the quote from that page: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This means we can use the GPLv3 licensed code since it applies to the "any later version" clause. If the Grub or SeaBIOS code is good, feel free to use it.
On Fri, 2 May 2014, Tarl Neustaedter wrote:
Have you looked at Openfirmware's Forth USB driver?
I have now but I'm not fluent in Forth so I'm afraid I cannot adapt that to OpenBIOS. On Fri, 2 May 2014, Programmingkid wrote:
Could you provide a zip file?
Why can't you open the tar.xz file?
I think I found a way to use the GPLv3 code. According to the licensing section at the openfirmware.info site, the license applied to OpenBIOS is GPLv2 or later. Here is my source: http://www.openfirmware.info/About:License
Here is the the quote from that page:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This means we can use the GPLv3 licensed code since it applies to the "any later version" clause. If the Grub or SeaBIOS code is good, feel free to use it.
But the beginning of the page that is relevant here says: "OpenBIOS is covered by the General Public License V2." as well as license and headers in some files I've looked at in the source don't mention "any later version" so currently it is GPLv2 only in my understanding so I think it cannot be mixed with GPLv3. Regards, BALATON Zoltan
On May 2, 2014, at 4:56 PM, BALATON Zoltan wrote:
On Fri, 2 May 2014, Tarl Neustaedter wrote:
Have you looked at Openfirmware's Forth USB driver?
I have now but I'm not fluent in Forth so I'm afraid I cannot adapt that to OpenBIOS.
On Fri, 2 May 2014, Programmingkid wrote:
Could you provide a zip file?
Why can't you open the tar.xz file?
I'm not sure. Maybe the file format is too new for my software.
I think I found a way to use the GPLv3 code. According to the licensing section at the openfirmware.info site, the license applied to OpenBIOS is GPLv2 or later. Here is my source: http://www.openfirmware.info/About:License
Here is the the quote from that page:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This means we can use the GPLv3 licensed code since it applies to the "any later version" clause. If the Grub or SeaBIOS code is good, feel free to use it.
But the beginning of the page that is relevant here says: "OpenBIOS is covered by the General Public License V2."
as well as license and headers in some files I've looked at in the source don't mention "any later version" so currently it is GPLv2 only in my understanding so I think it cannot be mixed with GPLv3.
What is the worst that can happen if you do mix GPLv2 code with GPLv3 code?
On Fri, 2 May 2014, Programmingkid wrote:
Why can't you open the tar.xz file?
I'm not sure. Maybe the file format is too new for my software.
Did you try this? What kind of software are you using? http://tukaani.org/xz/
What is the worst that can happen if you do mix GPLv2 code with GPLv3 code?
That my work is wasted as it cannot be incorporated in OpenBIOS and cannot be distributed by anyone. Regards, BALATON Zoltan
On May 3, 2014, at 5:42 AM, BALATON Zoltan wrote:
On Fri, 2 May 2014, Programmingkid wrote:
Why can't you open the tar.xz file?
I'm not sure. Maybe the file format is too new for my software.
Did you try this? What kind of software are you using? http://tukaani.org/xz/
I was trying to use the tar command to open the file.
On 2014-May-2, 16:56 , BALATON Zoltan wrote:
On Fri, 2 May 2014, Tarl Neustaedter wrote:
Have you looked at Openfirmware's Forth USB driver?
I have now but I'm not fluent in Forth so I'm afraid I cannot adapt that to OpenBIOS.
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
On Fri, 3 May 2014, Tarl Neustaedter wrote:
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
Problem is I don't know where to drop it to try if it works and if it doesn't I don't know how to debug Forth so I could only shoot in the dark. I don't even know where to start with this Forth driver. Regards, BALATON Zoltan
On 03/05/14 10:56, BALATON Zoltan wrote:
On Fri, 3 May 2014, Tarl Neustaedter wrote:
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
Problem is I don't know where to drop it to try if it works and if it doesn't I don't know how to debug Forth so I could only shoot in the dark. I don't even know where to start with this Forth driver.
Sadly the PCI code in OpenBIOS is still written in C so there would be some interface work required there. In terms of testing the code, Forth is an interpreted language so you can literally copy/paste from the source files into a serial console and see what happens ;) I suspect that the reality will be slightly different though, for example we know that OpenFirmware has behaviours which aren't implemented in OpenBIOS. I should also point out that given that the original OpenFirmware was written almost completely in Forth, a lot of the semantics are so tightly tied in that it would make sense to start looking at bits of Forth as you come across them, and even better you can use the Forth debugger (see README.debugger) to step through words one at a time. From the time I've spent working on OpenBIOS, I would say that the 2 things that have cost me the most time have been excessive use of C and premature forking of individual architectures. Historically OpenBIOS has a lot of C drivers borrowed from other projects which is great for getting something going but causes more headaches further down the line. Maybe the original aim was to convert the C drivers over to Forth as time allows? I don't know as that was prior to my involvement in the project. As an example, last summer I ended up rewriting the majority of the display layer and I would say that most of the bugs were caused by C structs and Forth structs not being in sync, plus there was massive code duplication between C and Forth. Currently the C code uses pointers into the Forth dictionary where required so that the values are always consistent, and now C is only used for low-level primitives e.g. blitting that can be used across all architectures. Similarly I spent time creating the common libopenbios since there was a lot of code duplicated between PPC, SPARC32 and SPARC64 which required multiple fixes and testing for minor fixes. But to go back to my original point: the more cross architecture work we do, the less maintenance is required and all architectures get bugfixes for free. And if we need cross architecture, then Forth is a better choice since it provides the greatest compatibility with clients and the IEEE1275 specification, and you get to debug and develop live systems step-by-step without having to rebuild/redeploy. ATB, Mark.
On Sun, 4 May 2014, Mark Cave-Ayland wrote:
On 03/05/14 10:56, BALATON Zoltan wrote:
On Fri, 3 May 2014, Tarl Neustaedter wrote:
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
Problem is I don't know where to drop it to try if it works and if it doesn't I don't know how to debug Forth so I could only shoot in the dark. I don't even know where to start with this Forth driver.
As this seems to be the preferred way I looked at it again to see if I can start trying to integrate the usb2 driver from openfirmwre but I still don't see where to start.
Sadly the PCI code in OpenBIOS is still written in C so there would be some interface work required there.
In terms of testing the code, Forth is an interpreted language so you can literally copy/paste from the source files into a serial console and see what happens ;) I suspect that the reality will be slightly different though, for example we know that OpenFirmware has behaviours which aren't implemented in OpenBIOS.
The usb driver is split into 75 *.fth files so it's not obvious what to paste in a console. Additionally there are some *.bth files that seem to build some FCode modules but these are not working on OpenBIOS as they contain words that I did not find in OpenBIOS. So I don't know how to get OpenBIOS's Forth at least try to interpret these files to see what is missing. The ohci.bth file looks like this: ---begin--- purpose: Load file for OHCI HCD command: &tokenize &this build-now silent on begin-tokenizing ohci.fc FCode-version2 " ohci" encode-string " device_type" property fload ${BP}/dev/usb2/hcd/ohci/loadpkg.fth end0 end-tokenizing ---end--- and the hcd/ohci/loadpkg.fth referenced here contains more fload commands that load the other parts. What is the equivalent in OpenBIOS's Forth to do this? Regards, BALATON Zoltan
On 05/05/14 10:26, BALATON Zoltan wrote:
On Sun, 4 May 2014, Mark Cave-Ayland wrote:
On 03/05/14 10:56, BALATON Zoltan wrote:
On Fri, 3 May 2014, Tarl Neustaedter wrote:
I'm not volunteering to do the work (lest I hear my boss scream in agony), but I suspect this is a case that it just drops in and works. Lillian wrote it for the OneLaptop project, and I understand that implementation and OpenBios haven't diverged all that much.
Problem is I don't know where to drop it to try if it works and if it doesn't I don't know how to debug Forth so I could only shoot in the dark. I don't even know where to start with this Forth driver.
As this seems to be the preferred way I looked at it again to see if I can start trying to integrate the usb2 driver from openfirmwre but I still don't see where to start.
Sadly the PCI code in OpenBIOS is still written in C so there would be some interface work required there.
First place I would look at is in drivers/pci.c and drivers/pci-database.c to make sure that the USB host is detected in the firmware tree - it should appear without any properties. Next download the IEEE1275 PCI bindings and have a look at the words there. Probably the first place to start is getting the PCI config space accesses working; for this you will probably need to implement some Forth wrappers around C for the PCI config space access functions from the PCI bindings.
In terms of testing the code, Forth is an interpreted language so you can literally copy/paste from the source files into a serial console and see what happens ;) I suspect that the reality will be slightly different though, for example we know that OpenFirmware has behaviours which aren't implemented in OpenBIOS.
The usb driver is split into 75 *.fth files so it's not obvious what to paste in a console. Additionally there are some *.bth files that seem to build some FCode modules but these are not working on OpenBIOS as they contain words that I did not find in OpenBIOS. So I don't know how to get OpenBIOS's Forth at least try to interpret these files to see what is missing.
In OpenBIOS, files are added into the build.xml file which generates a set of Makefiles when running the switch-arch script. The .bth files are probably used to create FCode blobs, much in the same way as the toke utility from the OpenBIOS fcode-utils does. Take a look at drivers/build.xml and in particular the vga driver to see how this is done, as this was a driver I converted over from C.
The ohci.bth file looks like this:
---begin--- purpose: Load file for OHCI HCD
command: &tokenize &this build-now
silent on
begin-tokenizing ohci.fc
FCode-version2
" ohci" encode-string " device_type" property
fload ${BP}/dev/usb2/hcd/ohci/loadpkg.fth
end0
end-tokenizing ---end---
and the hcd/ohci/loadpkg.fth referenced here contains more fload commands that load the other parts. What is the equivalent in OpenBIOS's Forth to do this?
Instead of fload, you should be able to use include instead (see forth/bootstrap/start.fs). And for tokenizing, you simply run the Forth source code through fcode-utils' toke command. Also once you start to get a feel for the work and think it's viable, we should get Stefan to make sure he's okay with the OpenFirmware license with respect to OpenBIOS' GPLv2. HTH, Mark.
On Wed, 7 May 2014, Mark Cave-Ayland wrote:
First place I would look at is in drivers/pci.c and drivers/pci-database.c to make sure that the USB host is detected in the firmware tree - it should appear without any properties. Next download the IEEE1275 PCI bindings and have a look at the words there.
I've already looked at pci-database.c for the C driver from coreboot's libpayload. The USB controller was detected but printed "cannot manage" as there was no driver. I could add a callback to call the init function of the driver. I assume for a Forth driver should replace this to call into Forth like the vga driver does.
Probably the first place to start is getting the PCI config space accesses working; for this you will probably need to implement some Forth wrappers around C for the PCI config space access functions from the PCI bindings.
I don't see this yet. Can you give me some more details like which Forth words should be implemented by wrapping which C functions and an example of such implementation?
In OpenBIOS, files are added into the build.xml file which generates a set of Makefiles when running the switch-arch script.
I've found this but I don't know how to add files for a driver. The vga driver is in build.xml like this: <fcode source="vga.fs" name="QEMU,VGA.bin" condition="DRIVER_VGA" /> What should be the name? Can I just come up with something or are there some rules to follow?
The .bth files are probably used to create FCode blobs, much in the same way as the toke utility from the OpenBIOS fcode-utils does. Take a look at drivers/build.xml and in particular the vga driver to see how this is done, as this was a driver I converted over from C.
The ohci.bth file looks like this:
---begin--- purpose: Load file for OHCI HCD
command: &tokenize &this build-now
silent on
begin-tokenizing ohci.fc
FCode-version2
" ohci" encode-string " device_type" property
fload ${BP}/dev/usb2/hcd/ohci/loadpkg.fth
end0
end-tokenizing ---end---
and the hcd/ohci/loadpkg.fth referenced here contains more fload commands that load the other parts. What is the equivalent in OpenBIOS's Forth to do this?
Instead of fload, you should be able to use include instead (see forth/bootstrap/start.fs). And for tokenizing, you simply run the Forth source code through fcode-utils' toke command.
OK, I'll try to use include instead of fload and see what errors I get and if I can make sense of them.
Also once you start to get a feel for the work and think it's viable, we should get Stefan to make sure he's okay with the OpenFirmware license with respect to OpenBIOS' GPLv2.
There's not much I can do about that licensing so feel free to ask now, it's better to know upfront if the patch cannot be accepted. (Although I've checked on gnu.org that the BSD style license should be compatible with GPLv2.) Regards, BALATON Zoltan
On 07/05/14 17:54, BALATON Zoltan wrote:
On Wed, 7 May 2014, Mark Cave-Ayland wrote:
First place I would look at is in drivers/pci.c and drivers/pci-database.c to make sure that the USB host is detected in the firmware tree - it should appear without any properties. Next download the IEEE1275 PCI bindings and have a look at the words there.
I've already looked at pci-database.c for the C driver from coreboot's libpayload. The USB controller was detected but printed "cannot manage" as there was no driver. I could add a callback to call the init function of the driver. I assume for a Forth driver should replace this to call into Forth like the vga driver does.
Yes, that's the one. You can add a dummy callback for testing that does nothing to start with, but that should be enough for it to show up with its device/vendor id when running "show-devs". Does Mac99 use OHCI or UHCI?
Probably the first place to start is getting the PCI config space accesses working; for this you will probably need to implement some Forth wrappers around C for the PCI config space access functions from the PCI bindings.
I don't see this yet. Can you give me some more details like which Forth words should be implemented by wrapping which C functions and an example of such implementation?
Okay: taking section 3.2.3 of the PCI bindings, as an example you'd need to wrap the config-l@ and config-l! words so that they call OpenBIOS' pci_config_read32() and pci_config_write32() functions to access PCI configuration space.
In OpenBIOS, files are added into the build.xml file which generates a set of Makefiles when running the switch-arch script.
I've found this but I don't know how to add files for a driver. The vga driver is in build.xml like this:
<fcode source="vga.fs" name="QEMU,VGA.bin" condition="DRIVER_VGA" />
What should be the name? Can I just come up with something or are there some rules to follow?
Bear in mind that fcode is for compiled files, e.g. the above says take vga.fs and output the binary QEMU,VGA.bin. To add a .fs to the Forth dictionary you need to add them within the <dictionary> tags.
The .bth files are probably used to create FCode blobs, much in the same way as the toke utility from the OpenBIOS fcode-utils does. Take a look at drivers/build.xml and in particular the vga driver to see how this is done, as this was a driver I converted over from C.
The ohci.bth file looks like this:
---begin--- purpose: Load file for OHCI HCD
command: &tokenize &this build-now
silent on
begin-tokenizing ohci.fc
FCode-version2
" ohci" encode-string " device_type" property
fload ${BP}/dev/usb2/hcd/ohci/loadpkg.fth
end0
end-tokenizing ---end---
and the hcd/ohci/loadpkg.fth referenced here contains more fload commands that load the other parts. What is the equivalent in OpenBIOS's Forth to do this?
Instead of fload, you should be able to use include instead (see forth/bootstrap/start.fs). And for tokenizing, you simply run the Forth source code through fcode-utils' toke command.
OK, I'll try to use include instead of fload and see what errors I get and if I can make sense of them.
Definitely start with a small set of files and get the basic PCI configuration accesses working first, and then slowly add in the other files until you get something that works.
Also once you start to get a feel for the work and think it's viable, we should get Stefan to make sure he's okay with the OpenFirmware license with respect to OpenBIOS' GPLv2.
There's not much I can do about that licensing so feel free to ask now, it's better to know upfront if the patch cannot be accepted. (Although I've checked on gnu.org that the BSD style license should be compatible with GPLv2.)
Okay - would you like to email Stefan and CC me? ATB, Mark.
On 2014-May-7, 13:50 , Mark Cave-Ayland wrote:
What should be the name? Can I just come up with something or are there some rules to follow?
Generally, the name should be descriptive. Since this is a driver generic to all USB1 and USB2 controllers, the name should probably be "usb". We want more complicated names when it's a vendor-specific driver or something like that.
On Wed, 7 May 2014, Mark Cave-Ayland wrote:
On 07/05/14 17:54, BALATON Zoltan wrote:
I've already looked at pci-database.c for the C driver from coreboot's libpayload. The USB controller was detected but printed "cannot manage" as there was no driver. I could add a callback to call the init function of the driver. I assume for a Forth driver should replace this to call into Forth like the vga driver does.
Yes, that's the one. You can add a dummy callback for testing that does nothing to start with, but that should be enough for it to show up with its device/vendor id when running "show-devs". Does Mac99 use OHCI or UHCI?
It uses OHCI. Did you look at the diff in the tar file I've sent earlier with my try for a usb driver? That includes the callback to handle the device so I think I have this already.
Okay: taking section 3.2.3 of the PCI bindings, as an example you'd need to wrap the config-l@ and config-l! words so that they call OpenBIOS' pci_config_read32() and pci_config_write32() functions to access PCI configuration space.
The ohci driver does not seem to need these words so I don't care about them at first. I'd rather have the driver compile or called first to get some error messages indicating what does it need and then work on those.
I've found this but I don't know how to add files for a driver. The vga driver is in build.xml like this:
<fcode source="vga.fs" name="QEMU,VGA.bin" condition="DRIVER_VGA" />
What should be the name? Can I just come up with something or are there some rules to follow?
Bear in mind that fcode is for compiled files, e.g. the above says take vga.fs and output the binary QEMU,VGA.bin. To add a .fs to the Forth dictionary you need to add them within the <dictionary> tags.
In my understanding the driver for ohci should be an fcode driver so I think I need to compile that. Can I just use QEMU,OHCI as a name?
Definitely start with a small set of files and get the basic PCI configuration accesses working first, and then slowly add in the other files until you get something that works.
I thought about starting with the ohci driver (it's in 9 files plus about the same ammount of others it uses) and try to get it compiled/loaded to see what functions it needs and then work on those.
There's not much I can do about that licensing so feel free to ask now, it's better to know upfront if the patch cannot be accepted. (Although I've checked on gnu.org that the BSD style license should be compatible with GPLv2.)
Okay - would you like to email Stefan and CC me?
I thought the other way around that you write him and maybe cc-me if you want and I try to work on the driver instead. Regards, BALATON Zoltan
On Wed, 7 May 2014, BALATON Zoltan wrote:
I thought about starting with the ohci driver (it's in 9 files plus about the same ammount of others it uses) and try to get it compiled/loaded to see what functions it needs and then work on those.
I've tried this but could not successfully compile an fcode driver probably due to openfirmware specific extensions that I don't know how to implement as they seem to be dependent on openfirmware's Forth implementation (just copying the definitions were not enough for these because those words they use are also undefined but I may be wrong as I don't know Forth very well). Here are the errors I got at the end: Error: File ../drivers/usb2/hcd/device.fth, Line 286. (Output Position = 18459). Word push-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 287. (Output Position = 18461). Word new-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 288. (Output Position = 18461). Word set-default-unit is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 290. (Output Position = 18462). Word destroy-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 291. (Output Position = 18462). Word pop-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 536. (Output Position = 19787). Word push-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 537. (Output Position = 19789). Word new-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 538. (Output Position = 19789). Word set-default-unit is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 540. (Output Position = 19790). Word destroy-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 541. (Output Position = 19790). Word pop-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 567. (Output Position = 19907). Word push-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 573. (Output Position = 19931). Word pop-package is not in dictionary. Error: File ../drivers/usb2/hcd/ohci/probe.fth, Line 80. (Output Position = 20234). Word push-package is not in dictionary. Error: File ../drivers/usb2/hcd/ohci/probe.fth, Line 98. (Output Position = 20324). Word pop-package is not in dictionary. I anyone wants to repeat what I did here it is: - Copied dev/usb2 from openfirmware to drivers usb2 - added a \ before purpose: at the beginning of each file to comment this line - replaced ${BP}/dev/ with ../drivers/ in all fload commands (looks like toke has fload while the interpreter has include) - Added a new file as drivers/usbohci.fs that replaces drivers/usb2/hcd/ohci/ohci.bth incorporating drivers/usb2/hcd/ohci/loadpkg.fth: ---begin--- fcode-version2 fload ../drivers/usb2/fwext.fs \ Generic HCD stuff fload ../drivers/usb2/align.fth \ DMA memory allocation fload ../drivers/usb2/pkt-data.fth \ USB packet definitions fload ../drivers/usb2/pkt-func.fth \ USB descriptor manipulations fload ../drivers/usb2/hcd/hcd.fth \ Common HCD methods fload ../drivers/usb2/hcd/error.fth \ Common HCD error manipulation fload ../drivers/usb2/hcd/dev-info.fth \ Common internal device info \ OHCI HCD stuff fload ../drivers/usb2/hcd/ohci/edtd.fth \ OHCI HCCA, ED & TD manipulations fload ../drivers/usb2/hcd/ohci/ohci.fth \ OHCI methods fload ../drivers/usb2/hcd/ohci/control.fth \ OHCI control pipe operations fload ../drivers/usb2/hcd/ohci/bulk.fth \ OHCI bulk pipes operations fload ../drivers/usb2/hcd/ohci/intr.fth \ OHCI interrupt pipes operations fload ../drivers/usb2/hcd/control.fth \ Common control pipe API \ OHCI usb bus probing stuff fload ../drivers/usb2/vendor.fth \ Vendor/product table manipulation fload ../drivers/usb2/device/vendor.fth \ Supported vendor/product tables fload ../drivers/usb2/hcd/fcode.fth \ Load fcode driver for child fload ../drivers/usb2/hcd/device.fth \ Make child node & its properties fload ../drivers/usb2/hcd/ohci/probe.fth \ Probe root hub fload ../drivers/usb2/hcd/probehub.fth \ Probe usb hub end0 ---end--- - Added these to build.xml: Index: arch/ppc/build.xml =================================================================== --- arch/ppc/build.xml (revision 1286) +++ arch/ppc/build.xml (working copy) @@ -20,6 +20,7 @@ <object source="qemu/tree.fs"/> <object source="qemu/qemu.fs"/> <object source="QEMU,VGA.bin" target="fcode" condition="DRIVER_VGA"/> + <object source="QEMU,OHCI.bin" target="fcode" condition="DRIVER_USB"/> </dictionary> <dictionary name="openbios-mol" init="openbios" target="forth" condition="MOL"> Index: drivers/build.xml =================================================================== --- drivers/build.xml (revision 1286) +++ drivers/build.xml (working copy) @@ -33,5 +38,6 @@ <fcode source="tcx.fs" name="QEMU,tcx.bin" condition="DRIVER_SBUS" /> <fcode source="cgthree.fs" name="QEMU,cgthree.bin" condition="DRIVER_SBUS" /> <fcode source="vga.fs" name="QEMU,VGA.bin" condition="DRIVER_VGA" /> + <fcode source="usbohci.fs" name="QEMU,OHCI.bin" condition="DRIVER_USB" /> </build> - Then tried to compile and copied some more definitions into drivers/usb2/fwext.fs: ---begin--- \ --- Firmworks extensions ---------------------------------------------- : encode-null 0 0 encode-bytes ; : +i encode-int encode+ ; : string-property 2swap encode-string 2swap property ; : integer-property rot encode-int 2swap property ; : encode-reg >r encode-phys r> encode-int encode+ ; : package( r> my-self >r >r is my-self ; : )package r> r> is my-self >r ; : push-hex r> base @ >r hex >r ; : pop-base r> r> base ! >r ; \ new-package is begin-package without the initial select \ : begin-package select-dev new-package ; : new-package new-device set-args ; : end-package finish-device ; ---end--- (Only the last few are actually needed but these were in one group so I copied all.) Apart from the above errors I get a bunch of warnings that I don't know how serious are but as it does not compile that's not an issue yet. I'm afraid this is all I could do with this and as I don't want to get into the details of the different forth implementations I just give up at this point and try to find out why the ADB driver in Linux is not finding the keyboard or if I can't figure that out I could still finish the C driver that might work for the keyboard. If anyone wants to pick up this Forth driver and experiment with it feel free to continue. Regards, BALATON Zoltan
On 2014-May-7, 16:56 , BALATON Zoltan wrote:
Error: File ../drivers/usb2/hcd/device.fth, Line 286. (Output Position = 18459). Word push-package is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 287. (Output Position = 18461). Word new-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 288. (Output Position = 18461). Word set-default-unit is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 290. (Output Position = 18462). Word destroy-instance is not in dictionary. Error: File ../drivers/usb2/hcd/device.fth, Line 291. (Output Position = 18462). Word pop-package is not in dictionary.
Eek. If you don't have those words, it is hopeless.
On 02/05/14 14:47, Programmingkid wrote:
Thank you for trying to improve the Power Macintosh emulator. I wanted to open the file you provided in the link, but I can't open a xz file. Could you provide a zip file?
I think I found a way to use the GPLv3 code. According to the licensing section at the openfirmware.info site, the license applied to OpenBIOS is GPLv2 or later. Here is my source: http://www.openfirmware.info/About:License
Here is the the quote from that page:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This means we can use the GPLv3 licensed code since it applies to the "any later version" clause. If the Grub or SeaBIOS code is good, feel free to use it.
IANAL but my understanding would be that if we distributed GPLv3 code in this manner then we'd effectively be "upgrading" OpenBIOS from GPLv2 to GPLv3. I'm worried that if we did that then it would affect how images are distributed with QEMU, packaging etc. ATB, Mark.
On May 4, 2014, at 6:15 PM, Mark Cave-Ayland wrote:
On 02/05/14 14:47, Programmingkid wrote:
Thank you for trying to improve the Power Macintosh emulator. I wanted to open the file you provided in the link, but I can't open a xz file. Could you provide a zip file?
I think I found a way to use the GPLv3 code. According to the licensing section at the openfirmware.info site, the license applied to OpenBIOS is GPLv2 or later. Here is my source: http://www.openfirmware.info/About:License
Here is the the quote from that page:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This means we can use the GPLv3 licensed code since it applies to the "any later version" clause. If the Grub or SeaBIOS code is good, feel free to use it.
IANAL but my understanding would be that if we distributed GPLv3 code in this manner then we'd effectively be "upgrading" OpenBIOS from GPLv2 to GPLv3. I'm worried that if we did that then it would affect how images are distributed with QEMU, packaging etc.
I think we are ok. We will stay with GPLv2 because the "Or later" clause allows us to use GPLv3. I'm thinking using the LGPL license might be better. It is a lot less restrictive, allowing others to use OpenBIOS with their own projects more freely.
On 02/05/14 11:59, BALATON Zoltan wrote:
Hello,
I'm trying to improve the emulation of new world Macs (mac99) in QEMU and noticed that OpenBIOS does not support usb keyboards thus it currently cannot be used with qemu-system-ppc64 -machine mac99 and still uses an ADB keyboard for new world G4 mac that usually have USB keyboards. Because of this I have looked at adding a usb driver to OpenBIOS.
I was looking for other open source drivers to adapt but most I could find were GPLv3 (Grub), LGPLv3 (SeaBios) which are incompatible with the current OpenBIOS license or too difficult to adapt (Linux). This mostly left the driver in Coreboot's libpayload library (http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=payloads/libpayloa...) which is BSD licensed that I gave a try. It wasn't too difficult to port to OpenBIOS but when I tried to use it it turned out that it does not handle the device being little endian on a big endian host and thus does not work correctly with ppc (but it might work on little endian hosts, I didn't test that; Coreboot libpayload seems to only support x86 and armv7.)
Fixing this is a bit tedious that I don't feel like doing now, I'd rather work on other problems towards my goal of running MorphOS on QEMU instead but I'd like to share the results so far in case someone wants to look at it, has any idea how to easily fix the endianness problem or maybe help with finishing it. Or if someone knows about another simple boot time driver that could be adapted instead and works correctly on big endian hosts please let me know.
The current work in progress version can be found here: http://goliat.eik.bme.hu/~balaton/openbios-usbhid-driver-wip.tar.xz
Any comments/help are welcome.
Rather than keep a tarball around, it may be better to keep your changes in a git repository forked from openbios.git on github or similar so that the changes can easily be rebased as time goes on. If there was demand for USB functionality I'd consider looking into this as/when time allows, however for the long term, I'd prefer to see less C in OpenBIOS (particularly for new functionality) as the C-Forth hybrid tends to make debugging a pain when trying to switch between Forth/C stacks :/ ATB, Mark.
participants (4)
-
BALATON Zoltan -
Mark Cave-Ayland -
Programmingkid -
Tarl Neustaedter