This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

boot hangs in 1st stage

Guru 20755 points

Hello,

I'm working with custom board with DM8148, and trying to boot from uart, but the 1st stage get hangs after "CCC.."
I have following instuction in 
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/336530/1175460.aspx
inorder to skip ddr config, but it still hangs.
I also tried this with EVM8148, and got same results. Is there something missing with that instructions?

What else should I try ?
How can I reduce DDR frequency ?

Thanks for suggestion,
Ran

  • Ran,

    Ran S. said:
    I also tried this with EVM8148, and got same results.

    Please go through the steps described in the below post:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/284046/997063.aspx#997063

    Note that there is no "CCCC..." when you load and run the 1st stage bootloader.

    Please try also with my u-boot.min.uart (attached in the post).

    Best regards,
    Pavel

  • Hi Pavel,


    Thanks very much.
    I tried the u-boot.min.uart you have attached, but still with no result.
    I have EVM board right beside the custom board, and with that everything is successful.
    Things get harder when I use the custom board. There is no print at all in 1st stage,
    So I would like to know how the best to continue from here:
    1. should I add print in 1st stage u-boot to see where it hangs (is that possible).
    2. should I try not to configure nand to see if that;s the problem ? (I following instruction for that in 
    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/336530/1175460.aspx
    B
    ut got no result)
    3. should I try to change frequency or configuration of nand ?
    4. Is there some way to use CCS to debug 1st stage failure ?

    I would appreciate any advise and guidelines.

    Thanks!
    Ran

  • I also tried to flash u-boot with CCS, but I get failure when trying to load the flash utility (binary) into memory:

    CortexA8: Output: **** DM8148 ALL ADPLL INIT IS In Progress .........
    CortexA8: GEL Output: A8 ADPLLJ CLKOUT value is = 600
    CortexA8: GEL Output: L3 ADPLLJ CLKOUT value is = 200
    CortexA8: GEL Output: DSP ADPLLJ CLKOUT value is = 500
    CortexA8: GEL Output: DSS ADPLLJ CLKOUT value is = 200
    CortexA8: GEL Output: HDVICP ADPLLJ CLKOUT value is = 266
    CortexA8: GEL Output: SGX ADPLLJ CLKOUT value is = 200
    CortexA8: GEL Output: USB ADPLLJ CLKOUT value is = 192
    CortexA8: GEL Output: VIDEO-0 ADPLLJ CLKOUT value is = 54
    CortexA8: GEL Output: VIDEO-1 ADPLLJ CLKOUT value is = 148
    CortexA8: GEL Output: VIDEO-2/HDMI ADPLLJ CLKOUT value is = 148
    CortexA8: GEL Output: AUDIO ADPLLJ CLKOUT value is = 200
    CortexA8: Output: **** DM8148 ALL ADPLL INIT IS Done **************
    CortexA8: GEL Output: **** Configuring DDR PLL to 400 MHz.........
    CortexA8: GEL Output: DDR ADPLLJ CLKOUT value is = 400
    CortexA8: Output: **** DM8148 DDR3 EVM EMIF0 and EMIF1 configuration in progress.........
    CortexA8: Output: Busy reading back DMM registers Please wait ...
    CortexA8: Output: DMM register read successfully
    CortexA8: Output: **** DM8148 DDR3 EVM EMIF0 and EMIF1 configuration is DONE ****
    CortexA8: Output: Enabling Clock for GPMC is in Progress, Please wait.....
    CortexA8: Output: GPMC Clock is Active
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Process CIO" at 0x8000a3ac: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x8000a99c: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x80007430: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)

     

    Thanks,

    Ran

  • Ran,

    Ran S. said:
    I have EVM board right beside the custom board, and with that everything is successful.

    When one SW runs fine on the EVM and fail on the custom board, this most often is indication of custom board hardware malfunction.

    Ran S. said:
    1. should I add print in 1st stage u-boot to see where it hangs (is that possible).

    All the below are messages from the 1st stage boot loader:

    U-Boot 2010.06 (Aug 16 2013 - 16:23:00)

    TI8148-GP rev 2.1

    ARM clk: 600MHz
    DDR clk: 400MHz

    DRAM:  2 GiB
    Using default environment

    The 2nd stage U-Boot will now be auto-loaded
    Please do not interrupt the countdown till TI8148_EVM prompt if 2nd stage is already flashed
    Hit any key to stop autoboot:  0
    TI-MIN#

    I do not think you can add a message before the very first message "U-Boot 2010.06 (Aug 16 2013 - 16:23:00)". 

    Ran S. said:
    2. should I try not to configure nand to see if that;s the problem ?

    I do not see how NAND is involved here (we have UART boot).

    Ran S. said:
    3. should I try to change frequency or configuration of nand ?

    I do not see how NAND is involved here (we have UART boot).

    Ran S. said:
    4. Is there some way to use CCS to debug 1st stage failure ?

    Yes. You can put a breakpoint into the 1st stage bootloader to see if your flow is going into it. There is possibility that the flow hang at the ROM code stage and thus never reach the 1st stage bootloader (u-boot.min.uart).

    Refer to the below links for more info:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/331762.aspx

    You can check at which stage your bootloader hang, with reading the trace vectors with CCStudio and JTAG. See the below links:

    DM814x TRM, section 4.12 Tracing, 4.3.2.3 RAM Exception Vectors, 4.3.2.4 Tracing Data


    http://processors.wiki.ti.com/index.php/Debug_Tips_for_DM81xx_Boot_Fail

    http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips

    http://processors.wiki.ti.com/index.php/DM814x_Hardware_Design_Guide

    http://processors.wiki.ti.com/index.php/DM814x_Software_Design_Guide

    Regards,
    Pavel

  • Ran,

    Ran S. said:
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Process CIO" at 0x8000a3ac: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x8000a99c: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)
    CortexA8: Breakpoint Manager: Retrying with a AET breakpoint
    CortexA8: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x80007430: (Error -1066 @ 0x333C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)

    Is there any breakpoint/watchpiont already there in the breakpoint window?

    If so, remove them before loading the binary.

    Regards,
    Pavel

  • Hi Pavel,

    Thanks very much.

    I tried several things as you mentioned above, but I still have difficulties.
    1. when trying to load u-boot.min.uart (compiled with -g option) I get window with message "could not determine file type) and in console window I get:
    CortexA8: GEL: Encountered a problem loading file: u-boot.min.uart Could not determine target type of file
    Is there something wrong in the sequence I'm doing:
     a. reset board
     b. load gel of DM8148
    c. run scripts:

        CortexA8: Output: **** DM8148 ALL ADPLL INIT IS In Progress ......... 
        CortexA8: GEL Output: A8 ADPLLJ CLKOUT value is = 600 
       CortexA8: GEL Output: L3 ADPLLJ CLKOUT value is = 200 
       CortexA8: GEL Output: DSP ADPLLJ CLKOUT value is = 500 
    CortexA8: GEL Output: DSS ADPLLJ CLKOUT value is = 200 
    CortexA8: GEL Output: HDVICP ADPLLJ CLKOUT value is = 266 
    CortexA8: GEL Output: SGX ADPLLJ CLKOUT value is = 200 
    CortexA8: GEL Output: USB ADPLLJ CLKOUT value is = 192 
    CortexA8: GEL Output: VIDEO-0 ADPLLJ CLKOUT value is = 54 
    CortexA8: GEL Output: VIDEO-1 ADPLLJ CLKOUT value is = 148 
    CortexA8: GEL Output: VIDEO-2/HDMI ADPLLJ CLKOUT value is = 148 
    CortexA8: GEL Output: AUDIO ADPLLJ CLKOUT value is = 200 
    CortexA8: Output: **** DM8148 ALL ADPLL INIT IS Done ************** 
    CortexA8: GEL Output: **** Configuring DDR PLL to 400 MHz......... 
    CortexA8: GEL Output: DDR ADPLLJ CLKOUT value is = 400 
    CortexA8: Output: **** DM8148 DDR3 EVM EMIF0 and EMIF1 configuration in progress......... 
    CortexA8: Output: Busy reading back DMM registers Please wait ...
    CortexA8: Output: DMM register read successfully 
    CortexA8: Output: **** DM8148 DDR3 EVM EMIF0 and EMIF1 configuration is DONE **** 
    CortexA8: Output: Enabling Clock for GPMC is in Progress, Please wait..... 
    CortexA8: Output: GPMC Clock is Active
    CortexA8: GEL: Encountered a problem loading file: D:\shared\version\u-boot.min.uart_mlo_ddr Could not determine target type of file

    d. run -> load program -> u-boot.min.uart (the address field is disabled!)


    I get this also with the EVM board, so there is probably something wrong with the sequence I'm soing above.
    Maybe the GEL scripts should be other than the mentioned above ?

    2. "Is there any breakpoint/watchpiont already there in the breakpoint window?" No there is no breakpoint when I get that message.

    Thanks,
    Ran




  • I also tried to boot u-boot.min.uart from serial ,and after getting no response in teraterm, I'm trying to connect with CCS to custom board to read registers, but get
    CortexA8: Error connecting to the target: (Error -2062 @ 0x1FE) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.232.0) 
    With EVM the boot from serial get to TI_MIN prompt, and then I can connect with CCS and read registers.
    So I can'r even read the vector registers when it hangs.

    Thanks,
    Ran

  • Ran,

    No GEL file here. The GEL file is used when we do not have u-boot, and has the same purpose. Here, we have u-boot.

    http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5#Setup_a_U-Boot_Debug_Project

    http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5#Setup_Target_Configuration

    http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5#Change_ARM_mode

    http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5#Perform_SPL_Debug

    Regards,
    Pavel

  • Hi Pavel,

    I see that both with EVM & custom board, the pc register starts doing the code of start_armboot, but with custom board the content of the memory (=instructions) is invalid as following. What might be the reason for that ?

    In custom board:

    start_armboot:
    80700514: 00004038 ANDEQ R4, R0, R8, LSR R0
    80700518: 000040EC ANDEQ R4, R0, R12, ROR #1
    8070051c: 00003000 ANDEQ R3, R0, R0
    80700520: 00008B09 ANDEQ R8, R0, R9, LSL #22
    80700524: 00008024 ANDEQ R8, R0, R4, LSR #32
    80700528: 00001000 ANDEQ R1, R0, R0
    8070052c: 00002024 ANDEQ R2, R0, R4, LSR #32
    80700530: 00000008 ANDEQ R0, R0, R8
    80700534: 000050D4 LDREQD R5, [R0], -R4
    80700538: 0000253E ANDEQ R2, R0, R14, LSR R5
    8070053c: 00001000 ANDEQ R1, R0, R0
    80700540: 00002024 ANDEQ R2, R0, R4, LSR #32
    80700544: 00002000 ANDEQ R2, R0, R0

    In EVM:
    start_armboot:
    80700514: E92D4038 STMFD R13!, {R3, R4, R5, R14}
    80700518: E59F40EC LDR R4, 0x8070060C
    8070051c: E5943000 LDR R3, [R4]
    80700520: E2438B09 SUB R8, R3, #9216
    80700524: E2488024 SUB R8, R8, #36
    80700528: E3A01000 MOV R1, #0
    8070052c: E3A02024 MOV R2, #36
    80700530: E1A00008 MOV R0, R8
    80700534: E59F50D4 LDR R5, 0x80700610
    80700538: EB00253E BL memset

    Thanks,
    Ran

  • Hi,

    Trying to do data verification after load program also fails in custom board:

    CortexA8: AutoRun: Target not run as the symbol "main" is not defined
    CortexA8: File Loader: Data verification failed at address 0x80700003 Please verify target memory and memory map.

    Is it SRAM memory that is failed ? Maybe the load to memory is failed because of GEL file ?

    What might cause such failure ?

    Thanks,
    Ran

  • Ran,

    Ran S. said:
    CortexA8: File Loader: Data verification failed at address 0x80700003

    Ran S. said:
    Is it SRAM memory that is failed ?

    No, this is DDR3_0.

    Internal RAM (OCMC RAM) is at 0x40300000 - 0x4031FFFF (128KB)

    DDR3_0 (first DDR3 controller) is at 0x80000000 - 0xBFFFFFFF (1GB)

    DDR3_1 (second DDR3 controller) is at 0xC0000000 - 0xFFFFFFFF (1GB)

    Something is wrong with your DDR3 hardware. Please check again the DM814x datasheet, section 8.13 DDR2/DDR3 Memory Controller.

    See also the EVM schematics (DDR3 part).

    Regards,
    Pavel

  • Hi,

    But I load and excute u-boot.min.uart, which is 1st stage u-boot. It does not  run from DDR as far as I understand, right ?

    the start_armboot routine should be executed before DDR initialization started, right ?

    Thanks,

    Ran

  • In Custom board each memory bank of DDR 2G, and I did not configure it. Maybe that's the issue ?

  • Ran,

    Ran S. said:
    But I load and excute u-boot.min.uart, which is 1st stage u-boot. It does not  run from DDR as far as I understand, right ?

    This is right. u-boot.min.uart runs from OCMC RAM (0x4030_0000).

    I will further check for the start_armboot routine.

    Regards,
    Pavel

  • Thanks very much Pavel,

    Ran

  • Ran,

    You can do this, but this is only for correct print of the DDR3 size in u-boot, I do not think this will fix your not-boot issue. See the below u-boot patch:

    http://arago-project.org/git/projects/u-boot-omap3.git?p=projects/u-boot-omap3.git;a=commit;h=f9ee129775caeb7dc494c5bf0f4ba69ceab34950

    Regards,
    Pavel

  • Hi Pavel,

    You're right, it did not help me resolve this issue yet, tough I made the change. As to the mem issue , I'll remember that when getting to linux. Meanwhile I still stuck in 1st stage. Please tell me if you get to any findings when checking the start_armboot issue of wrong contents.

    Thanks,

    Ran

  • Ran,

    From what I understand, start_armboot is used to switch to the 2nd stage u-boot (in DDR3 RAM).

    http://processors.wiki.ti.com/index.php/Understanding_u-boot-min_startup_for_DM814x

    The last two steps:

    1. The reset function will now relocate the code from TI_LOAD_ADDR to TEXT_ADDR
    2. The reset function branches to "start_armboot" C function, which is now at the relocated address.

    TI_LOAD_ADDR is 0x40300000 (internal RAM). start_armboot is at 0x80700528 (DDR3_0), see u-boot.map file.

    Regards,
    Pavel

  • Hi Pavel,

    Thanks very much for assistance.

    So if it's a matter of ddr configuration, I'm back to the original question...

    When I followed the instruction here: 
    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/336530/1175460.aspx
    (TEXT_BASE = 0x40310000) , even with EVM board, I did not get u-boot MIN prompt.
    Maybe I need another offset for TEXT_BASE ?

    Thanks,

    Ran

  • Hi,

    Ifwe're moving from first 64k to the next 64k of SRAM,while  u-boot.min.uart size is in my compilation is 68616  (>64k) it seems it might explain the problem, right ?
    Pavel,

    Do you have a .min version you can attach which works with the skipping ddr, so that I can verify that this is a DDR issue ?


    Regards,
    Ran

  • Ran,

    Can you attach your u-boot.min.uart file? I want to try it on my side. Please note that we have the below restrictions regarding the u-boot-MIN file size:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_UBOOT_User_Guide#Two_stage_U-Boot_design

    The size of the internal RAM in TI814X is 128KB out of which 18KB at the end is used by the ROM code. This placed a limit of 110KB on the size of the U-Boot binary which the ROM code can transfer to the internal RAM.

    U-Boot also requires some space for the stack, heap and global data during executing and this region currently needs to be setup before the TEXT_BASE of U-Boot.

    Since it is not possible to squeeze in all the functionality that is normally expected from U-Boot in < 110KB (after setting aside some space for stack, heap etc) a two stage approach has been adopted.

    Regards,
    Pavel

  • Ran,

    You can put a breakpoint just before getting into the DDR config function and see if your flow can reach it.

    u-boot/board/ti/ti8148/evm.c

    /*
     * early system init of muxing and clocks.
     */
    void s_init(u32 in_ddr)
    {
        /* TODO: Revisit enabling of I/D-cache in 1st stage */
    #if 0
        icache_enable();
        dcache_enable();
    #endif

        /*
         * Disable Write Allocate on miss to avoid starvation of other masters
         * (than A8).
         *
         * Ref DM814x Erratum: TODO
         */
        l2_disable_wa();

        /* Can be removed as A8 comes up with L2 enabled */
        l2_cache_enable();
        unlock_pll_control_mmr();
        /* Setup the PLLs and the clocks for the peripherals */
        prcm_init(in_ddr);
    #if defined(CONFIG_TI814X_CONFIG_DDR)
        if (!in_ddr)
            config_ti814x_ddr();    /* Do DDR settings */
    #endif
    }

    If you hang at config_ti814x_ddr() function, then this should be DDR issue.

    Best regards,
    Pavel

  • Hi Pavel,

    Thanks,
    I'll check that. I used the debugger with symbols but without using project with source files in CCS, so when using step by step method I saw that the first symbol I encounter was start_armboot. I did not see s_init. But I suspect that maybe the s_init is not a symbol. Anyway, I need to repeat the debugging with source files in CCS. 

    I also attached the u-boot.min.uart file I'm using. 
    8662.u-boot.min.uart.txt

    If it is a ddr issue should I proceed with the instructions in:

    http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot

    Thanks,

    Ran

  • Ran,

    Ran S. said:
    I also attached the u-boot.min.uart file I'm using. 
    8662.u-boot.min.uart.txt

    Thus u-boot.min.uart file does not work also on my side (DM814x EVM PG2.1).

    Can you check with the below u-boot.min.uart file, it is working fine on my side:

    6505.u-boot.min.uart

    Ran S. said:

    If it is a ddr issue should I proceed with the instructions in:

    http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot

    Yes

    Regards,
    Pavel

  • One more good wiki page:

    http://omappedia.org/wiki/Bootloader_Project

    Regards,
    Pavel

  • Hi Pavel,

    I'm a bit confused with this.

    I'm debugging with CCS on both EVM and custom board.
    before getting to start_armboot there is only some assembly without noticing s_init code symbol in between. Then When I get to start_armboot (first symbol I see with debugger) on EVM the assembly is correct with the code, but with custom board it is wrong. Now isn't ddr init should have been called before entering this routine ?

    With custom board the start_armboot assembly is garbage:

    start_armboot:
    80700514: 00004038 ANDEQ R4, R0, R8, LSR R0
    283 gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
    80700518: 000040EC ANDEQ R4, R0, R12, ROR #1
    8070051c: 00003000 ANDEQ R3, R0, R0
    80700520: 00008B09 ANDEQ R8, R0, R9, LSL #22
    80700524: 00008024 ANDEQ R8, R0, R4, LSR #32
    287 memset ((void*)gd, 0, sizeof (gd_t));
    80700528: 00001000 ANDEQ R1, R0, R0
    8070052c: 00002024 ANDEQ R2, R0, R4, LSR #32
    80700530: 00000008 ANDEQ R0, R0, R8

    Thanks,

    Ran

  • Hi Pavel,

    Thanks very much for support,

    I mistakenly attached previously wrong u-boot. I've attached again here the current u-boot 3362.u-boot.min.uart.txt

    It works with EVM.
    I still have some issues which make me puzulled as how to continue:

    1. trying to use u-boot in SRAM (according to instructions) fails also in EVM. I checked the size and it's less than ~60000 bytes, and the TEXT_BASE=0x40310000, as instructed.  I have no clue why it fails with this version. If you have such working version can you please send me ?
    2. trying to work with CCS , with the working EVM u-boot on EVM board:  in windows It works very strange I get to start_armboot after some assembly code , and this is the first symbol I see. I don't understand why I did not see symbol of s_init in between. It also behaves very strange when stepping inside start_armboot, the step in c code seems to jump from one line to other with no logic inside this routine. something seems bad (and all this in the working EVM u-boot MIN). When trying to work in Linux everything is very very slow, when working in CCS under ubuntu in virtualbox with XDS100v2. I could not continue with this environment becuase it hangs for couple of minutes at every operation. These are steps I'm doing in CCS:
       a. load memory ->  u-boot.min.uart file -> to address 0x40300000
       b. load symbols 0> u-boot file
    3. The DDR topology of custom board is 16bits instead of 32bits I tried to change only narrow_mode bits of SDRCR register, but still got no change.
    4.  About a less than a month ago I was working on DM8148 project, which luckily had no DDR issue and 1st u-boot loader worked without any issue at all. With this custom board, it hangs in 1st stage. The (supposed) only difference is bus width which is 16 –bits in this project. I checked with emulator and see the DDR (0x80000000 memory window) values are changing sometimes on window refresh. I've been trying to apply the guidelines for SW leveling as described in: http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot_Wordwise_SWleveling

    Meanwhile with the same seed as in the above link's example, I get each time different optimum results.
    I will check tomorrow if with the new seed from board's real CK/DQS, the SW leveling application windows results will be stable, or with same unstable windows.
    5. Another difficulty is that in http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot it is said that 16-bit interface should do word sw leveling (not BYTE sw leveling), but when I'm trying to use the result in u-boot, I see that u-boot driver uses byte leveling results....

    I would appreciate any suggestions as to how to continue from here.


    Thanks,
    Ran

  • Hi Pavel,

    I eventually succeeded with working in 250Mhz after intensive work with emulator , and booting MLO from serial !
    Thanks very much for help and guidance, it is very valuable !!!
    The next issue will be to try to get to 400Mhz , and config the LISA as required(I will open another thread for that)
    This are the steps I did:
    1. connecting with JTAG and using DM8148_EVM gel for configuration with DDR 400Mhz of DDR and than observing memory. I saw that 0x80000000 is not stable (every refresh)

    2. trying to execute word sw leveling with 400mhz - did not give same results each iteration
    3. Getting lower to 333Mhz - did not work.
    4, config DDr to 250Mhz (I had to add script for that in GEL) - now I saw that it is stable
    5. unfortunately there is no DDR test in script, I added such script and made test - OK
    6. porting the values to u-boot - problematic because u-boot of dvr rdk uses byte phy register values ( instead of word register sw leveling) . I had to patch the code  - then it worked !!!!

    Thanks

    Ran