Would it be reasonable to add libATA to DDE_Linux? I would like to run Genode on my computer and port various programs and libraries to Genode, but I can't get the ATA (ATAPI) driver to detect my hard drive (or my CD drive, for that matter). My computer's motherboard lacks AHCI support, and I don't feel inclined to buy a new computer for Genode, since my computer is good (has a quad-core processor and 4GB RAM) and is working just fine and I don't have a lot of money. As it is, unless I can get support for my hard drive, I'll probably have to drop Genode for about 4 years until I upgrade.
Hi Ben,
before proceeding with looking at the ATAPI and VESA issues, I warmly recommend you to find a way for obtaining the debug output over a serial line. There are several options:
* If your machine has a free PCI slot, there are PCI cards with comports available. To use such a card with Genode, you first have to determine the I/O ports used by the comports. For example, by booting Linux and using lspci to show the PCI resources. Once you know the I/O port address, you have to configure the respective kernel to use the specific I/O port. E.g., on Fiasco.OC, there is a kernel command line option. On NOVA, it may work out of the box because there is an UART detection mechanism in place (the bender chain loader).
* If your machine is a laptop, it may have a PCI-X cardbus slot. We are regularly using such devices as RS232 adapters. To use such an adapter for kernel debug output, you'd need to follow the same steps as for the PCI card.
* If your machine features Intel AMT (advanced management technology), you can redirect serial output over ethernet. To use AMT with Linux, have a look at the amtterm package. Also, you may search in the archive of the mailing list for additional information.
* If your machine features IPMI, you should also be able to redirect serial output over the network as well.
For debugging any kind of issue, please down-strip a run script with only the components needed for debugging the problem at hand. E.g., when you investigate the ATAPI driver issue, there is no point of having the PS/2 and VESA drivers present. They just pollute the debug output with distracting information and make the overall scenario more complicated than it needs to be.
As another hint for debugging individual issues on real hardware, you can dump the ISO images that are produced by the Genode build system directly on a USB stick (using 'dd') and boot your test machine from USB. This alleviates the need to modify the binaries and the boot-loader configuration on the hard disk of your machine.
For debugging the ATAPI problem, I recommend you to follow Sebastian's advice to investigate potential IRQ problems. In the past, we repeatedly experienced IRQ delivery problems on Fiasco.OC that were related to the IRQ configuration (edge vs. level triggered, high vs. how active). To investigate the issue, I would cross-correlate the behavior of the driver on different kernels. I would start with a non-APIC kernel (such as the old L4/Fiasco or OKL4), which uses plain old PIC interrupt numbers. Does the driver successfully detect the device when running on one of those kernels? If it works, you may try repeating the test with NOVA, which uses the APIC but has no known IRQ delivery issues. Make sure that you start the ACPI driver when using NOVA and route the IRQ session of the ATAPI driver to the ACPI driver. If you get it to work with NOVA, we know that the issue is actually related to the IRQ configuration on Fiasco.OC. So it might be worthwhile to revisit the pointers that Sebastian gave you.
Regarding your question about adding libATA to DDE-Linux, I would shy away from that and rather investigate the fixing of the remaining 64 bit issues of our existing ATAPI driver. I doubt that the driver is inherently unable to work on 64 bit. There was just no pressing need to support 64 bit until now. Actually, we even considered dropping the ATAPI driver altogether because it hasn't been used for such a long time.
Unfortunately, I won't be able to give meaningful assistance for debugging your VESA issue from remote. The best advise I can give you is to find a way to obtain the serial output. Once you can see the debug messages, you can enable the 'verbose' flag in 'libports/src/drivers/framebuffer/vesa/framebuffer.cc' to get more diagnostic information. On some hardware, the VESA driver is known to not work correctly. If this is the case for your machine, you may use a fallback: Some boot loaders such as GRUB1 with the OS patch allow you to set a VESA mode right at boot time (maybe GRUB2 has a similar feature?). Our VESA driver can be configured to use the currently active mode instead of attempting to set the mode by itself. To do that you have to specify the configuration attribute preinit="yes".
Good luck Norman
On 11/04/2014 02:23 AM, Nobody III wrote:
Would it be reasonable to add libATA to DDE_Linux? I would like to run Genode on my computer and port various programs and libraries to Genode, but I can't get the ATA (ATAPI) driver to detect my hard drive (or my CD drive, for that matter). My computer's motherboard lacks AHCI support, and I don't feel inclined to buy a new computer for Genode, since my computer is good (has a quad-core processor and 4GB RAM) and is working just fine and I don't have a lot of money. As it is, unless I can get support for my hard drive, I'll probably have to drop Genode for about 4 years until I upgrade.
Thanks. Since Genode seems to generally have inferior 64-bit support, I've switched to using 32-bit mode for the time being. I bought a serial cable on eBay yesterday, so that should help me if I can't get another way working before it arrives. I will try your advice and hope to get Genode up and running soon. As a side question, is there an easy way to combine input from a PS/2 keyboard and a USB mouse or should I write a server for that? On Nov 4, 2014 3:37 AM, "Norman Feske" <norman.feske@...1...> wrote:
Hi Ben,
before proceeding with looking at the ATAPI and VESA issues, I warmly recommend you to find a way for obtaining the debug output over a serial line. There are several options:
If your machine has a free PCI slot, there are PCI cards with comports available. To use such a card with Genode, you first have to determine the I/O ports used by the comports. For example, by booting Linux and using lspci to show the PCI resources. Once you know the I/O port address, you have to configure the respective kernel to use the specific I/O port. E.g., on Fiasco.OC, there is a kernel command line option. On NOVA, it may work out of the box because there is an UART detection mechanism in place (the bender chain loader).
If your machine is a laptop, it may have a PCI-X cardbus slot. We are regularly using such devices as RS232 adapters. To use such an adapter for kernel debug output, you'd need to follow the same steps as for the PCI card.
If your machine features Intel AMT (advanced management technology), you can redirect serial output over ethernet. To use AMT with Linux, have a look at the amtterm package. Also, you may search in the archive of the mailing list for additional information.
If your machine features IPMI, you should also be able to redirect serial output over the network as well.
For debugging any kind of issue, please down-strip a run script with only the components needed for debugging the problem at hand. E.g., when you investigate the ATAPI driver issue, there is no point of having the PS/2 and VESA drivers present. They just pollute the debug output with distracting information and make the overall scenario more complicated than it needs to be.
As another hint for debugging individual issues on real hardware, you can dump the ISO images that are produced by the Genode build system directly on a USB stick (using 'dd') and boot your test machine from USB. This alleviates the need to modify the binaries and the boot-loader configuration on the hard disk of your machine.
For debugging the ATAPI problem, I recommend you to follow Sebastian's advice to investigate potential IRQ problems. In the past, we repeatedly experienced IRQ delivery problems on Fiasco.OC that were related to the IRQ configuration (edge vs. level triggered, high vs. how active). To investigate the issue, I would cross-correlate the behavior of the driver on different kernels. I would start with a non-APIC kernel (such as the old L4/Fiasco or OKL4), which uses plain old PIC interrupt numbers. Does the driver successfully detect the device when running on one of those kernels? If it works, you may try repeating the test with NOVA, which uses the APIC but has no known IRQ delivery issues. Make sure that you start the ACPI driver when using NOVA and route the IRQ session of the ATAPI driver to the ACPI driver. If you get it to work with NOVA, we know that the issue is actually related to the IRQ configuration on Fiasco.OC. So it might be worthwhile to revisit the pointers that Sebastian gave you.
Regarding your question about adding libATA to DDE-Linux, I would shy away from that and rather investigate the fixing of the remaining 64 bit issues of our existing ATAPI driver. I doubt that the driver is inherently unable to work on 64 bit. There was just no pressing need to support 64 bit until now. Actually, we even considered dropping the ATAPI driver altogether because it hasn't been used for such a long time.
Unfortunately, I won't be able to give meaningful assistance for debugging your VESA issue from remote. The best advise I can give you is to find a way to obtain the serial output. Once you can see the debug messages, you can enable the 'verbose' flag in 'libports/src/drivers/framebuffer/vesa/framebuffer.cc' to get more diagnostic information. On some hardware, the VESA driver is known to not work correctly. If this is the case for your machine, you may use a fallback: Some boot loaders such as GRUB1 with the OS patch allow you to set a VESA mode right at boot time (maybe GRUB2 has a similar feature?). Our VESA driver can be configured to use the currently active mode instead of attempting to set the mode by itself. To do that you have to specify the configuration attribute preinit="yes".
Good luck Norman
On 11/04/2014 02:23 AM, Nobody III wrote:
Would it be reasonable to add libATA to DDE_Linux? I would like to run Genode on my computer and port various programs and libraries to Genode, but I can't get the ATA (ATAPI) driver to detect my hard drive (or my CD drive, for that matter). My computer's motherboard lacks AHCI support, and I don't feel inclined to buy a new computer for Genode, since my computer is good (has a quad-core processor and 4GB RAM) and is working just fine and I don't have a lot of money. As it is, unless I can get support for my hard drive, I'll probably have to drop Genode for about 4 years until I upgrade.
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
On 11/04/2014 05:38 PM, Nobody III wrote:
As a side question, is there an easy way to combine input from a PS/2 keyboard and a USB mouse or should I write a server for that?
please have a look at the 'input_merger' server in the 'os' repository. The README file describes how it can be configured.
Christian
Thank you. I will look at that. I was thinking of writing such a server myself. On Nov 5, 2014 11:40 AM, "Christian Prochaska" < christian.prochaska@...1...> wrote:
Hi Ben,
On 11/04/2014 05:38 PM, Nobody III wrote:
As a side question, is there an easy way to combine input from a PS/2 keyboard and a USB mouse or should I write a server for that?
please have a look at the 'input_merger' server in the 'os' repository. The README file describes how it can be configured.
Christian
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
Some boot loaders such as GRUB1 with the OS patch allow you to
set a VESA mode right at boot time (maybe GRUB2 has a similar feature?).
Mayber you can do something similiar in /etc/default/grub:
GRUB_GFXMODE=1280x800x32 GRUB_GFXPAYLOAD_LINUX=keep
First line set grub mode, second line advises it to keep the resolution in linux.
Best regards, Wolfgang
Unfortunately, I haven't gotten GRUB2 to work at 1920x1080. I have tried using 915resolution to add the video mode, but it only gave me an "out of frequency range" error. On Nov 4, 2014 12:00 PM, <w_schmidt@...181...> wrote:
Hi,
Some boot loaders such as GRUB1 with the OS patch allow you to
set a VESA mode right at boot time (maybe GRUB2 has a similar feature?).
Mayber you can do something similiar in /etc/default/grub:
GRUB_GFXMODE=1280x800x32 GRUB_GFXPAYLOAD_LINUX=keep
First line set grub mode, second line advises it to keep the resolution in linux.
Best regards, Wolfgang
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
unknown＠example.com -
Christian Prochaska -
Nobody III -
Norman Feske