U-Boot with direct NVMe boot support for eMMC/SPI Flash
(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
  Reply
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
  Reply
(12-29-2020, 08:35 PM)bwomp99 Wrote: ...
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?
...
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.

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.
--
Arwen Evenstar
Princess of Rivendale
  Reply
(12-30-2020, 09:43 AM)Arwen Wrote:
(12-29-2020, 08:35 PM)bwomp99 Wrote: ...
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?
...
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.

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?
  Reply
(01-03-2021, 01:21 PM)bwomp99 Wrote: ...
to do that I can (basically) just copy most of the root over to the NVMe and change the fstab - simple enough?
Yes, basically you copy all "/" to the NVMe, change it's "/etc/fstab" to reflect the new location.
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.
--
Arwen Evenstar
Princess of Rivendale
  Reply
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
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  NVMe SSD and battery life? dieselnutjob 3 277 04-19-2021, 01:55 PM
Last Post: slyecho
  PBP won't boot (no amber or green LED) ian-s-mcb 46 7,622 04-15-2021, 09:58 AM
Last Post: SnowyMountainWeb
Question erase spi flash aiminick 1 89 04-07-2021, 06:50 AM
Last Post: tophneal
  PIneBook Pro - Boot from SD mcdomx 12 8,929 03-29-2021, 01:13 AM
Last Post: 5825bc9762
  Selling Pinebook Pro 128GB version (w/ NVMe adaptor) due to lack of use VoT 3 740 03-19-2021, 03:11 AM
Last Post: jj282
  Happy eMMC and SDcard OS usage for Pinebook Pro Newbies... Paulie420 40 15,447 02-27-2021, 11:01 AM
Last Post: wdt
  Novice question: Pinebook Pro does boot (does it?) but black screen Gert V. 21 3,049 01-27-2021, 10:48 PM
Last Post: rimaille
  [split] U-Boot with NVMe support, keyboard & display working as400 83 29,619 01-27-2021, 12:48 AM
Last Post: as400
  Sudden Pinebook Pro boot problems ndp 3 733 01-21-2021, 09:51 AM
Last Post: ndp
  Pinebook Pro 128GB EMMC for sale **sold** dgkPBP 7 1,286 01-15-2021, 08:48 AM
Last Post: dgkPBP

Forum Jump:


Users browsing this thread: 3 Guest(s)