Hey,
I'm attempting to make a simple reboot feature on Freescale's iMX53-QSB. I'm currently working using the tz_vmm example. So, I understand that the way to achieve that on this board is through the watchdog timer, I followed the Linux kernel code that does this, and implemented a kernel module that does only the reboot part, this what i came up with: - volatile unsigned short *wdog1_base = (volatile unsigned short*) 0xf7e98000; *wdog1_base = (1 << 2); -
This exact code, i a kernel module, does an immediate reset and i get the u-boot shell. All of this is done on the normal world of course, now i wish to have this in the secure world, Running the exact same code in the secure world, in the handle hypercall routine i get: - no RM attachment (faulter 129090 with IP 70014c28 attempts to write to address f7e98000) void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented unknown signal context -
Any idea's how to achieve my reset from the secure world ? Also, if someone could shed some light about the error, I'm not that familiar with Genode, just starting to work with it.
Thanks in advanced.
Hi Ofer,
On 09/10/2015 10:21 AM, Ofer Hasson wrote:
Hey,
I'm attempting to make a simple reboot feature on Freescale's iMX53-QSB. I'm currently working using the tz_vmm example. So, I understand that the way to achieve that on this board is through the watchdog timer, I followed the Linux kernel code that does this, and implemented a kernel module that does only the reboot part, this what i came up with:
volatile unsigned short *wdog1_base = (volatile unsigned short*) 0xf7e98000; *wdog1_base = (1 << 2);
This exact code, i a kernel module, does an immediate reset and i get the u-boot shell. All of this is done on the normal world of course, now i wish to have this in the secure world, Running the exact same code in the secure world, in the handle hypercall routine i get:
no RM attachment (faulter 129090 with IP 70014c28 attempts to write to address f7e98000) void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented unknown signal context
The problem is that you took the virtual address the watchdog is mapped to within the Linux kernel, and try to access that address within Genode's HW kernel. That is why you see above page-fault message.
The kernel is running with a configured MMU too, it is not disabled within the kernel. Moreover, the kernel does not have all physical memory mapped one-by-one automatically.
Is there a hard constrain to do the reset within the kernel? It is much more convenient and easy to implement for instance within the platform driver. Because you do not need to extend the kernel syscall interface, or need an extra session interface within core. You could extend the platform driver interface instead.
In general, what a driver needs to do to access the Watchdog registers is the following:
# open an IOMEM session with the corresponding physical address (bus address) of the watchdog device # map the IOMEM dataspace to a free virtual memory area # access the watchdog registers via the virtual addresses, it was mapped to
A convenient way is to use the Attached_mmio helper class. It does everything for you. Moreover, the MMIO framework (used in that class) allows you to define registers, and bit-magic in a more comprehensible fashion.
The code to reset the board would look like the following:
#include <os/attached_mmio.h>
struct Watchdog : Genode::Attached_mmio { /* 16bit register at offset 0 */ struct Control : Register<0x0, 16> {
/* this Bitfield relates to (1 << 2) */ struct Enable : Bitfield<2, 1> {}; };
/* * the physical address range of the watchdog has to be given to * the attched_mmio base class (manual says: 0x53F98000, 0x1000) */ Watchdog() : Attached_mmio(WDOG_BASE, WDOG_SIZE) {}
void reset() { writeControl::Enable(1); } };
Assuming that Linux is doing nothing more with the device, and the device is accessable from user mode, it should work to incorporate above snippet into the platform driver.
Best Regards Stefan
Any idea's how to achieve my reset from the secure world ? Also, if someone could shed some light about the error, I'm not that familiar with Genode, just starting to work with it.
Thanks in advanced.
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I'll try it, thank you very much
On Thu, Sep 10, 2015 at 4:42 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Ofer,
On 09/10/2015 10:21 AM, Ofer Hasson wrote:
Hey,
I'm attempting to make a simple reboot feature on Freescale's iMX53-QSB. I'm currently working using the tz_vmm example. So, I understand that the way to achieve that on this board is through
the
watchdog timer, I followed the Linux kernel code that does this, and implemented a kernel module that does only the reboot part, this what i came up with:
volatile unsigned short *wdog1_base = (volatile unsigned short*)
0xf7e98000;
*wdog1_base = (1 << 2);
This exact code, i a kernel module, does an immediate reset and i get the u-boot shell. All of this is done on the normal world of course, now i wish to have
this
in the secure world, Running the exact same code in the secure world, in the handle hypercall routine i get:
no RM attachment (faulter 129090 with IP 70014c28 attempts to write to address f7e98000) void Genode::Pager_object::unresolved_page_fault_occurred(): not
implemented
unknown signal context
The problem is that you took the virtual address the watchdog is mapped to within the Linux kernel, and try to access that address within Genode's HW kernel. That is why you see above page-fault message.
The kernel is running with a configured MMU too, it is not disabled within the kernel. Moreover, the kernel does not have all physical memory mapped one-by-one automatically.
Is there a hard constrain to do the reset within the kernel? It is much more convenient and easy to implement for instance within the platform driver. Because you do not need to extend the kernel syscall interface, or need an extra session interface within core. You could extend the platform driver interface instead.
In general, what a driver needs to do to access the Watchdog registers is the following:
# open an IOMEM session with the corresponding physical address (bus address) of the watchdog device # map the IOMEM dataspace to a free virtual memory area # access the watchdog registers via the virtual addresses, it was mapped to
A convenient way is to use the Attached_mmio helper class. It does everything for you. Moreover, the MMIO framework (used in that class) allows you to define registers, and bit-magic in a more comprehensible fashion.
The code to reset the board would look like the following:
#include <os/attached_mmio.h>
struct Watchdog : Genode::Attached_mmio { /* 16bit register at offset 0 */ struct Control : Register<0x0, 16> {
/* this Bitfield relates to (1 << 2) */ struct Enable : Bitfield<2, 1> {}; }; /* * the physical address range of the watchdog has to be given to * the attched_mmio base class (manual says: 0x53F98000, 0x1000) */ Watchdog() : Attached_mmio(WDOG_BASE, WDOG_SIZE) {} void reset() { write<Control::Enable>(1); }};
Assuming that Linux is doing nothing more with the device, and the device is accessable from user mode, it should work to incorporate above snippet into the platform driver.
Best Regards Stefan
Any idea's how to achieve my reset from the secure world ? Also, if someone could shed some light about the error, I'm not that familiar with Genode, just starting to work with it.
Thanks in advanced.
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I forgot to update, it works perfectly, thank you so much !
On Fri, Sep 11, 2015 at 7:39 AM, Ofer Hasson <hassonof@...310...> wrote:
I'll try it, thank you very much
On Thu, Sep 10, 2015 at 4:42 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Ofer,
On 09/10/2015 10:21 AM, Ofer Hasson wrote:
Hey,
I'm attempting to make a simple reboot feature on Freescale's iMX53-QSB. I'm currently working using the tz_vmm example. So, I understand that the way to achieve that on this board is through
the
watchdog timer, I followed the Linux kernel code that does this, and implemented a
kernel
module that does only the reboot part, this what i came up with:
volatile unsigned short *wdog1_base = (volatile unsigned short*)
0xf7e98000;
*wdog1_base = (1 << 2);
This exact code, i a kernel module, does an immediate reset and i get
the
u-boot shell. All of this is done on the normal world of course, now i wish to have
this
in the secure world, Running the exact same code in the secure world, in the handle hypercall routine i get:
no RM attachment (faulter 129090 with IP 70014c28 attempts to write to address f7e98000) void Genode::Pager_object::unresolved_page_fault_occurred(): not
implemented
unknown signal context
The problem is that you took the virtual address the watchdog is mapped to within the Linux kernel, and try to access that address within Genode's HW kernel. That is why you see above page-fault message.
The kernel is running with a configured MMU too, it is not disabled within the kernel. Moreover, the kernel does not have all physical memory mapped one-by-one automatically.
Is there a hard constrain to do the reset within the kernel? It is much more convenient and easy to implement for instance within the platform driver. Because you do not need to extend the kernel syscall interface, or need an extra session interface within core. You could extend the platform driver interface instead.
In general, what a driver needs to do to access the Watchdog registers is the following:
# open an IOMEM session with the corresponding physical address (bus address) of the watchdog device # map the IOMEM dataspace to a free virtual memory area # access the watchdog registers via the virtual addresses, it was mapped to
A convenient way is to use the Attached_mmio helper class. It does everything for you. Moreover, the MMIO framework (used in that class) allows you to define registers, and bit-magic in a more comprehensible fashion.
The code to reset the board would look like the following:
#include <os/attached_mmio.h>
struct Watchdog : Genode::Attached_mmio { /* 16bit register at offset 0 */ struct Control : Register<0x0, 16> {
/* this Bitfield relates to (1 << 2) */ struct Enable : Bitfield<2, 1> {}; }; /* * the physical address range of the watchdog has to be given to * the attched_mmio base class (manual says: 0x53F98000, 0x1000) */ Watchdog() : Attached_mmio(WDOG_BASE, WDOG_SIZE) {} void reset() { write<Control::Enable>(1); }};
Assuming that Linux is doing nothing more with the device, and the device is accessable from user mode, it should work to incorporate above snippet into the platform driver.
Best Regards Stefan
Any idea's how to achieve my reset from the secure world ? Also, if someone could shed some light about the error, I'm not that familiar with Genode, just starting to work with it.
Thanks in advanced.
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Ofer Hasson -
Stefan Kalkowski