LS2085A: Starting up U-Boot on custom board

[ramasubramanian]

Hi,

We are able to establish JTAG connection to our target.  We flashed our PBL.bin and U-boot.bin to the flash.  We verified the contents in the flash by dumping the flash contents after power on reset.  We changed the jumper settings to load the RCW from NOR flash.  But we could not see the U-boot starting up.

We compared the RCW format that we dumped from RDB and that we programmed on our target.  We can see the difference which can be attributed to the clock speed configuration.  Rest all looks similar. 

Is there a way to check where the issue is? 

Regards

Rams

[marius_grigoras]

Hi Rams,

1. Please make sure you "erased" the flash memory zone before any write (this can be done using "--erase" parameter in conjunction with fl_write or from FP GUI using erase check.

2. Also, please note that on our RDB board the u-boot is using the second UART port (UART2) by default - the top one.

bootargs=console=ttyS1,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0600 ramdisk_size=0x2000000 default_hugepagesz=2m hugepagesz=2m hugepages=256

ttyS1 is for UART2 port

ttyS0 is for UART1 port

3. Also, you can try to erase using the CW FP the portion between 0x20_0000 and 0x30_0000 flash (this will erase the u-boot env zone - maybe is something corrupted there; erasing this part will force the u-boot to regenerate the environment zone).

Thank you,

Marius

[ramasubramanian]

Hello,

It seems that we are stuck in RCW loading phase when trying to boot from flash.

We compared reading of RCW with both RDB and our board and below are the dump.

RDB:

(bin) 68 % config cc cwtap:10.10.48.78

(bin) 69 % show cc

0: CodeWarrior TAP (cwtap:10.10.48.78) CC software ver. {0.0}

(bin) 70 % ccs::config_chain {ls2085a dap}

(bin) 71 % display ccs::read_reg 0 rcw_src 1

rcw_src=0x00000025

(bin) 72 % disp ccs::read_reg 0 0x1000 4

rcw1=0x48303830 rcw2=0x48480048 rcw3=0x00000000    rcw4=0x00000000

(bin) 73 % disp ccs::read_reg 0 0x1004 4

rcw5=0x00000000 rcw6=0x00200000 rcw7=0x00200000    rcw8=0x00000000

(bin) 74 % disp ccs::read_reg 0 0x1008 4

rcw9=0x00C12980 rcw10=0x00002580 rcw11=0x00000000 rcw12=0x00000000

(bin) 75 % disp ccs::read_reg 0 0x100c 4

rcw13=0x00000E0B rcw14=0x00000000 rcw15=0x00000000 rcw16=0x00000000

(bin) 76 % disp ccs::read_reg 0 0x1010 4

rcw17=0x00000000   rcw18=0x00000000   rcw19=0x00000000   rcw20=0x00000000

Our:

(bin) 68 % config cc cwtap:10.10.48.78

(bin) 77 % show cc

0: CodeWarrior TAP (cwtap:10.10.48.78) CC software ver. {0.0}

(bin) 78 % ccs::config_chain {ls2085a dap}

(bin) 79 % display ccs::read_reg 0 rcw_src 1

rcw_src=0x00000025

(bin) 80 % disp ccs::read_reg 0 0x1000 4

rcw1=0x00000000 rcw2=0x00000000 rcw3=0x00000000    rcw4=0x00000000

(bin) 81 % disp ccs::read_reg 0 0x1004 4

rcw5=0x00000000 rcw6=0x00000000 rcw7=0x00000000    rcw8=0x00000000

(bin) 82 % disp ccs::read_reg 0 0x1008 4

rcw9=0x00000000 rcw10=0x00000000 rcw11=0x00000000 rcw12=0x00000000

(bin) 83 % disp ccs::read_reg 0 0x100c 4

rcw13=0x00000000 rcw14=0x00000000 rcw15=0x00000000 rcw16=0x00000000

(bin) 84 % disp ccs::read_reg 0 0x1010 4

rcw17=0x00000000 rcw18=0x00000000 rcw19=0x00000000 rcw20=0x00000000

As per our understanding, the first 1MB is for RCW and PBL and the U-boot starts from the second MB.  We programmed the flash in similar way we program the RDB.  Do you see any issue why rcw is all zero?

Regards

Rams

[yipingwang]

Hello Rams,

Probably you modified CW initialization file as "useSafeRCW = True" to use hardcoded RCW when used CW to to connect the target. In the default CW configuration, CW from NOR will be used, which should cause CW failed to connect to the target board. Actually I suggest you change this configuration back as the default after flash programming to verify your RCW configuration during the bringing up.

I suggest you use QCVS tool to generate your PBL file(RCW+PBI) then flash it to NOR Flash. You could download Linux SDK pre-built image ISO, get the PBL file for ls2085ardb board, then import this file in QCVS tool  and modify the configuration according to your target board, and regenerate the PBL file again.

For Flash programming, you could use the script provided by Marius, or refer to the section "

Chapter 7 Flash Programmer" in the document C:\Freescale\CW4NET_v2015.08\CW_ARMv8\ARMv8\Help\PDF\ARMv8_Targeting_Manual.pdf.

If your problem remain, would you please provide the console log to us to do more investigation.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ramasubramanian]

Hello,

Thanks a lot for your support.  We are also in touch with our FAE and getting help to dump the flash.

We are using S70GL02GS 2Gbit NOR flash and the flash programmer supports S29GL01GP NOR flash.  Is S70GL02GS compatible in terms of S29GL01GP device?

Kindly clarify.  If not, then what we need support for programming S70GL02GS NOR flash.

Thanks

Rams

[ramasubramanian]

Hello,

This is what we read when we dump 0x30000000.  The content of the flash as read from 0x30000000 does not reflect the actual PBL image we programmed. When we use the flash programmer tool to dump, we see that the content matches.

(bin) 39 % disp ccs::read_mem 3 0x30000000 4 0 0x60

                  +0      +4      +8      +C

[0x30000000] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000010] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000020] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000030] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000040] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000050] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000060] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000070] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000080] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000090] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000A0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000B0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000C0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000D0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000E0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x300000F0] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000100] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000110] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000120] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000130] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000140] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000150] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000160] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

[0x30000170] 12FF12FF 12FF12FF 12FF12FF 12FF12FF

Regards

Rams

[marius_grigoras]

Hi Rams,

Possible problems:

1. Flash is not correctly connected to the board/SoC controller

2. NOR flash initialization is not correct in the gdb python initialization (check the IFC settings)

3. Or your NOR flash is not compatible with our supported NOR flash - I'll discuss this topic with my team.

Thank you,

Marius

[ramasubramanian]

Hi Marius,

Could you please elaborate on the second point?  I am unable to find IFC settings in gdb python initialization.

2. NOR flash initialization is not correct in the gdb python initialization (check the IFC settings)

Thanks

Rams

[marius_grigoras]

Hi Rams,

Basically I need the content of Init_IFC() function from the gdb python script (double click on the TCC and this file will be opened).

Thank you,

Marius

[ramasubramanian]

Hello,

Thanks for excellent back end support from NXP.  We got RCW loading phase working.  We got further with U-boot starting in flash.  Our custom board has fixed DDR.  We ran DDR validation tool and we will be running more DDR tests with the help of NXP support tomorrow. LS2085A RDB has DIMM and the u-boot startup and relocation to RAM may not work on other custom board.  Please correct me if I am wrong.  Our U-boot stops in memcpy function in reloc_fdt() in board_f.c

We have added fixed sdram init for our board

The LS2085A RDB dram init code has something like which is not in use for fixed_sdram setup for our board

gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;

    if (gd->ram_size > CONFIG_SYS_LS2_DDR_BLOCK1_SIZE) {

	gd->bd->bi_dram[0].size = CONFIG_SYS_LS2_DDR_BLOCK1_SIZE;
	gd->bd->bi_dram[1].start = CONFIG_SYS_DDR_BLOCK2_BASE;
	gd->bd->bi_dram[1].size = gd->ram_size -
				CONFIG_SYS_LS2_DDR_BLOCK1_SIZE;

#ifdef CONFIG_SYS_MEM_RESERVE_SECURE

	gd->secure_ram = gd->bd->bi_dram[1].start +
			gd->secure_ram -
			CONFIG_SYS_LS2_DDR_BLOCK1_SIZE;
	gd->secure_ram |= MEM_RESERVE_SECURE_MAINTAINED;

#endif

    }

Do we need to do any special customization for custom board.  We dont know if we are missing something in setting up the dram size and relocation address correctly.

Thanks

Rams

[marius_grigoras]

Hi Rams,

I guess you have tried to use the FP from CW to erase and write your images.

After you connect to the board, can you please try to read from 0x30000000 address using CW and let us know the output? (you can use the gdb cmd line or the memory view).

Thank you,

Marius

[marius_grigoras]

Hi Rams,

I discussed with the team and we never reproduced this scenario with all rcw bits being 0x0.

You said above that you used the hardcoded RCW - are you sure that right now you disabled correctly the hardcoded RCW? The source (25) is ok..NOR 16bits, but maybe you're missing something related to it.

Regards,

Marius

[marius_grigoras]

I'm using a script like this for flashing my SDK images using the flash programmer from CW for ARMv8. Indeed, the first 1MB is for RCW and the second one is for U-boot, according with the u-boot flash memory map.

[ramasubramanian]

Hello Marius,

Thanks.  We are going to monitor the address and data lines during flash accesses.

We could not find any reset sequence and flow diagram in the documentation.  Do you have any internal documentation explaining the reset flow diagram for LS2085A?

Like after POR, start -> SP loading RCW -> DDR init.. PLL init ->Pre Boot initialization - Jump to Flash @Addr -> Starting U-boot  ...etc.  If something fails in between, can we look at other registers to know the status of the CPU.  Without these, it is very hard to debug bareboard.

When RCW is configured to boot from flash, how does it jump to vbank0 @0x58000_0000?

We just have codewarrior documentation and high level u-boot debugging in ARM targeting manual.  That does not seem to help us during this stage.

Regards

Rams

[marius_grigoras]

Hi Rams,

I don't have any public doc explaining the reset flow, but please submit a new case to nxp.com (will be contacted to sign a NDA and mostly will get that doc to see more details) or contact your local FAE.

But long story short, the booting process is:

1. SP boot

- comes out of reset in secure-privileged state

- fetches instruction at 0x0 (reset vector)

- writes BLP register (very useful for GPP)

- releases GPP boot core via BRR register

- executes wfi (wait for interrupt)

2. GPP boot

- comes out of reset in secure (EL3) state

- brancy to secondary boot loader address found in BLP

- and now the u-boot code will make the IFC and DDR initialization (and of course other peripherals) and will relocate itself to DDR (main memory).

Regarding your question about how the u-boot will know to jump just after reset to 0x58000_0000 - this is a good question and the answer is simple: the memory-map for this SoC is hardcoded. Take a look at the chapter 2.2 from RM (System Memory Map) - you can see the IFC Region can be accessed from 0x3000_0000 and also from 0x5_8000_0000.

At boot time, based on the default CPSR (0x101) and AMASK (0x0) values you can access the NOR windows from multiple ranges.

x 0x30000000

0x30000000: 0xaa55aa55

x 0x38000000

0x38000000: 0xaa55aa55

x 0x588000000

0x588000000: 0xaa55aa55

x 0x580000000

0x580000000: 0xaa55aa55

x 0x500000000

0x500000000: 0x00000000

x 0x598000000

0x598000000: 0xaa55aa55

x 0x5A8000000

0x5a8000000: 0xaa55aa55

Also, quoting from LS2085A RM:

"For NOR boot, CS0 works as the boot chip-select. Therefore, during NOR boot, the external device should be connected on CS0. Before fetching the first instruction from an external device (NOR flash), the IFC flash timing registers are loaded with default timing parameters."

"CSPR0: Only chip-select 0 is used for booting. PS, MSEL[1], and TE is obtained from the configuration word when boot_load/rcw_load occurs. V will be set for CSPR0 when boot_load/rcw_load occurs with valid port size."

Regards,

Marius

[yipingwang]

Hello Rams,

CodeWarrior initialization file and the flash programmer could be executed successfully on your target board, it indicates that the basic hardware configuration of the target board is fine.

Probably there is problem with porting u-boot to the custom board, please pay attention to files include/configs/ls2085a_common.h and board/freescale/ls2085a/ls2085a.c.

I suggest you use CodeWarrior for ARMv8 to debug u-boot step by step to find where the issue is.

After install CodeWarrior for ARMv8, please refer to the section "8.1 U-Boot debug" in C:\Freescale\CW4NET_v2015.08\CW_ARMv8\ARMv8\Help\PDF\ARMv8_Targeting_Manual.pdf to debug u-boot.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------