[okl4-developer] Help with SoC Porting
Gabi Voiculescu
boy3dfx2 at yahoo.com
Tue Sep 22 01:42:53 EST 2009
Yes, you are right about the memory['virtual'].
Tracing back my machines I see a 'virtual' memory entry for:
class armv6(arm):
memory = arm.memory.copy()
memory['virtual'] = [Region(0x1000, 0xe0000000)] # Trap NULL pointer derefs.
class armv5(arm):
memory = arm.memory.copy()
base_vaddr = 0x80000000
memory['virtual'] = [Region(0x80000000, 0xd0000000)] # Trap NULL pointer derefs.
and I propagate this property onward through the xxx.memory.copy() command.
Not sure how the okl4 guys came up with these numbers, for v5 and v6, though.
Gabi Voicuelscu
--- On Mon, 9/21/09, Kumar Sanghvi <divinekumar at gmail.com> wrote:
From: Kumar Sanghvi <divinekumar at gmail.com>
Subject: Re: [okl4-developer] Help with SoC Porting
To: "Gabi Voiculescu" <boy3dfx2 at yahoo.com>
Cc: developer at okl4.org
Date: Monday, September 21, 2009, 12:30 PM
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> 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
https://lists.okl4.org/mailman/listinfo/developer
-----Inline Attachment Follows-----
_______________________________________________
Developer mailing list
Developer at 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/b6572103/attachment-0001.htm
More information about the Developer
mailing list