Hello all,

 

First of all, thanks for the Armbian project, love it so far, but had a slight problem with a kernel upgrade. To be honest, I forgot how I installed Armbian since it was a while ago, but I've been using this for a year or so.

 

I saw that unattended-upgrades installed a new kernel and I should reboot for this change. I was a bit apprehensive, but went ahead and rebooted. The NanoPI R4S didn't come back up. I attached a serial console to debug. The console showed that the initramfs was read successfully from the SD card, but then tried to mount to root filesystem by UUID and failed (it kept saying it tried to run /boot/local-block and eventually giving up and complaing that it couldn't find the root filesystem with UUID=...). I checked if the device was present in /dev, I only saw /dev/mmcblk1, but no "p1".

 

After a lot of debugging and trying, I noticed that if I took the SD card out, then put it back in, dmesg would show that it found the partition and only then it showed both /dev/mmcblk1 as well as /dev/mmcblk1p1. At that moment, if I exit the initramfs, it boots the system as normal.

 

After some trial and error, I noticed this happens with the linux-image-current-rockchip64=22.02.1 image. I can boot without problems with the linux-image-current-rockchip64=21.08.2 image, so I downgraded to that version of the package and put it on hold for now. I now have a working system with the linux-image at the 21.08.2 version, even though I upgraded the other packages (like linux-u-boot-nanopi-r4s-current to) their 22.x versions!

 

I looked around for a solution to this problem (or even understand it), but couldn't find something, so I decided to file this bug report. I did see someone mention changing the dtb (/boot/dtb/rockchip/rk3399-nanopi-r4s.dtb? /usr/lib/linux-image-current-rockchip64/rockchip/rk3399-nanopi-r4s.dtb? I don't know which one ends up in the initramfs) which I tried, but ultimately this did not fix my problem.

 

Now whenever I install the new kernel and I need to reboot, I know I can take out the SD-card a couple of seconds after booting, then put it back it to let the OS detect the partition. It's not ideal, but better than having to open up the case and attach a serial console.

 

Is this a known problem? Are there known solutions for this? I'm afraid this problem might persist with newer versions of the kernel and I do not want to be stuck at this version and not get security updates.

Similar issue with orange pi 4. My root partition is on SSD.

==> System boots normal after removing SD-card from fstab.

Additional problem with new kernel: defunct asterisk and thus blocked udp6 port.

(It happened once a day. Once a day I get a new IP address from my provider)

 

Exactly what microSD cards are you both using?  Are they SDHC or SDXC?

 

Do you have any USB peripherals plugged in?

 

Report the output of:

lsb_release -a || cat /usr/lib/os-release || cat /etc/os-release
cat /etc/armbian-release
uname -a
cat /boot/armbianEnv.txt
free -m
lspci
lsusb -t
lsblk
ls /dev/mmcblk? | xargs -IDEV -n1 parted DEV print

 

Note free -m is just to see which Nanopi R4S model you have...not that I think it matters.

 

I have a few Nanopi R4S running 5.15.25-rockchip64 #22.02.1 now and I have not experienced this issue yet. So I can't troubleshoot this locally yet, but maybe we can find some difference in our setups that will help me repeat the issue.

 

I also have an RK3399-based Rock Pi 4C that I could test with, though it's currently unpowered and not readily accessible, would be several days or longer before I could retrieve it if useful.

 

Of my active Nanopi R4S:

