Issue with ARM926EJS uboot relocation to DDR

Hi All,

I'm new to Uboot and has experience in bringing up VxWorks BSPs. I am working on developing support for a new SOC in Uboot. The SOC has an arm926ej-s based core and is implemented on Xilinx FPGA with SD-card as the boot device. With current setup DDR is already initialized by FPGA and SD card can be accessed using direct addressing. We have added board files and SoC related files to the Uboot directory and is able to successfully compile and get some outputs on UART (debug console). Currently, we have added only support for GPIO and UART drivers.
SD Card : 0x00000000 - 0x007FFFFF
SRAM    : 0x90000000 - 0x90007FFF
DDR       : 0x40000000 - 0x43FFFFFF
We are facing some issue with the uboot booting. We are able to see the initial uboot prints and debug prints when the stack pointer is in SRAM, but after we relocate the code from SD card to DDR and change the stack pointer to DDR we are getting junk prints on the console. Even though we have the uboot console prompt it doesn't seem to work. Whenever we give some input to the console it gives back some non-printable ASCII values.
Can anyone help me or suggest me what can be wrong here? Thanks in advance for your help.
I have emailed the same to the U-Boot mailing list, but so far there is no response.
Please see the console log:
initcall: 00005cdc
initcall: 00009a84
initcall: 00005ccc
initcall: 00005fbc
initcall: 000060c0
initcall: 00000418
initcall: 00006090
initcall: 00005fb4
malloc_simple: size=18, ptr=18, limit=400: 90000b30
malloc_simple: size=54, ptr=6c, limit=400: 90000b48
malloc_simple: size=4, ptr=70, limit=400: 90000b9c
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'root_driver'
   - not found
initcall: 00006088
initcall: 000010b0
initcall: 000004a8
initcall: 0000f77c
env_init: Environment nowhere init done (ret=0)
initcall: 00005f88
initcall: 0000f0dc
initcall: 000147c0
 U-Boot 2018.09 (Nov 01 2018 - 18:33:40 +0530)
 initcall: 00005eac
 U-Boot code: 00000000 -> 00024604  BSS: -> 00030608
 initcall: 00000438
 CPU: SoC Version 0.01
 CPU clock:        75MHz
 SDRAM clock:      75MHz
 initcall: 00006470
 initcall: 00005f70
 DRAM:  initcall: 000010ec
 SDRAM Reg 000 : ffffffff
 EDAC Reg  004 : ffffffff
 SDRAM Reg 100 : ffffffff
 EDAC Reg  104 : ffffffff
 EMC Reg       : 1ff
 initcall: 00006178
 Monitor len: 00030608
 Ram size: 04000000
 gd->relocaddr : 44000000
 Ram top: 44000000
 initcall: 00005cfc
 initcall: 00006098
 initcall: 00005d14
 initcall: 000060a0
 initcall: 00005e44
 Reserving 193k for U-Boot at: 43fcf000
 initcall: 00005e18
 Reserving 1152k for malloc() at: 43eaf000
 initcall: 00005f1c
 Reserving 80 Bytes for Board Info at: 43eaefb0
 initcall: 000060a8
 initcall: 00005de4
 Reserving 200 Bytes for Global Data at: 43eaeee8
 initcall: 00005d5c
 initcall: 000060b0
 initcall: 000060c8
 initcall: 000061f4
 gd->relocaddr : 43FCF000
 initcall: 00005d1c
 initcall: 000060dc
 RAM Configuration:
 Bank #0: 40000000 64 MiB
 DRAM:  64 MiB
 initcall: 00005d40
 New Stack Pointer is: 43eaeec0
 initcall: 00005ed8
 initcall: 000060b8
 initcall: 00005fd0
 __image_copy_start : 00000000
 __image_copy_end : 00024604
 gd copied successfully to new gd...
 Relocation Offset is: 43fcf000
 Relocating to Addr 43fcf000, new gd at 43eaeee8, sp at 43eaeec0
 Current Stack Pointer 90000a60
 rrrr    ccccooooeeee4444eeeettttllll44445555ttttllll44445555ttttllll00006666eeeeaaaa    44445555))))ENABLE CACHESWARNING: Caches not enabled
 ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))----ooooaaaaccccuuuu    7777tttt((((BBBBnnnneeeeyyyy4444ffff----4444ffffffffmmmmoooo    44449999----44449999
 ttttllll00005555eeeeaaaa    44444444))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))aaaaffff____iiiibbbbeeee0000
 aaaaffff____iiiibbbbeeee0000----    ''''ttttiiii''''----ttttuuuuttttllll00001111eeeeaaaa    44440000))))IIII::::aaaaiiii
 ttttllll0000aaaaeeeeaaaa    44449999))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))    nnnn    RRRR----BBBB        4444ffffttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))MMC:   ttttllll00006666eeeeaaaa    44445555))))nnnneeeellllnnnnoooonnnniiiimmmm    oooommmmccccNNNNooooccccaaaa        ::::ooooddddhhhhoooooooooooonnnniiiiEEEE::::ooooddddhhhhoooooooooooonnnntttt    hhhhbbbb    44442222bbbb====00000000aaaaHHHH    llllNNNN
 eeeebbbb,,,,llll::::eeee    BBBB    mmmmeeeebbbb,,,,dddd::::eeee    BBBB    mmmmEEEE    llll44442222    llll1111    4444ffff        eeeeoooo    uuuueeee    BBBB    mmmm""""EEEE    eeeetttt    4444ffffEEEE    eeeettttllll00006666eeeeaaaa    44445555))))ttttllll0000aaaaeeeeaaaa    44449999))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00008888eeeeaaaa    44447777))))In:    iiii4444ffff
 Out:   iiii4444ffff
 Err:   iiii4444ffff
 tttt    uuuuoooorrrr3333aaaaaaaa        cccctttt    uuuuoooorrrr3333aaaaaaaa        cccctttt    uuuuoooorrrr3333aaaaaaaa        ccccttttllll0000ddddeeeeaaaa    4444ffff))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))ttttllll00006666eeeeaaaa    44445555))))Net:       ttttiiiiiiiiSSSSppppNo ethernet found.
 ttttllll00006666eeeeaaaa    44445555))))tttt    uuuuoooorrrr3333aaaaaaaa        cccc    nnnnoooonnnneeeebbbbddddyyyy
     nnnnoooobbbbcccc""""DDDDNNNN""""Uboot >
 Uboot >
 Uboot >
 Uboot >
 Uboot >
 Uboot >
 Uboot >
 Uboot >
  • I cannot tell what's the root cause in a simple word. But from the symptom you mentioned, it looks like the stack is corrupted after Uboot is relocated to SP=90000a60. So although the uboot prompt is showed, when you execute any uboot console commands, it messes up.

    If you have a debugger such as DS-5 debugger, it may be easier to debug further. If you do not have, it may be a bit difficult. What I can suggest is to compare the SRAM content before relocation and the DDR content after the relocation, especially for the stack part.

  • The adr instruction is based on the assumption that your pc contains 0x8008 at the time that you execute it. The ldr is going to pull in a link time value which is the same no matter where you are.

    If for example this code is actually located at address 0x20000000 then when that first instruction (the adr is a pseudo instruction, in the disassembly it is a sub of 8), the adr, is executed now you get a 0x20000008-8 = 0x20000000 and you compare that with 0x8000 they dont match. If you are running the code at 0x8000 then 0x8008-8 = 0x8000 and the two match.

    Just read the code and look up the adr instruction (or do what I did and just try it and examine the output of the compiler/tools, and/or run it on hardware if that doesnt show the answer).


More questions in this forum