+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112)
+--- Thread: U-Boot with direct NVMe boot support for eMMC/SPI Flash (/showthread.php?tid=8439)
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - bwomp99 - 12-29-2020
(11-27-2019, 03:34 PM)pcm720 Wrote: Update (08/07/2020):
Now there's also an option to use mainline U-Boot (v2020.07) with reference ARM Trusted Firmware, no need to use Rockchip blobs anymore.
You can build it yourself using this repository and flash the image as usual (flash_erase + dd works for Manjaro):
https://github.com/pcm720/u-boot-build-scripts
The build script uses patches from dhivael, sigmaris and Manjaro.
v2020.07 binaries for SD/eMMC and SPI Flash are available as well, you can find them on Releases page of the repo.
The resulting SPI image works on my PBP and boots from NVMe just fine.
Boot priority is SD -> eMMC -> NVMe -> USB, and there's no need to destroy U-Boot on SD card anymore.
---------
I am today years old when I realized ARM doesn't function with a BIOS like x86 so I'm trying to figure this all out. Jumped the gun and got an NVME and adapter, so trying to find a way to boot off of it. I still have the stock Manjaro that came with the PBP but I might want to switch over to a debian base just because that's what I've used in the past.
Anyway, I see your update here from August, but when I try clone this repo and try to run the build.sh, it keeps asking me to set my account's default identity on git. So i do that and then it tells me this:
Code:
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
make: *** No rule to make target 'realclean'. Stop.
make: *** No rule to make target 'bl31'. Stop.
cp: cannot stat 'build/rk3399/release/bl31/bl31.elf': No such file or directory
make: *** No rule to make target 'realclean'. Stop.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
make: *** No rule to make target 'mrproper'. Stop.
cp: cannot stat '../build/bl31.elf': No such file or directory
make: *** No rule to make target 'pinebook-pro-rk3399_defconfig'. Stop.
make: *** No targets specified and no makefile found. Stop.
./build.sh: line 37: tools/mkimage: No such file or directory
dd: failed to open 'idbloader-spi.img': No such file or directory
cat: u-boot.itb: No such file or directory
cp: cannot stat 'idbloader-spi.img': No such file or directory
cp: cannot stat 'idbloader.img': No such file or directory
cp: cannot stat 'u-boot.itb': No such file or directory
make: *** No rule to make target 'mrproper'. Stop.Am I going about this all wrong? I've seen other discussions that talk about skipping messing with the SPI and just make the eMMC your /boot and put the rest of root (more or less) mounted on the NVME - is that good enough?
Appreciate the help and patience
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - wdt - 12-29-2020
It is NOT at all wise to put any uboot on SPI until you have thoroughly tested it
Be aware the the uboot package for SPI is a bit different,,,, uboot at 6M and idbloader 'expanded'
One way to test,, on emmc, save mbr, save 1st 16M, blank (/dev/zero) 1st 16M, restore mbr
Then, only the uboot on SD is available, to boot emmc use a small (tiny) SD
with ONLY uboot on it (idbloader, uboot.itb OR idbloader,uboot.img,trust.img,,, mainline vrs bsp)
You will find that uboot (for pbp) is NOT at all mature
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - Arwen - 12-30-2020
(12-29-2020, 08:35 PM)bwomp99 Wrote: ...It is much simpler to use the eMMC as the initial boot device, than mess with the SPI. That might change a year from now.
Am I going about this all wrong? I've seen other discussions that talk about skipping messing with the SPI and just make the eMMC your /boot and put the rest of root (more or less) mounted on the NVME - is that good enough?
...
And yes, you can have "/boot" on the eMMC, along with U-Boot. Then use the NVMe for everything else. It won't cost you much extra in boot time. But the reduction in problems could be dramatic.
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - bwomp99 - 01-03-2021
(12-30-2020, 09:43 AM)Arwen Wrote:(12-29-2020, 08:35 PM)bwomp99 Wrote: ...It is much simpler to use the eMMC as the initial boot device, than mess with the SPI. That might change a year from now.
Am I going about this all wrong? I've seen other discussions that talk about skipping messing with the SPI and just make the eMMC your /boot and put the rest of root (more or less) mounted on the NVME - is that good enough?
...
And yes, you can have "/boot" on the eMMC, along with U-Boot. Then use the NVMe for everything else. It won't cost you much extra in boot time. But the reduction in problems could be dramatic.
to do that I can (basically) just copy most of the root over to the NVMe and change the fstab - simple enough?
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - Arwen - 01-04-2021
(01-03-2021, 01:21 PM)bwomp99 Wrote: ...Yes, basically you copy all "/" to the NVMe, change it's "/etc/fstab" to reflect the new location.
to do that I can (basically) just copy most of the root over to the NVMe and change the fstab - simple enough?
And then change "/boot/x/y" to reflect the new root location on the kernel command line. Like;
linux /linux-5.4.72-gentoo.3 root=/dev/nvme0n1p1 ...
I've left off the exact path to the U-Boot config file, (the "x/y"), as I don't have that information handy.
Further, some distros keep the master U-Boot config file on "/etc/" somewhere, so "/boot/x/y" might get over-written on OS update.
If that does not work and you need to restore, simply boot off a SD card, (which you should make sure you have both a working one and that U-Boot recognizes it as boot target). Then modify the eMMC's "/boot/x/y" again, but restore the old until you can figure out what went wrong.
I can't give exact steps as I've not done it. But others have.
My suggestion is to come up with the steps first, including the back out plan. Then implement. If something goes wrong, you at least have a plan you can update with any missing step.
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - wdt - 01-04-2021
A little bit of precision here
Sometimes there is a template extlinux.conf in /etc/default, this is a debian thing mostly(ubuntu too?)
It unclear which has priority ,, boot.scr, extlinux.conf or BOOTAA64.EFI
since the initrd runs AFTER kernel (and this where mounting happens)
uboot looks for /boot.scr OR /boot/boot.scr (2partition, separate boot or 1 partition)
OR /extlinux/extlinux.conf or /boot/extlinux/extlinux.conf
Anyway, you have to change both fstab and extlinux.conf,
extlinux.conf has to point to root FS, can be device or UUID or LABEL
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - jiyong - 05-13-2021
The latest U-Boot that ships with Manjaro has support for direct boot from NVMe?
https://forum.manjaro.org/t/nvme-support-in-uboot-pinebookpro-2021-04-1/63774
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - tophneal - 05-13-2021
(05-13-2021, 08:15 AM)jiyong Wrote: The latest U-Boot that ships with Manjaro has support for direct boot from NVMe?
https://forum.manjaro.org/t/nvme-support-in-uboot-pinebookpro-2021-04-1/63774
It should, yes. IIRC Manjaro BSP uboot is mrfixit2001's. The changes in this uboot, should have already been pulled into that uboot. I believe that in order to boot from nvme, you will need to keep the uboot on the emmc still.
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - calinb - 06-08-2021
(05-13-2021, 11:44 AM)tophneal Wrote: It should, yes. IIRC Manjaro BSP uboot is mrfixit2001's. The changes in this uboot, should have already been pulled into that uboot. I believe that in order to boot from nvme, you will need to keep the uboot on the emmc still.
I will probably try the Manjaro BSP uboot first I but might risk flashing spiflash.bin.
I removed the "CROSS_COMPILE=aarch64-linux-gnu-" from pcm720s script and built:
765556 Jun 7 23:37 u-boot.itb
164910 Jun 7 23:37 idbloader.img
331776 Jun 7 23:37 idbloader-spi.img
1289844 Jun 7 23:37 spiflash.bin
My natively compiled files are all a bit smaller than the pre-built files here:
https://github.com/pcm720/u-boot-build-scripts/releases/tag/v2020.07
If I decide to flash my SPI, would it be less risky to flash the pre-built spiflash.bin file, given that it's worked for others here?
I just discovered these newer images. I think they are the latest but my native-build files are still smaller.
https://github.com/pcm720/u-boot-build-scripts/releases
RE: U-Boot with direct NVMe boot support for eMMC/SPI Flash - sepp - 06-24-2021
(01-04-2021, 08:52 AM)Arwen Wrote:decent advice - thanks(01-03-2021, 01:21 PM)bwomp99 Wrote: ...Yes, basically you copy all "/" to the NVMe, change it's "/etc/fstab" to reflect the new location.
to do that I can (basically) just copy most of the root over to the NVMe and change the fstab - simple enough?
And then change "/boot/x/y" to reflect the new root location on the kernel command line. Like;
linux /linux-5.4.72-gentoo.3 root=/dev/nvme0n1p1 ...
I've left off the exact path to the U-Boot config file, (the "x/y"), as I don't have that information handy.
Further, some distros keep the master U-Boot config file on "/etc/" somewhere, so "/boot/x/y" might get over-written on OS update.
If that does not work and you need to restore, simply boot off a SD card, (which you should make sure you have both a working one and that U-Boot recognizes it as boot target). Then modify the eMMC's "/boot/x/y" again, but restore the old until you can figure out what went wrong.
I can't give exact steps as I've not done it. But others have.
My suggestion is to come up with the steps first, including the back out plan. Then implement. If something goes wrong, you at least have a plan you can update with any missing step.