Booting base-hw image on a Freescale i.MX6

Thu Jan 9 08:30:06 CET 2014

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140109/580e2c2b/attachment.html>