Hi,
I tried to boot a basic setup to test the USB driver with acpi on top of NOVA. But now at boot time, I get the following error:
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 3002 MB to init int main(): --- init created, waiting for exit condition --- start new pager object with EIP=0x1024ec4, ESP=0x6001000 start new pager object with EIP=0x1027444, ESP=0x6001000 start new pager object with EIP=0x101f0a4, ESP=0x6001000 start new pager object with EIP=0x1066044, ESP=0x6001000 start new pager object with EIP=0x1039584, ESP=0x6001000 [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, v0 start new pager object with EIP=0x102a704, ESP=0x6001000 start new pager object with EIP=0x1038ee4, ESP=0x6001000 start new pager object with EIP=0x1022714, ESP=0x6001000 [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file [init -> acpi -> pci_drv] PCI driver started I/O memory [bf7fe000,bf800000) not available Local MMIO mapping failed! [init -> acpi] C++ runtime: Genode::Parent::Service_denied [init -> acpi] void* abort(): abort called
The memory map looks as follows:
Hypervisor info page contains 35 memory descriptors: Memory descriptor 1: 0 - 8f000 Memory descriptor 2: 8f000 - 90000 Memory descriptor 3: 90000 - 9d000 Memory descriptor 4: 9d000 - a0000 Memory descriptor 5: e0000 - 100000 Memory descriptor 6: 100000 - bf4bd000 Memory descriptor 7: bf4bd000 - bf4bf000 Memory descriptor 8: bf4bf000 - bf5c7000 Memory descriptor 9: bf5c7000 - bf7bf000 Memory descriptor 10: bf7bf000 - bf7df000 Memory descriptor 11: bf7df000 - bf7ff000 Memory descriptor 12: bf7ff000 - bf800000 Memory descriptor 13: bf800000 - c0000000 Memory descriptor 14: f8000000 - fc000000 Memory descriptor 15: fc000000 - fd000000 Memory descriptor 16: ffe00000 - 100000000 Memory descriptor 17: 4000000 - 43a0b95 Memory descriptor 18: 43a1000 - 4580547 Memory descriptor 19: 4581000 - 474c944 Memory descriptor 20: 474d000 - 4a55ab5 Memory descriptor 21: 4a56000 - 4a5cd2d Memory descriptor 22: 4a5d000 - 4a5d5ac Memory descriptor 23: 4a5e000 - 4bd06b6 Memory descriptor 24: 4bd1000 - 4de03d2 Memory descriptor 25: 4de1000 - 4f6bd5f Memory descriptor 26: 4f6c000 - 541c9e5 Memory descriptor 27: 541d000 - 55ae046 Memory descriptor 28: 55af000 - 57bfa8c Memory descriptor 29: 57c0000 - 5b575aa Memory descriptor 30: 5b58000 - 5d324e1 Memory descriptor 31: 5d33000 - 5f8763c Memory descriptor 32: 5f88000 - 6125c86 Memory descriptor 33: 6126000 - 627e07d Memory descriptor 34: 627f000 - 6742b89 Memory descriptor 35: 400000 - 1800000
What seems odd is that the range requested by the PCI driver (at least that would be my guess) lies partly in descriptor 11 (which is marked as not available in the HIP) and partly in descriptor 12 (which is available physical memory).
Any ideas what could be the problem here?
Cheers
Markus
Hello Markus,
On Mon, Jul 23, 2012 at 10:54:22AM +0200, Markus Partheymueller wrote:
What seems odd is that the range requested by the PCI driver (at least that would be my guess) lies partly in descriptor 11 (which is marked as not available in the HIP) and partly in descriptor 12 (which is available physical memory).
Any ideas what could be the problem here?
That looks strange. For clarification: It's the acpi_drv requesting that memory region (the PCI driver uses port I/O only).
It would be a good start to enable verbose logging in the driver (os/src/drivers/acpi/acpi.cc:27) and examine the methods Acpi_table::_search_rsdp() and Acpi_table::_rsdp(). One of those ACPI table mappings fails.
Greets
Hi Christian,
the only thing verbose logging added was this line:
[init -> acpi] Acpi_table::Acpi_table():RSDP 2a020
Does this help?
Greets
Markus
On 23 July 2012 11:18, Christian Helmuth <christian.helmuth@...1...> wrote:
Hello Markus,
On Mon, Jul 23, 2012 at 10:54:22AM +0200, Markus Partheymueller wrote:
What seems odd is that the range requested by the PCI driver (at least that would be my guess) lies partly in descriptor 11 (which is marked as not available in the HIP) and partly in descriptor 12 (which is available physical memory).
Any ideas what could be the problem here?
That looks strange. For clarification: It's the acpi_drv requesting that memory region (the PCI driver uses port I/O only).
It would be a good start to enable verbose logging in the driver (os/src/drivers/acpi/acpi.cc:27) and examine the methods Acpi_table::_search_rsdp() and Acpi_table::_rsdp(). One of those ACPI table mappings fails.
Greets
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Markus,
On Mon, Jul 23, 2012 at 12:47:37PM +0200, Markus Partheymueller wrote:
the only thing verbose logging added was this line:
[init -> acpi] Acpi_table::Acpi_table():RSDP 2a020
Does this help?
Hm, not much info. I'd recommend to instrument the Acpi_table methods with some PDBG()'s to find out what's going on with your machine:
... uint8_t *_map_io(addr_t base, size_t size, Io_mem_session_capability &cap) { PDBG("_map_io: [%p, %p)", (void*)base, (void*)(base + size)); Io_mem_connection io_mem(base, size); ...
I'm not the original author of the ACPI driver and, therefore, does not know it that well. Maybe, Sebastian could shed some light on this?
Regards
Hi Markus,
On 07/23/2012 12:59 PM, Christian Helmuth wrote:
Hello Markus,
On Mon, Jul 23, 2012 at 12:47:37PM +0200, Markus Partheymueller wrote:
the only thing verbose logging added was this line:
[init -> acpi] Acpi_table::Acpi_table():RSDP 2a020
Does this help?
Hm, not much info. I'd recommend to instrument the Acpi_table methods with some PDBG()'s to find out what's going on with your machine:
... uint8_t *_map_io(addr_t base, size_t size, Io_mem_session_capability &cap) { PDBG("_map_io: [%p, %p)", (void*)base, (void*)(base + size)); Io_mem_connection io_mem(base, size); ...
I'm not the original author of the ACPI driver and, therefore, does not know it that well. Maybe, Sebastian could shed some light on this?
It seems like you are only getting the 'root descriptor pointer' (RSDP). After that the driver tries to map the ACPI tables found in the 'root descriptor table' (RSDT). If you should be on a 64-Bit machine (I am guessing that since last time the driver worked for you), this is the wrong way to go from here. On 64Bit one has to use the XSDT table to retrieve the other ACPI table pointers. In that case it should be not too hard to extent the driver (use offset 24 instead of 16 to retrieve the XDST pointer from RSDP). If you are on a 32-Bit machine something is indeed very strange. I am not sure if region 11 is really not available. Usually the driver tries to map the table using one page (of I/O memory), which seems to work. If the table header suggests that the table is larger than 4K, it remaps the table using the corresponding size -- that fails (see Table_wrapper constructor). There is one thing you could try. We are only looking for 'DSTDT', 'SSDT', 'FACP', and 'MADT' tables. You could enclose line 930 and 951 in acpi.cc (Table_wrapper) with a try catch block and simply continue if mapping fails. If you are lucky only the first table pointer is messed up and the others work.
Please share your insights,
Sebastian
Hi,
I'm working on a 64bit machine, but only using 32bit binaries (hypervisor and genode).
I instrumented the methods with some PDGB and found out that the first attempt to map the table already fails:
[init -> acpi] Genode::uint8_t* Acpi_table::_map_io(Genode::addr_t, Genode::size_t, Genode::Io_mem_session_capability&): _map_io: [e0000, 100000) [init -> acpi] Acpi_table::Acpi_table(): RSDP 2a020 [init -> acpi] Table_wrapper::Table_wrapper(Genode::addr_t): Table wrapper with base bf7fe0ac I/O memory [bf7fe000,bf800000) not available Local MMIO mapping failed! [init -> acpi] C++ runtime: Genode::Parent::Service_denied [init -> acpi] void* abort(): abort called
The call that fails is
_io_mem = new (env()->heap()) Io_mem_connection(_base, size + _offset());
With the offset 0x0ac of the base address and the size 0x1000, I think it tries to map two pages of I/O memory from 0xbf7fe000 - 0xbf800000, but the memory map doesn't allow that, because of the overlap between available and not available memory.
On 23 July 2012 15:43, Sebastian Sumpf <Sebastian.Sumpf@...1...> wrote:
Hi Markus,
On 07/23/2012 12:59 PM, Christian Helmuth wrote:
Hello Markus,
On Mon, Jul 23, 2012 at 12:47:37PM +0200, Markus Partheymueller wrote:
the only thing verbose logging added was this line:
[init -> acpi] Acpi_table::Acpi_table():RSDP 2a020
Does this help?
Hm, not much info. I'd recommend to instrument the Acpi_table methods with some PDBG()'s to find out what's going on with your machine:
... uint8_t *_map_io(addr_t base, size_t size, Io_mem_session_capability &cap) { PDBG("_map_io: [%p, %p)", (void*)base, (void*)(base + size)); Io_mem_connection io_mem(base, size); ...I'm not the original author of the ACPI driver and, therefore, does not know it that well. Maybe, Sebastian could shed some light on this?
It seems like you are only getting the 'root descriptor pointer' (RSDP). After that the driver tries to map the ACPI tables found in the 'root descriptor table' (RSDT). If you should be on a 64-Bit machine (I am guessing that since last time the driver worked for you), this is the wrong way to go from here. On 64Bit one has to use the XSDT table to retrieve the other ACPI table pointers. In that case it should be not too hard to extent the driver (use offset 24 instead of 16 to retrieve the XDST pointer from RSDP). If you are on a 32-Bit machine something is indeed very strange. I am not sure if region 11 is really not available. Usually the driver tries to map the table using one page (of I/O memory), which seems to work. If the table header suggests that the table is larger than 4K, it remaps the table using the corresponding size -- that fails (see Table_wrapper constructor). There is one thing you could try. We are only looking for 'DSTDT', 'SSDT', 'FACP', and 'MADT' tables. You could enclose line 930 and 951 in acpi.cc (Table_wrapper) with a try catch block and simply continue if mapping fails. If you are lucky only the first table pointer is messed up and the others work.
Please share your insights,
Sebastian
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On 07/23/2012 04:26 PM, Markus Partheymueller wrote:
Hi,
I'm working on a 64bit machine, but only using 32bit binaries (hypervisor and genode).
I instrumented the methods with some PDGB and found out that the first attempt to map the table already fails:
[init -> acpi] Genode::uint8_t* Acpi_table::_map_io(Genode::addr_t, Genode::size_t, Genode::Io_mem_session_capability&): _map_io: [e0000, 100000) [init -> acpi] Acpi_table::Acpi_table(): RSDP 2a020 [init -> acpi] Table_wrapper::Table_wrapper(Genode::addr_t): Table wrapper with base bf7fe0ac I/O memory [bf7fe000,bf800000) not available Local MMIO mapping failed! [init -> acpi] C++ runtime: Genode::Parent::Service_denied [init -> acpi] void* abort(): abort called
The call that fails is
_io_mem = new (env()->heap()) Io_mem_connection(_base, size + _offset());
With the offset 0x0ac of the base address and the size 0x1000, I think it tries to map two pages of I/O memory from 0xbf7fe000 - 0xbf800000, but the memory map doesn't allow that, because of the overlap between available and not available memory.
Please try to subtract the offset from the initial '_map' call:
diff --git a/os/src/drivers/acpi/acpi.cc b/os/src/drivers/acpi/acpi.cc index 6f4970e..a8322b2 100644 --- a/os/src/drivers/acpi/acpi.cc +++ b/os/src/drivers/acpi/acpi.cc @@ -206,7 +206,7 @@ class Table_wrapper Table_wrapper(addr_t base) : _base(base), _io_mem(0), _table(0) { - _map(0x1000); + _map(0x1000 - _offset());
/* remap if table size is larger than current size */ if (_offset() + _table->size > 0x1000) {
If this should work, we have to make sure that 0x1000 - offset is at least 8 Bytes wide.
Sebastian
Hi,
Please try to subtract the offset from the initial '_map' call:
That didn't do it, because it still uses the base address with offset for the io mem connection. What did help was to use _base - _offset() in the constructor of Io_mem_connection. Now I could successfully boot genode with USB input devices and launch scout.
But that is of course a very dirty hack to get it running. The question is, why the creation of io_mem_connection fails, or if the memory map has some issues.
diff --git a/os/src/drivers/acpi/acpi.cc b/os/src/drivers/acpi/acpi.cc index 6f4970e..a8322b2 100644 --- a/os/src/drivers/acpi/acpi.cc +++ b/os/src/drivers/acpi/acpi.cc @@ -206,7 +206,7 @@ class Table_wrapper Table_wrapper(addr_t base) : _base(base), _io_mem(0), _table(0) {
_map(0x1000);
_map(0x1000 - _offset()); /* remap if table size is larger than current size */ if (_offset() + _table->size > 0x1000) {If this should work, we have to make sure that 0x1000 - offset is at least 8 Bytes wide.
Sebastian
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
I just wanted to ask about the status of this issue.
Cheers
Markus
On 23 July 2012 17:20, Markus Partheymueller <mail@...119...> wrote:
Hi,
Please try to subtract the offset from the initial '_map' call:
That didn't do it, because it still uses the base address with offset for the io mem connection. What did help was to use _base - _offset() in the constructor of Io_mem_connection. Now I could successfully boot genode with USB input devices and launch scout.
But that is of course a very dirty hack to get it running. The question is, why the creation of io_mem_connection fails, or if the memory map has some issues.
diff --git a/os/src/drivers/acpi/acpi.cc b/os/src/drivers/acpi/acpi.cc index 6f4970e..a8322b2 100644 --- a/os/src/drivers/acpi/acpi.cc +++ b/os/src/drivers/acpi/acpi.cc @@ -206,7 +206,7 @@ class Table_wrapper Table_wrapper(addr_t base) : _base(base), _io_mem(0), _table(0) {
_map(0x1000);
_map(0x1000 - _offset()); /* remap if table size is larger than current size */ if (_offset() + _table->size > 0x1000) {If this should work, we have to make sure that 0x1000 - offset is at least 8 Bytes wide.
Sebastian
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hey Markus,
On 07/26/2012 11:29 AM, Markus Partheymueller wrote:
Hi,
I just wanted to ask about the status of this issue.
Please try to subtract the offset from the initial '_map' call:
That didn't do it, because it still uses the base address with offset for the io mem connection. What did help was to use _base - _offset() in the constructor of Io_mem_connection. Now I could successfully boot genode with USB input devices and launch scout.
But that is of course a very dirty hack to get it running. The question is, why the creation of io_mem_connection fails, or if the memory map has some issues.
You may be right here, but in my opinion the 'Io_mem_connection' should perform as follows: 1. Mask the required region to page alignment 2. Map the thing 3. Add the offset to the dataspace
I have to verify that though, since Christian told me that the behavior may have changed. Therefore: https://github.com/genodelabs/genode/issues/309.
Greetings,
Sebastian
-
Christian Helmuth -
Markus Partheymueller -
Sebastian Sumpf