This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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 >
Parents
  • Hello ,

    In our case, the issue was with the SDRAM controller implemented on the FPGA. It had been configured to allow only 32bit access resulting in 8-bit and 16-bit accesses failing. To showcase this issue I kept the stack and heap in the internal SRAM itself and restricted the static and dynamic allocations inside the code to minimal so as to fit inside the SRAM. After these tweaks, all the string prints including the prompt were proper. 

    The SDRAM controller was later reconfigured to allow 8,16 and 32-bit access and everything worked fine for us.

    Hope you can resolve your issue ASAP. Best of luck.

    Regards,

    Amar

Reply
  • Hello ,

    In our case, the issue was with the SDRAM controller implemented on the FPGA. It had been configured to allow only 32bit access resulting in 8-bit and 16-bit accesses failing. To showcase this issue I kept the stack and heap in the internal SRAM itself and restricted the static and dynamic allocations inside the code to minimal so as to fit inside the SRAM. After these tweaks, all the string prints including the prompt were proper. 

    The SDRAM controller was later reconfigured to allow 8,16 and 32-bit access and everything worked fine for us.

    Hope you can resolve your issue ASAP. Best of luck.

    Regards,

    Amar

Children
No data