Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6 branch by Nikolay Golikov stating that he had a preliminary port of i.MX6 here: https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print "-1 = -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000. It loads the kernel (267.9 kB) but stops at "Loading kernel".
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions on how to proceed? Because we are literally stuck.
Also, is there a good debugging tool for testing the genode environment on direct hardware?
Thanks in advance Aditya Kousik
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6 branch by Nikolay Golikov stating that he had a preliminary port of i.MX6 here: https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print "-1 = -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000. It loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and ends at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't have such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions aren't correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions on how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In Nikolay's branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode environment on direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode, like GDB, but that wouldn't help on that low level you're currently working at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function as you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core. The definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of action? we can't load the kernel by running 'bootm' since you say it uses a different config. So what do we do with the uImage?
1. I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It succesfully loaded the kernel to that address. At this point, I had changed the load address to 10002000 to check if the image was read properly. It did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
What is the sequence of events, the programs that are sequentially executed to say that the kernel is 'running'?
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6
branch
by Nikolay Golikov stating that he had a preliminary port of i.MX6 here: https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print
"-1
= -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000. It loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and ends at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't have such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions aren't correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions
on
how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In Nikolay's branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode environment
on
direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode, like GDB, but that wouldn't help on that low level you're currently working at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
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/
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function as you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core. The definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of action? we can't load the kernel by running 'bootm' since you say it uses a different config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be loaded at start address 0x10001000. This ELF image is used by u-boot's mkimage utility to form a uImage file. This uImage can be loaded to some address above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had changed the load address to 10002000 to check if the image was read properly. It did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into the ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated memory sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially executed to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to you, to analyze the memory layout of the u-boot binary used on your platform, e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6
branch
by Nikolay Golikov stating that he had a preliminary port of i.MX6 here: https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print
"-1
= -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000. It loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and ends at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't have such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions aren't correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions
on
how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In Nikolay's branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode environment
on
direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode, like GDB, but that wouldn't help on that low level you're currently working at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
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/
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept using bootm till then. I wasn't exactly able to check where u-boot loaded its own memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
While it's still stuck at 'Starting kernel...' , I'll take your previous advice seriously. To use a JTAG debugger or recheck the UART definitions.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function as you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core. The definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of action?
we
can't load the kernel by running 'bootm' since you say it uses a
different
config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be loaded at start address 0x10001000. This ELF image is used by u-boot's mkimage utility to form a uImage file. This uImage can be loaded to some address above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had
changed
the load address to 10002000 to check if the image was read properly. It did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into the ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated memory sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially
executed
to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to you, to analyze the memory layout of the u-boot binary used on your platform, e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6
branch
by Nikolay Golikov stating that he had a preliminary port of i.MX6
here:
https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print
"-1
= -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000.
It
loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and ends at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't have such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions aren't correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions
on
how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In Nikolay's branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode environment
on
direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode, like GDB, but that wouldn't help on that low level you're currently working
at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
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/
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Aditya,
On 01/09/2014 08:30 AM, Aditya Kousik wrote:
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept using bootm till then. I wasn't exactly able to check where u-boot loaded its own memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
I recommend using a self-compiled u-boot on you imx6 board. Therefore, you'll be able to check its memory regions.
While it's still stuck at 'Starting kernel...' , I'll take your previous advice seriously. To use a JTAG debugger or recheck the UART definitions.
Moreover, you might skip the UART initialization routine. Just comment the body of the Imx31_uart_base constructor out in:
base/include/drivers/uart/imx31_uart_base.h
The UART should be initialized by u-boot anyway.
Of course, if you've a JTAG debugger present, and a corresponding connector on your test board, this probably will be the most comfortable path.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Yes that's right.
Regards Stefan
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function as you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core. The definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of action?
we
can't load the kernel by running 'bootm' since you say it uses a
different
config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be loaded at start address 0x10001000. This ELF image is used by u-boot's mkimage utility to form a uImage file. This uImage can be loaded to some address above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had
changed
the load address to 10002000 to check if the image was read properly. It did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into the ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated memory sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially
executed
to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to you, to analyze the memory layout of the u-boot binary used on your platform, e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6
branch
by Nikolay Golikov stating that he had a preliminary port of i.MX6
here:
https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does print
"-1
= -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000.
It
loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and ends at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't have such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking the right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions aren't correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any suggestions
on
how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In Nikolay's branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode environment
on
direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode, like GDB, but that wouldn't help on that low level you're currently working
at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
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/
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Stefan,
I'm working with Aditya on the port. We're now trying to blink an LED at the start of execution of the kernel (at the place where you asked us to print a PDBG), since the JTAG is going to take a while. We've tried using i.MX53's GPIO driver by modifying the register addresses in board_base.h.
Basically, we need to write to the GPIO9 (GPIO1_IO09 in i.MX6) : Can this be accomplished by calling the read/write/direction functions in driver.h of os/src/driver/gpio. Or can we simply write to a register by implementing util/mmio.h?
Thanks and regards Meenakshi
On Thu, Jan 9, 2014 at 3:14 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/09/2014 08:30 AM, Aditya Kousik wrote:
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept using bootm till then. I wasn't exactly able to check where u-boot loaded its
own
memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
I recommend using a self-compiled u-boot on you imx6 board. Therefore, you'll be able to check its memory regions.
While it's still stuck at 'Starting kernel...' , I'll take your previous advice seriously. To use a JTAG debugger or recheck the UART definitions.
Moreover, you might skip the UART initialization routine. Just comment the body of the Imx31_uart_base constructor out in:
base/include/drivers/uart/imx31_uart_base.h
The UART should be initialized by u-boot anyway.
Of course, if you've a JTAG debugger present, and a corresponding connector on your test board, this probably will be the most comfortable path.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Yes that's right.
Regards Stefan
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function
as
you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core.
The
definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of
action?
we
can't load the kernel by running 'bootm' since you say it uses a
different
config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be loaded at start address 0x10001000. This ELF image is used by u-boot's mkimage utility to form a uImage file. This uImage can be loaded to some address above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had
changed
the load address to 10002000 to check if the image was read properly.
It
did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into the ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated memory sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially
executed
to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to you, to analyze the memory layout of the u-boot binary used on your platform, e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote:
Hello all,
We've tried to run a basic test-printf script on a Freescale i.MX6 sabrelite board. Based on thishttp://sourceforge.net/p/genode/mailman/message/31760885/, we implemented the necessary files. We had also come across an i.MX6
branch
by Nikolay Golikov stating that he had a preliminary port of i.MX6
here:
https://github.com/decaprox/genode/tree/i.mx6
We ran RUN_OPT="--target=uboot" make run/printf to see if it does
"-1
= -1 = -1" to the serial console (tested with gtkterm).
We ran the boot image uImage through TFTP at load address 0x10800000.
It
loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and
ends
at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't
have
such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
How do we know if the kernel is indeed running, or are we checking
the
right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions
aren't
correct.
I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any
suggestions
on
how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In
Nikolay's
branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
Also, is there a good debugging tool for testing the genode
environment
on
direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode,
like
GDB, but that wouldn't help on that low level you're currently working
at.
Regards Stefan
Thanks in advance Aditya Kousik
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
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/
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Meenakshi,
On 01/18/2014 09:16 AM, Meenakshi Narayanan wrote:
Hi Stefan,
I'm working with Aditya on the port. We're now trying to blink an LED at the start of execution of the kernel (at the place where you asked us to print a PDBG), since the JTAG is going to take a while. We've tried using i.MX53's GPIO driver by modifying the register addresses in board_base.h.
well, I don't think this is the way to success.
Because you didn't finished to get some output from the UART, possibly because your kernel image isn't setup correctly, you're now trying to rope the far more complex GPIO driver code into the kernel? As long as things are working similar like within the i.MX53 SoC, moreover the GPIO pins depend on a correctly configured IOMUX controller, which is a ball of wires. Just to give you some complexity metric between both in form of reference manual pages, the IOMUX controller comprises 800 pages, and the UART about 80. To sum it up, setting up GPIO pins correctly is a far more error-prone task than setting up the UART on this platform.
What about my advices within the last mail, compiling your own u-boot, thereby having the ability to better check the setup of your kernel (e.g. via additional prints), and not initializing the UART within the kernel, because it's already done successfully by u-boot?
Moreover, you might start with a very easy binary (no complete Genode kernel/image), which you write from scratch. That binary can be some very simple assembler code, which only puts some character to the UART, and nothing more. If that fails too, it's probably a boot issue, which I would guess it is.
Basically, we need to write to the GPIO9 (GPIO1_IO09 in i.MX6) : Can this be accomplished by calling the read/write/direction functions in driver.h of os/src/driver/gpio. Or can we simply write to a register by implementing util/mmio.h?
Of course, you can use the classes in "util/mmio.h" to simply access I/O memory mapped registers. In fact, the MMIO framework is designed for that operation purpose. The code in "os/src/driver/gpio" is used for the user-level GPIO driver in Genode, and cannot be used directly within the base-hw kernel.
Regards Stefan
Thanks and regards Meenakshi
On Thu, Jan 9, 2014 at 3:14 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/09/2014 08:30 AM, Aditya Kousik wrote:
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept using bootm till then. I wasn't exactly able to check where u-boot loaded its
own
memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
I recommend using a self-compiled u-boot on you imx6 board. Therefore, you'll be able to check its memory regions.
While it's still stuck at 'Starting kernel...' , I'll take your previous advice seriously. To use a JTAG debugger or recheck the UART definitions.
Moreover, you might skip the UART initialization routine. Just comment the body of the Imx31_uart_base constructor out in:
base/include/drivers/uart/imx31_uart_base.h
The UART should be initialized by u-boot anyway.
Of course, if you've a JTAG debugger present, and a corresponding connector on your test board, this probably will be the most comfortable path.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Yes that's right.
Regards Stefan
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function
as
you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and also base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core.
The
definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of
action?
we
can't load the kernel by running 'bootm' since you say it uses a
different
config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be loaded at start address 0x10001000. This ELF image is used by u-boot's mkimage utility to form a uImage file. This uImage can be loaded to some address above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had
changed
the load address to 10002000 to check if the image was read properly.
It
did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into the ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated memory sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially
executed
to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to you, to analyze the memory layout of the u-boot binary used on your platform, e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 01/02/2014 08:52 AM, Aditya Kousik wrote: > Hello all, > > We've tried to run a basic test-printf script on a Freescale i.MX6 > sabrelite board. Based on > thishttp://sourceforge.net/p/genode/mailman/message/31760885/, > we implemented the necessary files. We had also come across an i.MX6 branch > by Nikolay Golikov stating that he had a preliminary port of i.MX6
here:
> https://github.com/decaprox/genode/tree/i.mx6 > > We ran RUN_OPT="--target=uboot" make run/printf to see if it does
"-1 > = -1 = -1" to the serial console (tested with gtkterm). > > We ran the boot image uImage through TFTP at load address 0x10800000.
It
> loads the kernel (267.9 kB) but stops at "Loading kernel".
Assuming, your resulting kernel image is linked to 0x10001000, and
ends
at about 0x102cbc55, like the result I got when compiling Nikolay's branch, your load address for the u-boot uImage sounds reasonable. Unfortunately, I can't reproduce your experiments, because I don't
have
such a board available. The first thing that comes to my mind is, that Nikolay used another board containing the i.MX6 SoC than you with another memory layout of the related peripherals.
> > How do we know if the kernel is indeed running, or are we checking
the
> right UART ports? (we checked UART1)
First at all, you should add a printf command like:
PDBG("kernel started!")"
at the very beginning of the kernel's execution. In Nikolay's branch I would add it here:
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
If that message isn't printed, very likely your UART definitions
aren't
correct.
> > I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any
suggestions
on > how to proceed? Because we are literally stuck.
Forget about "bootargs" in u-boot. They are specific to booting the Linux kernel. U-boot puts them into the Linux/ARM specific ATAG structure. In Genode that structure isn't used. It's hard coded in the kernel, which UART is used for kernel/core debug messages. In
Nikolay's
branch, he uses the UART with memory mapped I/O located at 0x02020000, and with the following UART definition:
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
Please check whether this corresponds with your board's definitions.
> > Also, is there a good debugging tool for testing the genode
environment
on > direct hardware?
Well, there is JTAG of course, which isn't related to Genode specifically. There are other debugging utils available on Genode,
like
GDB, but that wouldn't help on that low level you're currently working
at.
Regards Stefan
> > Thanks in advance > Aditya Kousik > > > >
> Rapidly troubleshoot problems before they affect your business. Most
IT
> organizations don't have a clear picture of how application
performance
> affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
> > > > _______________________________________________ > Genode-main mailing list > Genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
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/
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello all,
Genode base-hw kernel runs successfully on i.MX6. Stefan: we were looking at the wrong UART port (1 instead of 2) which led us on a wild goose chase. And we set the GPIO pins directly by setting IOMUX to GPIO mode: we lit a LED bulb successfully. The driver, as you mentioned is quite complex.
We're getting the following message for test-printf ::
Starting kernel ...
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1020 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> test-printf] -1 = -1 = -1 [init] virtual void Genode::Child_policy::exit(int): child exited with exit value 0
We ran nested_init to verify again and got the following::
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1021 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init] parent provides [init] service "ROM" [init] service "RAM" [init] service "CAP" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] service "SIGNAL" [init] child "init" [init] RAM quota: 10223616 [init] ELF binary: init [init] priority: 0 [init -> init] Could not open file "ld.lib.so" [init -> init] parent provides [init -> init] service "ROM" [init -> init] service "RAM" [init -> init] service "CAP" [init -> init] service "PD" [init -> init] service "RM" [init -> init] service "CPU" [init -> init] service "LOG" [init -> init] service "SIGNAL" [init -> init] child "init" [init -> init] RAM quota: 4980736 [init -> init] ELF binary: init [init -> init] priority: 0 [init -> init -> init] Could not open file "ld.lib.so" [init -> init -> init] parent provides [init -> init -> init] service "ROM" [init -> init -> init] service "RAM" [init -> init -> init] service "CAP" [init -> init -> init] service "PD" [init -> init -> init] service "RM" [init -> init -> init] service "CPU" [init -> init -> init] service "LOG" [init -> init -> init] service "SIGNAL" [init -> init -> init] No children to start
One, Are these satisfactory messages? (Are the test scripts running as they should) Two, Why does test-printf not work when I try to print Genode::printf("Hello World!"); and consequently set run_genode_until "Hello World!" 10 (or {Hello World!} 10). [init -> test-printf] does not get initialized.
Regards Aditya.
On Mon, Jan 20, 2014 at 8:35 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Meenakshi,
On 01/18/2014 09:16 AM, Meenakshi Narayanan wrote:
Hi Stefan,
I'm working with Aditya on the port. We're now trying to blink an LED at the start of execution of the kernel (at the place where you asked us to print a PDBG), since the JTAG is going to take a while. We've tried using i.MX53's GPIO driver by modifying the register addresses in board_base.h.
well, I don't think this is the way to success.
Because you didn't finished to get some output from the UART, possibly because your kernel image isn't setup correctly, you're now trying to rope the far more complex GPIO driver code into the kernel? As long as things are working similar like within the i.MX53 SoC, moreover the GPIO pins depend on a correctly configured IOMUX controller, which is a ball of wires. Just to give you some complexity metric between both in form of reference manual pages, the IOMUX controller comprises 800 pages, and the UART about 80. To sum it up, setting up GPIO pins correctly is a far more error-prone task than setting up the UART on this platform.
What about my advices within the last mail, compiling your own u-boot, thereby having the ability to better check the setup of your kernel (e.g. via additional prints), and not initializing the UART within the kernel, because it's already done successfully by u-boot?
Moreover, you might start with a very easy binary (no complete Genode kernel/image), which you write from scratch. That binary can be some very simple assembler code, which only puts some character to the UART, and nothing more. If that fails too, it's probably a boot issue, which I would guess it is.
Basically, we need to write to the GPIO9 (GPIO1_IO09 in i.MX6) : Can this be accomplished by calling the read/write/direction functions in driver.h of os/src/driver/gpio. Or can we simply write to a register by
implementing
util/mmio.h?
Of course, you can use the classes in "util/mmio.h" to simply access I/O memory mapped registers. In fact, the MMIO framework is designed for that operation purpose. The code in "os/src/driver/gpio" is used for the user-level GPIO driver in Genode, and cannot be used directly within the base-hw kernel.
Regards Stefan
Thanks and regards Meenakshi
On Thu, Jan 9, 2014 at 3:14 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/09/2014 08:30 AM, Aditya Kousik wrote:
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept
using
bootm till then. I wasn't exactly able to check where u-boot loaded its
own
memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
I recommend using a self-compiled u-boot on you imx6 board. Therefore, you'll be able to check its memory regions.
While it's still stuck at 'Starting kernel...' , I'll take your
previous
advice seriously. To use a JTAG debugger or recheck the UART
definitions.
Moreover, you might skip the UART initialization routine. Just comment the body of the Imx31_uart_base constructor out in:
base/include/drivers/uart/imx31_uart_base.h
The UART should be initialized by u-boot anyway.
Of course, if you've a JTAG debugger present, and a corresponding connector on your test board, this probably will be the most comfortable path.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Yes that's right.
Regards Stefan
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote:
Hello Stefan,
I added the print debug call inside extern "C" void kernel() function
as
you'd suggested. Still no response from the processor.
I checked the address specifications in both Imx31_uart_base.h and
also
base/include/platform/imx6/board_base.h in Nikolay's branch. They are correct, to the dot. Even AIPS mapping in board.h in base-hw's core.
The
definitions seem to be fine.
Ideally, what is expected to happen, i.e, the expected course of
action?
we
can't load the kernel by running 'bootm' since you say it uses a
different
config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be
loaded
at start address 0x10001000. This ELF image is used by u-boot's
mkimage
utility to form a uImage file. This uImage can be loaded to some
address
above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret the uImage header at that address, load the ELF image within the uImage to the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
- I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'. It
succesfully loaded the kernel to that address. At this point, I had
changed
the load address to 10002000 to check if the image was read properly.
It
did. 2. As a different approach, ran 'go 10002000'. This was what I got "##Application started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into
the
ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated
memory
sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel gets executed with the MMU enabled using u-boot's page-table setup etc.
What is the sequence of events, the programs that are sequentially
executed
to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections (binary data, exception vector) clashes with the scenario ones. Unfortunately, mostly u-boot doesn't warn you if it fails to load the whole image due to memory clashes. Therefore, it would be good, if it's possible to
you,
to analyze the memory layout of the u-boot binary used on your
platform,
e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
Thanks in advance Aditya Kousik
On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
> Hi, > > On 01/02/2014 08:52 AM, Aditya Kousik wrote: >> Hello all, >> >> We've tried to run a basic test-printf script on a Freescale i.MX6 >> sabrelite board. Based on >> thishttp://sourceforge.net/p/genode/mailman/message/31760885/, >> we implemented the necessary files. We had also come across an
i.MX6
> branch >> by Nikolay Golikov stating that he had a preliminary port of i.MX6
here:
>> https://github.com/decaprox/genode/tree/i.mx6 >> >> We ran RUN_OPT="--target=uboot" make run/printf to see if it does
> "-1 >> = -1 = -1" to the serial console (tested with gtkterm). >> >> We ran the boot image uImage through TFTP at load address
0x10800000.
It
>> loads the kernel (267.9 kB) but stops at "Loading kernel". > > Assuming, your resulting kernel image is linked to 0x10001000, and
ends
> at about 0x102cbc55, like the result I got when compiling Nikolay's > branch, your load address for the u-boot uImage sounds reasonable. > Unfortunately, I can't reproduce your experiments, because I don't
have
> such a board available. The first thing that comes to my mind is,
that
> Nikolay used another board containing the i.MX6 SoC than you with > another memory layout of the related peripherals. > >> >> How do we know if the kernel is indeed running, or are we checking
the
>> right UART ports? (we checked UART1) > > First at all, you should add a printf command like: > > PDBG("kernel started!")" > > at the very beginning of the kernel's execution. In Nikolay's
branch I
> would add it here: > > > >
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
> > If that message isn't printed, very likely your UART definitions
aren't
> correct. > >> >> I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any
suggestions
> on >> how to proceed? Because we are literally stuck. > > Forget about "bootargs" in u-boot. They are specific to booting the > Linux kernel. U-boot puts them into the Linux/ARM specific ATAG > structure. In Genode that structure isn't used. It's hard coded in
the
> kernel, which UART is used for kernel/core debug messages. In
Nikolay's
> branch, he uses the UART with memory mapped I/O located at
0x02020000,
> and with the following UART definition: > > > >
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
> > Please check whether this corresponds with your board's definitions. > >> >> Also, is there a good debugging tool for testing the genode
environment
> on >> direct hardware? > > Well, there is JTAG of course, which isn't related to Genode > specifically. There are other debugging utils available on Genode,
like
> GDB, but that wouldn't help on that low level you're currently
working
at.
> > Regards > Stefan > >> >> Thanks in advance >> Aditya Kousik >> >> >> >> >
>> Rapidly troubleshoot problems before they affect your business.
Most
IT
>> organizations don't have a clear picture of how application
performance
>> affects their revenue. With AppDynamics, you get 100% visibility
into
> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! >> >
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
>> >> >> >> _______________________________________________ >> 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/ > > >
> Rapidly troubleshoot problems before they affect your business. Most
IT
> organizations don't have a clear picture of how application
performance
> affects their revenue. With AppDynamics, you get 100% visibility
into
your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
> Pro! >
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
> _______________________________________________ > Genode-main mailing list > Genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
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/
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
The structure of Genode::printf is quite interesting. Running the test-printf scenario with PDBG("Hello World") works fine. It simply prints 'int main(int, char**): Hello World!'
Looking up the definition for the Genode printf in base/printf.h was not so revealing. What makes the "-1 = -1 = -1" regex special that init refuses to spawn the init->test-printf child process?
Regards Meenakshi
On Wed, Jan 29, 2014 at 11:06 AM, Aditya Kousik <adit267.kousik@...9...>wrote:
Hello all,
Genode base-hw kernel runs successfully on i.MX6. Stefan: we were looking at the wrong UART port (1 instead of 2) which led us on a wild goose chase. And we set the GPIO pins directly by setting IOMUX to GPIO mode: we lit a LED bulb successfully. The driver, as you mentioned is quite complex.
We're getting the following message for test-printf ::
Starting kernel ...
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1020 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> test-printf] -1 = -1 = -1 [init] virtual void Genode::Child_policy::exit(int): child exited with exit value 0
We ran nested_init to verify again and got the following::
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1021 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init] parent provides [init] service "ROM" [init] service "RAM" [init] service "CAP" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] service "SIGNAL" [init] child "init" [init] RAM quota: 10223616 [init] ELF binary: init [init] priority: 0 [init -> init] Could not open file "ld.lib.so" [init -> init] parent provides [init -> init] service "ROM" [init -> init] service "RAM" [init -> init] service "CAP" [init -> init] service "PD" [init -> init] service "RM" [init -> init] service "CPU" [init -> init] service "LOG" [init -> init] service "SIGNAL" [init -> init] child "init" [init -> init] RAM quota: 4980736 [init -> init] ELF binary: init [init -> init] priority: 0 [init -> init -> init] Could not open file "ld.lib.so" [init -> init -> init] parent provides [init -> init -> init] service "ROM" [init -> init -> init] service "RAM" [init -> init -> init] service "CAP" [init -> init -> init] service "PD" [init -> init -> init] service "RM" [init -> init -> init] service "CPU" [init -> init -> init] service "LOG" [init -> init -> init] service "SIGNAL" [init -> init -> init] No children to start
One, Are these satisfactory messages? (Are the test scripts running as they should) Two, Why does test-printf not work when I try to print Genode::printf("Hello World!"); and consequently set run_genode_until "Hello World!" 10 (or {Hello World!} 10). [init -> test-printf] does not get initialized.
Regards Aditya.
On Mon, Jan 20, 2014 at 8:35 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Meenakshi,
On 01/18/2014 09:16 AM, Meenakshi Narayanan wrote:
Hi Stefan,
I'm working with Aditya on the port. We're now trying to blink an LED at the start of execution of the kernel (at the place where you asked us to print a PDBG), since the JTAG is going to take a while. We've tried
using
i.MX53's GPIO driver by modifying the register addresses in
board_base.h.
well, I don't think this is the way to success.
Because you didn't finished to get some output from the UART, possibly because your kernel image isn't setup correctly, you're now trying to rope the far more complex GPIO driver code into the kernel? As long as things are working similar like within the i.MX53 SoC, moreover the GPIO pins depend on a correctly configured IOMUX controller, which is a ball of wires. Just to give you some complexity metric between both in form of reference manual pages, the IOMUX controller comprises 800 pages, and the UART about 80. To sum it up, setting up GPIO pins correctly is a far more error-prone task than setting up the UART on this platform.
What about my advices within the last mail, compiling your own u-boot, thereby having the ability to better check the setup of your kernel (e.g. via additional prints), and not initializing the UART within the kernel, because it's already done successfully by u-boot?
Moreover, you might start with a very easy binary (no complete Genode kernel/image), which you write from scratch. That binary can be some very simple assembler code, which only puts some character to the UART, and nothing more. If that fails too, it's probably a boot issue, which I would guess it is.
Basically, we need to write to the GPIO9 (GPIO1_IO09 in i.MX6) : Can
this
be accomplished by calling the read/write/direction functions in
driver.h
of os/src/driver/gpio. Or can we simply write to a register by
implementing
util/mmio.h?
Of course, you can use the classes in "util/mmio.h" to simply access I/O memory mapped registers. In fact, the MMIO framework is designed for that operation purpose. The code in "os/src/driver/gpio" is used for the user-level GPIO driver in Genode, and cannot be used directly within the base-hw kernel.
Regards Stefan
Thanks and regards Meenakshi
On Thu, Jan 9, 2014 at 3:14 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/09/2014 08:30 AM, Aditya Kousik wrote:
Hello Stefan,
I was looking for alternate methods of running the program loaded at address 10001000. That was the only motive behind trying go. I kept
using
bootm till then. I wasn't exactly able to check where u-boot loaded
its
own
memory sections. So instead, I set the load address for the kernel way above at 20000000 where I'm sure nothing else clashed. And loaded the uImage to 20800000.
I recommend using a self-compiled u-boot on you imx6 board. Therefore, you'll be able to check its memory regions.
While it's still stuck at 'Starting kernel...' , I'll take your
previous
advice seriously. To use a JTAG debugger or recheck the UART
definitions.
Moreover, you might skip the UART initialization routine. Just comment the body of the Imx31_uart_base constructor out in:
base/include/drivers/uart/imx31_uart_base.h
The UART should be initialized by u-boot anyway.
Of course, if you've a JTAG debugger present, and a corresponding connector on your test board, this probably will be the most
comfortable
path.
I ran test-printf on linux and this is what I got:
spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" Quota exceeded! amount=4096, size=4096, consumed=4096 [init] upgrading quota donation for SIGNAL session [init -> test-printf] -1 = -1 = -1 Test succeeded
Am I supposed to get similar messages from core on my board?
Yes that's right.
Regards Stefan
Thanks in advance Aditya
On Mon, Jan 6, 2014 at 3:28 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Aditya,
On 01/06/2014 09:18 AM, Aditya Kousik wrote: > Hello Stefan, > > I added the print debug call inside extern "C" void kernel()
function
as
> you'd suggested. Still no response from the processor. > > I checked the address specifications in both Imx31_uart_base.h and
also
> base/include/platform/imx6/board_base.h in Nikolay's branch. They
are
> correct, to the dot. Even AIPS mapping in board.h in base-hw's core.
The
> definitions seem to be fine. > > Ideally, what is expected to happen, i.e, the expected course of
action?
we > can't load the kernel by running 'bootm' since you say it uses a different > config. So what do we do with the uImage?
Well, I can't follow your conclusions to not using bootm? You've a complete scenario packed into an ELF image, which is built to be
loaded
at start address 0x10001000. This ELF image is used by u-boot's
mkimage
utility to form a uImage file. This uImage can be loaded to some
address
above 0x10300000 e.g. via TFTP like you did it. Assuming you've loaded the uImage to 0x10800000, you should boot the scenario with "bootm 0x10800000". After that u-boot will interpret
the
uImage header at that address, load the ELF image within the uImage
to
the appropriated memory sections, prepare the machine registers, and finally jump to 0x10001000.
> > 1. I loaded the uImage to 0x10800000 with TFTP as 'tftp 10800000'.
It
> succesfully loaded the kernel to that address. At this point, I had changed > the load address to 10002000 to check if the image was read
properly.
It
> did. > 2. As a different approach, ran 'go 10002000'. This was what I got > "##Application > started at 0x10002000, Application terminated, rc = 0x100A4004"
Using the 'go XXX' command let u-boot simply load that address into
the
ip register. As you've loaded an uImage to the related address, the machine executes the u-boot image header information, which of course fails. Even if you load the ELF image by hand to the appropriated
memory
sections, it is not recommended to use the 'go' command, as u-boot doesn't prepare the machine as expected. For instance, the kernel
gets
executed with the MMU enabled using u-boot's page-table setup etc.
> > What is the sequence of events, the programs that are sequentially executed > to say that the kernel is 'running'?
In your case I assume:
tftp 0x10800000 <network path to uImage> bootm 0x10800000
One further problem might be that u-boot's own memory sections
(binary
data, exception vector) clashes with the scenario ones.
Unfortunately,
mostly u-boot doesn't warn you if it fails to load the whole image
due
to memory clashes. Therefore, it would be good, if it's possible to
you,
to analyze the memory layout of the u-boot binary used on your
platform,
e.g.: "readelf -S <u-boot binary>"
If there's a clash you can change the "LD_TEXT_ADDR" variable in "base-hw/mk/spec-hw_imx6.mk" to another non-clashing address.
Regards Stefan
> > Thanks in advance > Aditya Kousik > > > On Thu, Jan 2, 2014 at 4:33 PM, Stefan Kalkowski < > stefan.kalkowski@...1...> wrote: > >> Hi, >> >> On 01/02/2014 08:52 AM, Aditya Kousik wrote: >>> Hello all, >>> >>> We've tried to run a basic test-printf script on a Freescale i.MX6 >>> sabrelite board. Based on >>> thishttp://sourceforge.net/p/genode/mailman/message/31760885/, >>> we implemented the necessary files. We had also come across an
i.MX6
>> branch >>> by Nikolay Golikov stating that he had a preliminary port of i.MX6 here: >>> https://github.com/decaprox/genode/tree/i.mx6 >>> >>> We ran RUN_OPT="--target=uboot" make run/printf to see if it does
>> "-1 >>> = -1 = -1" to the serial console (tested with gtkterm). >>> >>> We ran the boot image uImage through TFTP at load address
0x10800000.
It >>> loads the kernel (267.9 kB) but stops at "Loading kernel". >> >> Assuming, your resulting kernel image is linked to 0x10001000, and
ends
>> at about 0x102cbc55, like the result I got when compiling Nikolay's >> branch, your load address for the u-boot uImage sounds reasonable. >> Unfortunately, I can't reproduce your experiments, because I don't
have
>> such a board available. The first thing that comes to my mind is,
that
>> Nikolay used another board containing the i.MX6 SoC than you with >> another memory layout of the related peripherals. >> >>> >>> How do we know if the kernel is indeed running, or are we checking
the
>>> right UART ports? (we checked UART1) >> >> First at all, you should add a printf command like: >> >> PDBG("kernel started!")" >> >> at the very beginning of the kernel's execution. In Nikolay's
branch I
>> would add it here: >> >> >> >>
https://github.com/decaprox/genode/blob/i.mx6/base-hw/src/core/kernel.cc#L13...
>> >> If that message isn't printed, very likely your UART definitions
aren't
>> correct. >> >>> >>> I gave "console=ttymxc0, 115200" as bootargs in u-boot. Any
suggestions
>> on >>> how to proceed? Because we are literally stuck. >> >> Forget about "bootargs" in u-boot. They are specific to booting the >> Linux kernel. U-boot puts them into the Linux/ARM specific ATAG >> structure. In Genode that structure isn't used. It's hard coded in
the
>> kernel, which UART is used for kernel/core debug messages. In
Nikolay's
>> branch, he uses the UART with memory mapped I/O located at
0x02020000,
>> and with the following UART definition: >> >> >> >>
https://github.com/decaprox/genode/blob/i.mx6/base/include/drivers/uart/imx3...
>> >> Please check whether this corresponds with your board's
definitions.
>> >>> >>> Also, is there a good debugging tool for testing the genode
environment
>> on >>> direct hardware? >> >> Well, there is JTAG of course, which isn't related to Genode >> specifically. There are other debugging utils available on Genode,
like
>> GDB, but that wouldn't help on that low level you're currently
working
at. >> >> Regards >> Stefan >> >>> >>> Thanks in advance >>> Aditya Kousik >>> >>> >>> >>> >>
>>> Rapidly troubleshoot problems before they affect your business.
Most
IT
>>> organizations don't have a clear picture of how application
performance
>>> affects their revenue. With AppDynamics, you get 100% visibility
into
>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >>> >>
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
>>> >>> >>> >>> _______________________________________________ >>> 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/ >> >> >>
>> Rapidly troubleshoot problems before they affect your business.
Most
IT
>> organizations don't have a clear picture of how application
performance
>> affects their revenue. With AppDynamics, you get 100% visibility
into
your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >>
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
>> _______________________________________________ >> Genode-main mailing list >> Genode-main@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main >> > > > >
> Rapidly troubleshoot problems before they affect your business.
Most IT
> organizations don't have a clear picture of how application
performance
> affects their revenue. With AppDynamics, you get 100% visibility
into
your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
> > > > _______________________________________________ > Genode-main mailing list > Genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >
-- Stefan Kalkowski Genode Labs
Rapidly troubleshoot problems before they affect your business. Most
IT
organizations don't have a clear picture of how application
performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
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/
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Aditya
On 29.01.2014 06:36, Aditya Kousik wrote:
Hello all,
Genode base-hw kernel runs successfully on i.MX6. Stefan: we were looking at the wrong UART port (1 instead of 2) which led us on a wild goose chase. And we set the GPIO pins directly by setting IOMUX to GPIO mode: we lit a LED bulb successfully. The driver, as you mentioned is quite complex.
We're getting the following message for test-printf ::
Starting kernel ...
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1020 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so http://ld.lib.so" [init -> test-printf] -1 = -1 = -1 [init] virtual void Genode::Child_policy::exit(int): child exited with exit value 0
We ran nested_init to verify again and got the following::
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1021 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so http://ld.lib.so" [init] parent provides [init] service "ROM" [init] service "RAM" [init] service "CAP" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] service "SIGNAL" [init] child "init" [init] RAM quota: 10223616 [init] ELF binary: init [init] priority: 0 [init -> init] Could not open file "ld.lib.so http://ld.lib.so" [init -> init] parent provides [init -> init] service "ROM" [init -> init] service "RAM" [init -> init] service "CAP" [init -> init] service "PD" [init -> init] service "RM" [init -> init] service "CPU" [init -> init] service "LOG" [init -> init] service "SIGNAL" [init -> init] child "init" [init -> init] RAM quota: 4980736 [init -> init] ELF binary: init [init -> init] priority: 0 [init -> init -> init] Could not open file "ld.lib.so http://ld.lib.so" [init -> init -> init] parent provides [init -> init -> init] service "ROM" [init -> init -> init] service "RAM" [init -> init -> init] service "CAP" [init -> init -> init] service "PD" [init -> init -> init] service "RM" [init -> init -> init] service "CPU" [init -> init -> init] service "LOG" [init -> init -> init] service "SIGNAL" [init -> init -> init] No children to start
One, Are these satisfactory messages? (Are the test scripts running as they should) Two, Why does test-printf not work when I try to print Genode::printf("Hello World!"); and consequently set run_genode_until "Hello World!" 10 (or {Hello World!} 10). [init -> test-printf] does not get initialized.
Regards Aditya.
The output of your run/printf and run/nested_init looks fine. I assume you're getting no output with Genode::printf("Hello World!"); because Genode buffers print jobs until a line-break comes in, to save RPCs. Could please try Genode::printf("Hello World!\n"); ?
Best regards, Martin
Hi Martin,
You were right. Adding a line break fixed it. Who would have thought? :-)
Great. We can proceed from here. Thank you for bearing with us.
Regards Aditya
On Wed, Jan 29, 2014 at 5:00 PM, Martin Stein <martin.stein@...1...>wrote:
Hi Aditya
On 29.01.2014 06:36, Aditya Kousik wrote:
Hello all,
Genode base-hw kernel runs successfully on i.MX6. Stefan: we were looking at the wrong UART port (1 instead of 2) which led us on a wild goose chase. And we set the GPIO pins directly by setting IOMUX to GPIO mode: we lit a LED bulb successfully. The driver, as you mentioned is quite complex.
We're getting the following message for test-printf ::
Starting kernel ...
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1020 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> test-printf] -1 = -1 = -1 [init] virtual void Genode::Child_policy::exit(int): child exited with exit value 0
We ran nested_init to verify again and got the following::
int main(): --- create local services --- int main(): --- start init --- int main(): transferred 1021 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init] parent provides [init] service "ROM" [init] service "RAM" [init] service "CAP" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] service "SIGNAL" [init] child "init" [init] RAM quota: 10223616 [init] ELF binary: init [init] priority: 0 [init -> init] Could not open file "ld.lib.so" [init -> init] parent provides [init -> init] service "ROM" [init -> init] service "RAM" [init -> init] service "CAP" [init -> init] service "PD" [init -> init] service "RM" [init -> init] service "CPU" [init -> init] service "LOG" [init -> init] service "SIGNAL" [init -> init] child "init" [init -> init] RAM quota: 4980736 [init -> init] ELF binary: init [init -> init] priority: 0 [init -> init -> init] Could not open file "ld.lib.so" [init -> init -> init] parent provides [init -> init -> init] service "ROM" [init -> init -> init] service "RAM" [init -> init -> init] service "CAP" [init -> init -> init] service "PD" [init -> init -> init] service "RM" [init -> init -> init] service "CPU" [init -> init -> init] service "LOG" [init -> init -> init] service "SIGNAL" [init -> init -> init] No children to start
One, Are these satisfactory messages? (Are the test scripts running as they should) Two, Why does test-printf not work when I try to print Genode::printf("Hello World!"); and consequently set run_genode_until "Hello World!" 10 (or {Hello World!} 10). [init -> test-printf] does not get initialized.
Regards Aditya.
The output of your run/printf and run/nested_init looks fine. I assume you're getting no output with Genode::printf("Hello World!"); because Genode buffers print jobs until a line-break comes in, to save RPCs. Could please try Genode::printf("Hello World!\n"); ?
Best regards, Martin
WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.cl... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Meenakshi,
On 29.01.2014 12:09, Meenakshi Narayanan wrote:
Hello,
The structure of Genode::printf is quite interesting. Running the test-printf scenario with PDBG("Hello World") works fine. It simply prints 'int main(int, char**): Hello World!'
Looking up the definition for the Genode printf in base/printf.h was not so revealing. What makes the "-1 = -1 = -1" regex special that init refuses to spawn the init->test-printf child process?
Regards Meenakshi
I guess it works with PDBG in contrast to printf because PDBG (as well as PINF, PLOG, and PERR) are macros that add a line-break to the end of an input string, which in turn causes the string to be send to the LOG-session server immediately. However, the backend of these macros is the Genode::printf function that leaves things like line-breaks and coloring sequences in the hand of the user.