SSD for PBP

[bcnaz]

* ********************

Thank You, Very interesting

I Need to go back and watch again with some powered headphones, with my volume at 150%, it was still low.
But it is a very detailed & informative video.
I was under the impression before, that the chip would have to be removed to be flashed, Obviously I was wrong/mistaken.

********************

[Arwen]

As far as I know, you can flash the SPI while booted on the Pinebook Pro.

The difficulty comes in if you flash the SPI with firmware that the Rockchip recognizes as valid. But, this new SPI firmware does not allow booting. Thus, the term "brick". That's when you need an external programmer, (with other computer to perform the programming). Or modifying the SPI clock pin, (cut or short).

Remember, the SPI firmware is booted before other sources. From the Wiki;

... default hard-coded boot order of the SoC: SPI, eMMC, USB 2.0, USB 3.0, SD card.
Wiki - Pinebook Pro - Bootable Storage

[z4v4l]

Just for clarification. rk3399 ROM code boot order is this:
1. SPI NOR
2. SPI NAND
3. eMMC
4. SD
5. USB OTG*

* - USB is used not as mass storage device interface, so sticks can't be used, but as an interface for remote downloading the payload through a rockchip custom protocol.

[bcnaz]

*************

I thought they changed that for the Pine book Pro version ?
SD card, then USB, then EMMc ?
I could very likely be incorrect, But ?

**************

[bcnaz]

**********

OOh I see, It IS sent to the EMMc, which forwards it to the sd card, then usb.....
My Bad...

***********

[zaius]

Please see this:  https://wiki.pine64.org/index.php/Pinebo...le_Storage

After you update it,  the boot order for the stock Debian + MATE build is: SD, USB 2.0, eMMC.

It is possible to run the OS off the  SSD by pointing extlinux on the eMMC to rootfs on the SSD.  We just need more detailed instructions.  Please, feel feel to write them, and post them on the Wiki or in this thread.


This is not to say other ways of booting from the SSD are not possible.  However, as Luke wrote,  flashing the SPI can be dangerous as it could disable the computer, requiring soldering or some other invasive hardware hacking to fix it.  Since this is beyond the capability of most users, they should wait for a safe way of doing it.

[danielt]

I was under the impression before, that the chip would have to be removed to be flashed,  Obviously I was wrong/mistaken.

That is being discussed a bit more in another thread (https://forum.pine64.org/showthread.php?...2#pid50402 ).

Ultimately it depends on the surrounding circuitry and whether applying power to the flash chip causes too much of the rest of the board to come alive (where it will either draw too much current from the programmer or just get in the way by trying to communicate with the flash chip itself). After reading the schematic I'm fairly optimistic it will work for PBP but definitely not 100% sure.

[z4v4l]

@zaius, the info the the wiki section is wrong and misleading. it confuses ROM code boot order - this is what is "hardcoded", - with uboot boot order, which is not hardcoded and is configurable. the first loads uboot, the second - the OS. it's different things and what is written in that wiki totally contradicts rk3399 manual.
so for example, linux on SPI is nonsense, but it's OK (at least on SBCs) for uboot, and only uboot on NVMe is not possible, whereas linux there is, at least when uboot is capable of handling PCIe/NVMHCI. or, better firmware shows up.

[zaius]

@zaius, the info the the wiki section is wrong and misleading. it confuses ROM code boot order - this is what is "hardcoded", - with uboot boot order, which is not hardcoded and is configurable. the first loads uboot, the second - the OS. it's different things and what is written in that wiki totally contradicts rk3399 manual.
so for example, linux on SPI is nonsense, but it's OK (at least on SBCs) for uboot, and only uboot on NVMe is not possible, whereas linux there is, at least when uboot is capable of handling PCIe/NVMHCI. or, better firmware shows up.

OK, I merely edited what others wrote.  I don't have any other sources of information at this time.

Currently, there are three statements:

1. The Pinebook Pro is capable of booting from SPI, eMMC, USB 2.0, USB 3.0, or an SD card. It cannot boot from USB-C.
2. At this time, the boot order for the custom uboot (on eMMC) on the default Debian + MATE build is: SD, USB 2.0, eMMC.
2. This boot order is different then the default hard-coded boot order of the SoC: SPI, eMMC, USB 2.0, USB 3.0, SD card. Booting off USB 3.0 storage is not currently available, but will be in the future.

Please, correct what is wrong, either in this thread or via PM, and then I'll go fix the Wiki.


Thanks

[z4v4l]

I think, the first thing, that needs to be clarified is distinguishing between the ROM code boot ordering and uboot ordering and therefore - between where uboot could be placed and where OS could. the term "hardcoded" is confusing, basically it makes sense only if it refers to the ROM code, - the only "hardcoded" thing in this chain. its boot ordering is given in the rk3399 manual and I posted it above. those places are where uboot could be placed and the order given is the order of searching for firmware, not OS. this thing is important because it's where users can place their uboot. flashing firmware along with the OS is the unfortunate way to do stuff on SBCs. but on the other hand, people want their OS to be on USB sticks or even SATA/NVMe SSDs, but uboot can't be there, and that's why it's important to distinguish for everybody to get it (finally). so, you need to have uboot at one of those and only those interfaces to get booting happen. and the order will be that and can't be changed. the next thing is clarifying of what uboot can boot (the OS) from. here, the order is not as important since you can change it, in boot.scr or whatever uboot script/commands. so, the answer from where uboot can boot the OS is those interfaces, that are supported by the provided uboot version. as I understand, it can do USB but can't PCIe. and the orders currently mentioned in the wiki most probably refer to the way uboot scripts/boot commamds are currently configured (however I think it's a mix of that and the ROM code order, because I doubt uboot will search linux on SPI).