01-03-2020, 01:00 PM
(This post was last modified: 02-01-2020, 11:06 AM by sigmaris.
Edit Reason: Updated with new release with added PCI SATA boot support and some bugs fixed.
)
Update 2020-02-01: Made a new release based on v2020.01, with added SATA AHCI boot support, and a fix for the " rockchip_dnl_key_pressed: adc_channel_single_shot fail" issue where the Recover button wasn't being read successfully.
--
After seeing @ pcm720's thread on porting the RK3399 PCIe/NVMe driver from Radxa's Rock Pi 4 U-Boot version, and this guide to building U-Boot for RockPro64 with all mainline, open source components, I've copied the aforementioned PCIe driver into mainline U-Boot, fixed a bug in the driver, created some configuration for U-Boot and a build script to create U-Boot binaries for RockPro64 with SPI and NVMe boot support.
The code is available on Github and:
- is based on mainline U-Boot
- doesn't use any binary-only blobs for booting
- with support for installation to SPI flash
- with support for storing the U-Boot Environment in SPI flash (configured to store it at offset 0x3f8000 bytes, 8KBytes size)
- can insert "partition" entries in the SPI Flash device tree for Linux so that /dev/mtdX devices are created for each area of the SPI flash layout it uses (if there is a spi-nor flash node in Linux's device tree for it to stick them on)
- with support for booting Linux off an NVMe device
- with support for booting Linux off a SATA drive attached to a PCIe SATA controller (AHCI)
- also supports the normal U-Boot features of booting from eMMC/SD/USB/Network
You can see the differences between current U-Boot master and this version here.
I have tested the SPI installation, SPI environment saving & loading, USB boot, network boot, SATA boot, and NVMe boot on my RockPro64 with a Samsung 970 EVO Plus NVMe device. I don't have any other NVMe devices to test with, and I'd like to verify this works for others, so if anyone else is interested, and would like to test this build, read on. In particular I'm uncertain if this works for other NVMe devices and possibly other SPI flash chips - my RockPro64 has a Gigadevice gd25q128 chip, but I've heard some other versions may use Winbond flash chips which I haven't been able to test with.
The build script ( here) has several stages and builds several different binaries. The binaries attached to this release are:
- flash_spi.img.gz - this is an image which can be un-gzipped and written to an SD card, it starts U-Boot from the SD card and then runs this script to install U-Boot to SPI Flash. The image includes flash_spi.scr and spi_combined.img. More detailed info here.
- erase_spi.img.gz - this is an image similar to flash_spi.img.gz above, but instead it erases your SPI Flash using this script.
- flash_spi.scr - this is the compiled script to install U-Boot to SPI flash, it's not useful except for certain specific scenarios (if you want to make your own install SD-card). It is included in flash_spi.img.gz.
- mmc_idbloader.img - this is the image containing the TPL+SPL of U-Boot compiled for eMMC/SD card install, it should be written to eMMC or SD card at offset 64 sectors.
- mmc_u-boot.itb - this is the image containing U-Boot proper compiled for eMMC/SD card install, it should be written to eMMC or SD card at offset 16384 sectors.
- spi_idbloader.img - this is the image containing the TPL+SPL of U-Boot compiled for SPI Flash install, it should be written to SPI flash at offset 0, but for writing I recommend using spi_combined.img instead - see below.
- spi_u-boot.itb - this is the image containing U-Boot proper compiled for SPI Flash install, it should be written to SPI flash at offset 0x60000 bytes, but for writing I recommend using spi_combined.img instead - see below.
- spi_combined.img - this contains spi_idbloader.img, padding, and then spi_u-boot.itb at offset 0x60000 bytes, this can be written to SPI flash starting at offset 0 and will write spi_idbloader.img and spi_u-boot.itb at the correct locations.
For testing it - you'll need to have a serial / UART console available so that you can see log messages and interact with U-Boot that way - there is no HDMI or keyboard support in U-Boot.
Also, I strongly recommend *not* trying to flash it to SPI at first, since SPI is first in the RK3399 boot order, so if you flash something there and it doesn't work, your board is useless until you temporarily disable SPI to recover it.
Instead, first as a test just write mmc_idbloader.img and mmc_u-boot.itb to a spare SD card, remove / disable eMMC and SPI if you are currently booting off them, and test the NVMe boot functionality by booting off SD card, interrupting U-boot at the "Hit any key to stop autoboot" stage, and then entering: run bootcmd_nvme0 at the U-Boot => prompt to scan the NVMe device for bootable files and boot from it. On your NVMe drive, you just need something U-Boot can boot, e.g. a root partition with a /boot/extlinux/extlinux.conf or /boot/boot.scr telling it how to load the kernel, initrd and FDT file.
Then, if testing using a spare SD card works successfully, try installing to SPI, making sure you have a way to recover by disabling SPI temporarily if needed.
Some caveats: I've seen it mentioned that the PCIe driver for RK3399 from the Rock Pi 4 U-Boot is somewhat buggy, and looking at the code it seems like some PCIe features are missing or deliberately disabled; there is no support for more than one PCI device and no support for any other type of device apart from NVMe (so no PCI SATA adapter support at the moment, sorry). I don't know enough about the RK3399 PCIe controller to be able to find any more bugs from reading the code, but they might be there. Update: this is now using an updated PCIe driver from Patrick Wildt, based on OpenBSD's driver, and now does support PCI SATA adapters that implement the AHCI standard.
Also, if you're not sure what "write mmc_idbloader.img to eMMC or SD card at offset 64 sectors." means or how to do that, I recommend not trying this at all until some other folks have verified that it works, and it's packaged in an easier to use format.
01-03-2020, 01:34 PM
(This post was last modified: 01-03-2020, 01:34 PM by Jeremiah Cornelius.
Edit Reason: spelling
)
This is an outstanding community contribution and a solid stepping-stone towards maturity of the platform.
Thank you!
— Jeremiah Cornelius
"Be the first person not to do something, that no one has thought of not doing before’’
— Brian Eno, "Oblique Strategies"
01-03-2020, 07:52 PM
(This post was last modified: 01-03-2020, 08:01 PM by belfastraven.)
(01-03-2020, 01:00 PM)sigmaris Wrote: After seeing @pcm720's thread on porting the RK3399 PCIe/NVMe driver from Radxa's Rock Pi 4 U-Boot version, and this guide to building U-Boot for RockPro64 with all mainline, open source components, I've copied the aforementioned PCIe driver into mainline U-Boot, fixed a bug in the driver, created some configuration for U-Boot and a build script to create U-Boot binaries for RockPro64 with SPI and NVMe boot support.
The code is available on Github and:
- is based on mainline U-Boot
- doesn't use any binary-only blobs for booting
- with support for installation to SPI flash
- with support for storing the U-Boot Environment in SPI flash (configured to store it at offset 0x3f8000 bytes, 8KBytes size)
- can insert "partition" entries in the SPI Flash device tree for Linux so that /dev/mtdX devices are created for each area of the SPI flash layout it uses (if there is a spi-nor flash node in Linux's device tree for it to stick them on)
- with support for booting Linux off an NVMe device
- also supports the normal U-Boot features of booting from eMMC/SD/USB/Network
You can see the differences between current U-Boot master and this version here.
I have tested the SPI installation, SPI environment saving & loading, USB boot, network boot, and NVMe boot on my RockPro64 with a Samsung 970 EVO Plus NVMe device. I don't have any other NVMe devices to test with, and I'd like to verify this works for others, so if anyone else is interested, and would like to test this build, read on. In particular I'm uncertain if this works for other NVMe devices and possibly other SPI flash chips - my RockPro64 has a Gigadevice gd25q128 chip, but I've heard some other versions may use Winbond flash chips which I haven't been able to test with.
The build script (here) has several stages and builds several different binaries. The binaries attached to this release are:
- flash_spi.img.gz - this is an image which can be un-gzipped and written to an SD card, it starts U-Boot from the SD card and then runs this script to install U-Boot to SPI Flash. The image includes flash_spi.scr and spi_combined.img. More detailed info here.
- flash_spi.scr - this is the compiled script to install U-Boot to SPI flash, it's not useful except for certain specific scenarios (if you want to make your own install SD-card). It is included in flash_spi.img.gz.
- mmc_idbloader.img - this is the image containing the TPL+SPL of U-Boot compiled for eMMC/SD card install, it should be written to eMMC or SD card at offset 64 sectors.
- mmc_u-boot.itb - this is the image containing U-Boot proper compiled for eMMC/SD card install, it should be written to eMMC or SD card at offset 16384 sectors.
- spi_idbloader.img - this is the image containing the TPL+SPL of U-Boot compiled for SPI Flash install, it should be written to SPI flash at offset 0, but for writing I recommend using spi_combined.img instead - see below.
- spi_u-boot.itb - this is the image containing U-Boot proper compiled for SPI Flash install, it should be written to SPI flash at offset 0x60000 bytes, but for writing I recommend using spi_combined.img instead - see below.
- spi_combined.img - this contains spi_idbloader.img, padding, and then spi_u-boot.itb at offset 0x60000 bytes, this can be written to SPI flash starting at offset 0 and will write spi_idbloader.img and spi_u-boot.itb at the correct locations.
For testing it - you'll need to have a serial / UART console available so that you can see log messages and interact with U-Boot that way - there is no HDMI or keyboard support in U-Boot.
Also, I strongly recommend *not* trying to flash it to SPI at first, since SPI is first in the RK3399 boot order, so if you flash something there and it doesn't work, your board is useless until you temporarily disable SPI to recover it.
Instead, first as a test just write mmc_idbloader.img and mmc_u-boot.itb to a spare SD card, remove / disable eMMC and SPI if you are currently booting off them, and test the NVMe boot functionality by booting off SD card, interrupting U-boot at the "Hit any key to stop autoboot" stage, and then entering: run bootcmd_nvme0 at the U-Boot => prompt to scan the NVMe device for bootable files and boot from it. On your NVMe drive, you just need something U-Boot can boot, e.g. a root partition with a /boot/extlinux/extlinux.conf or /boot/boot.scr telling it how to load the kernel, initrd and FDT file.
Then, if testing using a spare SD card works successfully, try installing to SPI, making sure you have a way to recover by disabling SPI temporarily if needed.
Some caveats: I've seen it mentioned that the PCIe driver for RK3399 from the Rock Pi 4 U-Boot is somewhat buggy, and looking at the code it seems like some PCIe features are missing or deliberately disabled; there is no support for more than one PCI device and no support for any other type of device apart from NVMe (so no PCI SATA adapter support at the moment, sorry). I don't know enough about the RK3399 PCIe controller to be able to find any more bugs from reading the code, but they might be there.
Also, if you're not sure what "write mmc_idbloader.img to eMMC or SD card at offset 64 sectors." means or how to do that, I recommend not trying this at all until some other folks have verified that it works, and it's packaged in an easier to use format.
This is very exciting. I am happy to test this, as I have already messed up my flash a few times and am adept at shortings pins 23 and 25 and getting into makrom mode to fix things :-)
Running as you have suggested, from the SD card, I am getting the following: this is from a current armbian mainline build. I normally would be booting from an DS card on which I have written mainline u-boot, as armbian is still using the old rockchip based u-boot for this board. This is a Samsung pm981 nvme. It is formatted btrs? Is that the problem, or should I be checking something else?
-Boot TPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:42)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:42 +0000)
Trying to boot from MMC1
NOTICE: BL31: v2.2(release):v2.2-277-gb1af2a51
NOTICE: BL31: Built : 15:44:18, Jan 3 2020
U-Boot 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:42 +0000)
Model: Pine64 RockPro64
DRAM: 3.9 GiB
PMIC: RK808
MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment
In: serial@ff1a0000
Out: serial@ff1a0000
Err: serial@ff1a0000
Model: Pine64 RockPro64
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
=> run bootcmd_nvme0
Device 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
** Unrecognized filesystem type **
JI'm just including the log this time so that you can see that I did use the proper images....
Once again, thanks.
01-04-2020, 04:04 AM
(This post was last modified: 01-04-2020, 06:16 AM by sigmaris.
Edit Reason: added link to build artefacts
)
(01-03-2020, 07:52 PM)belfastraven Wrote: ...
=> run bootcmd_nvme0
Device 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
** Unrecognized filesystem type **
JI'm just including the log this time so that you can see that I did use the proper images....
Once again, thanks.
@ belfastraven thanks for testing, and pasting the full log here. Looks like your NVMe device is detected OK, I suspect the "Unrecognized filesystem type" problem is just because there is no BTRFS support in this build (it's not enabled in U-Boot by default).
I enabled BTRFS in the config and re-built U-Boot, I haven't tested this yet but you could try using the resulting build, attached:
mmc_u-boot.zip (Size: 471.35 KB / Downloads: 527)
Edit: if you need the SPI binaries from this build, they can be downloaded from this build artifacts page.
(01-04-2020, 04:04 AM)sigmaris Wrote: (01-03-2020, 07:52 PM)belfastraven Wrote: ...
=> run bootcmd_nvme0
Device 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
** Unrecognized filesystem type **
JI'm just including the log this time so that you can see that I did use the proper images....
Once again, thanks.
@belfastraven thanks for testing, and pasting the full log here. Looks like your NVMe device is detected OK, I suspect the "Unrecognized filesystem type" problem is just because there is no BTRFS support in this build (it's not enabled in U-Boot by default).
I enabled BTRFS in the config and re-built U-Boot, I haven't tested this yet but you could try using the resulting build, attached:
Edit: if you need the SPI binaries from this build, they can be downloaded from this build artifacts page. Just wnted to let you know that I tried with the new u-boot images. I no longer got the UnrecognizedFilesystem message, but got a scanning message, then got returned to the u-boot prompt. I changed the armbian build to use ext4 for the nvme, and did reach the kernel starting message, but then hung. I believe this is because the armbian bootscript specifies the partition for u-boot, and seems to specify that it use the same partition from which the spl-tpl image ran. I am going to try to get the armbian images to work, but am now going to try with a manjaro build (which has a much simpler boot script. :-). I'm reasonably good with "c" "bash" not so much...
01-04-2020, 04:10 PM
(This post was last modified: 01-05-2020, 02:31 AM by Bullet64.)
Many thanks for your work!!!
I have seen an booting NVMe device  But i got some errors. Tomorrow i will do more tests.....
Update
Works fine! 
Code: U-Boot TPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36 +0000)
Trying to boot from SPI
NOTICE: BL31: v2.2(release):v2.2-277-gb1af2a51
NOTICE: BL31: Built : 15:44:18, Jan 3 2020
U-Boot 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36 +0000)
Model: Pine64 RockPro64
DRAM: 2 GiB
PMIC: RK808
MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 B
*** Warning - bad CRC, using default environment
In: serial@ff1a0000
Out: serial@ff1a0000
Err: serial@ff1a0000
Model: Pine64 RockPro64
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1055 bytes read in 8 ms (127.9 KiB/s)
select kernel
1: kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339
2: kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339-memtest
Enter choice: 1: kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339
Retrieving file: /boot/initrd.img-4.4.197-1236-rockchip-ayufan-g30faab37e339
5143934 bytes read in 224 ms (21.9 MiB/s)
Retrieving file: /boot/vmlinuz-4.4.197-1236-rockchip-ayufan-g30faab37e339
20545544 bytes read in 874 ms (22.4 MiB/s)
append: rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=62:03:b0:d6:dc:b3 4
Retrieving file: /boot/dtbs/4.4.197-1236-rockchip-ayufan-g30faab37e339/rockchipb
96273 bytes read in 17 ms (5.4 MiB/s)
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Ramdisk to 7da26000, end 7df0dd7e ... OK
ERROR: reserving fdt memory region failed (addr=0 size=0)
Loading Device Tree to 000000007da0b000, end 000000007da25810 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[...gekürzt...]
Filesystem
Code: rock64@rockpro64:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 960M 0 960M 0% /dev
tmpfs 193M 7.7M 185M 4% /run
/dev/nvme0n1p7 1.9G 1.1G 669M 62% /
tmpfs 963M 0 963M 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 963M 0 963M 0% /sys/fs/cgroup
/dev/nvme0n1p6 112M 4.0K 112M 1% /boot/efi
tmpfs 193M 0 193M 0% /run/user/1000
Attention, you must resize filesystem for
Sorry for any mistakes. English is not my native language
1. Quartz64 Model B, 4GB RAM
2. Quartz64 Model A, 4GB RAM
3. RockPro64 v2.1
https://linux-nerds.org/
01-05-2020, 03:22 AM
(This post was last modified: 01-05-2020, 03:27 AM by Bullet64.)
@ sigmaris works boot from usb3 with this uboot? Don't work for me.
I am using this image
Code: buster-minimal-rockpro64-0.9.16-1163-arm64.img
Sorry for any mistakes. English is not my native language
1. Quartz64 Model B, 4GB RAM
2. Quartz64 Model A, 4GB RAM
3. RockPro64 v2.1
https://linux-nerds.org/
@ Bullet64 I'm glad you're having some success with this. You might be aware of this already, but in this log:
(01-04-2020, 04:10 PM)Bullet64 Wrote: ...
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1055 bytes read in 8 ms (127.9 KiB/s)
select kernel
...
it shows U-Boot is reading /boot/extlinux/extlinux.conf off the SD card, not the NVMe device. However this would still work if you tell Linux the root filesystem is on NVMe, e.g. with a root=UUID="..." entry in the kernel command line, since Linux would later detect the NVMe device and mount the root filesystem on it.
On the other hand, it *should* be possible to have U-Boot read /boot/extlinux/extlinux.conf and the kernel and initrd off the NVMe device directly, and not involve an SD card at all.
(01-05-2020, 03:22 AM)Bullet64 Wrote: @sigmaris works boot from usb3 with this uboot? Don't work for me.
I am using this image
Code: buster-minimal-rockpro64-0.9.16-1163-arm64.img
I've tested that booting Linux from a SanDisk USB-stick works (if it's plugged in to either the USB 3.0 or USB 2.0 Type-A ports) but that USB-stick would only be using USB 2.0, I don't have any USB3 disks to test with at the moment. I'll see if I can get one to try out.
Out of curiosity, is boot from a USB3 disk working for you with the Rockchip downstream/vendor U-Boot ( https://github.com/rockchip-linux/u-boot/ or one of the other U-Boot builds which is derived from Rockchip's source code, e.g. Ayufan's)?
Oh, sorry. I add wrong log.
Code: U-Boot TPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36 +0000)
Trying to boot from SPI
NOTICE: BL31: v2.2(release):v2.2-277-gb1af2a51
NOTICE: BL31: Built : 15:44:18, Jan 3 2020
U-Boot 2020.01-rc5-01969-g0bfd4738c6 (Jan 03 2020 - 15:46:36 +0000)
Model: Pine64 RockPro64
DRAM: 2 GiB
PMIC: RK808
MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 B
*** Warning - bad CRC, using default environment
In: serial@ff1a0000
Out: serial@ff1a0000
Err: serial@ff1a0000
Model: Pine64 RockPro64
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
Card did not respond to voltage select!
Device 0: Vendor: 0x144d Rev: 1B2QEXE7 Prod: S466NX0K606125A
Type: Hard Disk
Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Scanning nvme 0:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
2073 bytes read in 4 ms (505.9 KiB/s)
select kernel
1: kernel-4.4.202-1237-rockchip-ayufan-gfd4492386213
2: kernel-4.4.202-1237-rockchip-ayufan-gfd4492386213-memtest
3: kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339
4: kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339-memtest
Only USB3-Device what is booting from Kamils u-boot is my Samsung T5 SSD and my Corsair GTX USB3-Stick.
I have flashed u-boot to SPI.
What is booting?
What not?
Thanks for your work. When i can help testing, let me know.
Sorry for any mistakes. English is not my native language
1. Quartz64 Model B, 4GB RAM
2. Quartz64 Model A, 4GB RAM
3. RockPro64 v2.1
https://linux-nerds.org/
(01-04-2020, 04:04 AM)sigmaris Wrote: (01-03-2020, 07:52 PM)belfastraven Wrote: ...
=> run bootcmd_nvme0
Device 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
** Unrecognized filesystem type **
JI'm just including the log this time so that you can see that I did use the proper images....
Once again, thanks.
@belfastraven thanks for testing, and pasting the full log here. Looks like your NVMe device is detected OK, I suspect the "Unrecognized filesystem type" problem is just because there is no BTRFS support in this build (it's not enabled in U-Boot by default).
I enabled BTRFS in the config and re-built U-Boot, I haven't tested this yet but you could try using the resulting build, attached:
Edit: if you need the SPI binaries from this build, they can be downloaded from this build artifacts page. I now have armbian booting from SPI flash u-boot, its great to be booting from SPI running 5.4.8 kernel with current u-boot. I have booted sdcard, emmc and pcie NVME. I haven't tried with USB ports yet. I had gone back to ext4.
Have you thought of including an image like your flash image, that would just 0-out the flash in case of problems. I believe ayufan has one https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rockpro64.img.xz
thanks again.
|
