Has anyone gotten any Genode drivers to work on computers with AMD processors? The only one that I've gotten to work was fb_drv, which doesn't need to receive interrupts. The other 2 drivers that I've tried recently, usb_drv and ahci_drv, both hang. Has anyone had better compatibility here?
One of our test boards [1] uses an AMD G-series (GX-424). Framebuffer, Intel Ethernet, serial, and USB all seem to work with both and Nova and seL4 microkernels (this was Genode 17.05 iirc).
// Steve Harp
[1] https://www.ieiworld.com/en/product/model.php?II=563
On 4/2/18 4:05 AM, Nobody III wrote:
Has anyone gotten any Genode drivers to work on computers with AMD processors? The only one that I've gotten to work was fb_drv, which doesn't need to receive interrupts. The other 2 drivers that I've tried recently, usb_drv and ahci_drv, both hang. Has anyone had better compatibility here?
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
first I'd like to thank Ben for providing me his ACPI tables.
This morning I digged through the disassembled DSDT and got the feeling that this AMD platforms depends on an ACPI-capable OS calling the _PIC and _PRT methods for IRQ setup. This is the call trace I discovered
call _PIC to inform AML of the interrupt model in use _PIC calls _SB.IRQC in APIC mode _SB.IRQC configures several SystemIO fields (e.g., PIRA, PIRB)
_PRT reports the routing table as usual referencing AR00 in APIC mode so this part should be working already. I suggest further investigation of the IRQ-related setup done in the DST AML code. Unfortunately, I'm not familiar enough with acpica to know if it could be easily adapted to try a full ACPI setup (incl. IRQs) on the platform.
Regards
Thanks for the analysis. The OSDev wiki says, "The ACPICA code is meant to be directly integrated into the host OS, as a kernel-resident subsystem." This suggests that we could likely use acpica without too much trouble.
By the way, could you please give me a quick explanation of the _PIC and _PRT methods, and how they're stored?
On Wed, Apr 4, 2018 at 1:45 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hello,
first I'd like to thank Ben for providing me his ACPI tables.
This morning I digged through the disassembled DSDT and got the feeling that this AMD platforms depends on an ACPI-capable OS calling the _PIC and _PRT methods for IRQ setup. This is the call trace I discovered
call _PIC to inform AML of the interrupt model in use _PIC calls _SB.IRQC in APIC mode _SB.IRQC configures several SystemIO fields (e.g., PIRA, PIRB)
_PRT reports the routing table as usual referencing AR00 in APIC mode so this part should be working already. I suggest further investigation of the IRQ-related setup done in the DST AML code. Unfortunately, I'm not familiar enough with acpica to know if it could be easily adapted to try a full ACPI setup (incl. IRQs) on the platform.
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Ben,
On Wed, Apr 04, 2018 at 01:23:42PM -0600, Nobody III wrote:
Thanks for the analysis. The OSDev wiki says, "The ACPICA code is meant to be directly integrated into the host OS, as a kernel-resident subsystem." This suggests that we could likely use acpica without too much trouble.
That's perfectly true for traditional monolithic kernels like Linux but should not be taken as given for our approach of a minimal trusted computing base. ACPI comes with significant complexity due to its dependency on AML and therefore an AML interpreter. If there's the slightest chance to keep ACPICA out of the TCB we should invest the effort. A good example is our acpi_drv which implements the ATARE approach [2] to statically parse PCI routing tables.
By the way, could you please give me a quick explanation of the _PIC and _PRT methods, and how they're stored?
Please refer to the ACPI specification [1] sections "5.8.1 _PIC Method" and "6.2.13 _PRT (PCI Routing Table)". Those methods are part of the DSDT table and implemented in ASL/AML.
[1] http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf [2] https://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf
Regards
I looked at my DSDT myself, and compared it to the DSDT on my laptop (which runs Genode without any problems). The _PRT method is very similar, but the _PIC method is very different. I don't fully understand what's going on, but it calls a method IRQC(), which sets a bunch of variables (PIRA, PIRB, PIRC, PIRD, PIRE, PIRF, PIRG, PIRH, HDAD, GEC, GPP0, GPP1, GPP2, GPP3, USB1, USB2, USB3, USB4, USB5, USB6, USB7, IDE, SATA) to 0x1F. It also sets Local1 = PD64. After returning from IRQC(), _PIC() sets PICM = Arg0.
To better make sense of this, I need to know how Genode currently sets the interrupt model (PIC, APIC, or SAPIC). The ACPI specification requires PIC mode unless _PIC is called. How does Genode get around that?
On Thu, Apr 5, 2018 at 1:43 AM, Christian Helmuth <christian.helmuth@...533...... labs.com> wrote:
Hello Ben,
On Wed, Apr 04, 2018 at 01:23:42PM -0600, Nobody III wrote:
Thanks for the analysis. The OSDev wiki says, "The ACPICA code is meant
to
be directly integrated into the host OS, as a kernel-resident subsystem." This suggests that we could likely use acpica without too much trouble.
That's perfectly true for traditional monolithic kernels like Linux but should not be taken as given for our approach of a minimal trusted computing base. ACPI comes with significant complexity due to its dependency on AML and therefore an AML interpreter. If there's the slightest chance to keep ACPICA out of the TCB we should invest the effort. A good example is our acpi_drv which implements the ATARE approach [2] to statically parse PCI routing tables.
By the way, could you please give me a quick explanation of the _PIC and _PRT methods, and how they're stored?
Please refer to the ACPI specification [1] sections "5.8.1 _PIC Method" and "6.2.13 _PRT (PCI Routing Table)". Those methods are part of the DSDT table and implemented in ASL/AML.
[1] http://www.uefi.org/sites/default/files/resources/ACPI%206_ 2_A_Sept29.pdf [2] https://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I've been trying to figure out how to implement a simple solution to this. Where can I implement this? Is it safe to implement it in its own component that executes before usb_drv, ahci_drv, or any other driver starts? Using the sequence component should prevent any race conditions.
Eventually, should the solution be added to acpi_drv? Or should it be its own separate component?
I'd like to begin by writing a simple component that uses ACPICA to call the _PIC method. This seems like an easy and reliable way to get the APIC setup properly. Would this work?
After getting a basic solution working, we could work on implementing a simpler heuristic-based solution to interpret the _PIC method without using a full-blown AML parser.
In the end, an ACPICA-based fallback solution (in its own component) would be useful anyway. It may increase the TCB dramatically, but at the very least it would be helpful for debugging.
On Sun, Apr 8, 2018 at 2:22 AM, Nobody III <hungryninja101@...9...> wrote:
I looked at my DSDT myself, and compared it to the DSDT on my laptop (which runs Genode without any problems). The _PRT method is very similar, but the _PIC method is very different. I don't fully understand what's going on, but it calls a method IRQC(), which sets a bunch of variables (PIRA, PIRB, PIRC, PIRD, PIRE, PIRF, PIRG, PIRH, HDAD, GEC, GPP0, GPP1, GPP2, GPP3, USB1, USB2, USB3, USB4, USB5, USB6, USB7, IDE, SATA) to 0x1F. It also sets Local1 = PD64. After returning from IRQC(), _PIC() sets PICM = Arg0.
To better make sense of this, I need to know how Genode currently sets the interrupt model (PIC, APIC, or SAPIC). The ACPI specification requires PIC mode unless _PIC is called. How does Genode get around that?
On Thu, Apr 5, 2018 at 1:43 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hello Ben,
On Wed, Apr 04, 2018 at 01:23:42PM -0600, Nobody III wrote:
Thanks for the analysis. The OSDev wiki says, "The ACPICA code is meant
to
be directly integrated into the host OS, as a kernel-resident
subsystem."
This suggests that we could likely use acpica without too much trouble.
That's perfectly true for traditional monolithic kernels like Linux but should not be taken as given for our approach of a minimal trusted computing base. ACPI comes with significant complexity due to its dependency on AML and therefore an AML interpreter. If there's the slightest chance to keep ACPICA out of the TCB we should invest the effort. A good example is our acpi_drv which implements the ATARE approach [2] to statically parse PCI routing tables.
By the way, could you please give me a quick explanation of the _PIC and _PRT methods, and how they're stored?
Please refer to the ACPI specification [1] sections "5.8.1 _PIC Method" and "6.2.13 _PRT (PCI Routing Table)". Those methods are part of the DSDT table and implemented in ASL/AML.
[1] http://www.uefi.org/sites/default/files/resources/ACPI%206_2 _A_Sept29.pdf [2] https://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
It looks like the acpica component should already call the _PIC method. I combined run/acpica and run/usb_hid, which I was able to get working in QEMU, but it made no difference in the result on my PC. What should I try from here?
On Mon, Apr 9, 2018 at 2:03 AM, Nobody III <hungryninja101@...9...> wrote:
I've been trying to figure out how to implement a simple solution to this. Where can I implement this? Is it safe to implement it in its own component that executes before usb_drv, ahci_drv, or any other driver starts? Using the sequence component should prevent any race conditions.
Eventually, should the solution be added to acpi_drv? Or should it be its own separate component?
I'd like to begin by writing a simple component that uses ACPICA to call the _PIC method. This seems like an easy and reliable way to get the APIC setup properly. Would this work?
After getting a basic solution working, we could work on implementing a simpler heuristic-based solution to interpret the _PIC method without using a full-blown AML parser.
In the end, an ACPICA-based fallback solution (in its own component) would be useful anyway. It may increase the TCB dramatically, but at the very least it would be helpful for debugging.
On Sun, Apr 8, 2018 at 2:22 AM, Nobody III <hungryninja101@...9...> wrote:
I looked at my DSDT myself, and compared it to the DSDT on my laptop (which runs Genode without any problems). The _PRT method is very similar, but the _PIC method is very different. I don't fully understand what's going on, but it calls a method IRQC(), which sets a bunch of variables (PIRA, PIRB, PIRC, PIRD, PIRE, PIRF, PIRG, PIRH, HDAD, GEC, GPP0, GPP1, GPP2, GPP3, USB1, USB2, USB3, USB4, USB5, USB6, USB7, IDE, SATA) to 0x1F. It also sets Local1 = PD64. After returning from IRQC(), _PIC() sets PICM = Arg0.
To better make sense of this, I need to know how Genode currently sets the interrupt model (PIC, APIC, or SAPIC). The ACPI specification requires PIC mode unless _PIC is called. How does Genode get around that?
On Thu, Apr 5, 2018 at 1:43 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hello Ben,
On Wed, Apr 04, 2018 at 01:23:42PM -0600, Nobody III wrote:
Thanks for the analysis. The OSDev wiki says, "The ACPICA code is
meant to
be directly integrated into the host OS, as a kernel-resident
subsystem."
This suggests that we could likely use acpica without too much trouble.
That's perfectly true for traditional monolithic kernels like Linux but should not be taken as given for our approach of a minimal trusted computing base. ACPI comes with significant complexity due to its dependency on AML and therefore an AML interpreter. If there's the slightest chance to keep ACPICA out of the TCB we should invest the effort. A good example is our acpi_drv which implements the ATARE approach [2] to statically parse PCI routing tables.
By the way, could you please give me a quick explanation of the _PIC
and
_PRT methods, and how they're stored?
Please refer to the ACPI specification [1] sections "5.8.1 _PIC Method" and "6.2.13 _PRT (PCI Routing Table)". Those methods are part of the DSDT table and implemented in ASL/AML.
[1] http://www.uefi.org/sites/default/files/resources/ACPI%206_2 _A_Sept29.pdf [2] https://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
On Tue, Apr 10, 2018 at 09:20:37PM -0600, Nobody III wrote:
It looks like the acpica component should already call the _PIC method. I combined run/acpica and run/usb_hid, which I was able to get working in QEMU, but it made no difference in the result on my PC. What should I try from here?
Did you make sure (by instrumenting the ACPICA os backend) that it changes values in the systemio/lpc? If yes, I'm out of ideas.
Greets
What exactly are you referring to, and how do I do it?
On Thu, Apr 12, 2018 at 12:47 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hi Ben,
On Tue, Apr 10, 2018 at 09:20:37PM -0600, Nobody III wrote:
It looks like the acpica component should already call the _PIC method. I combined run/acpica and run/usb_hid, which I was able to get working in QEMU, but it made no difference in the result on my PC. What should I try from here?
Did you make sure (by instrumenting the ACPICA os backend) that it changes values in the systemio/lpc? If yes, I'm out of ideas.
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Ben,
On Thu, Apr 12, 2018 at 02:14:04AM -0600, Nobody III wrote:
What exactly are you referring to, and how do I do it?
Unfortunately, you need to dig through the code, but if you dare it may be really rewarding. I'm neither the author of the Genode acpica-library port nor an expert in ACPICA at a whole, but find and grep yielded me some hints where to look at.
So, navigate to repos/libports/src/lib/acpica and try to find some appropriate backend functions to instrument. This may not suffice, so you should also navigate to contrib/acpica-<hash>/src/lib/acpica and instrument source/components/executer/exregion.c (AcpiExSystemMemorySpaceHandler). To be honest, from this point it's up to you to invest more effort to get your platform running.
Good luck
On 04/12/2018 05:02 AM, Christian Helmuth wrote:
Ben,
On Thu, Apr 12, 2018 at 02:14:04AM -0600, Nobody III wrote:
What exactly are you referring to, and how do I do it?
Unfortunately, you need to dig through the code, but if you dare it may be really rewarding. I'm neither the author of the Genode acpica-library port nor an expert in ACPICA at a whole, but find and grep yielded me some hints where to look at.
So, navigate to repos/libports/src/lib/acpica and try to find some appropriate backend functions to instrument. This may not suffice, so you should also navigate to contrib/acpica-<hash>/src/lib/acpica and instrument source/components/executer/exregion.c (AcpiExSystemMemorySpaceHandler). To be honest, from this point it's up to you to invest more effort to get your platform running.
Good luck
Nobody, I am also interesting in looking at this code, with the goal of getting networking to work in a VirtualBox client. (My main machine is AMD-based, so I am interested in that also, but I like to do most of my experimenting in a VM.)
Unfortunately, I don't have much free time at the moment, but I can try to assist your efforts as much as I can. I haven't worked on driver-level code in years, but I don't mind shaking off the rust for a good cause. ;^)
If you post your discoveries / observations on this ML (or elsewhere, as appropriate), I will do the same.
Okay. I have figured out how to call the _PIC method. I called it the same way Linux does, but I'm not seeing any change in output. I'm going to try to get more debugging output, and I'm going to try booting different OSes on my computer, and maybe try stripping down the ACPI code until one of them (e.g. FreeBSD) stops working.
Also, I discovered that OpenBSD has its own ACPI implementation, which is much smaller than ACPICA, with 17 kLOC rather than 122 kLOC. This might be useful to port parts of if it works well enough.
On Sat, Apr 14, 2018 at 4:13 PM, John J. Karcher < devuser@...544...> wrote:
On 04/12/2018 05:02 AM, Christian Helmuth wrote:
Ben,
On Thu, Apr 12, 2018 at 02:14:04AM -0600, Nobody III wrote:
What exactly are you referring to, and how do I do it?
Unfortunately, you need to dig through the code, but if you dare it may be really rewarding. I'm neither the author of the Genode acpica-library port nor an expert in ACPICA at a whole, but find and grep yielded me some hints where to look at.
So, navigate to repos/libports/src/lib/acpica and try to find some appropriate backend functions to instrument. This may not suffice, so you should also navigate to contrib/acpica-<hash>/src/lib/acpica and instrument source/components/executer/exregion.c (AcpiExSystemMemorySpaceHandler). To be honest, from this point it's up to you to invest more effort to get your platform running.
Good luck
Nobody, I am also interesting in looking at this code, with the goal of getting networking to work in a VirtualBox client. (My main machine is AMD-based, so I am interested in that also, but I like to do most of my experimenting in a VM.)
Unfortunately, I don't have much free time at the moment, but I can try to assist your efforts as much as I can. I haven't worked on driver-level code in years, but I don't mind shaking off the rust for a good cause. ;^)
If you post your discoveries / observations on this ML (or elsewhere, as appropriate), I will do the same.
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
On 15.04.2018 00:13, John J. Karcher wrote:
On 04/12/2018 05:02 AM, Christian Helmuth wrote:
Ben,
On Thu, Apr 12, 2018 at 02:14:04AM -0600, Nobody III wrote:
What exactly are you referring to, and how do I do it?
Unfortunately, you need to dig through the code, but if you dare it may be really rewarding. I'm neither the author of the Genode acpica-library port nor an expert in ACPICA at a whole, but find and grep yielded me some hints where to look at.
So, navigate to repos/libports/src/lib/acpica and try to find some appropriate backend functions to instrument. This may not suffice, so you should also navigate to contrib/acpica-<hash>/src/lib/acpica and instrument source/components/executer/exregion.c (AcpiExSystemMemorySpaceHandler). To be honest, from this point it's up to you to invest more effort to get your platform running.
Good luck
Nobody, I am also interesting in looking at this code, with the goal of getting networking to work in a VirtualBox client. (My main machine is AMD-based, so I am interested in that also, but I like to do most of my experimenting in a VM.)
Unfortunately, I don't have much free time at the moment, but I can try to assist your efforts as much as I can. I haven't worked on driver-level code in years, but I don't mind shaking off the rust for a good cause. ;^)
If you post your discoveries / observations on this ML (or elsewhere, as appropriate), I will do the same.
Ben & John,
may you please try my branch [0] with the run/ahci_bench and run/lwip scenarios and tell me whether this change anything for your setups ?
Thanks,
Alex.
[0] https://github.com/alex-ab/genode/commits/acpica_ext
On 05/02/2018 07:42 AM, Alexander Boettcher wrote:
Ben & John,
may you please try my branch [0] with the run/ahci_bench and run/lwip scenarios and tell me whether this change anything for your setups ?
Thanks,
Alex.
Thanks Alex for all that work!
Unfortunately, I am not advanced enough in Git or the new Genode build tools to know how to do this. Could you provide the commands needed to download/merge and build? (I have created a clean Sculpt EA tree, as described in the tutorial.)
Thanks again!
Hi John,
On 03.05.2018 17:47, John J. Karcher wrote:
On 05/02/2018 07:42 AM, Alexander Boettcher wrote:
Ben & John,
may you please try my branch [0] with the run/ahci_bench and run/lwip scenarios and tell me whether this change anything for your setups ?
Thanks,
Alex.
Thanks Alex for all that work!
Unfortunately, I am not advanced enough in Git or the new Genode build tools to know how to do this. Could you provide the commands needed to download/merge and build? (I have created a clean Sculpt EA tree, as described in the tutorial.)
never mind, I got it now tested myself and actually could fix it differently for Genode as VM in Virtualbox [0]. The drivers (sata/network) of Genode will run in Virtualbox in the upcoming Sculpt TC.
Cheers,
Alex.
[0] https://github.com/genodelabs/genode/issues/2801
On 05/04/2018 04:47 AM, Alexander Boettcher wrote:
Hi John,
On 03.05.2018 17:47, John J. Karcher wrote:
On 05/02/2018 07:42 AM, Alexander Boettcher wrote:
Ben & John,
may you please try my branch [0] with the run/ahci_bench and run/lwip scenarios and tell me whether this change anything for your setups ?
Thanks,
Alex.
Thanks Alex for all that work!
Unfortunately, I am not advanced enough in Git or the new Genode build tools to know how to do this. Could you provide the commands needed to download/merge and build? (I have created a clean Sculpt EA tree, as described in the tutorial.)
never mind, I got it now tested myself and actually could fix it differently for Genode as VM in Virtualbox [0]. The drivers (sata/network) of Genode will run in Virtualbox in the upcoming Sculpt TC.
Cheers,
Alex.
Great news - can't wait to try it!
-
Alexander Boettcher -
Christian Helmuth -
John J. Karcher -
Nobody III -
Steven Harp