• One is 4GB LPDDR4 model, 2 ext4 partitions on uSD card, running Debian bullseye, current install started as Armbian 22.02 bullseye image, with 1 USB3 Realtek 8153 based NIC plugged in
• One is 4GB LPDDR4 model, 2 ext4 partitions on uSD card, running Debian bullseye, current install started as Armbian 21.08 bullseye image, no USB peripherals
• One is 1GB DDR3 model, single ext4 partition on uSD card, running Debian buster, current install started as Armbian buster image (I don't recall specific version), no USB peripherals

All are fully updated with latest Debian and Armbian packages including 5.15.25-rockchip64 #22.02.1 SMP PREEMPT Sun Feb 27 09:05:47 UTC 2022 aarch64 GNU/Linux kernel.  I've not messed with the device trees or any boot settings on any of them.

 

All are booting from 32GB Sandisk SD32G SDHC A1 class micro SD cards.  I believe a mix of SDSQUAR-032G and SDSQUA4-032G models.

 

As mentioned all reboot into 5.15.25-rockchip64 #22.02.1 without uSD card unplug/replug, so I am wondering what's different between our setups.  If you're both using SDXC I do have an extra 256GB micro SDXC card I could try.

Perhaps it was a missing firmware update.
Got update for:
* armbian-config
* armbian-firmware-full
and switch to new kernel again.
Rebootet 2 times -- Mounting of SD-card was OK.

 

The SD card is a SanDisk Ultra 16 GB Micro SDHC A1 (class 10).

 

No USB peripherals, 2 NICs connected.

 

@cropi4: I've also tried to reboot with the new armbian-config and armbian-firmware-full + new kernel, but it didn't boot (I don't know why because I didn't have the serial console connected). I've managed to boot with the unplug/replug sd-card trick and reinstalled the older kernel. That worked.

 

Output:

 

# lsb_release -a || cat /usr/lib/os-release || cat /etc/os-release
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=nanopi-r4s
BOARD_NAME="NanoPi R4S"
BOARDFAMILY=rk3399
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=92a1c729d-dirty
VERSION=22.02.1
LINUXFAMILY=rockchip64
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
BRANCH=current

# uname -a
Linux ice.i.elfstone.nl 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux

# cat /boot/armbianEnv.txt
verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=be304ae0-43cf-4546-bc4a-c529a5ecb38a
rootfstype=ext4
console=serial
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u


# free -m
               total        used        free      shared  buff/cache   available
Mem:            3863         260        3218          10         385        3521
Swap:           1931           0        1931

# lspci
00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)


# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M


# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk1     179:0    0 14.8G  0 disk
└─mmcblk1p1 179:1    0 14.7G  0 part /
zram0       252:0    0  1.9G  0 disk [SWAP]
zram1       252:1    0   50M  0 disk /var/log


# ls /dev/mmcblk? | xargs -IDEV -n1 parted DEV print
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk1: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      16.8MB  15.8GB  15.8GB  primary  ext4

 

vor 19 Stunden schrieb Michiel Holtkamp:

@cropi4: I've also tried to reboot with the new armbian-config and armbian-firmware-full + new kernel, but it didn't boot (I don't know why because I didn't have the serial console connected). I've managed to boot with the unplug/replug sd-card trick and reinstalled the older kernel. That worked.

I had to reboot again. And this time the SD-card issue was back.
==> It was just "by chance" that it booted 2 times without problems.

Attached are 2 log files.
One with working SD-card and one reboot where SD-card initialization failed.
The the ok case was a cold start.
In mmc.nok.log: "mmc2: card never left busy state"

 

mmc.ok.log mmc.nok.log

I saw there was a new kernel package (linux-image-current-rockchip64=22.05.1) so I tried if that solved my problems.

 

@ab1v2 Would you mind taking a look? Do I need to provide more information to help you debug?

 

Still have the same problem. I saw another thread that had the same problem on OrangePi:

