11-29-2019, 10:59 AM
(This post was last modified: 11-29-2019, 11:01 AM by pcm720.)
(11-29-2019, 09:18 AM)tophneal Wrote: (11-27-2019, 03:34 PM)pcm720 Wrote: Of course, since SPI flash is a no-go for now, U-Boot lives on eMMC: you still have to keep it connected. But that's a start.
Pardon my ignorance, but why is u-boot on SPI a no-go for us right now? I've noticed that other rk3399 hardware has achieved it (Khadas Edge has a script to flash u-boot to SPI in their wiki.) Would it not be possible to adapt these existing tools to flash SPI on the PBP?
Awesome work on this modification, btw! I'm looking forward to loading it onto my CrOs install today.
Thanks!
SPI is a no-go for the same reasons Pine64 ships their U-Boot on eMMC: there is no safe way of flashing it and no easy way to recover.
Plus, I guess there's still work to do: it would be nice to have display and keyboard working in the pre-boot, before they're initialized by the kernel.
(11-29-2019, 10:59 AM)pcm720 Wrote: ...
Thanks!
SPI is a no-go for the same reasons Pine64 ships their U-Boot on eMMC: there is no safe way of flashing it and no easy way to recover.
Plus, I guess there's still work to do: it would be nice to have display and keyboard working in the pre-boot, before they're initialized by the kernel. There is a program to write the SPI flash. How safe it is, I don't know. Perhaps I will play with it on my ROCKPro64, (same RK3399 & SPI). It has an easier way via header connector to disable the SPI flash if a U-Boot image does not work.
I did come up with a scheme to make using the SPI safer. Since it's 16MBytes, we can likely store 2 U-Boot images. The idea is to keep the working one, but add a new one for additional features. If the new one fails spectacularly, and prevents any other recovery, we power off. Then insert a special SD card, which the initial SPI image would check the SD card for a special signature. Like a 64 byte code at a specific location. Then fail back to the older, working U-Boot image. (Or a second 64 byte code that causes a boot to the SD card.)
Anyway, I will start a thread somewhere so we can pick it apart. And hopefully re-assemble it into something that would work for U-Boot on SPI flash.
--
Arwen Evenstar
Princess of Rivendale
Well done, I am happy to see that we can boot our PBPs from the NVMe... how drastic is the performance increase? do you happen to have any comparative specs, OP?
11-30-2019, 10:28 AM
(This post was last modified: 11-30-2019, 10:42 AM by pcm720.)
(11-30-2019, 01:13 AM)clover Wrote: Well done, I am happy to see that we can boot our PBPs from the NVMe... how drastic is the performance increase? do you happen to have any comparative specs, OP?
No, because there isn't any performance increase.
It's just a bootloader: kernel, device tree and initrd aren't big enough to benefit from NVMe speeds.
The only diference is that it now you can keep boot files directly on your NVMe drive and not bother with mounting eMMC as /boot.
11-30-2019, 12:06 PM
(This post was last modified: 11-30-2019, 12:06 PM by mamboman777.)
I think what we are asking is for a test comparing all of the os loaded on an emmc vs nvme. I understand that putting boot on emmc and everything else on nvme will be similar to everything on nvme. I'm curious what the difference between everything on emm and everything on nvme is.
I haven't really spent a lot of time with eMMC, but I feel that the difference in not big enough to notice.
Yes, it's a little bit snappier, but you still have to wait for applications to load since the real bottleneck here is the CPU.
Anyway, I can't really do any comparisons since I don't have the eMMC in my PBP anymore.
The repository was updated with SPI image 
12-03-2019, 12:25 AM
(This post was last modified: 12-03-2019, 12:35 AM by Wizzard.)
(12-02-2019, 10:27 PM)pcm720 Wrote: I haven't really spent a lot of time with eMMC, but I feel that the difference in not big enough to notice.
Yes, it's a little bit snappier, but you still have to wait for applications to load since the real bottleneck here is the CPU.
Anyway, I can't really do any comparisons since I don't have the eMMC in my PBP anymore.
The repository was updated with SPI image
So we can finally boot directly from NVMe? What do we have to do for that?
edit: I noticed this link https://github.com/pcm720/rockchip-u-boot/releases and this step:
# dd if=spiflash.bin of=/dev/mtd0
So after flashing, it will allow to boot from NVMe without eMMC? what about SD card priority?
(12-03-2019, 12:25 AM)Wizzard Wrote: (12-02-2019, 10:27 PM)pcm720 Wrote: I haven't really spent a lot of time with eMMC, but I feel that the difference in not big enough to notice.
Yes, it's a little bit snappier, but you still have to wait for applications to load since the real bottleneck here is the CPU.
Anyway, I can't really do any comparisons since I don't have the eMMC in my PBP anymore.
The repository was updated with SPI image
So we can finally boot directly from NVMe? What do we have to do for that?
edit: I noticed this link https://github.com/pcm720/rockchip-u-boot/releases and this step:
# dd if=spiflash.bin of=/dev/mtd0
So after flashing, it will allow to boot from NVMe without eMMC? what about SD card priority?
Yes. The U-Boot is set up to look for boot scripts/extlinux configuration files in the following order: microSD, NVMe, eMMC, anything else.
However, there's a catch with pre-made microSD images. See OP for details.
12-03-2019, 06:22 AM
(This post was last modified: 12-03-2019, 06:27 AM by Wizzard.)
(12-03-2019, 06:09 AM)pcm720 Wrote: Yes. The U-Boot is set up to look for boot scripts/extlinux configuration files in the following order: microSD, NVMe, eMMC, anything else.
However, there's a catch with pre-made microSD images. See OP for details.
Great! But what do you mean by that catch? Where do I find the details?
edit: ok, I get it, read another thread 
No, the details are in the opening post of this very same thread.
|
