Flashing firmware procedure WS3.0

Hello, are there any updates in the procedure compared to the ws1.0, ws1.1, ws2.0 described in https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware?

I tried basically all above mentioned switch combinations but I can't get to prompt. My final goal is to flash the FreeRTOS for the CR7. According to the "R-Car Gen3 CR7 FreeRTOS Software - Release Note" document this would be the last step in the Firmware update (not mentioned on the elinux page though).

With the SW1 On, SW6 all ON switch combo I can start our Linux (I can provide more startup log details if required). Thank you.

  • Hello
    Please tell us your board type name and serial Nnumber.
  • In reply to gohda:

  • In reply to albert:

    Hi Albert-san

    Thank you for your information.
    It is H3 v3.0 SK (DDR8GiB).

    Please refer to the "In case of DDR 8GiB board" procedure in elinux.org/.../H3SK

    If you can't get to prompt, please attach the all logs.
  • In reply to gohda:

    Hello Gohda-san

    Thank you for your help. That elinux section provides the same procedure for both 4GiB and 8GiB boards, the difference I see is only in the file tables to be used for flashing. So I'm still not able to get the prompt therefore I provide you the log I see when starting the board with the following switch/jumper setup:
    SW1 - ON, SW6 - all ON, JP1 1-2 short (the other switch combinations result an empty console without prompt)

    (just a slightly relevant extra info here, we have also a ws2.0 board, with that one I have no problems to get to the point where the xls2 command requests the inputs)

    Thanks again
    [ 0.000149] NOTICE: BL2: R-Car H3 Initial Program Loader(CA57)
    [ 0.004586] NOTICE: BL2: Initial Program Loader(Rev.2.0.4)
    [ 0.010119] NOTICE: BL2: PRR is R-Car H3 Ver.3.0
    [ 0.014788] NOTICE: BL2: Board is Starter Kit Rev.2.0
    [ 0.019900] NOTICE: BL2: Boot device is HyperFlash(80MHz)
    [ 0.025327] NOTICE: BL2: LCM state is CM
    [ 0.029368] NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x53
    [ 0.035343] NOTICE: BL2: CH0: 0x400000000 - 0x47fffffff, 2 GiB
    [ 0.041205] NOTICE: BL2: CH1: 0x500000000 - 0x57fffffff, 2 GiB
    [ 0.047080] NOTICE: BL2: CH2: 0x600000000 - 0x67fffffff, 2 GiB
    [ 0.052955] NOTICE: BL2: CH3: 0x700000000 - 0x77fffffff, 2 GiB
    [ 0.058845] NOTICE: BL2: DDR3200(rev.0.37)
    [ 0.074173] NOTICE: BL2: [COLD_BOOT]
    [ 0.083746] NOTICE: BL2: DRAM Split is 4ch(DDR f)
    [ 0.087045] NOTICE: BL2: QoS is default setting(rev.0.11)
    [ 0.092489] NOTICE: BL2: DRAM refresh interval 1.95 usec
    [ 0.097846] NOTICE: BL2: Periodic Write DQ Training
    [ 0.102874] NOTICE: BL2: Lossy Decomp areas
    [ 0.107004] NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570
    [ 0.114089] NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0
    [ 0.121001] NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0
    [ 0.127916] NOTICE: BL2: v1.5(release):236f8fb-dirty
    [ 0.132924] NOTICE: BL2: Built : 06:15:00, Nov 26 2019
    [ 0.138112] NOTICE: BL2: Normal boot
    [ 0.141752] NOTICE: BL2: dst=0xe6324100 src=0x8180000 len=512(0x200)
    [ 0.148140] NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800)
    [ 0.154760] NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000)
    [ 0.161986] NOTICE: BL2: dst=0x44100000 src=0x8200000 len=1048576(0x100000)
    [ 0.176810] NOTICE: BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000)
    [ 0.190785] NOTICE: BL2: Booting BL31

    U-Boot 2018.09 (Nov 01 2019 - 13:59:24 +0000)

    CPU: Renesas Electronics R8A7795 rev 3.0
    Model: Renesas H3ULCB board based on r8a7795 ES2.0+ with 8GiB (4 x 2 GiB)
    DRAM: 7.9 GiB
    Bank #0: 0x048000000 - 0x0bfffffff, 1.9 GiB
    Bank #1: 0x500000000 - 0x57fffffff, 2 GiB
    Bank #2: 0x600000000 - 0x67fffffff, 2 GiB
    Bank #3: 0x700000000 - 0x77fffffff, 2 GiB

    Flash: 64 MiB
    MMC: sd@ee100000: 0, sd@ee140000: 1
    Loading Environment from MMC... OK
    In: serial@e6e88000
    Out: serial@e6e88000
    Err: serial@e6e88000
    Net: eth0: ethernet@e6800000
    Hit any key to stop autoboot: 0
    18463232 bytes read in 406 ms (43.4 MiB/s)
    72377 bytes read in 7 ms (9.9 MiB/s)
    ## Flattened Device Tree blob at 48000000
    Booting using the fdt blob at 0x48000000
    Using Device Tree in place at 0000000048000000, end 0000000048014ab8

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.75-ltsi-yocto-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP PREEMPT Thu Dec 5 19:53:41 UTC 2019
    [ 0.000000] Boot CPU: AArch64 Processor [411fd073]
    [ 0.000000] Machine model: Renesas H3ULCB board based on H3ULCB + with 8GiB (4 x 2 GiB)
  • In reply to albert:

    Hi Albert-san
    Thank you for your reply.

    Is your question that Minimonitor doesn't start?
    If yes, please check the following settings to start Minimonitor.
    SW6[1]=ON, SW6[2]=ON, SW6[3]=OFF, SW6[4]=ON
    If Minimonitor still doesn't start, you may have accidentally destroyed Minimonitor.
    Please contact a vendor.
  • In reply to gohda:

    Hi Albert-san

    How's this issue?
    I would like to close if resolved.
  • In reply to gohda:

    Hello Gohda-san

    I still couldn't contact a vendor, the problem persists with my WS3.0 board.
    Meanwhile I double-checked the elinux wiki, it has been updated, now it is official that the WS3.0 has the exact same procedure as the WS2.0 so I guess you can close the issue (unless you can give some info how to restore the Minimonitor on my own).

    I think, however, that we could use this issue to learn something valuable from it. You wrote above:
    "you may have accidentally destroyed Minimonitor".
    Is there a known (maybe undocumented or not so easy to find) way to destroy the Minimonitor? Some forbidden switch/jumper combination, settings etc. ? Me personally didn't do anything unusual with this WS3.0 board, just tried it like my other board (WS2.0) which works as expected.

    Thank you!
  • In reply to albert:

    Hi Albert,

    Below is how to write the loader without MiniMonitor:


    I think that it's possible to write loader unless board is broken.

    Could you try this method?

  • In reply to albert:

    Hi albert,

    Do you have any updates?

    If this issue has been solved,
    can we close this question?