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