I tried "ls /dev" and noticed there was no mmcblk1p1 (the output is also a bit garbled, that's maybe my quickly-hacked-together serial console):

drwxr-xr-x 11 0 0    2680 .
drwxr-xr-x 13 0 0       0 ..
drwxr-xr-x  4 0 0      80 disk
drwxr-xr-x  2 0 0     220 block
lrwxrwxrwx  1 0 0       4 rtc -> rtc0
drwxr-xr-x  2 0 0    2520 char
drwxr-xr-x  2 0 0       0 pts
brw-------  1 0 0 179,  0 mmcblk1
crw-------  1 0 0 248,  0 iio:device0
crw-------  1 0 0 252,  0 rtc0
drwxr-xr-x  2 0 0      60 dri
crw-------  1 0 0  10,234 btrfs-control
crw-------  1 0 0  10,124 cpu_dma_latency
crw-------  1 0 0  10,125 uleds
crw-------  1 0 0 247,  0 watchdog0
crw-------  1 0 0  10,130 watchdog
crw-------  1 0 0  89,  4 i2c-4
crw-------  1  0 loop0
crw-------  1 0 0  10,237 loop-control
crw-------  1 0 0   4, 66 ttyS2
crw-------  1 0 0   4, 64 ttyS0
crw---  1 0 0   4, 50 tty50
crw--w----  1 0 0   4, 49 tty49
crw--w----  1 0 0   4, 48 tty48
crw--w----  1 0 0   4, 47 tty  1 0 0 254,  0 gpiochip0

I removed the sd-card and then inserted it again (while keeping the board powered) and the immediately after tried "ls /dev" again, notice there is now mmcblk1p1:

drwxr-xr-x 11 0 0    2700 .
drwxr-xr-x 13 0 0       0 ..
drwxr-xr-x  6 0 0     120 disk
brw-------  1 0 0 179,  1 mmcblk1p1
brw-------  1 0 0 179,  0 mmcblk1
drwxr-xr-x  2 0 0     240 block
lrwxrwxrwx  1 0 0       4 rtc -> rtc0
drwxr-xr-x  2 0 0    2520 char
drwxr-xr-x  2 0 0       0 pts
crw-------  1 0 0 248,  0 iio:device0
crw-------  1 0 0 252,  0 rtc0
drwxr-xr-x  2 0 0      60 dri
crw-------  1 0 0  10,234 btrfs-control
crw-------  1 0 0  10,124 cpu_dma_latency
crw-------  1 0 0  10,125 uleds
crw-------  1 0 0 247,  0 watchdog0
crw-------  1 0 0  10,130 watchdog
crw------- 7,  1 loop1
brw-------  1 0 0   7,  0 loop0
crw-------  1 0 0  10,237 loop-control
crw-------  1 0 0   4, 66 ttyS2
0 0   4, 11 tty11
crw--w----  1 0 0   4, 10 tty10
crw--w----  1 0 0   4,  9 tty9
crw--w----  1 0 0   4,  8 tty8
crw--w----  1 0 0   4,  7 tty7
crw--w----  1 0 0   4,  6 tty6
crw--w----  1 0 0   4,  5 tty5
crw--w----  1 0 0   4,  4 tt2
crw-------  1 0 0 254,  1 gpiochip1
crw-------  1 0 0 254,  0 gpiochip0

The output of "dmesg" is:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.35-rockchip64 (root@1b91979a92d9) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.1 SMP PREEMPT Sat May 28 08:37:27 UTC 2022
[    0.000000] Machine model: FriendlyElec NanoPi R4S
[    0.000000] efi: UEFI not found.
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x000000e9000000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmw  0.000000] 	Trampoline variant of Tasks RCU enabled.
[    0.000000] 	Rude variant of Tasks RCU enabled.
[    0.000000] 	Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jupport
[    0.018640] CPU features: detected: 32-bit EL1 Support
[    0.018650] CPU features: detected: CRC32 instructions
[    0.045252] CPU: All CPU(s) started at EL2
[    0.045334] alternatives: patching kernel code
[    0.048877] devtmpfs: initialized
[    0.064384] Registered cp15_barrier emulation handler
[    0.064409] Registered setend emulati080075] thermal_sys: Registered thermal governor 'fair_share'
[    0.080086] thermal_sys: Registered thermal governor 'bang_b  1.432445]    32regs          :  2932 MB/sec
[    1.436661]    arm64_neon      :  2344 MB/sec
[    1.436670] xor: using function: 32regs (2932 MB/sec)
[    1.436685] Key type asymmetric registered
[    1.436692] Asymmetric key parser 'x509' registered
[    1.436817] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246)
[    1.437058] io scheduler mq-deadline registered
[    1.437067] io scheduler kyber registered
[    1.437279] io scheduler bfq registeUSB hub found
[    1.613269] hub 4-0:1.0: 1 port detected
[    1.613872] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[    1.613896] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 5
[    1.614069] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x8000000002010010
[    1.614132] xhci-hcd xhci-hcd.1.auto: irq 74, io mem 0xfe900000
[    1.614558] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.158-rtc rk808-rtc: setting system clock to 2013-01-18T08:50:10 UTC (1358499010)
[    2.078211] vcc1v8_s3: supplied by vcc_1v8
[    2.078525] dwmmc_rockchip fe320000.mmc: IDMAC supports 32-bit address mode.
[    2.078564] dwmmc_rockchip fe320000.mmc: Using internal DMA controller.
[    2.078580] dwmmc_rockchip fe320000.mmc: Version ID is 270a
[    2.078648] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 32,32 bit host data width,256 deep fifo
[    2.079336] vcca0v9_s3: supp00:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.092407] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req SC16G 14.8 GiB 
[  244.151462]  mmcblk1: p1

Notice that after 244 seconds, p1 is found, this is when I ejected/reinserted the sd-card.

btw, forgot output of console during boot:

DDR Version 1.24 20191016
In
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 0, cs 1, advanced training done
channel 1, cs 0, advanced training done
channel 1, cs 1, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 250
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=15193MB
FwPartOffset=2000 , 0
StorageInit ok = 55625
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=0xbaf64
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 return SMC_UNK
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.10-armbian (Feb 04 2021 - 00:04:17 +0100)

