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@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main