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 <
[email protected]> 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 <
> > [email protected]> 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 <
> >>> [email protected]> 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
> >>>>> [email protected]
> >>>>> 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
> >>>> [email protected]
> >>>> 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
> >>> [email protected]
> >>> 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/genode-main