SoC: Rockchip rk3399
Reset cause: POR
Model: FriendlyElec NanoPi R4S
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   mmc@fe320000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 5 ms (622.1 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
181 bytes read in 4 ms (43.9 KiB/s)
12373016 bytes read in 527 ms (22.4 MiB/s)
30343680 bytes read in 1287 ms (22.5 MiB/s)
77471 bytes read in 12 ms (6.2 MiB/s)
2698 bytes read in 8 ms (329.1 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3f90000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    12372952 Bytes = 11.8 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 f1362000, end f1f2ebd8 ... OK
   Loading Device Tree to 00000000f12e6000, end 00000000f1361fff ... OK

Starting kernel ...

Loading, please wait...
Starting version 247.3-7
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=be304ae0-43cf-4546-bc4a-c529a5ecb38a does not exist.  Dropping to a shell!
(initramfs) 

After dropping to shell, I can reject/re-insert sd-card (as mentioned above) and exit the shell, and the kernel boots and the system comes up normally

 

 

If I use a previous version (linux-image-current-rockchip64=21.08.2) then the boot process continues without interruption:

 

DDR Version 1.24 20191016
In
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CSx8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 0, cs 1, advanced training done
channel 1, cs 0, advanced training done
channel 1, cs 1, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 250
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=15193MB
FwPartOffset=2000 , 0
StorageInit ok = 55511
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=0xbaf64
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 return SMC_UNK
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.10-armbian (Feb 04 2021 - 00:04:17 +0100)

SoC: Rockchip rk3399
Reset cause: POR
Model: FriendlyElec NanoPi R4S
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   mmc@fe320000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 5 ms (622.1 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
181 bytes read in 4 ms (43.9 KiB/s)
13468112 bytes read in 574 ms (22.4 MiB/s)
28580352 bytes read in 1213 ms (22.5 MiB/s)
77471 bytes read in 12 ms (6.2 MiB/s)
2698 bytes read in 8 ms (329.1 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3de0000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    13468048 Bytes = 12.8 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 f1256000, end f1f2e190 ... OK
   Loading Device Tree to 00000000f11da000, end 00000000f1255fff ... OK

Starting kernel ...

Loading, please wait...
Starting version 247.3-7
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.36.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 
/dev/mmcblk1p1: recovering journal
/dev/mmcblk1p1: clean, 72731/936448 files, 786511/3846544 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

Welcome to [1mDebian GNU/Linux 11 (bullseye)

 

Funny. I had the same issue but only with 64GB sd card. With 32GB it works...

I saw there was a new kernel package (linux-image-current-rockchip64=22.05.3) so I tried if that solved my problems. Alas, still the same problem. Reinstalled 21.08.2 because that's the last version that worked for me.

 

Does anyone have an idea?

I'm trying to load Armbian onto a NanoPi R4S, but an running into problems where it won't start with certain versions, and running apt update breaks it on other versions.

I've hooked up the serial interface so I can see what's going on during boot, so there are pastebin links to the logs.

 

Fresh Image (Jammy/Focal):

Trying to use Jammy or Focal I cannot the the board to boot at all with a completely fresh image. The error message complains that the UUID for the main partition does not exist

Log: https://pastebin.com/gQeyhVf5

 

 

Fresh image (Bullseye/Buster), post account creation:

Bullseye and Buster will initially boot, but sometimes will not boot properly if doing a soft-reboot (ie. sudo reboot now), requiring a hard power-cycle to boot (which is a bit annoying since the board won't be in the easiest place to get to). At this stage I haven't done anything except the initial prompt to change the root password

It has the same error message that UUID does not exist

Log: https://pastebin.com/cnNbZVFT

 

 

Post apt update/upgrade (Bullseye/Buster):

With both Bullseye and Buster, I run apt update and apt upgrade since it's generally a good idea to keep packages up-to-date for security. I didn't change any other files or do anything else except run the update

However in both, after running apt upgrade it is no longer able to boot no mater how many times I power cycle it. Also complains UUID does not exist

Log: https://pastebin.com/pqyxBrvS

 

After apt update was complete, but before power cycling/rebooting it I did check the UUIDs of the partitions using blkid and also checked /boot/armbianEnv.txt to check if either had changed. But the UUID's still matched what they were previously so it doesn't seem that anything got changed or corrupted

 

 

In all the cases where it won't boot it seems to be complaining that the UUID for the rootfs doesn't exist. And I'm not sure how to fix it

@littlecxm Tagging the maintainer.

 

Which images did you use (full file name)?

Merged with other topic (actually the topic right next to yours...) that describes a similar problem.

Jammy boots up fine: http://ix.io/41zg

apt upgrade & reboot was fine too

Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz

 

Bullseye boots up fine: http://ix.io/41zi

apt upgrade & reboot was fine too

Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz

 

 

Tests performed with 32GB Sandisk Extreme V30 U3 A1

Images written and verified with USBimager 1.0.8

Sorry if it takes a while to reply. I just made an account, so the number of posts I can make per day appears to be limited to 1.

 

On 7/3/2022 at 6:29 PM, schwar3kat said:

@littlecxm Tagging the maintainer.

 

Which images did you use (full file name)?

I did some additional testing and tried flashing several different images including some older versions:

Couldn't boot at all (same error UUID does not exist):

• Armbian_22.05.3_Nanopi-r4s_focal_current_5.15.48.img.xz
• Armbian_22.02.1_Nanopi-r4s_focal_current_5.15.25.img.xz
• Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz
• Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz
• Armbian_22.02.1_Nanopi-r4s_bullseye_current_5.15.25.img.xz
• Armbian_21.08.1_Nanopi-r4s_hirsute_edge_5.13.12.img.xz
• Armbian_22.02.1_Nanopi-r4s_jammy_edge_5.16.11.img

Booted but would no longer boot after apt update/upgrade:

• Armbian_21.08.1_Nanopi-r4s_focal_current_5.10.60.img.xz
• Armbian_21.08.1_Nanopi-r4s_buster_current_5.10.60.img.xz
• Armbian_21.08.1_Nanopi-r4s_bullseye_current_5.10.60.img.xz

I also have tried 3 different SD cards. So I doubt that is the cause, unless all 3 are somehow bad.

All the ones that don't work appear to be 5.10.* I'm not sure if the newer ones come bundled with the newer version of the package that breaks it?

 

 

On 7/3/2022 at 10:22 PM, Werner said:

Merged with other topic (actually the topic right next to yours...) that describes a similar problem.

Woops, sorry about that. When I read the title I didn't realize it was referring to the same problem

 

I wish I had found it easier because it would have saved me a lot of time installing packages a couple at a time until I found the one that broke it...

I also came to the same conclusion that updating linux-image-current-rockchip64 to version 22.*.* or newer breaks it.

 

 

On 7/4/2022 at 12:18 AM, Werner said:

Jammy boots up fine: http://ix.io/41zg

apt upgrade & reboot was fine too

Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz

 

Bullseye boots up fine: http://ix.io/41zi

apt upgrade & reboot was fine too

Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz

 

 

Tests performed with 32GB Sandisk Extreme V30 U3 A1

Images written and verified with USBimager 1.0.8

I tried three different  32GB SanDisk Ultra SD cards and none of the newer images will boot (including Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz and Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz)

I was using Rufus, but I also downloaded and tried the same version of USBimager 1.0.8 to eliminate that variable and still had the same problem

 

I don't know if there might be some problem with my board? That seems unlikely since the older images still work...

But given that the images work on the board you tested and aren't working on mine I'm not sure what would cause that.

Maybe there are undocumented revisions of this board out there which causes some to boot and others not.

 

Mine has on the back side:
 

Quote

 

E234156

SL-M

RU94V-0

4220

NanoPi R4S (4GB)

2008

 

 

 

18 hours ago, skybob22 said:

I just made an account, so the number of posts I can make per day appears to be limited to 1.

Only for fairly new accounts. This restrictions lifts automatically once you have just a few posts. This measure is unfortunately necessary in order to fight spam in forums. A rather small price to pay for having a perfectly clean forums

 

4 hours ago, Werner said:

Maybe there are undocumented revisions of this board out there which causes some to boot and others not.

There might also be some variances in components between units (different manufacturers, batches, etc..) that might have been "uncovered" by some minor change in kernel code.

 

I remember having a unit of Rock Pi 4A (no wifi) that did not boot with eMMC while the other unit 4GB 4B (wifi) did boot without issues.

I consulted other Rock Pi 4A Armbian users and they did not observe such behaviour.

I finally found the cause in the mmc kernel driver and even implemented a patch for it in Armbian, but that did require lots of fiddling and debugging.

 

Unfortunately at this point I cannot reproduce the issue with my NanoPi R4S unit.

Update: I solved the problem on my end.

 

All I did was swap the failing SD card (SanDisk Ultra 16 GB, A1 class, SDHC) to a different one (SanDisk Extreme 32 GB, UHS-1, SDHC) and the new kernel(s) boot without any problem. So it seems that with the kernel upgrade, the support for the former SD-card broke, but it still works for other types.

 

If someone wants to debug this, I can do checks because I have setup serial console that I can plug in whenever necessary. For now I will not do any further research on this, unless someone asks.