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
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. 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?
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
Hi Praveen, Norman,
First of all, it's cool to see you sharing this code with us and I enjoyed reading it!
According to the i.MX6 manual, the uSDHC is a new implementation that is at least not fully compatible with the eSDHC. For example, there are new registers, new features (tuning), and common registers differ. I think it's a good idea to treat uSDHC and eSDHC separately for now and maybe later determine in which way they can share more code.
Regarding your commit, Praveen, there are two suggestions that came to my mind while having a first look at it:
* I saw that you've opened up a new sd_card.h in the uSDHC sub-directory of the driver. However, the concept of the existing generic sd_card.h is to provide SD-card functionality that is independent of the specific hardware implementation. Thus, if the code you've added in usdhc/sd_card.h is of such characteristic, I would suggest to provide it through the existing sd_card.h instead of adding a new header. If the existing implementations in sd_card.h are not sufficient to reuse them properly for the uSDHC, they should rather be adapted.
* For sources you've added around the driver like repos/ports-foc/run/linux_imx6.run repos/os/run/part_blk_sd.run repos/dde_rump/run/rump_ext2_sd.run I would create dedicated commits so the driver commit really concentrates on the driver and its dependencies. This way, one can add and test this feature without the need for fetching such sattelite code.
Beside that, the code looks clean and comprehensible to me :)
Best regards, Martin
On 20.03.2015 11:40, Norman Feske 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. 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?
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
Norman, I had talked about this earlier. We really need an i.MX6 reference platform. Both the Wandboard or the saberlite are good choices. I prefer the saberlite since it is the official FS ref design. I think a lot of us have variants of base_hw running on i.MX6. And F.OC and seL4 also support it.
We do have a ref. i.MX6 tablet (production quality) coming next month that will end up as an additional ref. platform for us since we can actually run a virtualized android on it. I think the vendor plans to sell for for 300 USD. It has HAB enabled so we can have a truly secure platform.
When it becomes stable and generally available, I would like to see it adopted as a ref. platform since it will be a usable android tablet running on genode (albeit with slightly poor battery life courtesy the i.MX6 !). I also want to convince the vendor to upgrade the display. But it is a nice aluminium chassis so does not look to shoddy.
On Fri, Mar 20, 2015 at 4:10 PM, Norman Feske <norman.feske@...1...> 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. 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?
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
Hi Norman
On Fri, Mar 20, 2015 at 4:10 PM, Norman Feske <norman.feske@...1...> 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
Hi Martin
Comments inline...
On Fri, Mar 20, 2015 at 8:42 PM, Martin Stein <martin.stein@...1...> wrote:
Hi Praveen, Norman,
First of all, it's cool to see you sharing this code with us and I enjoyed reading it!
Thank you
According to the i.MX6 manual, the uSDHC is a new implementation that is at least not fully compatible with the eSDHC. For example, there are new registers, new features (tuning), and common registers differ. I think it's a good idea to treat uSDHC and eSDHC separately for now and maybe later determine in which way they can share more code.
That's true.
Regarding your commit, Praveen, there are two suggestions that came to my mind while having a first look at it:
- I saw that you've opened up a new sd_card.h in the uSDHC sub-directory
of the driver. However, the concept of the existing generic sd_card.h is to provide SD-card functionality that is independent of the specific hardware implementation. Thus, if the code you've added in usdhc/sd_card.h is of such characteristic, I would suggest to provide it through the existing sd_card.h instead of adding a new header. If the existing implementations in sd_card.h are not sufficient to reuse them properly for the uSDHC, they should rather be adapted.
The reason we created another sd_card.h is, USDHC returns CSD register shifted by 8 bits. That could also have been handled in the read_csd() function of the controller instead of sd_card.h. We have made that change and added a new commit.
We have also added Set_blocklen() command to sd_card.h. We currently see that the change is present in the staging branch of Genode (for FS iMX53) and does not collide with any other sd_card driver implementation.
- For sources you've added around the driver like repos/ports-foc/run/linux_imx6.run repos/os/run/part_blk_sd.run repos/dde_rump/run/rump_ext2_sd.run
I would create dedicated commits so the driver commit really concentrates on the driver and its dependencies. This way, one can add and test this feature without the need for fetching such sattelite code.
Thanks for the suggestions. I've created two different commits, please take a look and let us know if they look fine.
Regards
Praveen Srinivas IIT Madras
Beside that, the code looks clean and comprehensible to me :)
Best regards, Martin
On 20.03.2015 11:40, Norman Feske 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. 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?
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
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
Hi Praveen,
Thank you for taking the time to implement the suggestions :)
On 24.03.2015 08:33, Praveen B wrote:
The reason we created another sd_card.h is, USDHC returns CSD register shifted by 8 bits. That could also have been handled in the read_csd() function of the controller instead of sd_card.h. We have made that change and added a new commit.
We've had a similar problem at the eSDHC of the i.MX53 and found that it didn't apply only to the CSD but to 136-bit responses in general. Thus we went a step further and implemented the decoding directly in the declaration of the response registers. If you're interested, you can find this approach on our staging branch [1] in the eSDHC driver [2] (Cmdrsp0..3 provide the raw response data while Rsp136_0..3 combine them in a way that decoding is done automatically by the register framework).
We have also added Set_blocklen() command to sd_card.h. We currently see that the change is present in the staging branch of Genode (for FS iMX53) and does not collide with any other sd_card driver implementation.
It's cool to see the similarities: We had to implement the Set_blocklen command too for the eSDHC. It is now provided the same way as in your commit on our staging branch [1] and thus wouldn't have to be added for the uSDHC any more.
* For sources you've added around the driver like repos/ports-foc/run/linux_imx6.run repos/os/run/part_blk_sd.run repos/dde_rump/run/rump_ext2_sd.run I would create dedicated commits so the driver commit really concentrates on the driver and its dependencies. This way, one can add and test this feature without the need for fetching such sattelite code.Thanks for the suggestions. I've created two different commits, please take a look and let us know if they look fine.
Despite some minor style fixes, the commit looks fine to me. However, when contributing to our public branch, two rather bureaucratic issues regarding the file and commit headers will come up:
* First, as the contributors agreement behind the code refers to the IIT Madras, it would be good for us to have an according connection in the commit messages. Hence, most appreciated would be if you use an IIT-Madras mail address for authoring instead of the current Gmail address. Alternatively, an additional line in the commit messages like "Contributed by the Department of Computer Sience & Engg., IIT Madras." would be fine too.
* Second, the date in the copyright headers of the new files should be changed to 2015. I hope this is OK for you.
Last but not least, as I tried to re-base your code I stumbled over a problem not related to the uSDHC but the i.MX6 support it relies on. The according patch is distributed over several commits with unrelated commits in between. This complicates handling of the patch in general. The commits should be combined into a single one before being contributed. If you agree, I would do this as I aim to merge our local CuBox-i and WandBoard support with your i.MX6 support anyway.
Best regards, Martin
[1] https://github.com/genodelabs/genode/tree/staging [2] os/src/drivers/sd_card/imx53/esdhcv2.h
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. * 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. * 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. * I've merged some redundant code between i.MX6 and i.MX53 into ``spec/imx`` * 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: 0x02020000, 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.
Cheers, Martin
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.stein@...1...> 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:
0x02020000, 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
Hi Praveen,
On 26.03.2015 18:30, Praveen B wrote:
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.
Good that you've re-based and merged your work. This way, it shouldn't be a big deal to bring in our Wandboard port as base.
By the way, is SMP enabled for CortexA9 processors in the latest base-hw version?
No, there is a local topic branch in my repository that enables Cortex-A9 SMP but it causes problems with another board and thus isn't merged yet. However, if you like to try SMP, I can re-base it for you.
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.
Thats because 'is_smp' doesn't reflect wether SMP extensions are used by Genode (this is what 'NR_OF_CPUS' is for) but merely wether they're provided by the board. The return value of 'is_smp' is needed to decide on the sharebility and cacheability of translation tables which, if not set on SMP boards, causes new translations to not appear before an appropriate cache flush. That's why you receive a page fault. On platforms without SMP extensions, the flush is achieved through the hook 'Cpu::translation_added'.
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 think, as we'll need to split up 'drivers/board_base.h' for Wandboard and your board anyway, the best solution would be to define
UART_1_IRQ = 59, UART_1_MMIO_BASE = 0x021e8000,
in 'platform_your_board/drivers/board_base.h' and
UART_1_IRQ = 58, UART_1_MMIO_BASE = 0x02020000,
in 'platform_wand_quad/drivers/board_base.h'. This way we can keep the generic serial header.
We will try to run the code on our board as soon as possible and let you know, If there are any issues.
Cool. I'm curious about your observations.
Cheers, Martin
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 <srinivasprv@...9...> 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.stein@...1...> 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:
0x02020000, 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
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 <srinivasprv@...9...> 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 <srinivasprv@...9...> 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.stein@...1...> 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:
0x02020000, 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
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) <madhu@...275...> 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 <srinivasprv@...9...> 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 <srinivasprv@...9...> 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.stein@...1...> 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:
0x02020000, 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
-- Regards, Madhu
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
Hi Madhu, Praveen,
On 27.03.2015 13:24, Praveen B wrote:>
We have tested the ported code on SABRE Lite board and it is working, except that we need to change UART1 to UART2(0x021e8000). ... Apart from these typical configuration changes, we have verified that the image generated from this branch is working successfully on Sabrelite board.
Cool, thank you for the quick feedback :) I'm glad that the port does that well.
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.
If using UART1 is an issue for you, I would check the clock and power management first. The HW kernel as it is, in contrast to Linux, doesn't do any initialization regarding these aspects.
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?
On 28.03.2015 05:23, Madhu (Macaque Labs) wrote:
What are are asking for (default UART, RAM size) are board specific features. can't these be added to files for board specific configuration ?
On 28.03.2015 16:27, Praveen B wrote:>
We will follow Martin's suggestion of using a different board_base.h file for our board.
I think that would be the most desirable option. The generic parts of both 'Board_base' classes should go to an additional header [1] as it is also done for example by 'usb_armory' and 'imx53_qsb' (see [2]).
Cheers, Martin
[1] 'base/include/platform/imx6/drivers/board_base_support.h' [2] 'base/include/platform/imx53/drivers/board_base_support.h'
-
Madhu (Macaque Labs) -
Martin Stein -
Norman Feske -
Praveen B