Rock Pi 4C NVMe boot (no other storage connected) won't work

Hi,

I’ve flashed Debian 9 Desktop(Dual Display) to an NVMe drive using etcher.

With only the NVMe drive connected (so no SD and eMMC), it won’t boot at all.
If i flash the same image to an eMMC and connect both (so eMMC and NVMe are connected, SD is not) then it boots from the NVMe).

I’m now debugging this a bit and attached a serial connection to see the console data it spits out.
The error it gives is clear as to why it fails but “why” that happens is a total mystery to me.

Scanning nvme 0:4...
Found /extlinux/extlinux.conf
pxefile_addr_str = 0x00500000
bootfile = /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
598 bytes read in 1 ms (584 KiB/s)
select kernel
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
2:      kernel-4.4.154-95-rockchip-gd2ab1f26e1b3
Enter choice: Retrieving file: /hw_intfc.conf
reading /hw_intfc.conf
1807 bytes read in 1 ms (1.7 MiB/s)
dtoverlay number: 0, name:/overlays/console-on-ttyS2.dtbo 
dtoverlay number: 1, name:/overlays/spi1-flash.dtbo 
hw_conf.valid = 1
hw_conf.pwm0 = 0
hw_conf.pwm1 = 0
hw_conf.uart2 = 0
hw_conf.uart4 = 0
hw_conf.spi1 = 1
hw_conf.spi2 = 0
hw_conf.i2c2 = 0
hw_conf.i2c6 = 0
hw_conf.i2c7 = 0
hw_conf.dts_overlay_count = 2
hw_conf.dts_overlay[0] = /overlays/console-on-ttyS2.dtbo
hw_conf.dts_overlay[1] = /overlays/spi1-flash.dtbo
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
Retrieving file: /vmlinuz-4.4.154-111-rockchip-g39b306a41b2d
reading /vmlinuz-4.4.154-111-rockchip-g39b306a41b2d
ERROR: status = 2013, phase = 1, head = 1
Error reading cluster
** Unable to read file /vmlinuz-4.4.154-111-rockchip-g39b306a41b2d **
Skipping kernel-4.4.154-111-rockchip-g39b306a41b2d for failure retrieving kernel
Retrieving file: /hw_intfc.conf
reading /hw_intfc.conf
1807 bytes read in 0 ms
dtoverlay number: 2, name:/overlays/console-on-ttyS2.dtbo 
dtoverlay number: 3, name:/overlays/spi1-flash.dtbo 
hw_conf.valid = 1
hw_conf.pwm0 = 0
hw_conf.pwm1 = 0
hw_conf.uart2 = 0
hw_conf.uart4 = 0
hw_conf.spi1 = 1
hw_conf.spi2 = 0
hw_conf.i2c2 = 0
hw_conf.i2c6 = 0
hw_conf.i2c7 = 0
hw_conf.dts_overlay_count = 4
hw_conf.dts_overlay[0] = 
hw_conf.dts_overlay[1] = 
hw_conf.dts_overlay[2] = /overlays/console-on-ttyS2.dtbo
hw_conf.dts_overlay[3] = /overlays/spi1-flash.dtbo
2:      kernel-4.4.154-95-rockchip-gd2ab1f26e1b3
Retrieving file: /vmlinuz-4.4.154-95-rockchip-gd2ab1f26e1b3
reading /vmlinuz-4.4.154-95-rockchip-gd2ab1f26e1b3
ERROR: status = 2013, phase = 1, head = 0
Error reading cluster
** Unable to read file /vmlinuz-4.4.154-95-rockchip-gd2ab1f26e1b3 **
Skipping kernel-4.4.154-95-rockchip-gd2ab1f26e1b3 for failure retrieving kernel
SCRIPT FAILED: continuing...

As you can see, it cannot find the kernel image files.
I mounted the NVMe in another pc. The fourth partition (and EFI one) does have vmlinuz-4.4.154-111-rockchip-g39b306a41b2d and vmlinuz-4.4.154-95-rockchip-gd2ab1f26e1b3 right in the EFI mount at it’s root level. It’s not hidden away in a sub folder or something.

For whatever reason that i don’t get, it reads the bootfile just fine:

bootfile = /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
598 bytes read in 1 ms (584 KiB/s)
select kernel
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
2:      kernel-4.4.154-95-rockchip-gd2ab1f26e1b3

but fails, on the very same mount, to read the kernel images.
They are there:

-rwxr-xr-x 1 root root  20M Jul  8 17:04 vmlinuz-4.4.154-111-rockchip-g39b306a41b2d
-rwxr-xr-x 1 root root  19M Oct 21  2019 vmlinuz-4.4.154-95-rockchip-gd2ab1f26e1b3

