[okl4-developer] Help with SoC Porting
Kumar Sanghvi
divinekumar at gmail.com
Mon Sep 21 19:30:38 EST 2009
Hi Gabi,
Thank you for providing the pointers for debugging the build.
Just to answer your 1st point:-
1. For assessing potential errors due to the first issue i recommend
commenting out the base_vaddr ...
memory['virtual']....
In my previous email I stated I never have set these.
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.
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.
I have removed the base_vaddr.
However, if I remove the memory['virtual'], the build won't compile giving
following errors:-
[root at 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
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
[VIRT] build/hello/bin/hello.linkaddress
[LINK] build/hello/bin/hello
GNU ld (GNU Binutils) 2.18
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
[XML ] build/images/weaver.xml
[ELF ] build/images/image.elf
Error: Virtual pool/zone "virtual" not found.
Now printing a traceback.
Traceback (most recent call last):
File "tools/pyelf/elfweaver.py", line 79, in ?
main(sys.argv)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/main.py",
line 108, in main
__commands__[args[1]](args[2:])
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py",
line 270, in merge_cmd
merge(spec_file, options)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py",
line 184, in merge
image.layout(machine, pools)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/image.py",
line 901, in layout
pools)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/image.py",
line 367, in layout
pools._alloc(alloc_items[0], alloc_group)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py",
line 470, in _alloc
self.alloc_virtual(item.get_pool(), group)
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py",
line 494, in alloc_virtual
return self.__alloc(name, group, self.virtual_pools, "Virtual")
File
"/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py",
line 483, in __alloc
raise MergeError, '%s pool/zone "%s" not found.' % (mem_type, name)
MergeError: Virtual pool/zone "virtual" not found.
scons: *** [build/images/image.elf] Error 1
scons: building terminated because of errors.
I will try out rest of the steps suggested by you and let you all know the
results.
Thanks again.
Kumar.
On Sun, Sep 20, 2009 at 4:19 PM, Gabi Voiculescu <boy3dfx2 at yahoo.com> wrote:
> Hello Kumar.
>
> You left out a couple of potential issues:
> 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)
> 2- uboot has mmu turned on before it loads the okl4 image (which fails a
> prerequisite from head.spp in your beagleboard platform)
> 3- your okl4 elf image is not good for some reason (like bad entry
> point/load_address)
> 4- you write to the console before you init your serial debug console (in
> which case you go into a forever loop)
> 5- bad cache maintenance before loading l4
>
> 1. For assessing potential errors due to the first issue i recommend
> commenting out the base_vaddr ...
> memory['virtual']....
> In my previous email I stated I never have set these.
> 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.
> 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.
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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:
> arm-linux-objdump -S build/image/image.elf.nobits -to disassemble the okl4
> image
> arm-linux-objdump -S build/pistachio/bin/kernel, - to dissassemble the
> kernel elf
> 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.
>
>
> 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).
>
> 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 .
> 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?
>
>
>
> This would be the order in which I would start my checks.
>
> As for your Unassigned mem writew 48070008...Could this be a warning that
> the peripheral located at address is not supported by qemu-omap3?
>
> I will have to do a beagleboard port prety soon myself, so please keep us
> informed about your progress.
>
> Hope I gave you some ideas,
> Gabi Voiculescu
>
>
> --- On *Sun, 9/20/09, Kumar Sanghvi <divinekumar at gmail.com>* wrote:
>
>
> From: Kumar Sanghvi <divinekumar at gmail.com>
> Subject: Re: [okl4-developer] Help with SoC Porting
> To: "Jonathan Sokolowski" <jsok at ok-labs.com>
> Cc: developer at okl4.org
> Date: Sunday, September 20, 2009, 12:17 AM
>
>
> Hi Jonathan,
>
> Thank you for pointing towards the qemu logs.
>
>
> 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.
> I give below commands to create the nand image
> *./bb_nandflash.sh x-load.bin.ift beagle.bin x-loader
> ./bb_nandflash.sh u-boot.bin beagle.bin u-boot
> ./bb_nandflash.sh okl4image.elf beagle.bin kernel
> ./bb_nandflash_ecc beagle.bin 0x0 0xe80000
> *
> Then I give below command to run the emulator with created nand image
> *./qemu-system-arm -M beagle -mtdblock beagle.bin -serial stdio -d
> in_asm,int,exec,cpu*
>
> Once the u-boot prompt comes up, at the u-boot prompt, I type as below
>
> *OMAP3 beagleboard.org # nand read 0x80000000 0x280000 0x400000
> NAND read: device 0 offset 0x280000, size 0x400000
> 4194304 bytes read: OK
> OMAP3 beagleboard.org # go 0x80000000
> *
> After entering above command, emulator exits with below message
>
> *## Starting application at 0x80000000 ...
> Internal resource leak before 80000004 *//this error message
> can be co-related to 'tstvs' line in below outputs from log file*
> Unassigned mem readl 00000000pc 80000004
> [root at localhost arm-softmmu]#
> *
> Following is last 20 lines of qemu log file. I have attached the full log
> file with this mail.
> (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)
>
> *[root at localhost arm-softmmu]#tail -20 qemu.log
> 0x80e862cc: mov r3, r0
> 0x80e862d0: push {r4, lr}
> 0x80e862d4: mov r0, r1
> 0x80e862d8: mov r1, r2
> 0x80e862dc: blx r3 *// I suppose that this line
> corresponds to u-boot command "go 0x80000000" given at u-boot prompt*
>
> ----------------
> IN:
> 0x80000000: undefined
>
> ----------------
> IN:
> 0x80000004: tstvs r1, r1, lsl #2 *//cannot make out what this is
> and from where it is coming from? *
> 0x80000008: andeq r0, r0, r0
> 0x8000000c: andeq r0, r0, r0
> 0x80000010: eoreq r0, r8, r2
> 0x80000014: andeq r0, r0, r1
> 0x80000018: undefined instruction 0xf0000000 *// this seems to be the
> culprit -- need to find the cause*
>
> *So, it seems that the okl4image.elf is not loading or the 1st instruction
> at the address 0x80000000 is not being recognized.
> And I believe that the 1st instruction of okl4image.elf would be from
> platform/SoCXX/pistachio/src/head.spp
>
>
> =======================================================================================================================================
> I have even tried commenting out my soc_init code in
> platform/omap3530/pistachio/src/plat.c file.
> However no difference is observed.
>
> I even tried writing directly to the serial port.....but no difference.
>
> 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.
>
> ==========================================================================================================================================
>
> At this stage, I am suspecting below:-
> 1. okl4image.elf itself is not getting loaded and code of head.spp is not
> executed.Something is going wrong somewhere.
> 2. Somewhere, my memory related calculations are wrong and the generated
> okl4image.elf is not proper.
> 3. I am making a mistake somewhere in loading the okl4image.elf in the
> qemu-omap3 simulator.
> However, I have tested the okl4image.elf on Beagleboard also and its not
> working.
> Below is output from Beagleboard in minicom
>
> * Texas Instruments X-Loader
> 1.41
> Starting OS
> Bootloader...
>
>
>
> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)
>
> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
> OMAP3 Beagle Board + LPDDR/NAND
> DRAM: 128 MB
> NAND: 256 MiB
> In: serial
> Out: serial
> Err: serial
> Audio Tone on Speakers ... complete
> OMAP3 beagleboard.org #
> OMAP3 beagleboard.org # mmcinit;fatload mmc 0 0x80000000 image.elf;go
> 0x80000000
> reading image.elf
>
> 331564 bytes read
> ## Starting application at 0x80000000 ...
> *
>
> Please advise.
>
> Thanks,
> Kumar.
>
>
>
> On Thu, Sep 17, 2009 at 5:26 AM, Jonathan Sokolowski <jsok at ok-labs.com<http://mc/compose?to=jsok@ok-labs.com>
> > wrote:
>
>> Hi Kumar,
>> 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.
>>
>> You should be able to determine the correct physical region/s from your
>> board's datasheets.
>>
>> Also note that when setting base_vaddr, it should be identical to the base
>> of your virtual region!
>>
>> As for the bad register writes, the address looks like some device exists
>> at that physical address. Maybe check your datasheet for some hints?
>>
>> I would suggest the following to begin debugging:
>> 1) If you qemu has some logging or execution tracing available, turn it on
>> and analyse the trace.
>> 2) Do some low-level serial printing from within the kernel, i.e. writing
>> directly to serial registers.
>>
>> Hope this helps,
>> Jonathan Sokolowski
>>
>> On 17/09/2009, at 9:06 AM, Kumar Sanghvi wrote:
>>
>> Hi All,
>>
>> I need some help with SoC porting part.
>> I have written some code for OKL4 3.0 port for Beagleboard. The code is
>> compiling fine and generating images.
>> I try to load the image in Qemu-omap3 simulator and it exits with below
>> error message:-
>> "Unassigned mem writew 48070008 = 0xffff pc 80e9b298"
>>
>> I try to load the image on Beagleboard and nothing comes on serial
>> terminal.
>>
>> 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
>> -memory[physical], memory[virtual] and vbase_address correctly.
>>
>>
>>
>> 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:-
>>
>> ========================================================================================================================================================
>> [root at 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
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> [ELF ] build/images/image.elf
>> Error:
>> Now printing a traceback.
>>
>> Traceback (most recent call last):
>> File "tools/pyelf/elfweaver.py", line 79, in ?
>> main(sys.argv)
>> File
>> "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/main.py",
>> line 108, in main
>> __commands__[args[1]](args[2:])
>> File
>> "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py",
>> line 270, in merge_cmd
>> merge(spec_file, options)
>> File
>> "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/merge.py",
>> line 166, in merge
>> namespace, image)
>> 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
>> pool.collect_xml(el, machine, pools)
>> File
>> "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/pools.py",
>> line 128, in collect_xml
>> pools.add_physical_memory(self.name, machine, src=src, base=base,
>> size=size)
>> 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
>> self.physical_pools[physpool].add_memory(base, size, mem_type)
>> File
>> "/home/kumar/Hypervisor/OKL/experimental-okl4-30-beagleboard-porting/okl4_3.0-armv6/tools/pyelf/weaver/allocator.py",
>> line 352, in add_memory
>> assert size % self.min_alloc == 0
>> AssertionError
>>
>> scons: *** [build/images/image.elf] Error 1
>> scons: building terminated because of errors.
>>
>> ========================================================================================================================================================
>>
>> I then set the following values and build compiles fine generating image
>>
>> =>platform/omap3530/tools/machines.py:
>> memory[physical] = [Region(0x80000000, 0x82000000)]
>>
>> =>arch/arm/tools/machines.py
>> class armv7(arm):
>> memory = arm.memory.copy()
>> #memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer
>> derefs.
>> base_vaddr = 0x10000000
>> memory['virtual'] = [Region(0x1000, 0xd0000000)] # Trap NULL pointer
>> derefs.
>> #memory['virtual'] = [Region(0x80000000, 0xd0000000)] # Trap NULL
>> pointer derefs.
>> #memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer
>> derefs.
>>
>> class armv7a(armv7):
>> cpp_defines = armv7.cpp_defines + [("__ARMv__", 7), "__ARMv7A__"]
>> arch_version = 7
>>
>> class cortexa8(armv7a):
>> c_flags = armv7a.c_flags
>> cpu = "cortexa8"
>>
>>
>>
>> ======================================================================================================================================================================
>> I have attached readelf output for the generated elf image with this mail.
>>
>>
>>
>> =======================================================================================================================================================================
>>
>> Below is sequence of output from qemu-omap3 simulator
>>
>> omap3-sim output:-
>>
>> omap_venc_write: Bad register 0x48050c00
>> omap_venc_write: Bad register 0x48050c04
>> omap_venc_write: Bad register 0x48050c8c
>> omap_venc_write: Bad register 0x48050c98
>> omap_venc_write: Bad register 0x48050c9c
>> omap_venc_write: Bad register 0x48050cac
>> omap_venc_write: Bad register 0x48050cbc
>> omap_venc_write: Bad register 0x48050cc0
>> omap_diss_write: Bad register 0x48050044
>> omap_diss_write: Bad register 0x48050048
>> omap_diss_write: Read-only register 0x48050050
>> omap_diss_write: Read-only register 0x48050058
>> omap_disc_write: Bad register 0x48050414
>> omap_disc_write: Bad register 0x480504a8
>>
>> At this point, u-boot prompt is available and I give below command at
>> u-boot prompt:-
>> beagleboard#mmcinit;fatload mmc 0 80000000 image.elf;go 80000000
>>
>> The simulator simply exits with below line:-
>> Unassigned mem writew 48070008 = 0xffff pc 80e9b298 //This error message might indicate something
>> [root at localhost arm-softmmu]#
>>
>>
>> ==============================================================================================================================================================
>>
>>
>> So, at this point, below are some possible failure points:-
>> 1. Parameters for memory[physical],memory[virtual] and base_vaddress are
>> wrongly given, so memory layout is not proper in the generated elf file.
>> 2. u-boot arguments given are wrong.
>> 3. Serial code written in platform/omap3530/pistachio/kdb/console.c is
>> wrong, as nothing is coming on screen.
>> 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.
>> But as nothing is coming on screen, not sure what is happenning.
>>
>> Really not able to make out where to start debugging / troubleshooting at
>> this point.
>> Please help with any suggestions / advise.
>>
>> Thanks,
>> Kumar.
>> <Beagle-readelf-output.rtf>
>> _______________________________________________
>> Developer mailing list
>> Developer at okl4.org <http://mc/compose?to=Developer@okl4.org>
>> https://lists.okl4.org/mailman/listinfo/developer
>>
>>
>>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org <http://mc/compose?to=Developer@okl4.org>
> https://lists.okl4.org/mailman/listinfo/developer
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20090921/b487f0e5/attachment-0001.htm
More information about the Developer
mailing list