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.