Any idea what it’s doing wrong and how to fix it?

Cheers,
Mark

Hi, do you have USB Type-A to Type-A cable for flashing spi image under Linux? I suggest that you use a latest spi image, https://dl.radxa.com/rockpi/images/loader/spi/rockpi4c-uboot-trust-spi_2017.09-2697-ge41695afe3_20201219.img.

After flashing this new image, remember to remove microSD and eMMC Module.

The latest ROCK Pi 4C Debian image: https://dl.radxa.com/rockpi/images/debian/rockpi4c_debian_buster_xfce4_arm64_20201219_0331-gpt.img.gz.

You can try the armbian’s spi image. It is much newer and better than radxa’s.

1 Like

I flashed it using the wiki step to flash it while running an OS from an eMMC and i’m somewhat sure (not entirely) that the version you mentioned here was flashed to the SPI. Right now, when you update your debian image you apparently get that file.

As for the Type-A to Type-A cable. I actually don’t have that cable. I truly have a shitload of USB cables but all from something to something else. None from A to A…

That i didn’t try. I downloaded it from the downloads page, which seems to be from 2020-07-16.
I’ll try that image right away.

If i get nothing working, that will be my last resort. I’m kinda hesitant to go that route because it doesn’t seem to be an officially supported way for Rock Pi 4C, it’s a third party distribution. Now i’m fine with the distribution but i find the SPI stuff a bit scary. Thank you for the suggestion though :slight_smile:

Armbian is a powerful build system behind which is a highly experienced community specialised for ARM single board computers. There is not many ways how you can integrate Rockchip RK3399 and there is nobody who knows everything about the chip … A lot of vendors use it this way or another. We study all of them otherwise its not possible to deal with this.

We provide Radxa specific hardware interface based images, but we also provide Radxa specific community supported, developed and maintained (a lot by our staff) modern hardware interface which should be your only path on a long run. You don’t want to use development kernels forever, don’t you? Current legacy kernel, where hw support for this chip was brought up by Rockchip, is maintained by a few people Rockchip and board engineers and will some day be abandoned by Rockchip and subsequently by Radxa.

Linux kernel is a community project and community focus, not just from Armbian, goes into modern public common hardware layer. And Armbian plays important role in this. 3rd party distributions - from our perspective - are integrating our work into their distributions. But they don’t have know-how and can’t support you. We can.

On a side, we also provide our own Linux distribution which quality you can easily check. Also comes with a powerful SDK which can match industry standard software. It is also used by many developers, 3rd party service deployers and a few single board computer vendors.

It should be the other way around. Modern kernel doesn’t have all functions ported from legacy, but if those that interest you are there, you should not think twice.

So, i flashed that SPI version you mentioned. The NVMe has the debian version you mentioned.
It’s sadly going nowhere. Her’s the full serial log:

DDR Version 1.20 20190314
In
channel 0
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 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 400MHz 0,1
channel 0
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 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 800MHz 1,0
Channel 0: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
OUT
Boot1: 2018-06-26, version: 1.14
CPUId = 0x0
ChipType = 0x10, 221
Spi_ChipId = b4016
SpiBootInit:0
mmc0:cmd8,32
mmc0:cmd5,32
mmc0:cmd55,32
mmc0:cmd1,32
mmc0:cmd8,32
mmc0:cmd5,32
mmc0:cmd55,32
mmc0:cmd1,32
mmc0:cmd8,32
mmc0:cmd5,32
mmc0:cmd55,32
mmc0:cmd1,32
SdmmcInit=0 1
StorageInit ok = 21718
SecureMode = 0
SecureInit ret = 0, SecureMode = 0
GPT vendor signature is wrong
LoadTrust Addr:0x1800
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 1000
Load OK, addr=0x200000, size=0xf1664
RunBL31 0x10000
␁NOTICE:  BL31: v1.3(debug):0e7a845
NOTICE:  BL31: Built : 16:13:46, Apr 17 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(1181): 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 2017.09-2697-ge41695afe3 (Dec 19 2020 - 04:47:27 +0000), Build: jenkins-linux-build-release-436

Model: Radxa ROCK Pi 4C
PreSerial: 2
DRAM:  3.9 GiB
Relocation Offset is: f5bde000
Sysmem: init
I2c speed: 400000Hz
PMIC:  RK808 
vdd_center 900000 uV
vdd_cpu_l 900000 uV
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Using default environment

