NanoPC-T4 will not boot image made with current build script [bug]


Recommended Posts

So I noticed my NanoPC-T4's will not boot an image made with the latest armbian build script. I did a binary search on the commits and tracked down the breaking change:

commit 75d0f64e3d75e7c34466871b9723ef1a238609d8		<- THIS COMMIT AND ANYTHING AFTER IS BROKEN
Author: Piotr Szczepanik <piter75@gmail.com>
Date:   Fri Apr 17 21:30:37 2020 +0200

    Switch rk3399 to u-boot v2020.04 (#1873)
    
    * Switched rk3399 to u-boot 2020.04-rc4
    * Switched rk3399 u-boot to v2020.04, synchronized configs
    * Updated to u-boot v2020.04 final
    * Fixed OrangePi 4 device tree reference

commit cc98ba3c0d3ff8d84ed08bfbf691b3bc94a6bc2b		<- THIS BOOTS FINE
Author: Igor Pečovnik <igorpecovnik@users.noreply.github.com>
Date:   Fri Apr 17 21:29:06 2020 +0200

    Disable MESA on bionic (#1895)
    
    Also enable xfce4 power manager on some boards
    
    Signed-off-by: Igor Pecovnik <igor.pecovnik@gmail.com>


I checked the output on the serial console, it looks like the board gets stuck in an infinite boot loop:

######## POWER ON BOARD ########

DDR Version 1.24 20191016
In
Channel 0: LPDDR3, 800MHz
CS = 0
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x6
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
CS = 1
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x6
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB
Channel 1: LPDDR3, 800MHz
CS = 0
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x6
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
CS = 1
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x6
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA0DAA0, stride = 0xD
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 248
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996026, cmd 0x83a
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996025, cmd 0x83a
emmc reinit
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996026, cmd 0x83a
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996027, cmd 0x83a
emmc reinit
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996021, cmd 0x83a
mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996022, cmd 0x83a
SdmmcInit=2 1
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=128001MB
FwPartOffset=2000 , 0
StorageInit ok = 121149
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
hdr 0000000003380880 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

Load OK, addr=0x200000, size=0xad9e8
RunBL31 0x40000
NOTICE:  BL31: v1.3(debug):42583b6
NOTICE:  BL31: Built : 07:55:13, Oct 15 2019
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    plat_rockchip_pmu_init(1190): pd status 3e
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will reK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2020.04-armbian (Apr 26 2020 - 00:46:29 +0000)

SoC: Rockchip rk3399
Reset cause: POR
Model: FriendlyElec NanoPC-T4
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... *** Warning - No block device, using default environment

"Synchronous Abort" handler, esr 0x96000045
elr: 0000000000231550 lr : 00000000002314ec (reloc)
elr: 00000000f4576550 lr : 00000000f45764ec
x0 : 00000000f254a3c0 x1 : 00000000f8000000
x2 : 00000000f82a4000 x3 : 0000000000000000
x4 : 0000000011b3dc40 x5 : 0000000011b3dc40
x6 : 00000000ffffdff1 x7 : 0000000000000128
x8 : 0000000000000129 x9 : 0000000000000008
x10: 0000000000000008 x11: 0000000000000001
x12: 000000000000012a x13: 0000000000005dc0
x14: 0000000000000000 x15: 00000000f252d698
x16: 0000000000008080 x17: 0000000000000032
x18: 00000000f253cdd8 x19: 00000000f254a3c0
x20: 00000000f25415a0 x21: 00000000f252d480
x22: 00000000f45ea6c8 x23: 00000000f45ea6c8
x24: 00000000f254a368 x25: 00000000f254a370
x26: 00000000f254a130 x27: 00000000f254a378
x28: 0000000000000002 x29: 00000000f252d430

Code: 8b020022 eb02003f 54fffee2 b9403403 (b8004423)
Resetting CPU ...

resetting ...

######## OUTPUT REPATS AT THIS POINT ########



 

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?
9 hours ago, ethDreamer said:

I checked the output on the serial console, it looks like the board gets stuck in an infinite boot loop

Do you have HDMI connected to your T4 while booting? If so, can you test it with HDMI disconnected?

HDMI is one of the possible offenders that come to my mind as it was freshly enabled for rk3399 boards in v2020.04.

 

I have tested the change with M4 (v1) and M4V2 albeit without HDMI - it works well.

I tested it with HDMI on OrangePi 4 and it booted although the HDMI output in u-boot was garbled.

Link to post
Share on other sites
On 4/27/2020 at 8:06 AM, piter75 said:

Do you have HDMI connected to your T4 while booting? If so, can you test it with HDMI disconnected?

HDMI is one of the possible offenders that come to my mind as it was freshly enabled for rk3399 boards in v2020.04.

 

I have tested the change with M4 (v1) and M4V2 albeit without HDMI - it works well.

I tested it with HDMI on OrangePi 4 and it booted although the HDMI output in u-boot was garbled.


Yup that did it.  It boots fine with the latest commit 716bd3b9dc.. as long as HDMI is unplugged.  If HDMI is plugged in, it will enter that boot loop.  I can plug in HDMI after the boot loader gets to this point:

Quote

Found U-Boot script /boot/boot.scr
2940 bytes read in 5 ms (574.2 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
151 bytes read in 5 ms (29.3 KiB/s)
6786524 bytes read in 396 ms (16.3 MiB/s)
19296264 bytes read in 1083 ms (17 MiB/s)
104819 bytes read in 13 ms (7.7 MiB/s)
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6786460 Bytes = 6.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f1eb1000, end f2529d9c ... OK
ERROR: reserving fdt memory region failed (addr=0 size=0)
   Loading Device Tree to 00000000f1e2f000, end 00000000f1eb0fff ... OK

Starting kernel ...
 

I feel like I'm not going to be the last person to run into this issue so I hope they find this post..

Side note: is there any way to have the kernel redirect output to the serial console after this point? Because otherwise I don't see anything until the system reaches the login prompts. I'm more than happy to be a tester for this.
 

Link to post
Share on other sites
13 hours ago, ethDreamer said:

I feel like I'm not going to be the last person to run into this issue so I hope they find this post.

I will probably disable HDMI in u-boot at least for NanoPC-T4 for now to avoid it.

 

13 hours ago, ethDreamer said:

is there any way to have the kernel redirect output to the serial console after this point?

Set verbosity=7 in /boot/armbianEnv.txt instead of the default of 1 to make the kernel output verbose.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...