Uses for SPI Flash

[Arwen]

I saw something frightening when I went searching for a larger SPI flash device.
Vendors make 2Gbit SPI flash devices, (256MByte). Way larger than our current
128Mbit, (16Mbyte).

But, an earlier post was probably correct, 16Mbyte is alot. My desired firmware
would be Open Firmware, as it's programable, easy to use and does not have to
be a GUI. It probably will fit in 16Mbyte.

Ideally, I would be able to test the Open Firmware as a partition / location on the
eMMC or SD card. Then have uboot run it. That way, no worrying about flashing
it to the SPI until the final testing.

For those that don't know, Open Firmware allows setting boot order, like;

Code:

setenv boot-device emmc sdxc

We may even beable to include PCIe NVMe bootability in Open Firmware. (The
Rockchip does not have this feature inside it.)

[z4v4l]

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.

[Arwen]

I've had horrible luck with x86/x64 boot devices. Perhaps it's older BIOS that is the issue. It just does not seem to remember boot order 100% of the time, and booting off the second drive seems problematic. It's not worth going into here, since we are not looking to implement BIOS like firmware.

It does appear EFI has the features. However, all the times I've tried it, unless it was some kind of automated installer, it failed to install and allow booting. That was Linux only. Perhaps I need to just learn it in detail like I had to learn Grub.

[enip]

In the end I ended up ordering a CH341A and a test clip since that should be able to get me out of almost anything ;-) .

Never celebrate too early. I've recently bought one and used it to dump firmware from my router's surface soldered flash. It didn't work because the power from the test clip leaked into the board. If only there was some kind of diode on the flash's VCC it might work (I guess), but it was not my case. The clip worked well with a DIMM SPD chip though, both read and write.

If I was PINE I'd put a socketed flash onto the board like the one you see on the PC desktop boards. Instead they've made it soldered and there isn't even a hardware switch to disable it even though the flash is the first (right?) boot priority for rk3399. So in case you mess the flash up but it still looks like a bootable device for the chip's BROM, how do you fix it without desoldering? I hope they've made it available with a test clip right on-board so that the clip's VCC doesn't leak into the whole board.

[danielt]

how do you fix it without desoldering?

By combining info from the PBP schematic and the Rock64Pro wiki I came up with: carefully use your tweezers to short out pins 4 and 6 of the flash chip for the first two seconds of boot .

I won't *test* the above until I have to though!

[kalpazanius]

how do you fix it without desoldering?

By combining info from the PBP schematic and the Rock64Pro wiki I came up with: carefully use your tweezers to short out pins 4 and 6 of the flash chip for the first two seconds of boot .

I won't *test* the above until I have to though!

I'd rather try to short out pins 4 and 7. Pin 4 is GND. Pin 7 is /RESET/HOLD and is only connected to VCC3_0 through resistor. It seems perfectly safe to ground this pin.
Pin 6 is connected to Pin28 on the CPU. Grounding Pin 6 would result in output current overload for P28 on the CPU. Probably not dangerous for a couple of seconds but I would not try this.

[danielt]

I'd rather try to short out pins 4 and 7. Pin 4 is GND. Pin 7 is /RESET/HOLD and is only connected to VCC3_0 through resistor. It seems perfectly safe to ground this pin.
Pin 6 is connected to Pin28 on the CPU. Grounding Pin 6 would result in output current overload for P28 on the CPU. Probably not dangerous for a couple of seconds but I would not try this.

Yes, I didn't really like the idea of grounding the clock pin either... but it what the (rockpro64) wiki recommends! I think you are right, pin 7 looks a much safer pin to play with. To be honest I might be influenced by the mechanics and how likely am I to catch the Vcc pin by accident!

[ayufan]

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.

[enip]

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?

[tsago]

As an extension I'd be very interested in how to recover from a completely wiped device (nothing in SPI, nothing in eMMC). If I understood correctly SD card won't be used in such a scenario, is that right?
(though this probably should be in a separate thread, I guess...)