Model: Radxa ROCK Pi 4C
## Error: "rkimg_bootdev" not defined
Bootdev: mmc 1
MMC: no card present
mmc_init: -123, time 0
rockchip_get_bootdev: can't find dev_desc!
[Vendor ERROR]:Invalid boot device type(0)
MMC: no card present
mmc_init: -123, time 0
rockchip_get_bootdev: can't find dev_desc!
[Vendor ERROR]:Invalid boot device type(0)
MMC: no card present
mmc_init: -123, time 0
rockchip_get_bootdev: can't find dev_desc!
rockchip_get_boot_mode: dev_desc is NULL!
MMC: no card present
mmc_init: -123, time 0
rockchip_get_bootdev: can't find dev_desc!
init_resource_list: dev_desc is NULL!
Can't find file:logo.bmp
failed to display uboot logo
CLK: (uboot. arml: enter 816000 KHz, init 816000 KHz, kernel 0N/A)
CLK: (uboot. armb: enter 24000 KHz, init 24000 KHz, kernel 0N/A)
  aplll 816000 KHz
  apllb 24000 KHz
  dpll 800000 KHz
  cpll 24000 KHz
  gpll 800000 KHz
  npll 600000 KHz
  vpll 24000 KHz
  aclk_perihp 133333 KHz
  hclk_perihp 66666 KHz
  pclk_perihp 33333 KHz
  aclk_perilp0 266666 KHz
  hclk_perilp0 88888 KHz
  pclk_perilp0 44444 KHz
  hclk_perilp1 100000 KHz
  pclk_perilp1 50000 KHz
Net:   eth0: ethernet@fe300000
Hit key to stop autoboot('CTRL+C'):  0 
Here trying to boot from nvme
dcache off

Device 0: Vendor: 0x144d Rev: 2B2QEXE7 Prod: S5H9NS0NB06268N     
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning nvme 0:1...
Found /extlinux/extlinux.conf
pxefile_addr_str = 0x00500000
bootfile = /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
423 bytes read in 1 ms (413.1 KiB/s)
select kernel
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
Enter choice: Retrieving file: /hw_intfc.conf
reading /hw_intfc.conf
1807 bytes read in 1 ms (1.7 MiB/s)
dtoverlay number: 0, name:/overlays/console-on-ttyS2.dtbo 
dtoverlay number: 1, name:/overlays/spi1-flash.dtbo 
hw_conf.valid = 1
hw_conf.pwm0 = 0
hw_conf.pwm1 = 0
hw_conf.uart2 = 0
hw_conf.uart4 = 0
hw_conf.spi1 = 1
hw_conf.spi2 = 0
hw_conf.i2c2 = 0
hw_conf.i2c6 = 0
hw_conf.i2c7 = 0
hw_conf.dts_overlay_count = 2
hw_conf.dts_overlay[0] = /overlays/console-on-ttyS2.dtbo
hw_conf.dts_overlay[1] = /overlays/spi1-flash.dtbo
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
Retrieving file: /initrd.img-4.4.154-111-rockchip-g39b306a41b2d
reading /initrd.img-4.4.154-111-rockchip-g39b306a41b2d
ERROR: status = 2013, phase = 0, head = 1
Error reading cluster
** Unable to read file /initrd.img-4.4.154-111-rockchip-g39b306a41b2d **
Skipping kernel-4.4.154-111-rockchip-g39b306a41b2d for failure retrieving initrd
SCRIPT FAILED: continuing...
MMC: no card present
mmc_init: -123, time 0
Card did not respond to voltage select!
mmc_init: -95, time 26
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   failed to get usb phy
Port not available.
USB3:   failed to get usb phy
Port not available.
USB4:   Can't get the usbphy register address
probe failed, error -6
USB5:   Can't get the usbphy register address
probe failed, error -6
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Help?

As far as log states there is clearly problem with initd, most likely it need to be updated

You are absolutely right, @igorp!
And based on my findings thus far it looks like i’m not going get it working :frowning:

I’ll give the Armbian SPI a shot later tomorrow.

I eventually want to have Manjaro ARM on it and play with the rk3399 repositories to get the most out of this little thing.

Every distro i try gives me an error like that.
Which leads me to think that the initrd isn’t the issue. The SPI (or u-boot) probably is.

Take advice(s) and don’t waste time with Manjaro or Rockchip stock kernel which is the same as Radxa kernel, just without support for Radxa hardware. Nothing will work with that kernel. Ain’t that simple …

I will, but please don’t assume that what you did right there.

I want to play with hardware acceleration. Like image effects (the rk3399 has a chip for it, they have a repository for it), like video encoding through va-api, like Vulkan and/or OpenGL ES, etc… For the kernel. I’m not touching that. That’s just going a bit too far for me.

