Can't Modify U-Boot Environment Variables on Updated Firmware

Jump to: navigation, search

I have done so. It looks like my problem is similar to the "Firmware update hangs" thread below except that I can actually get the firmware update to happen. The update obviously doesn't work though since U-Boot doesn't load when it should.

01:57, 18 July 2017

I have the same h3ulcb board(RTP0RC77951SKBX010SA00) as you. I updated the loader but it started normally.

[    0.000194] NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14
[    0.005761] NOTICE:  BL2: PRR is R-Car H3 Ver2.0
[    0.010335] NOTICE:  BL2: Board is unknown Rev0.0
[    0.015006] NOTICE:  BL2: Boot device is HyperFlash(80MHz)
[    0.020445] NOTICE:  BL2: LCM state is CM
[    0.024423] NOTICE:  BL2: AVS setting succeeded. DVFS_SetVID=0x52
[    0.030611] NOTICE:  BL2: DDR3200(rev.0.22)NOTICE:  [COLD_BOOT]NOTICE:  ..0
[    0.091235] NOTICE:  BL2: DRAM Split is 4ch
[    0.095121] NOTICE:  BL2: QoS is default setting(rev.0.14)
[    0.100621] NOTICE:  BL2: Lossy Decomp areas
[    0.104798] NOTICE:       Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570
[    0.111883] NOTICE:       Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0
[    0.118795] NOTICE:       Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0
[    0.125709] NOTICE:  BL2: v1.3(release):4eef9a2
[    0.130199] NOTICE:  BL2: Built : 10:20:37, Jul 19 2017
[    0.135386] NOTICE:  BL2: Normal boot
[    0.139028] NOTICE:  BL2: dst=0xe6320190 src=0x8180000 len=512(0x200)
[    0.145574] NOTICE:  BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800)
[    0.152037] NOTICE:  BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000)
[    0.159261] NOTICE:  BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000)
[    0.169741] NOTICE:  BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000)


U-Boot 2015.04 (Jul 19 2017 - 10:20:39)

CPU: Renesas Electronics R8A7795 rev 2.0
Board: H3ULCB
I2C:   ready
DRAM:  3.9 GiB
MMC:   sh-sdhi: 0, sh-sdhi: 1
In:    serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot:  0
=>

However, the following are different.

[    0.100623] NOTICE:  BL2: Lossy Decomp areas
[    0.104798] NOTICE:       Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570
(snip)

It seems that you changed something. At first, could you build according to procedure of elinux?

18:31, 18 July 2017

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:R-Car/Boards/Yocto-Gen3/Can't Modify U-Boot Environment Variables on Updated Firmware/reply (4).

Yes. One thing that wasn't clear to me was where to actually get those files. I've been using the ones that are found in ~/tmp/deploy/images/h3ulcb/ after building yocto. Assuming that's the correct path, I'm going to try rebuilding yocto in case I messed something up in that process.

One possible indication of what the issue is: I looked through the Renesas Device Manual https://www.renesas.com/en-us/doc/products/rcar/R-Car_StarterKit_Gen3_H3_M3_DEV_Rev.053.pdf to find a solution and found that in the section on booting the addresses the board boots from are slightly different from those on the e-linux wiki (looking at page 238 in particular). I'm a machine learning guy by trade and my architecture knowledge is rather scant comparatively so maybe this is nothing/not what I thought it means.

00:10, 19 July 2017

Yes, /tmp/deploy/images/h3ulcb is correct path. Please refer to the No13 of http://elinux.org/R-Car/Boards/Yocto-Gen3#Building_the_BSP_for_Renesas_H3ULCB.2C_M3ULCB.

All updating methods are described below. http://elinux.org/R-Car/Boards/H3SK#Flashing_firmware Could you try again?

If "u-boot" still doesn't start up please attach the log when flashing the firmware.

04:03, 21 July 2017

Rebuilding the whole thing from scratch worked. Something must have gone wrong in the initial build because the .dtb file sizes between the two builds were off by a few hundred bytes.

23:38, 22 July 2017