Booting base-hw image on a Freescale i.MX6

Mon Jan 6 10:58:19 CET 2014

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 at ...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
>>> this<http://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#L1366
>>
>> 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/imx31_uart_base.h
>>
>> 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.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Genode-main mailing list
>>> Genode-main at 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.clktrk
>> _______________________________________________
>> Genode-main mailing list
>> Genode-main at 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.clktrk
> 
> 
> 
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/