Also, my daily driver is archlinux thus i really want to use arch on rk3399 if possible. It’s just easier for me. But if that is not working and armbian is, well… then armbian it is :slight_smile:

Can you try this in U-Boot console?

dcache off
pci e
nvme scan
setenv devnum 0
run nvme_boot

Just trying to help you question your assumptions.

VA is a kernel function, bypassing standard OS implementation, and 3D too - which comes in currently unstable open source on a modern and stable but closed on legacy kernel … but ofc you need userland libraries that things function as well. No idea if video encoding works accelerated.

How Linux looks and feels from users perspective is the smallest problem you will have here.

Could you explain stuff a little more detailed please.

What’s wrong with va-api? You make it sound like it’s bad. You need “a” way to do hardware accelerated video encoding/decoding. va-api is one such standard to get just that. vdpau is another, though that’s quite unlikely to be supported. OpenMAX is another still though that usually is not working on desktop platforms. It’s more of an Android thing even though the spec isn’t specifically tailored to mobile as far as i know.

If i read your reply correctly, which is hard because you leave a lot of room for “interpreatation”, then you’re advocating to use armbian as that might have a fully functional desktop and is modern (kernel wise). Yet (i assume here) it lacks the hardware handling of vital features to make it get the most out of the rk3399. If i’m correct here - you probably know as you seem to be running it - then i’m definitely going for an “old crappy kernel with support”. My reason being software rendering on arm for gui purposes is… not pleasant to work with (understatement). I’m not even talking about software rendered video yet which would likely be limited to at most 720p if it isn’t hardware accelerated.

It’s fine if you feel comfortable using debian or a derivative like it. I don’t feel comfortable using it. I have a strong preference towards archlinux (or it’s derivatives). Merely using debian in the distributed images already feels alien to me. Like for instance, no autocompletion for any commands that need to run as root (like they don’t exist). I had that with fdisk. It’s just not my OS of choice. Sure, you might be able to fix it with configs/packages/zsh/something_else_you_know_and_i_dont … I’m just not willing to figure it out if there is an os i like out there that i can use too (that being Manjaro ARM, it has Pi 4C support).

It didn’t seem to be working :frowning:

=> dcache off
=> 
=> pci e
=> 
=> nvme scan
=> 
=> setenv devnum 0
=> 
=> run nvme_boot

Device 0: Vendor: 0x144d Rev: 2B2QEXE7 Prod: S5H9NS0NB06268N     
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning nvme 0:1...
Found /extlinux/extlinux.conf
pxefile_addr_str = 0x00500000
bootfile = /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
423 bytes read in 1 ms (413.1 KiB/s)
select kernel
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
Enter choice: Retrieving file: /hw_intfc.conf
reading /hw_intfc.conf
1807 bytes read in 1 ms (1.7 MiB/s)
dtoverlay number: 2, name:/overlays/console-on-ttyS2.dtbo 
dtoverlay number: 3, name:/overlays/spi1-flash.dtbo 
hw_conf.valid = 1
hw_conf.pwm0 = 0
hw_conf.pwm1 = 0
hw_conf.uart2 = 0
hw_conf.uart4 = 0
hw_conf.spi1 = 1
hw_conf.spi2 = 0
hw_conf.i2c2 = 0
hw_conf.i2c6 = 0
hw_conf.i2c7 = 0
hw_conf.dts_overlay_count = 4
hw_conf.dts_overlay[0] = 
hw_conf.dts_overlay[1] = 
hw_conf.dts_overlay[2] = /overlays/console-on-ttyS2.dtbo
hw_conf.dts_overlay[3] = /overlays/spi1-flash.dtbo
1:      kernel-4.4.154-111-rockchip-g39b306a41b2d
Retrieving file: /initrd.img-4.4.154-111-rockchip-g39b306a41b2d
reading /initrd.img-4.4.154-111-rockchip-g39b306a41b2d
ERROR: status = 2013, phase = 0, head = 0
Error reading cluster
** Unable to read file /initrd.img-4.4.154-111-rockchip-g39b306a41b2d **
Skipping kernel-4.4.154-111-rockchip-g39b306a41b2d for failure retrieving initrd
SCRIPT FAILED: continuing...
=> 

Also, before i got to this point i had a load of Waiting for PHY auto negotiation to complete.......... Is there a way to skip that for faster testing custom commands?

VA is not exactly my field of interest, but Rockchip is claiming they play by the book / standard. I am not deep enough to judge quality http://rockchip.wikidot.com/status or Colabora work on Hantro. Both are not very fresh news and things should work now, probably not encoding and probably not OOB.

I am trying to focus on your problem from the topic and I am in general not interested in VA.

Also I am not advocating usage of Debian userland here or telling that Arch is crap. No. I am half embedded engineer and I am used to many different / custom things.

Armbian simply has far better support in ARM than Arch or Manjaro. Not ZSH, without which I can’t live since a very long time. And is perhaps the reason why I don’t notice default Debian shortcomings … which clearly exits.

Could you show us the output of u-boot’s printenv command?

Sure thing!

=> printenv
arch=arm
baudrate=1500000
board=evb_rk3399
board_name=evb_rk3399
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=nvme mmc1 mmc0 usb0 pxe dhcp 
bootargs=storagemedia=sd androidboot.mode=sd
bootcmd=run distro_bootcmd;boot_android ${devtype} ${devnum};bootrkp;
bootcmd_dhcp=run boot_net_usb_start; run boot_net_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_nvme=echo Here trying to boot from nvme;dcache off;echo dcache off;pci e;nvme scan;setenv devnum 0;run nvme_boot;
bootcmd_pxe=run boot_net_usb_start; run boot_net_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=1
bootfile=/extlinux/extlinux.conf
bootfstype=fat
cpu=armv8
cpuid#=5456503934302e303000000000128483
devnum=0
devplist=1
devtype=nvme
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
ethact=ethernet@fe300000
ethaddr=8a:21:4c:f8:e6:f1
fdt_addr_r=0x08300000
fdt_overlay_addr_r=0x08200000
fdtcontroladdr=0xe9dc8260
fdtfile=rockchip/rk3399-rock-pi-4c.dtb
fileaddr=0x700000
filesize=0x70f
hw_conf_addr_r=0x00700000
kernel_addr_r=0x00280000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
nvme_boot=if nvme dev ${devnum}; then setenv devtype nvme; run scan_dev_for_boot_part; fi
partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;
pxefile_addr_r=0x00600000
ramdisk_addr_r=0x0a200000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_scripts; run scan_dev_for_extlinux; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x00500000
serial#=f86cac3707ac07a2
soc=rockchip
stderr=serial,vidconsole
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
vendor=rockchip

Environment size: 3293/32764 bytes
=> 
arch=arm
baudrate=1500000
board=evb_rk3399
board_name=evb_rk3399
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=nvme mmc1 mmc0 usb0 pxe dhcp 
bootargs=storagemedia=sd androidboot.mode=sd
bootcmd=run distro_bootcmd;boot_android ${devtype} ${devnum};bootrkp;
bootcmd_dhcp=run boot_net_usb_start; run boot_net_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_nvme=echo Here trying to boot from nvme;dcache off;echo dcache off;pci e;nvme scan;setenv devnum 0;run nvme_boot;
bootcmd_pxe=run boot_net_usb_start; run boot_net_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=1
bootfile=/extlinux/extlinux.conf
bootfstype=fat
cpu=armv8
cpuid#=5456503934302e303000000000128483
devnum=0
devplist=1
devtype=nvme
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
ethact=ethernet@fe300000
ethaddr=8a:21:4c:f8:e6:f1
fdt_addr_r=0x08300000
fdt_overlay_addr_r=0x08200000
fdtcontroladdr=0xe9dc8260
fdtfile=rockchip/rk3399-rock-pi-4c.dtb
fileaddr=0x700000
filesize=0x70f
hw_conf_addr_r=0x00700000
kernel_addr_r=0x00280000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
nvme_boot=if nvme dev ${devnum}; then setenv devtype nvme; run scan_dev_for_boot_part; fi
partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;
pxefile_addr_r=0x00600000
ramdisk_addr_r=0x0a200000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_scripts; run scan_dev_for_extlinux; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x00500000
serial#=f86cac3707ac07a2
soc=rockchip
stderr=serial,vidconsole
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
vendor=rockchip

Environment size: 3293/32764 bytes
=> 

2 things to note here.

  1. I only typed printenv once. It apparently gives me the output twice. I’m merely posting it as is, just to be sure, but it’s probably everything twice.
  2. This is the u-boot as was suggested a couple posts back with the debian version that was suggested with it. The only storage connected to the device is an NVMe. There is no SD or eMMC. In terms of cables connected to the device. It only has the power cable connected and the serial lines on the gpio pins. Nothing else (no ethernet, monitor, usb, … nothing!)

I’m looking forward to the next command to run :stuck_out_tongue:
We’ll eventually (hopefully) get it working!

The “print twice” thing is a common mistake. It will happen with every command you use whatsoever, which might cause other interesting special effects.

Solution: Configure your serial port to send CR or LF to the board, not both.