Booting base-hw image on a Freescale i.MX6

Thu Jan 9 10:44:19 CET 2014

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 at ...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 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/
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> 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.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/