<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hello Kumar.<br><br>I would give the entry point address as physical address instead of virtual (like it is for linux. I think you should set the -e to 0x8000000 as well. <br><br><br>
For sure, Okl4 does require the MMU to be off on entry, and if it is not then the head.spp code will make sure of it. So, to avoid problems, when you
type bootelf in UBoot, you need to make sure MMU is off). <br><br>Okl4 will turn
MMU on in the code (in the system_startyp_mmu() function call in
pistachio). To achieve this it does a copy of the kernel code (before MMU is on)
from the physical base to the virtual base (in that
startup_system_mmu() function I mentioned earlier), to have no problem
on finding the first instruction after the MMU is turned on.<br><br><br><br>As I said I do not use uBoot so I can be sure of the folllowing, but ...<br>My observation is that linux's entry point is at a 8k offset from the base of physical memory and this might be for a reason (to allow uBoot RAM program to still exist, while you are loading the okl4 binary). <br><br>If the set of -e to the physical base fails, and gives indications that this is a failure from uBoot, it could be an idea to set the entry point to 0x8008000 and also make this setting for the okl4 image by changing the memory['physical'] base value accordingly in your platform's machines.py.<br><br><br>I also see from your head.spp:<br><span style="color: rgb(0, 0, 153);"> f0000010: ee070f16 mcr 15, 0, r0, cr7, cr6, {0}</span><br> that you do not perform a
correct armv7 clean op on the L1 dcache (that entire dcache clean coprocessor command is deprecated, and can lead either to unimplemennted/nop/unpreictable behavior). You should perform a similar op on set/way instead, like you can find in the arm920t implementation.<br><br>Good luck,<br>Gabi Voiculescu<br><br>--- On <b>Thu, 9/24/09, Kumar Sanghvi <i><divinekumar@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Kumar Sanghvi <divinekumar@gmail.com><br>Subject: Re: [okl4-developer] Help with SoC Porting<br>To: "Gabi Voiculescu" <boy3dfx2@yahoo.com><br>Cc: developer@okl4.org<br>Date: Thursday, September 24, 2009, 3:42 AM<br><br><div id="yiv1791300167">Hi Gabi,<br><br>Answer to some more debug pointers suggested by you:-<div class="im"><br><br><span style="color: rgb(102, 0, 0);">3.What
does the crosscompiler readelf (arm-linux-readelf -h in mycase) say?
Just to doublecheck the readelf output since the "readelf" is designed
for the x86 gcc toolchain, and it is not part of the crosscompiler
suite.
</span><br style="color: rgb(102, 0, 0);"><br></div>--> The arm-linux-readelf says the same thing. Below is the output<br><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">[root@localhost okl4_3.0-armv6]# ../../opt/nicta/tools/gcc-3.4.4-glibc-2.3.5/arm-linux/bin/arm-linux-readelf build/images/image.elf.nobits -l</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Elf file type is EXEC (Executable file)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Entry point 0xf0000000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> There are 6 program headers, starting at offset 52</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Program Headers:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> LOAD 0x008000 0xf0000000 0x80000000 0x24328 0x24328 RWE 0x8000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> LOAD 0x030000 0xf0028000 0x80028000 0x06000 0x06000 RW 0x8000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> LOAD 0x038000 0x00100000 0x80030000 0x066dc 0x066dc R E 0x8000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> LOAD 0x03e6ec 0x0010e6ec 0x800256ec 0x00160 0x00160 RW 0x8000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> LOAD 0x03f000 0x0010f000 0x80037000 0x009c7 0x009c7 RW 0x1000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> LOAD 0x040000 0x00001000 0x80026000 0x01000 0x01000 RW 0x1000</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Section to Segment mapping:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> Segment Sections...</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">
00 kernel.text kernel.rodata kernel.kdebug kernel.init
kernel.roinit kernel.elfweaver_info kernel.data kernel.got
kernel.got.plt kernel.kdebug-data kernel.bss </span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> 01 kernel.kspace kernel.traps kernel.utcb_page </span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> 02 hello.text hello.rodata </span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> 03 hello.got hello.data hello.bss </span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> 04 hello.cell_environment </span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> 05 initscript </span><br style="color: rgb(0, 0, 153);"><br>==============================<div class="ii gt">==========================================================================================================================<div class="im">
<br>
<br><span style="color: rgb(102, 0, 0);">Try
adding zero_bss = True to your machines.py definitions. It will create
an okl4 image.elf.nobits. And make your binary out of the
image.elf.nobits. This could eliminate problems with your BSS sections
not being zero-ed out at startup (was a problem in an older okl4 public
release). You would init somethng with 0 in your code and it would be
nonzero in real life.
</span><br style="color: rgb(102, 0, 0);"><br></div>-->zero_bss = True is already present in machines.py.<br><br>========================================================================================================================================================
<br><div class="im"><span style="color: rgb(102, 0, 0);">To this regard
you can disassemble your elf image to check contents at the load
address position. Since this is part of the kernel image it might be
better to check the pistachio kernel elf image directly:
</span><br style="color: rgb(102, 0, 0);"><span style="color: rgb(102, 0, 0);">arm-linux-objdump -S build/image/image.elf.nobits -to disassemble the okl4 image
</span><br style="color: rgb(102, 0, 0);"><span style="color: rgb(102, 0, 0);">arm-linux-objdump -S build/pistachio/bin/kernel, - to dissassemble the kernel elf
</span><br style="color: rgb(102, 0, 0);"><span style="color: rgb(102, 0, 0);">and
check if at physical address 0x80000000 (which based on the readelf
means at virtual address 0xf0000000) you actually see some
instructions: should be the head.spp if I remember correctly.
</span><br style="color: rgb(102, 0, 0);"><br style="color: rgb(102, 0, 0);"></div>--> disassembly of image.elf.nobits does show instructions from head.spp at address 0xf0000000. Below is a snippet.<br> Disassembly of section kernel.text:<br>
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000000 <_start>:</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000000: e329f0d3 msr CPSR_fc, #211 ; 0xd3</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000004: e3a00078 mov r0, #120 ; 0x78</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000008: ee010f10 mcr 15, 0, r0, cr1, cr0, {0}</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f000000c: e3a00000 mov r0, #0 ; 0x0</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000010: ee070f16 mcr 15, 0, r0, cr7, cr6, {0}</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000014: ee070f15 mcr 15, 0, r0, cr7, cr5, {0}</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000018: ee080f17 mcr 15, 0, r0, cr8, cr7, {0}</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f000001c: e59fd008 ldr sp, [pc, #8] ; f000002c <__phys_addr_stack></span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000020: e28ddffe add sp, sp, #1016 ; 0x3f8</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000024: eb000001 bl f0000030 <kernel_arch_init></span><br style="color: rgb(0, 0, 153);"><br><br><br>========================================================================================================================================================<br>
<br><br>--> disassembly of pistachio/bin/kernel does show instructions from head.spp at address 0xf0000000. Below is a snippet.<br><br><br> Disassembly of section .text:<br><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000000 <_start>:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000000: e329f0d3 msr CPSR_fc, #211 ; 0xd3</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000004: e3a00078 mov r0, #120 ; 0x78</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000008: ee010f10 mcr 15, 0, r0, cr1, cr0, {0}</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f000000c: e3a00000 mov r0, #0 ; 0x0</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000010: ee070f16 mcr 15, 0, r0, cr7, cr6, {0}</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000014: ee070f15 mcr 15, 0, r0, cr7, cr5, {0}</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000018: ee080f17 mcr 15, 0, r0, cr8, cr7, {0}</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f000001c: e59fd008 ldr sp, [pc, #8] ; f000002c <__phys_addr_stack></span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000020: e28ddffe add sp, sp, #1016 ; 0x3f8</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000024: eb000001 bl f0000030 <kernel_arch_init></span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000028 <L1>:</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000028: eafffffe b f0000028 <L1></span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f000002c <__phys_addr_stack>:</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f000002c: 00000000 andeq r0, r0, r0</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000030 <kernel_arch_init>:</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000030: e28f0004 add r0, pc, #4 ; 0x4</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000034: eb008273 bl f0020a08 <init_memory></span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f0000038 <L1>:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f0000038: eafffffe b f0000038 <L1></span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> f000003c <__phys_addr_ram>:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> f000003c: 00000000 andeq r0, r0, r0</span><br style="color: rgb(0, 0, 153);"><br><br>========================================================================================================================================================<br>
<br>Another thing that I learned about u-boot is below:-<br>1) I was using 'go' command to load the okl4 elf kernel. <br> As it turns out, 'go' command is useful to load standalone binaries and is not suitable for loading kernels.<br>
<br>2) So, to load the kernel elf, options are to use <br> -bootelf command<br> -bootm command<br><br>3) The u-boot which came pre-flashed on my beagleboard does not have the bootelf command.<br> (I might probably need to build the u-boot myself with bootelf option turned on, and then burn this new u-boot to the flash.<br>
Then I should be able to directly load the okl4 elf image. I am keeping this as last option)<br><br>4)
To load kernel image with 'bootm' command, it is required to attach a
u-boot header to the kernel image. The 'mkimage' tool helps here.<br>
I give the below command to attach u-boot header to the okl4 elf image<br><br><span style="color: rgb(0, 0, 153);"> mkimage -A arm -O linux -n 'OKL4' -T kernel -C none -a 0x80000000 -e 0xf0000000 -d build/images/image.elf okl41uImage.img</span><br>
Here: - -a == load address<br> -e == entry point<br><b>
===> Could someone confirm if I am giving the correct values for the
load address and the entry point (-a and -e values)? </b><br> For the Linux kernel 'uImage', load address is 0x80008000 and entry point is 0x80008000.<br>
<br><br> With this new okl4uImage, the error message has changed in
the omap3 simulator. The simulator is still exiting but it seems that
it is trying to load the kernel and not recognizing the address of
entry point. <br>
<br><span style="color: rgb(0, 0, 153);"> OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org/">beagleboard.org</a> # </span><br style="color: rgb(0, 0, 153);"><div class="im"><span style="color: rgb(0, 0, 153);"> OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org/">beagleboard.org</a> # nand read 0x80000000 0x280000 0x400000</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> NAND read: device 0 offset 0x280000, size 0x400000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> 4194304 bytes read: OK</span><br style="color: rgb(0, 0, 153);">
</div><span style="color: rgb(0, 0, 153);"> OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org/">beagleboard.org</a> # bootm 80000000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> ## Booting kernel from Legacy Image at 80000000 ...</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> Image Name: OKL4</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Image Type: ARM Linux Kernel Image (uncompressed)</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> Data Size: 331552 Bytes = 323.8 kB</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Load Address: 80000000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> Entry Point: f0000000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Verifying Checksum ... OK</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> XIP Kernel Image ... OK</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Starting kernel ...</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> smc 80e80414 insn 1600070 </span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> Unassigned mem readb f0000000pc f0000000</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> [root@localhost arm-softmmu]# </span><br style="color: rgb(0, 0, 153);"><br><br> <br> I have yet to test this on the beagleboard itself. <br><br>
However, from simulator error, it seems that it is still not
recognising f0000000 address - probably because MMU is not turned on
till this point?<br>
I think that correcting the value of Load address and Entry point
while using the 'mkimage' tool will help to resolve the issue .ie.
atleast kernel will load properly and execution will start with the
code of head.spp.<br>
<br><br><br>Thanks,<br><font color="#888888">Kumar.</font><div><div><span id="q_123e990ef0e70b7c_10" class="h4"><br></span></div></div></div><br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 9:12 PM, Gabi Voiculescu <span dir="ltr"><<a rel="nofollow" ymailto="mailto:boy3dfx2@yahoo.com" target="_blank" href="/mc/compose?to=boy3dfx2@yahoo.com">boy3dfx2@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
Yes, you are right about the memory['virtual'].<br><br>Tracing back my machines I see a 'virtual' memory entry for:<br>class armv6(arm):<div class="im"><br> memory = arm.memory.copy()<br> memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer derefs.<br>
<br></div>class armv5(arm):<br> memory = arm.memory.copy()<br> base_vaddr = 0x80000000<div class="im"><br> memory['virtual'] = [Region(0x80000000, 0xd0000000)] # Trap NULL pointer derefs.<br><br></div>and I propagate this property onward through the xxx.memory.copy() command.<br>
<br>Not sure how the okl4 guys came up with these numbers, for v5 and v6, though.<br>Gabi Voicuelscu<div class="im"><br><br>--- On <b>Mon, 9/21/09, Kumar Sanghvi <i><<a rel="nofollow" ymailto="mailto:divinekumar@gmail.com" target="_blank" href="/mc/compose?to=divinekumar@gmail.com">divinekumar@gmail.com</a>></i></b> wrote:<br>
</div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div class="im"><br>From: Kumar Sanghvi <<a rel="nofollow" ymailto="mailto:divinekumar@gmail.com" target="_blank" href="/mc/compose?to=divinekumar@gmail.com">divinekumar@gmail.com</a>><br>
Subject: Re: [okl4-developer] Help with SoC Porting<br></div>To: "Gabi Voiculescu" <<a rel="nofollow" ymailto="mailto:boy3dfx2@yahoo.com" target="_blank" href="/mc/compose?to=boy3dfx2@yahoo.com">boy3dfx2@yahoo.com</a>><br>Cc: <a rel="nofollow" ymailto="mailto:developer@okl4.org" target="_blank" href="/mc/compose?to=developer@okl4.org">developer@okl4.org</a><br>
Date: Monday, September 21, 2009, 12:30 PM<div><div></div><div class="h5"><br><br><div>Hi Gabi,<br><br>Thank you for providing the pointers for debugging the build.<br><br>Just to answer your 1st point:-<br><span style="color: rgb(102, 0, 0);">1. For assessing potential errors due to the first issue i recommend commenting out the base_<span>vaddr</span> ...</span><br style="color: rgb(102, 0, 0);">
<span style="color: rgb(102, 0, 0);">memory['virtual']....</span><br style="color: rgb(102, 0, 0);"><span style="color: rgb(102, 0, 0);">In my previous email I stated I never have set these. </span><br style="color: rgb(102, 0, 0);">
<span style="color: rgb(102, 0, 0);">The
virtual should specify how much memory is assignated to the starting
virtual memory pool, and I see no reason to limit it at pre-build time.
</span><br style="color: rgb(102, 0, 0);"><span style="color: rgb(102, 0, 0);">As for base_vaddr, the readelf still says the entry point is
0xf000.0000 (vaddr) even after you forced base_vaddr on okl4, so either
this is ignored or affecting some (but not all) okl4 initialization
location in the elf image, and thus causing you problems.</span><br><br>I have removed the base_vaddr.<br>However, if I remove the memory['virtual'], the build won't compile giving following errors:-<br><br><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">[root@localhost okl4_3.0-armv6]# ./tools/build.py MACHINE=beagle PROJECT=examples EXAMPLE=hello TOOLCHAIN=gnu_arm_eabi_toolchain pistachio.TOOLCHAIN=gnu_arm_toolchain PYFREEZE=false kdb_serial=true kdb_breakin=false debug_trace=5 verbose_init=true</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">scons: Reading SConscript files ...</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">scons: done reading SConscript files.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">scons: Building targets ...</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">[VIRT] build/hello/bin/hello.linkaddress</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">[LINK] build/hello/bin/hello</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">GNU ld (GNU Binutils) 2.18</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Copyright 2007 Free Software Foundation, Inc.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">This program is free software; you may redistribute it under the terms of</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">the GNU General Public License version 3 or (at your option) a later version.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">This program has absolutely no warranty.</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">[XML ] build/images/weaver.xml</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">[ELF ] build/images/image.elf</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Error: Virtual pool/zone "virtual" not found.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">Now printing a traceback.</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Traceback (most recent call last):</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> File "tools/pyelf/elfweaver.py", line 79, in ?</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> main(sys.argv)</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/main.py", line 108, in main</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> __commands__[args[1]](args[2:])</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py", line 270, in merge_cmd</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> merge(spec_file, options)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py", line 184, in merge</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> image.layout(machine, pools)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/image.py", line 901, in layout</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> pools)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/image.py", line 367, in layout</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> pools._alloc(alloc_items[0], alloc_group)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py", line 470, in _alloc</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> self.alloc_virtual(item.get_pool(), group)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py", line 494, in alloc_virtual</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> return self.__alloc(name, group, self.virtual_pools, "Virtual")</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py", line 483, in __alloc</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> raise MergeError, '%s pool/zone "%s" not found.' % (mem_type, name)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">MergeError: Virtual pool/zone "virtual" not found.</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">scons: *** [build/images/image.elf] Error 1</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">scons: building terminated because of errors.</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);">I will try out rest of the steps suggested by you and let you all know the results.<br><br>Thanks again.<br>Kumar.<br><br><br><div class="gmail_quote">
On Sun, Sep 20, 2009 at 4:19 PM, Gabi Voiculescu <span dir="ltr"><<a rel="nofollow" target="_blank" href="http://mc/compose?to=boy3dfx2@yahoo.com">boy3dfx2@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
Hello Kumar.<br><br>You left out a couple of potential issues:<br>1- build script does not use the virtual address range you thought and forcefully specified in your machines.py (there could be something hardwired missed by everybody)<br>
2- uboot has mmu turned on before it loads the okl4 image (which fails a prerequisite from head.spp in your beagleboard platform)<br>3- your okl4 elf image is not good for some reason (like bad entry point/load_address)<br>
4- you write to the console before you init your serial debug console (in which case you go into a forever loop)<br>5- bad cache maintenance before loading l4<br><br>1. For assessing potential errors due to the first issue i recommend commenting out the <span style="color: rgb(0, 0, 153);"> base_<span>vaddr</span> ...</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">memory['virtual']</span>....<br>In my previous email I stated I never have set these. <br>The virtual should specify how much memory is assignated to the starting virtual memory pool, and I see no reason to limit it at pre-build time. <br>
As for base_vaddr, the readelf still says the entry point is 0xf000.0000 (vaddr) even after you forced base_vaddr on okl4, so either this is ignored or affecting some (but not all) okl4 initialization location in the elf image, and thus causing you problems. <br>
<br>2.I'm not sure how you can test MMU state before loading the okl4 image via uboot, but there should be a command to specify processor status. <br>I haven't yet used uboot, since my last platforms were either emulated or using other bootloaders, but will have to start within a week or so myself.<br>
<br>3.What does the crosscompiler readelf (arm-linux-readelf -h in mycase) say? Just to doublecheck the readelf output since the "readelf" is designed for
the x86 gcc toolchain, and it is not part of the crosscompiler suite.<br><br>Try adding zero_bss = True to your machines.py definitions. It will create an okl4 image.elf.nobits. And make your binary out of the image.elf.nobits. This could eliminate problems with your BSS sections not being zero-ed out at startup (was a problem in an older okl4 public release). You would init somethng with 0 in your code and it would be nonzero in real life.<br>
<br>To this regard you can disassemble your elf image to check contents at the load address position. Since this is part of the kernel image it might be better to check the pistachio kernel elf image directly:<br>arm-linux-objdump -S build/image/image.elf.nobits -to disassemble the okl4 image<br>
arm-linux-objdump -S build/pistachio/bin/kernel, - to dissassemble the kernel elf<br>and check if at physical address 0x80000000 (which based on the readelf means at virtual address 0xf0000000) you actually see some
instructions: should be the head.spp if I remember correctly.<br><br><br>4. Doublecheck you do not print anything to the okl4 debug console (no printf, no printk, no SOC_TRACEF) before you map in the console sfr in omap3530/pistachio/src/plat.c and perform the console init in your omap3530/pistachio/kdb/console.c (UART3 for beagleboard). If I rememeber correctly (since I do not have the okl4 sources at hand right now).<br>
<br>5. omap3530/.../Head.spp. Did you change the d cache flush instruction? There is no "dcache flush all" cp15 instruction in armv7. It's a nop. You need to flush by set/way to actually clean the cache. To this regard how is the OMAP cache set up: L1 enabled, L2 disabled? OMAP has more cache levels integrated .<br>
You haven't used any of the armv7 mnemonics yet, right (like isb, dsb, etcetera)? Or used a different compiler pair for building your example other than the default one?<br><br><br><br>This would be the order in which
I would start my checks.<br><br>As for your Unassigned mem writew 48070008...Could this be a warning that the peripheral located at address is not supported by qemu-omap3?<br><br>I will have to do a beagleboard port prety soon myself, so please keep us informed about your progress.<br>
<br>Hope I gave you some ideas,<br>Gabi Voiculescu<br><br><br>--- On <b>Sun, 9/20/09, Kumar Sanghvi <i><<a rel="nofollow" target="_blank" href="http://mc/compose?to=divinekumar@gmail.com">divinekumar@gmail.com</a>></i></b> wrote:<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<br>From: Kumar Sanghvi <<a rel="nofollow" target="_blank" href="http://mc/compose?to=divinekumar@gmail.com">divinekumar@gmail.com</a>><br>Subject: Re: [okl4-developer] Help with SoC Porting<br>To: "Jonathan Sokolowski" <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jsok@ok-labs.com">jsok@ok-labs.com</a>><br>
Cc: <a rel="nofollow" target="_blank" href="http://mc/compose?to=developer@okl4.org">developer@okl4.org</a><br>Date: Sunday, September 20, 2009, 12:17 AM<div><div></div><div><br><br><div>Hi Jonathan,<br><br>Thank you for pointing towards the qemu logs.<br>
<br><br>Firstly, for loading okl4image.elf in qemu-omap3 simulator, I am creating a nand image
comprising of x-loader, u-boot and okl4image.elf and then loading that nand image in qemu-omap3 simulator.<br>
I give below commands to create the nand image<br><b style="color: rgb(0, 0, 153);">./bb_nandflash.sh x-load.bin.ift beagle.bin x-loader<br>./bb_nandflash.sh u-boot.bin beagle.bin u-boot<br>./bb_nandflash.sh okl4image.elf beagle.bin kernel<br>
./bb_nandflash_ecc beagle.bin 0x0 0xe80000<br></b><br>Then I give below command to run the emulator with created nand image<br><b style="color: rgb(0, 0, 153);">./qemu-system-arm -M beagle -mtdblock beagle.bin -serial stdio -d in_asm,int,exec,cpu</b><br>
<br>Once the u-boot prompt comes up, at the u-boot prompt, I type as below <br><br><b style="color: rgb(0, 0, 153);">OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org">beagleboard.org</a> # nand read 0x80000000 0x280000 0x400000<br>
NAND read: device 0 offset 0x280000, size 0x400000<br>
4194304 bytes read: OK<br>OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org">beagleboard.org</a> # go 0x80000000<br></b><br>After entering above command, emulator exits with below message<br><br><b style="color: rgb(0, 0, 153);">## Starting application at 0x80000000 ...<br>
Internal resource leak before 80000004 </b><span style="color: rgb(0, 0, 0);">//this error message can be co-related to 'tstvs' line in below outputs from log file</span><b style="color: rgb(0, 0, 153);"><br>
Unassigned mem readl 00000000pc 80000004<br>[root@localhost arm-softmmu]# <br></b><br>Following is last 20 lines of qemu log file. I have attached the full log file with this mail.<br>(Since the log file is to house target asm instructions, I believe that start of the log file will have asm instructions generated from x-loader code and u-boot code)<br>
<br><b style="color: rgb(0, 0, 153);">[root@localhost arm-softmmu]#tail -20 qemu.log<br>0x80e862cc: mov r3, r0<br>0x80e862d0: push {r4, lr}<br>0x80e862d4: mov r0, r1<br>0x80e862d8: mov r1, r2<br>
0x80e862dc: blx r3 </b><span style="color: rgb(0, 0, 0);">// I suppose that this line corresponds to u-boot command "go 0x80000000" given at u-boot prompt</span><b style="color: rgb(0, 0, 153);"><br>
<br>----------------<br>IN: <br>0x80000000: undefined<br><br>----------------<br>IN: <br>0x80000004: tstvs r1, r1, lsl #2 </b><span style="color: rgb(0, 0, 0);">//cannot make out what this is and from where it is coming from? </span><b style="color: rgb(0, 0, 153);"><br>
0x80000008: andeq r0, r0, r0<br>0x8000000c: andeq r0, r0, r0<br>0x80000010: eoreq r0, r8, r2<br>0x80000014: andeq r0, r0, r1<br>0x80000018: undefined instruction 0xf0000000 </b><span style="color: rgb(0, 0, 0);">// this seems to be the culprit -- need to find the cause</span><b style="color: rgb(0, 0, 153);"><br>
<br></b>So, it seems that the okl4image.elf is not loading or the 1st instruction at the address 0x80000000 is not being recognized.<br>And I believe that the 1st instruction of okl4image.elf would be from platform/SoCXX/pistachio/src/head.spp<br>
<br>=======================================================================================================================================<br>I have even tried commenting out my soc_init code in platform/omap3530/pistachio/src/plat.c file.<br>
However no difference is observed.<br><br>I even tried writing directly to the serial port.....but no difference.<br><br>It seems that execution is not at all reaching the soc_init. In fact, I suspect that even the code present in head.spp, arch/arm/pistachio/src/start.spp, arch/arm/pistachio/src/init.cc are also not executed.<br>
==========================================================================================================================================<br><br>At this stage, I am suspecting below:-<br>1. okl4image.elf itself is not getting loaded and code of head.spp is not executed.Something is going wrong somewhere.<br>
2. Somewhere, my memory related calculations are wrong and the generated okl4image.elf is not proper.<br>3. I am making a mistake somewhere in loading the okl4image.elf in the qemu-omap3 simulator.<br> However, I have tested the okl4image.elf on Beagleboard also and its not working.<br>
Below is output from Beagleboard in minicom<br><br><b style="color: rgb(0, 0, 153);"> Texas Instruments X-Loader 1.41 <br> Starting OS Bootloader... <br>
<br> <br> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) <br>
<br> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz <br>
OMAP3 Beagle Board + LPDDR/NAND <br> DRAM: 128 MB <br> NAND: 256 MiB<br> In: serial<br> Out: serial<br> Err: serial<br> Audio Tone on Speakers ... complete<br>
OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org">beagleboard.org</a> # <br> OMAP3 <a rel="nofollow" target="_blank" href="http://beagleboard.org">beagleboard.org</a> # mmcinit;fatload mmc 0 0x80000000 image.elf;go 0x80000000<br>
reading image.elf<br><br>
331564 bytes read<br> ## Starting application at 0x80000000 ...<br></b><br><br>Please advise.<br><br>Thanks,<br>Kumar.<br><br><br><br><div class="gmail_quote">On Thu, Sep 17, 2009 at 5:26 AM, Jonathan Sokolowski <span dir="ltr"><<a rel="nofollow" target="_blank" href="http://mc/compose?to=jsok@ok-labs.com">jsok@ok-labs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Hi Kumar,<div><br></div><div>The assertion errors you are seeing when not setting the physical and virtual memory regions correctly are perfectly normal, they are simply ensuring alignment is sane.</div>
<div><br></div><div>You should be able to determine the correct physical region/s from your board's datasheets.</div><div><br></div><div>Also note that when setting base_vaddr, it should be identical to the base of your virtual region!</div>
<div><br></div><div>As for the bad register writes, the address looks like some device exists at that physical address. Maybe check your datasheet for some hints?</div><div><br></div><div>I would suggest the following to begin debugging:</div>
<div>1) If you qemu has some logging or execution tracing available, turn it on and analyse the trace.</div><div>2) Do some low-level serial printing from within the kernel, i.e. writing directly to serial registers.</div>
<div><br><div>
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div>
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div>
<div>Hope this helps,</div><div>Jonathan Sokolowski</div></div></span></div></span></span>
</div>
<br><div><div><div></div><div><div>On 17/09/2009, at 9:06 AM, Kumar Sanghvi wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>Hi All,<br><br>I need some help with SoC porting part.<br>
I have written some code for OKL4 3.0 port for Beagleboard. The code is compiling fine and generating images.<br>I try to load the image in Qemu-omap3 simulator and it exits with below error message:-<br>
"Unassigned mem writew 48070008 = 0xffff pc 80e9b298"<br><br>I try to load the image on Beagleboard and nothing comes on serial terminal.<br><br>It is very possible that my serial code is not written correctly. But, since the simulator is exiting with some memory related messages, I am doubtful if I have set the parameters for<br>
-memory[physical], memory[virtual] and vbase_address correctly.<br><br><br><br>Following is the build command-line. The below error message comes if I don't specify or wrongly specify values for memory[virtual] and vbase_address in arch/arm/tools/machines.py for the cortexa8 definition:-<br>
========================================================================================================================================================<br><span style="color: rgb(0, 0, 153);">[root@localhost okl4_3.0-armv6]# ./tools/build.py MACHINE=beagle PROJECT=examples EXAMPLE=hello TOOLCHAIN=gnu_arm_eabi_toolchain pistachio.TOOLCHAIN=gnu_arm_toolchain PYFREEZE=false kdb_serial=true kdb_breakin=false debug_trace=5 verbose_init=true</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">scons: Reading SConscript files ...</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">scons: done reading SConscript files.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">scons: Building targets ...</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">[ELF ] build/images/image.elf</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Error: </span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">Now printing a traceback.</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Traceback (most recent call last):</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> File "tools/pyelf/elfweaver.py", line 79, in ?</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> main(sys.argv)</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/main.py", line 108, in main</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> __commands__[args[1]](args[2:])</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py", line 270, in merge_cmd</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> merge(spec_file, options)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py", line 166, in merge</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> namespace, image)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py", line 103, in collect_image_objects</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> pool.collect_xml(el, machine, pools)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py", line 128, in collect_xml</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> pools.add_physical_memory(<a rel="nofollow" target="_blank" href="http://self.name/">self.name</a>, machine, src=src, base=base, size=size)</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py", line 574, in add_physical_memory</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> self.physical_pools[physpool].add_memory(base, size, mem_type)</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> File "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/allocator.py", line 352, in add_memory</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> assert size % self.min_alloc == 0</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">AssertionError</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">scons: *** [build/images/image.elf] Error 1</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">scons: building terminated because of errors.</span><br style="color: rgb(0, 0, 153);">
========================================================================================================================================================<br><br>I then set the following values and build compiles fine generating image<br>
<br><span style="color: rgb(0, 0, 153);">=>platform/omap3530/tools/machines.py:</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> memory[physical] = [Region(0x80000000, 0x82000000)]</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">=>arch/arm/tools/machines.py</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> class armv7(arm):</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> memory = arm.memory.copy()</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> #memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer derefs.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> base_vaddr = 0x10000000</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> memory['virtual'] = [Region(0x1000, 0xd0000000)] # Trap NULL pointer derefs.</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> #memory['virtual'] = [Region(0x80000000, 0xd0000000)] # Trap NULL pointer derefs.</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> #memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer derefs.</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> class armv7a(armv7):</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> cpp_defines = armv7.cpp_defines + [("__ARMv__", 7), "__ARMv7A__"]</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> arch_version = 7</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> class cortexa8(armv7a):</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> c_flags = armv7a.c_flags</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> cpu = "cortexa8"</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><br>======================================================================================================================================================================<br>I have attached readelf output for the generated elf image with this mail.<br>
<br><span style="color: rgb(0, 0, 153);"></span><br>=======================================================================================================================================================================<br>
<br>Below is sequence of output from qemu-omap3 simulator<br><br>omap3-sim output:-<br><br><span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050c00</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050c04</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050c8c</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050c98</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050c9c</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050cac</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050cbc</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_venc_write: Bad register 0x48050cc0</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_diss_write: Bad register 0x48050044</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_diss_write: Bad register 0x48050048</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_diss_write: Read-only register 0x48050050</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_diss_write: Read-only register 0x48050058</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">omap_disc_write: Bad register 0x48050414</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">omap_disc_write: Bad register 0x480504a8</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);">At this point, u-boot prompt is available and I give below command at u-boot prompt:-<br><span style="color: rgb(0, 0, 153);">beagleboard#mmcinit;fatload mmc 0 80000000 image.elf;go 80000000</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">The simulator simply exits with below line:-</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">Unassigned mem writew 48070008 = 0xffff pc 80e9b298 <span style="color: rgb(0, 0, 0);"> //This error message might indicate something</span></span><br style="color: rgb(0, 0, 153);">
[root@localhost arm-softmmu]# <br><br>==============================================================================================================================================================<br><br><br>So, at this point, below are some possible failure points:-<br>
1. Parameters for memory[physical],memory[virtual] and base_vaddress are wrongly given, so memory layout is not proper in the generated elf file.<br>2. u-boot arguments given are wrong.<br>3. Serial code written in platform/omap3530/pistachio/kdb/console.c is wrong, as nothing is coming on screen. <br>
4. If serial code is fine, and considering that build is made with 'verbose_init=true', atleast some output should come from arch/arm/pistachio/src/init.cc file.<br> But as nothing is coming on screen, not sure what is happenning.<br>
<br>Really not able to make out where to start debugging / troubleshooting at this point.<br>Please help with any suggestions / advise.<br><br>Thanks,<br>Kumar.<br>
</div></div><span><Beagle-readelf-output.rtf></span>_______________________________________________<br>Developer mailing list<br><a rel="nofollow" target="_blank" href="http://mc/compose?to=Developer@okl4.org">Developer@okl4.org</a><br>
<a rel="nofollow" target="_blank" href="https://lists.okl4.org/mailman/listinfo/developer">https://lists.okl4.org/mailman/listinfo/developer</a><br>
</blockquote></div><br></div></div></blockquote></div><br>
</div><br></div></div>-----Inline Attachment Follows-----<div><br><br><div>_______________________________________________<br>Developer mailing list<br><a rel="nofollow" target="_blank" href="http://mc/compose?to=Developer@okl4.org">Developer@okl4.org</a><br>
<a rel="nofollow" target="_blank" href="https://lists.okl4.org/mailman/listinfo/developer">https://lists.okl4.org/mailman/listinfo/developer</a><br></div></div></blockquote></td></tr></tbody></table><br>
</blockquote></div><br>
</div></div></div></blockquote></td></tr></tbody></table><br>
</blockquote></div><br>
</div></blockquote></td></tr></table><br>