Booting base-hw image on a Freescale i.MX6

[Aditya Kousik]

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