Re: i.MX6 support
Okay We will follow Martin's suggestion of using a different board_base.h file for our board. Regards Praveen On Sat, Mar 28, 2015 at 9:53 AM, Madhu (Macaque Labs) ma...@macaque.in wrote: Praveen, What are are asking for (default UART, RAM size) are board specific features. can't these be added to files for board specific configuration ? They can be added to make but Make anyway will need to have config for each board and it is better not to hard code that config in the Makefile. Preferable to pick it up from a config file. On Fri, Mar 27, 2015 at 5:54 PM, Praveen B srinivas...@gmail.com wrote: Hi Martin, We have tested the ported code on SABRE Lite board and it is working, except that we need to change UART1 to UART2(0x021e8000). Our default console for u-boot is UART2. We tried to see the output of Genode runscript on UART1(by keeping actual values for UART) also but for some reason we see a non-readable output on UART1. This serial port hardware do not have any issues, since we are able to use both the serial ports while running Linux, with same configuration on the same board. If you know of any possible reasons for enabling this to work correctly, please let us know. Regarding RAM region, is it possible to set default values to 1 GB, as Sabre Lite is having only 1 GB RAM. Or Is it possible to pass the size(along with the possible UART interface) as an option through a variable in Makefile? (By this we can keep generic variables and assign these generic values depending on some variable set in make file.) Apart from these typical configuration changes, we have verified that the image generated from this branch is working successfully on Sabrelite board. Regards Praveen Srinivas IIT Madras On Thu, Mar 26, 2015 at 11:00 PM, Praveen B srinivas...@gmail.com wrote: Hi Martin, Good to know the similarities in ESDHC and USDHC. Same method can be adopted for USDHC as the driver does not use CID register(only other 132 bit register). Taking into consideration all the issues, we have forked another repository, https://github.com/iitmadras/genode and updated the commits. Please take a look at it. On Thu, Mar 26, 2015 at 8:51 PM, Martin Stein martin.st...@genode-labs.com wrote: Hi Praveen, I've created a branch (https://github.com/m-stein/genode/tree/1467_hw_imx6_support) that works on our Wandboard Quad and our CuBox-i and opened an according issue (https://github.com/genodelabs/genode/issues/1467). Some annotations: * I have not merged the Trustzone support that was started in your branch as there is no scenario for this right now. We will update on Trustzone support, once we are confident about it. * I tried to add the L2-cache support from your branch but it doesn't work as it is for our boards. Thus, I didn't merge it. We tried to add L2-cache support. But it is not working for Sabre Lite board as well. We should have removed it in the previous repository. It is updated in the new repository. * I modified the kernel to not use the EPIT timer but the CortexA9 Private Timer because it's our default on CortexA9 CPUs and the better choice when enabling SMP support. Okay. We will try it on our board. It should work. By the way, is SMP enabled for CortexA9 processors in the latest base-hw version? Because In our port if we return false for is_smp() function of our board, there is an unresolved page fault in the Core thread. We have also assigned variable, NR_OF_CPUS = 1. * I've merged some redundant code between i.MX6 and i.MX53 into ``spec/imx`` The file 'serial.h' in spec/imx can be an issue for our board, because our board uses UART 0x021e8000 as you mentioned below. We'll think about how to solve it. * I've not merged the uSDHC enums and specs that your i.MX6 port includes because they should be added by the uSDHC commit The main differences between our boards and yours seem to be the following: * the Cortex A9 clock (Wand/Cubox: 792 Mhz, Your board: 800 Mhz) but this value isn't needed anyway * the UART instance connected to the serial port (Wand/Cubox: 0x0202, Your board: 0x021e8000) * the RAM range configuration Do you have any objections regarding the commit? If not, I'd suggest you to re-base your work regarding the i.MX6 onto the branch respectively the Genode master branch as soon as the commit arrived there to simplify our collaboration in the future. We will try to run the code on our board as soon as possible and let you know, If there are any issues. Regards Praveen Srinivas IIT Madras Cheers, Martin -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials
Re: i.MX6 support
Hi Martin, We have tested the ported code on SABRE Lite board and it is working, except that we need to change UART1 to UART2(0x021e8000). Our default console for u-boot is UART2. We tried to see the output of Genode runscript on UART1(by keeping actual values for UART) also but for some reason we see a non-readable output on UART1. This serial port hardware do not have any issues, since we are able to use both the serial ports while running Linux, with same configuration on the same board. If you know of any possible reasons for enabling this to work correctly, please let us know. Regarding RAM region, is it possible to set default values to 1 GB, as Sabre Lite is having only 1 GB RAM. Or Is it possible to pass the size(along with the possible UART interface) as an option through a variable in Makefile? (By this we can keep generic variables and assign these generic values depending on some variable set in make file.) Apart from these typical configuration changes, we have verified that the image generated from this branch is working successfully on Sabrelite board. Regards Praveen Srinivas IIT Madras On Thu, Mar 26, 2015 at 11:00 PM, Praveen B srinivas...@gmail.com wrote: Hi Martin, Good to know the similarities in ESDHC and USDHC. Same method can be adopted for USDHC as the driver does not use CID register(only other 132 bit register). Taking into consideration all the issues, we have forked another repository, https://github.com/iitmadras/genode and updated the commits. Please take a look at it. On Thu, Mar 26, 2015 at 8:51 PM, Martin Stein martin.st...@genode-labs.com wrote: Hi Praveen, I've created a branch (https://github.com/m-stein/genode/tree/1467_hw_imx6_support) that works on our Wandboard Quad and our CuBox-i and opened an according issue (https://github.com/genodelabs/genode/issues/1467). Some annotations: * I have not merged the Trustzone support that was started in your branch as there is no scenario for this right now. We will update on Trustzone support, once we are confident about it. * I tried to add the L2-cache support from your branch but it doesn't work as it is for our boards. Thus, I didn't merge it. We tried to add L2-cache support. But it is not working for Sabre Lite board as well. We should have removed it in the previous repository. It is updated in the new repository. * I modified the kernel to not use the EPIT timer but the CortexA9 Private Timer because it's our default on CortexA9 CPUs and the better choice when enabling SMP support. Okay. We will try it on our board. It should work. By the way, is SMP enabled for CortexA9 processors in the latest base-hw version? Because In our port if we return false for is_smp() function of our board, there is an unresolved page fault in the Core thread. We have also assigned variable, NR_OF_CPUS = 1. * I've merged some redundant code between i.MX6 and i.MX53 into ``spec/imx`` The file 'serial.h' in spec/imx can be an issue for our board, because our board uses UART 0x021e8000 as you mentioned below. We'll think about how to solve it. * I've not merged the uSDHC enums and specs that your i.MX6 port includes because they should be added by the uSDHC commit The main differences between our boards and yours seem to be the following: * the Cortex A9 clock (Wand/Cubox: 792 Mhz, Your board: 800 Mhz) but this value isn't needed anyway * the UART instance connected to the serial port (Wand/Cubox: 0x0202, Your board: 0x021e8000) * the RAM range configuration Do you have any objections regarding the commit? If not, I'd suggest you to re-base your work regarding the i.MX6 onto the branch respectively the Genode master branch as soon as the commit arrived there to simplify our collaboration in the future. We will try to run the code on our board as soon as possible and let you know, If there are any issues. Regards Praveen Srinivas IIT Madras Cheers, Martin -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join
Re: i.MX6 support
Hi Martin, Good to know the similarities in ESDHC and USDHC. Same method can be adopted for USDHC as the driver does not use CID register(only other 132 bit register). Taking into consideration all the issues, we have forked another repository, https://github.com/iitmadras/genode and updated the commits. Please take a look at it. On Thu, Mar 26, 2015 at 8:51 PM, Martin Stein martin.st...@genode-labs.com wrote: Hi Praveen, I've created a branch (https://github.com/m-stein/genode/tree/1467_hw_imx6_support) that works on our Wandboard Quad and our CuBox-i and opened an according issue (https://github.com/genodelabs/genode/issues/1467). Some annotations: * I have not merged the Trustzone support that was started in your branch as there is no scenario for this right now. We will update on Trustzone support, once we are confident about it. * I tried to add the L2-cache support from your branch but it doesn't work as it is for our boards. Thus, I didn't merge it. We tried to add L2-cache support. But it is not working for Sabre Lite board as well. We should have removed it in the previous repository. It is updated in the new repository. * I modified the kernel to not use the EPIT timer but the CortexA9 Private Timer because it's our default on CortexA9 CPUs and the better choice when enabling SMP support. Okay. We will try it on our board. It should work. By the way, is SMP enabled for CortexA9 processors in the latest base-hw version? Because In our port if we return false for is_smp() function of our board, there is an unresolved page fault in the Core thread. We have also assigned variable, NR_OF_CPUS = 1. * I've merged some redundant code between i.MX6 and i.MX53 into ``spec/imx`` The file 'serial.h' in spec/imx can be an issue for our board, because our board uses UART 0x021e8000 as you mentioned below. We'll think about how to solve it. * I've not merged the uSDHC enums and specs that your i.MX6 port includes because they should be added by the uSDHC commit The main differences between our boards and yours seem to be the following: * the Cortex A9 clock (Wand/Cubox: 792 Mhz, Your board: 800 Mhz) but this value isn't needed anyway * the UART instance connected to the serial port (Wand/Cubox: 0x0202, Your board: 0x021e8000) * the RAM range configuration Do you have any objections regarding the commit? If not, I'd suggest you to re-base your work regarding the i.MX6 onto the branch respectively the Genode master branch as soon as the commit arrived there to simplify our collaboration in the future. We will try to run the code on our board as soon as possible and let you know, If there are any issues. Regards Praveen Srinivas IIT Madras Cheers, Martin -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: SD card driver for Freescale i.MX6 in Genode
Hi Norman On Fri, Mar 20, 2015 at 4:10 PM, Norman Feske norman.fe...@genode-labs.com wrote: Hello Praveen, We have developed a Genode device driver for USDHC card reader for Freescale i.MX6 procesor. You may find the corresponding code in the repository, https://github.com/srinivasprv/genode The specific driver code is available in usdhc directory of sd_card directory. thank you for sharing your work with us! Your patch looks very nice. Thank you. Coincidentally, we just added an SD-card driver for the i.MX53 platform last week. See the following commit referenced at the following issue: https://github.com/genodelabs/genode/issues/1458 Whereas the i.MX53 driver addresses the so-called ESDHC controller, your patch addresses the USDHC controller. Are both drivers complementary? As Martin replied, there were some new register definitions in USDHC and some common registers differ. For example, the lower 16 bit-fields of CMD register(called XFER_TYPE in ESDHC), are defined in Mixer_Control register for USDHC. Also USDHC returns CSD register shifted by 8 bits. That has to be handled in read_csd() function of the controller code. Regards Praveen Srinivas IIT Madras On another note, the mainline Genode version does not officially support i.MX6 yet. So I am afraid that including your driver without prior enabling i.MX6 would not be very sensible. As a precondition, we should enable at least one i.MX6-based platform (e.g., Wandboard?). Otherwise, we would not able to add your driver to our regular test infrastructure. What do you think about how to go about it? Best regards Norman -- 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 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
SD card driver for Freescale i.MX6 in Genode
Dear all, We have developed a Genode device driver for USDHC card reader for Freescale i.MX6 procesor. You may find the corresponding code in the repository, https://github.com/srinivasprv/genode The specific driver code is available in usdhc directory of sd_card directory. We have tested the driver with L4Linux. The test procedure was done by copying and moving files, as large as 1GB, multiple times across different partitions of SD card. The expected behavior and actual behavior matched in all cases. Request you to review the code and offer comments. We would also like to know if this can be integrated into the next version of Genode release. Look forward to your review comments. Regards Praveen Srinivas IIT Madras -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Para-virtualization support for ARM on Genode
Hi Stefan, Thank you for the information. Can you explain how we can run the two tests, Network performance and compiling Genode's core on Genode tests? We will use latest Fiasco.OC kernel by modifying etc/foc.conf, if version matters. For linux performance we will use standard tools. Regards Praveen On Thu, Sep 25, 2014 at 6:44 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com wrote: Hi Praveen, On 09/25/2014 12:12 PM, Praveen B wrote: Hi Stefan, (Sorry I was in a hurry and mentioned Norman in my previous mail) I can run L4Linux, on i.MX6 board with Genode on Fiasco.OC kernel. But there is one confusion. Is Genode running as an application in L4Re? How are L4re, Genode and L4Linux related in the port for Fiasco.OC kernel? Genode isn't running as an application in L4Re. L4Linux in its unmodified form uses L4Re bindings, as well as Fiasco.OC kernel bindings. Our version of L4Linux in Genode replaces the L4Re library with a Genode specific one that implements the same API. However, Genode's L4Linux version is tied to the Fiasco.OC kernel bindings, like the original one. Can you give an estimate of how much is the performance drawback of running Genode over Fiasco.OC kernel over base-hw? How do we go about measuring the performance difference? Well, as always this is a matter of what kind of performance test you do. I would be very cautious in judging performance in general. I can provide exactly two kinds of measurements we're doing regularily. The first is a network performance test (I/O burden), which measures throughput of packets within a defined time range. The following numbers are measured on a Cortex A9 Pandaboard: |---| || Genode/Fiasco.OC | Genode/HW | |---| | RX | 70.2 Mbit/s| 88.8 Mbit/s | |---| | TX | 89.7 MBit/s| 93.7 MBit/s | |---| The second is compiling Genode's core process on top of Genode. The following numbers are measured on a Cortex A15 Arndale board. With Fiasco.OC the whole test takes 492 seconds, and on the HW-kernel it takes 216 seconds. This test spawns a lot of child processes, and destroys them again. Thereby everything is done sequentially. Fiasco.OC's SMP implementation suffers from a performance weakness when it comes to kernel object deletion. However, we use an already outdated version of Fiasco.OC. It might be that the developers of Fiasco.OC removed this performance weakness in the meantime. However, when it comes to L4Linux, most performance critical functionality (e.g. paging code) is done using kernel primitives only. That said, the difference of the runtime performance of L4Linux on top of L4Re or Genode should be less important in contrast to ordinary Genode applications. But I haven't measured it in the past. We need only one virtual linux as Mr.Madhu mentioned. But trustzone is not yet working for i.MX6 board and another student, Chirag, is working on that. We will look into that solution once trustzone works. But Which one of the three solutions might be the better solution in terms of performance? I think it is Trustzone VM as the guest runs as there is no virtualization overhead of CPU and Memory. Please clarify. I would assume the same, especially when the VM uses a lot of hardware devices on its behalf. But when doing heavy I/O related stuff on virtualized devices it might be different. As the world switch between non-secure/secure world is more costly than a normal context switch, and the memory transfer (using non-cached memory) is more costly too, a para-virtualized guest in the secure world might be cheaper. Again it depends on the use-case, and you'll have to measure it, if performance is such an issue. Regards Stefan Thanks in advance Regards Praveen, IIT Madras On Mon, Sep 22, 2014 at 8:37 PM, Praveen B srinivas...@gmail.com mailto:srinivas...@gmail.com wrote: Norman, Thank you for the reply. On Mon, Sep 22, 2014 at 3:25 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com mailto:stefan.kalkow...@genode-labs.com wrote: Hi, On 09/22/2014 08:26 AM, Praveen B wrote: Hi We are able to run Genode-14.08 on i.MX6 board. Now I am planning to add support for virtualization for Genode on i.MX6. As the processor is Cortex-A9, it does not have virtualization extensions. So I am planning to implement a hypervisor to run para-virtualized linux, similar to the one proposed in the following paper, http://systems.cs.columbia.edu/archive/pub/2014/03/kvm-arm-the-design-and-implementation-of-the-linux-arm-hypervisor/ The paper you're refering to doesn't use a para
Re: Para-virtualization support for ARM on Genode
Stefan, On Fri, Sep 26, 2014 at 4:43 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com wrote: Hi Praveen, On 09/26/2014 11:16 AM, Praveen B wrote: Hi Stefan, Thank you for the information. Can you explain how we can run the two tests, Network performance and compiling Genode's core on Genode tests? The network performance was measured using the run script netperf_lwip, the Genode core compilation is measured using noux_tool_chain_auto. Both run scripts can be found in the 'ports' repository, under 'repos/ports/run'. Thank you. We will use them for our tests. We will use latest Fiasco.OC kernel by modifying etc/foc.conf, if version matters. It's just an assumption, as I said I don't know whether the developers of Fiasco.OC fixed the SMP performance weakness in a more recent version. The following e-mail from Christian Prochaska on the l4-hackers mailing list explains the SMP problem in more detail: http://permalink.gmane.org/gmane.comp.micro-kernel.l4.devel/4896 I'll run L4Linux on L4Re on both the kernels(old and new). If I can find significant performance improvement then I'll try to run over Genode. Just a warning: if you're planning to upgrade to a more recent version of Fiasco.OC, don't expect that everthing will run out-of-the-box. If there are some issues like makefiles and toolchains, I might be able to handle them. Otherwise, I'll get back to you. Thanks and Regards Praveen Regards Stefan -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Para-virtualization support for ARM on Genode
Hi Stefan, (Sorry I was in a hurry and mentioned Norman in my previous mail) I can run L4Linux, on i.MX6 board with Genode on Fiasco.OC kernel. But there is one confusion. Is Genode running as an application in L4Re? How are L4re, Genode and L4Linux related in the port for Fiasco.OC kernel? Can you give an estimate of how much is the performance drawback of running Genode over Fiasco.OC kernel over base-hw? How do we go about measuring the performance difference? We need only one virtual linux as Mr.Madhu mentioned. But trustzone is not yet working for i.MX6 board and another student, Chirag, is working on that. We will look into that solution once trustzone works. But Which one of the three solutions might be the better solution in terms of performance? I think it is Trustzone VM as the guest runs as there is no virtualization overhead of CPU and Memory. Please clarify. Thanks in advance Regards Praveen, IIT Madras On Mon, Sep 22, 2014 at 8:37 PM, Praveen B srinivas...@gmail.com wrote: Norman, Thank you for the reply. On Mon, Sep 22, 2014 at 3:25 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com wrote: Hi, On 09/22/2014 08:26 AM, Praveen B wrote: Hi We are able to run Genode-14.08 on i.MX6 board. Now I am planning to add support for virtualization for Genode on i.MX6. As the processor is Cortex-A9, it does not have virtualization extensions. So I am planning to implement a hypervisor to run para-virtualized linux, similar to the one proposed in the following paper, http://systems.cs.columbia.edu/archive/pub/2014/03/kvm-arm-the-design-and-implementation-of-the-linux-arm-hypervisor/ The paper you're refering to doesn't use a para-virtualization approach, but uses hardware assisted virtualization. I'm sorry. That was wrong link. The paper is, http://systems.cs.columbia.edu/archive/pub/2010/07/kvm-for-arm/ I am not sure that would work for ARMv7 as they have only tested for ARMv5. Can you suggest any other para-virtualization solutions preferred for the implementation of Genode. I saw L4Linux but it is a port of linux to L4Re and not to the kernel itself. On the other hand, SierraVisor and Xen are bare metal hypervisors. You're right vanilla L4Linux is tied to L4Re, but we've a port of L4Linux that runs on Genode, but on Fiasco.OC only. Alternatively, if one instance of Linux is enough for your scenario, you might use the normal world of TrustZone to ease up para-virtualization, as you don't have to implement CPU virtualization on your own, but other devices only. The third alternative of course is to para-virtualize Linux from scratch. We will use the first option, that is, L4Linux with Genode on Fiasco.OC. Thank you Regards Praveen The road map for Genode 14.11 says virtualization support for Cortex-A7. I assume you will be using virtualization extensions and not a para-virtualization solution. Yes, we're planning to support hardware-assisted virtualization, although it should be called Cortex-A15 instead of Cortex-A7. Nevertheless, the difference should be negligible. Can you suggest which is the best place to start. Should I implement a VMM similar to tz_vmm server or should it be implemented in base-hw as VMM should be in supevisor mode and not user mode. If you're planning to build a para-virtualized solution on your own, I would strongly recommend to follow the spirit of Genode's microkernel based architecture. To minimize the trusted computing base (TCB) of all applications, the kernel shouldn't include code that is used just by a corner-case (para-virtualization) application. Instead use the scheme of having the virtual machine monitor within the user-mode. Thereby, the VMM might be linked together with the para-virtualized VM, like it is done in the L4Linux approach, or you change to a disjunct VMM task whenever the VM traps. Regards Stefan Regards Praveen Srinivas M.Tech 2nd Year, CSE, IIT Madras -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ 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/ -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance
Para-virtualization support for ARM on Genode
Hi We are able to run Genode-14.08 on i.MX6 board. Now I am planning to add support for virtualization for Genode on i.MX6. As the processor is Cortex-A9, it does not have virtualization extensions. So I am planning to implement a hypervisor to run para-virtualized linux, similar to the one proposed in the following paper, http://systems.cs.columbia.edu/archive/pub/2014/03/kvm-arm-the-design-and-implementation-of-the-linux-arm-hypervisor/ I am not sure that would work for ARMv7 as they have only tested for ARMv5. Can you suggest any other para-virtualization solutions preferred for the implementation of Genode. I saw L4Linux but it is a port of linux to L4Re and not to the kernel itself. On the other hand, SierraVisor and Xen are bare metal hypervisors. The road map for Genode 14.11 says virtualization support for Cortex-A7. I assume you will be using virtualization extensions and not a para-virtualization solution. Can you suggest which is the best place to start. Should I implement a VMM similar to tz_vmm server or should it be implemented in base-hw as VMM should be in supevisor mode and not user mode. Regards Praveen Srinivas M.Tech 2nd Year, CSE, IIT Madras -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Platform Initialization Problem
Martin, Thank you very much. For the latest code we can start genode successfully, after adding appropriate changes for imx6. But there was one issue, imx53 and imx31 uses uart 1 and imx6 uses uart2 as mentioned by Aditya here, http://sourceforge.net/p/genode/mailman/message/31897976/ . In the latest code imx53 and imx31 uses serial.h from imx folder in base-hw/src/core/include/spec folder. Instead of using this serial.h, we modified serial.h to use uart 2 and kept the file in imx6 folder and changed the makefile accordingly. Now it is working. Thank you Praveen IIT Madras. On Mon, Aug 18, 2014 at 12:02 PM, Martin Stein martin.st...@genode-labs.com wrote: Hi Praveen, On 18.08.2014 07:00, Praveen B wrote: We will pull the current branch and try if it works, as you suggested for Bob. I think that would be a good idea. Be aware that further wide-ranging clean-up commits, especially hw: re-organize file structure, entered the master branch recently. If you have any questions regarding the concept behind these changes, don't hesitate to ask. Martin -- ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main -- ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Platform Initialization Problem
Hi Martin, Sorry I could not reply soon as I've been away for a while. And Thank you for the explanation. The address 0x10159000 is not present in BSS. BSS range is 0x1007 to 0x10112fa4. I've checked it and everything is going fine until first Rom_module is created. After allocation, we are getting page fault in the constructor call of Avl_string_base, the class from which Rom_module is derived. The address of page fault is 0x1008 same as in the case of Bob working on Beaglebone. And our code was also working till 13.11. I guess our problem is also related to MMU, which is MMDC for imx6 as I mentioned in my previous mail. We will pull the current branch and try if it works, as you suggested for Bob. Thanks and Regards Praveen IIT Madras. On Mon, Aug 11, 2014 at 4:43 PM, Martin Stein martin.st...@genode-labs.com wrote: Hi Praveen, Stefan isn't online these days. 'Genode::map_local()' uses the 'Kernel::core_pd()-platform_pd()-page_slab()' as backing store. This allocator is of the type 'Genode::Page_slab' as defined in 'base-hw/src/core/include/page_slab.h'. The class contains a member 'Slab_block _initial_sb' which is used for the first couple of allocations (especially for the allocation of the second slab block). Furthermore the page slab of the core PD is created via the 'unmanaged_singleton' utility in 'base-hw/src/core/kernel/kernel.cc'. Thus it should be located in the BSS. That said, it might be normal that you're observing a page-table base inside the program image. Is 0x10159000 inside your BSS? You can check this via 'genode-arm-objdump' or instrument the Page_slab::alloc method to check wether it uses the initial block for this page table. Cheers Martin On 08.08.2014 09:14, Praveen B wrote: Hi Stefan, I am working along with Chirag to port Genode on imx6. We inserted the existing RAM regions in Platform::_ram_regions.( We rechecked it with linux kernel source code for imx6) But still we are getting page fault on every access to new Rom_module. I tried to track the memory allocation what I understood is, In map_local() call, when inserting into page tables in _insert_second_level() function in short_translation_table.h file of base-hw, slab-phys_addr() and slab-virt_addr() return 0 after kernel initialization. So it creates a new page table and inserting into it. Inserting the same values(phys:1000, virt:1000) as arguments of map_local() function in platform.cc. When I print the address of new page table created, I found that it is in the range of Program Image.(address of pt is 10159000, and program image range is (10001000-10189fa4). I wonder if the memory allotted is clashing with program memory. Or, Can it be the issue with MMDC controller of imx6? Because no other board in base-hw uses MMDC controller, do we need to implement the interface for MMDC in imx6? Thanks and Regards Praveen, IIT Madras On Tue, Jul 29, 2014 at 6:43 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com wrote: Hi, On 07/28/2014 11:28 AM, chirag garg wrote: Hi stefan, Thanks a lot in Advance, We are trying to debug the Failed to communicate Thread Event . And we found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc In the Platform () constructor Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header-base, header-size, (const char*)header-name); is not getting executed(giving page fault) . Do you know what could be the problem ? Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the core_mem_alloc() allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault. But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault. Regards Stefan Regards Chirag Garg IIT Madras , Rise Lab -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ 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/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge
Re: Platform Initialization Problem
Hi Stefan, I am working along with Chirag to port Genode on imx6. We inserted the existing RAM regions in Platform::_ram_regions.( We rechecked it with linux kernel source code for imx6) But still we are getting page fault on every access to new Rom_module. I tried to track the memory allocation what I understood is, In map_local() call, when inserting into page tables in _insert_second_level() function in short_translation_table.h file of base-hw, slab-phys_addr() and slab-virt_addr() return 0 after kernel initialization. So it creates a new page table and inserting into it. Inserting the same values(phys:1000, virt:1000) as arguments of map_local() function in platform.cc. When I print the address of new page table created, I found that it is in the range of Program Image.(address of pt is 10159000, and program image range is (10001000-10189fa4). I wonder if the memory allotted is clashing with program memory. Or, Can it be the issue with MMDC controller of imx6? Because no other board in base-hw uses MMDC controller, do we need to implement the interface for MMDC in imx6? Thanks and Regards Praveen, IIT Madras On Tue, Jul 29, 2014 at 6:43 PM, Stefan Kalkowski stefan.kalkow...@genode-labs.com wrote: Hi, On 07/28/2014 11:28 AM, chirag garg wrote: Hi stefan, Thanks a lot in Advance, We are trying to debug the Failed to communicate Thread Event . And we found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc In the Platform () constructor Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header-base, header-size, (const char*)header-name); is not getting executed(giving page fault) . Do you know what could be the problem ? Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the core_mem_alloc() allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault. But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault. Regards Stefan Regards Chirag Garg IIT Madras , Rise Lab -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ 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/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
