Hi,
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
Thanks, Bob Stewart
not sure if its this (error code seems to indicate otherwise) but on the am335x you need to enable the various units otherwise they do not appear at their physical addresses at all, and reading from the address will get you a trap.
On Mon, Apr 13, 2015 at 2:41 AM, Bob Stewart <robjsstewart@...196...> wrote:
Hi,
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
Thanks, Bob Stewart
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thanks for the input Tim, but enabing the clock was the first thing I did, as with all the other devices I use. There are power management status registers in the Control Module. The bits in their identify that the PRUSS modules I'm trying to access have power and the memory power is on. Also, the. clock control enable bit is happily sitting at 2 indicating the clock is running.
Everything seems to point to something about the translation table enties, or the lack thereof.
Bob
Sent from my android device.
-----Original Message----- From: Tim Newsham <tim.newsham@...9...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Mon, 13 Apr 2015 12:52 PM Subject: Re: Data Abort MMU exception on mapped IO register read
not sure if its this (error code seems to indicate otherwise) but on the am335x you need to enable the various units otherwise they do not appear at their physical addresses at all, and reading from the address will get you a trap.
On Mon, Apr 13, 2015 at 2:41 AM, Bob Stewart <robjsstewart@...196...> wrote:
Hi,
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
Thanks, Bob Stewart
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
On 04/13/2015 02:41 PM, Bob Stewart wrote:
Hi,
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
What make me wonder is that a DFSR value of 0x805, which means as you already stated a first-level translation fault, should never end in a "unknown MM exception" message. Getting this kind of translation fault is pretty normal, and normally leads to the translation tables being populated.
When you look at the corresponding lines of code:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/incl...
and:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/spec...
Actually when following the execution path you should never get the message with such a DFSR. Are you sure you examined the fault correctly? Do you print 'cpu_exception', and DFSR value directly inside the "unknown MMU exception" message scope?
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
As being said, this is normal. You should not see any translation table entries before it is accessed the first time. It is populated lazily. Normally the exception you describe is the correct time to fill in the entries. The question is why the exception is not treated as an ordinary page-fault exception, but as an unusual type of MMU exception instead.
I assume, you have examined the ordinary exception, but not the actual problematic MMU exception (which is probably an external data-abort - means bus error). Please try out the attached patch, and post the message results.
Regards Stefan
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
Thanks, Bob Stewart
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
On 13.04.2015 14:41, Bob Stewart wrote:
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
To simplify the error case even further, you could manually create an 'Io_mem_connection($DEVICE_BASE) io' and access the return value of 'env()-attach(io->dataspace())'.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
This looks fishy to me. "unknown MMU exception" is printed if the 'in_fault' function returns false. The implementation of this function in [1] returns false only on Data Aborts if 'Dfsr::Fs' is neither 5 (section transl. fault) nor 7 (page transl. fault) but obviously it is 5 in your case.
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
This must not be a problem as the Region Manager in Core doesn't map eager. Instead, Core gets contacted by the kernel as soon as the first fault occurs on a region (this is what should happen next in your scenario). Then, if the faulter is allowed to acces the region, Core adds the mapping to the translation table and resumes the faulter with its PC set to the instruction that caused the fault.
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Although I assume the 'in_fault' inconsistency mentioned above to be the problem: Have you checked wether there is an additional bridge or bus-access controller for the L4? E.g. we had problems with such a controller (AIPS) on our i.MX boards in the past. It prevented access to some devices that were connected through one bus (IPS) while access to devices at the another bus wasn't a problem. Thus, we configure the controller in [2].
Cheers, Martin
[1] base-hw/src/core/include/spec/arm/cpu_support.h [2] base-hw/src/core/include/spec/imx/board_support.h
Thanks for the reply, Stefan. You were correct, I was grabbing the Dfsr after the MMU message. Your patch produced the following:
unknown MMU exception (data-abort) DFSR=1008 IFSR=7 DFAR=8b000000 ip=810006e0
So it looks like its an external issue related to access on the L4 bus to this particular peripheral.
There is little documentation on the L3/L4 interconnections in the TRM for this processor, so I'll ask the Sitara community, which is generally not very helpful.
Thank you very much for your help. Bob
On 04/14/2015 07:27 AM, Stefan Kalkowski wrote:
Hi Bob,
On 04/13/2015 02:41 PM, Bob Stewart wrote:
Hi,
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
What make me wonder is that a DFSR value of 0x805, which means as you already stated a first-level translation fault, should never end in a "unknown MM exception" message. Getting this kind of translation fault is pretty normal, and normally leads to the translation tables being populated.
When you look at the corresponding lines of code:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/incl...
and:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/spec...
Actually when following the execution path you should never get the message with such a DFSR. Are you sure you examined the fault correctly? Do you print 'cpu_exception', and DFSR value directly inside the "unknown MMU exception" message scope?
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
As being said, this is normal. You should not see any translation table entries before it is accessed the first time. It is populated lazily. Normally the exception you describe is the correct time to fill in the entries. The question is why the exception is not treated as an ordinary page-fault exception, but as an unusual type of MMU exception instead.
I assume, you have examined the ordinary exception, but not the actual problematic MMU exception (which is probably an external data-abort - means bus error). Please try out the attached patch, and post the message results.
Regards Stefan
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
Thanks, Bob Stewart
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thanks Martin, your suggestions are very helpfull. My first assumption when I got this error was that it must be related to the L4 bus as all the other peripherals I attached to were on the L3 bus. But I found no mention of. L4 configurabilty in the processors' TRM. Linux has a UIO driver for this particular peripheral but the only configuration that driver did was to enable the clock to the module, which a necessary step for most peripherals on this SoC.
As you can see from my reply to Stefan, the real error is related to bus access.
Bob
Sent from my android device.
-----Original Message----- From: Martin Stein <martin.stein@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Tue, 14 Apr 2015 3:32 AM Subject: Re: Data Abort MMU exception on mapped IO register read
Hi Bob,
On 13.04.2015 14:41, Bob Stewart wrote:
I'm running with 15.02, base-hw on a TI AM3359 processor. I've successfully created device drivers for most of the devices on the peripheral bus without issue. Accessing the the final device i need a driver for, is causing me fits.
I attached the IO device register space with the usual creation of a Attached_io_mem_dataspace based object which also uses the very useful MMIO utility object. I also tried it without MMIO and just accessed the space through local_addr<void>.
To simplify the error case even further, you could manually create an 'Io_mem_connection($DEVICE_BASE) io' and access the return value of 'env()-attach(io->dataspace())'.
When I try to read an address in the mapped space I get an "unknown MMU exception". When I write to the same address no error occurs (I'm assuming for now it's failing silently). Putting PDBG's in the arm thread code shows that the error on the read is is being caused by a DATAT_ABORT. Peeking at the data fault status register (dfsr) shows 0x805 which according the the the ARM7 technical reference manual decodes to a translation table error.
This looks fishy to me. "unknown MMU exception" is printed if the 'in_fault' function returns false. The implementation of this function in [1] returns false only on Data Aborts if 'Dfsr::Fs' is neither 5 (section transl. fault) nor 7 (page transl. fault) but obviously it is 5 in your case.
The virtual address created when the io device is mapped is 0x81B0_0000 (the load_addr<void>), but I see no section table entry being created for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering correctly sections are 16 MB is size for this architecture. I'm instrumenting short_translation_table.h to see what translation table entries are being created. I also don't seen any short translation table entries being created in the 0x81bxx_xxxx region.
This must not be a problem as the Region Manager in Core doesn't map eager. Instead, Core gets contacted by the kernel as soon as the first fault occurs on a region (this is what should happen next in your scenario). Then, if the faulter is allowed to acces the region, Core adds the mapping to the translation table and resumes the faulter with its PC set to the instruction that caused the fault.
My platform support code does include the physical address and size for the region containing the device I'm trying to access.
The only physical difference with this device and the others I've successfully created drivers for, is that is runs of the L4 interconnection whereas the others were on the L3 interconnect. In this SoC the L4 is bridged to the L3 interconnect and runs at half the speed of the L3 bus. But I doubt that this would make any difference to the mapping of the device. This device is also much higher in memory that the other devices.
Although I assume the 'in_fault' inconsistency mentioned above to be the problem: Have you checked wether there is an additional bridge or bus-access controller for the L4? E.g. we had problems with such a controller (AIPS) on our i.MX boards in the past. It prevented access to some devices that were connected through one bus (IPS) while access to devices at the another bus wasn't a problem. Thus, we configure the controller in [2].
Cheers, Martin
[1] base-hw/src/core/include/spec/arm/cpu_support.h [2] base-hw/src/core/include/spec/imx/board_support.h
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
On 14.04.2015 14:19, robjsstewart@...196... wrote:
Linux has a UIO driver for this particular peripheral but the only configuration that driver did was to enable the clock to the module, which a necessary step for most peripherals on this SoC.
As you can see from my reply to Stefan, the real error is related to bus access.
If Linux does merely this clock config, different boot loaders could cause the different bus configs. Thus, if you don't find documentation on the bus controllers, maybe the boot loader source of your Linux scenario gives you further hints.
Cheers, Martin
Good idea, Martin. I'll dig through the u-boot source for the AM335x. I sent a message to Robert C Nelson who maintains an excellent wiki on various ARM processors to see what he did to get the Linux driver working.
Bob
Sent from my android device.
-----Original Message----- From: Martin Stein <martin.stein@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Tue, 14 Apr 2015 8:30 AM Subject: Re: Data Abort MMU exception on mapped IO register read
Hi Bob,
On 14.04.2015 14:19, robjsstewart@...196... wrote:
Linux has a UIO driver for this particular peripheral but the only configuration that driver did was to enable the clock to the module, which a necessary step for most peripherals on this SoC.
As you can see from my reply to Stefan, the real error is related to bus access.
If Linux does merely this clock config, different boot loaders could cause the different bus configs. Thus, if you don't find documentation on the bus controllers, maybe the boot loader source of your Linux scenario gives you further hints.
Cheers, Martin
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Through some educated bit fiddling I managed to get the PRUSS module to be io mapped correctly and thereby able to read and write to it.
For those who may try to get the PRUSS module on a TI AM335x working on the base-hw kernel, the module is sitting by default in a power reset state. It requires that the Pru_icss_lrst bit in the RM_PER_RSTCTL register be cleared before doing any operations on the module Section 8.1.13.2 in the TRM contains the register definitions.
Thanks again to Stefan and Martin for their help.
Bob
Sent from my android device.
-----Original Message----- From: robjsstewart@...196... To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Tue, 14 Apr 2015 9:37 AM Subject: Re: Data Abort MMU exception on mapped IO register read
Good idea, Martin. I'll dig through the u-boot source for the AM335x. I sent a message to Robert C Nelson who maintains an excellent wiki on various ARM processors to see what he did to get the Linux driver working.
Bob
Sent from my android device.
-----Original Message----- From: Martin Stein <martin.stein@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Tue, 14 Apr 2015 8:30 AM Subject: Re: Data Abort MMU exception on mapped IO register read
Hi Bob,
On 14.04.2015 14:19, robjsstewart@...196... wrote:
Linux has a UIO driver for this particular peripheral but the only configuration that driver did was to enable the clock to the module, which a necessary step for most peripherals on this SoC.
As you can see from my reply to Stefan, the real error is related to bus access.
If Linux does merely this clock config, different boot loaders could cause the different bus configs. Thus, if you don't find documentation on the bus controllers, maybe the boot loader source of your Linux scenario gives you further hints.
Cheers, Martin
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
unknown＠example.com -
Bob Stewart -
Martin Stein -
Stefan Kalkowski -
Tim Newsham