Uses for SPI Flash

[z4v4l]

no, you got it wrong. in that scenario, SD card will be probed.

[tsago]

If you use my images there's already a script that allows you to use SPI Flash.

The functionality of uboot are kind of limited (no PCIE support), but it should be enough to play with:
- rock64_write_spi_flash.sh
- rock64_erase_spi_flash.sh

It works for rock64/rockpro64/pinebook-pro.

I hope that I adapt that soon to support also NVME drives, so it would actually make a difference.

What is the easiest/correct way to unbrick PBP in case of messed spi flash content?

no, you got it wrong. in that scenario, SD card will be probed.

Ah thanks for the correction! So we will always be able to recover from a nuked device with a compatible OS image on an SD card, that's great!

[enip]

Ah thanks for the correction! So we will always be able to recover from a nuked device with a compatible OS image on an SD card, that's great!

I think you've got it wrong. z4v4l did respond to your message, not mine.

The case I'm interested in is not a wiped SPI, but a messed one: it has a correct header or something which the BROM check for a bootable device, but the rest is a mess. So the BROM surely boots into SPI.

[bcnaz]

Any normal firmware lets you set up the boot order. Suporting NVMHCI in the ROM code would be an overkill, none of mask ROM codes provide such. it's definitely a job for the FW (don't confuse these, what Rockchip provides is not a FW, it's an "engine" for rolling out the FW). And of course, no matter where - UEFI, ARC or OF, support for NVMHCI (or USB mass storage or anything else) should be created to exist.
OF is an obsoleted standard, it doesn't evolve. UEFI does. And it is very extensible, it doesn't require to be GUI (but every self-respected vendor will provide it, since it's a useful feature for users), but also it provides its "shell" (command interpreter), and therefore - scripting capabilities and even has a byte code instruction set for architecture independent drivers. It integrates well with modern configuration standards like ACPI and given its implementation is not bloated AF, it will fit into even a couple of megs. I am not aware of someone working on OF for ARM. Linaro only pulled device trees out of it and brought them into linux, so did uboot following the latter unconditionally, but it's not OF. Any FW could be installed in any place where ROM code can locate it:

• - SPI
  
• - eMMC boot partitions (areas) - if ROM code can load from there
  
• - eMMC general purpose area
  
• - SD
  
• - all kinds of raw NAND devices
  

(For development purposes, having FW on SD is the best, for end users - obviously on SPI NOR flash chip).
And then, the FW can boot (OS loader->OS) from whatever source it can reach - even from the network (iSCSI, PXE, TFTP). This is how it is on x86 and nothing prevents it to happen on ARM. the current inability to boot the OS from NVMe drives or USB ones is lacking features in uboot.

    ?
For us 'consumer' level users would it be possible to use a sd card to put the correct firmware on the SPI...?
  to make the PCIe device bootable, 
  and then install the operating system using another sd card on the NVMe drive  ?
  (  I think AYUFAN  kind of hinted at this,  in  another post on this thread )  ?
  OF Course that would require the correct programming be written and available to the consumer users.

                 Thanks  !

[z4v4l]

yes, it would be possible. it's possible technically - booting from SD works - the things left are 1) ensuring  SPI flashed firmware isn't prone to bricking the board, and 2) making it understand PCIe/NVMHCI, of course.
as an example, for the illustration, you download the image of your choice and it is provided not as a plain image, but as a live image, that being first run out of an SD card, gives you opportunity to either run as a live session (for familiarizing) or start installation. if the installation has been chosen, the installer then lets you choose the OS installation target device (eMMC, NVMe SSD, or even USB storage - because why not for SBCs, the latter is not kewl for a laptop though). then it asks you of whether you want to install/update firmware and if you do, again, it will give you choice (theoretically, apart from SPI, it could be eMMC, with the boot areas includingly! however this is too optimistic - not all ROM codes understand reading eMMC boot areas, anyway, general purpose area is always ready, and even an SD card - but one probably won't want this scenario for the laptop). and finally installing/updating all these things where needed. this is a whole installation procedure, not that easy (and dumb) as dd-ing, it's harder to accomplish, but it has advantages, for example, it would take care of proper initializing GUIDs inside a GPT partitioned drive - they, GUIDs, need to be unique for every disk and partition in the whole Universe, rockchip already uses the GPT scheme, but of course dd-ing violates GPT badly. and many other benefits. but it's only an example intended to clarify the answer to your question. also, when things get even more developed, it will be possible to update firmware through the fancy firmware user interface. ^_^ in short, it's possible. as I understood, the main obstacle is lack of NVMHCI support in uboot. using eMMC as an OS installation target is a good solution. you of course still can use NVMe SSD for your data.

[bcnaz]

EFIFY

So, Would the SPI be flashed with the first sd card to install the correct firmware so it will "Look" for the NVMe drive ?
and then use a second sd card to install the operating system to the NVMe drive ?
Ideally, if you are in 'Live' mode on the sd card, it 'could be possible' to just have it start and install with one card, but I do not know if that option is open at this time.. ?

( or, use the sd card as the boot media which directs it to the NVMe, but that would require keeping the sd card installed ? )
( But no bricking the board then ? )
I have read many of your posts, so if you tell me it cannot be done, or cannot be done yet, I can accept that.
Thanks

[z4v4l]

you should understand the difference between what is possible (to do with PBP, in this respect) in theory and what is available now. now your (safe) option is to flash the image, containing both uboot and linux, onto eMMC or use what's preinstalled there while use NVMe SSD as an additional storage device, because it is not supported (yet) by FW for the OS booting (still, with some trickery, you can have something even now, read at the end). In future, it may change, NVMHCI may get support in uboot and then direct OS booting from there will be reality, but I don't know if that will happen. and I don't know how exactly installation process will look like then, it depends on how it is implemented, but to answer your question - no, there is no need to have 2 SD cards for the whole installation. it's not needed. installation may vary from an edgy, careless script plainly dd-ing things from a source to a target to a sophisticated installation program with fancy interface and loads of options and questions to you. I assume all provided images have uboot inside, that behaves the same way as the preflashed one, with respect to boot ordering, meaning they give SD the highest priority - this thing lets you flash different linux distributions onto your PBP. Understand, my "live" OS, running from an SD card and doing installation was an example to illustrate. for now, all "installation" is dd-ing the whole image, with uboot and linux in expected places (uboot parts need to be placed at specifical sectors). obviously, with NVMe as an OS installation target, the installation cannot be this easy anymore - you need to put FW in one place and the OS in another. moreover, - places have yet to be figured out, because it's a user choice! see, it's an install program, that we are talking about. maybe someone will make it, in future. my example "live" SD OS just showed that. you need to rely more on what's available now.

if you are ready for messing with that extlinux stuff, if you know how to work with it, the wiki suggests you to try:

It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires uboot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC.