Uses for SPI Flash
#21
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.)
--
Arwen Evenstar
Princess of Rivendale
#22
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.
#23
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.
--
Arwen Evenstar
Princess of Rivendale
#24
(10-01-2019, 07:07 AM)danielt Wrote: 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.
#25
Big Grin 
(10-08-2019, 06:24 AM)enip Wrote: 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 Cool .

I won't *test* the above until I have to though!
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#26
(10-08-2019, 09:41 AM)danielt Wrote:
(10-08-2019, 06:24 AM)enip Wrote: 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 Cool .

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.
#27
(10-08-2019, 09:53 AM)kalpazanius Wrote: 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!
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#28
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.
Homepage: https://ayufan.eu

Releases:
Rock/Pro 64/Pinebook Pro: LinuxChromium OS
So/Pine A64/Pinebook: LinuxAndroid 6.0Android 7.1

Buy me a Beer
#29
(10-08-2019, 01:34 PM)ayufan Wrote: 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?
#30
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...)


Possibly Related Threads…
Thread Author Replies Views Last Post
  U-Boot with direct NVMe boot support for eMMC/SPI Flash pcm720 118 95,522 06-08-2021, 11:04 PM
Last Post: calinb
Question erase spi flash aiminick 1 293 04-07-2021, 06:50 AM
Last Post: tophneal
  Booting to sdcard stopped working after emmc flash techiedog 3 1,125 12-31-2020, 06:30 PM
Last Post: Anarethos
  Flash non-bootable eMMC? midnightcheese 2 652 12-24-2020, 08:01 AM
Last Post: midnightcheese
  U-Boot on SPI flash - discussion Arwen 20 8,027 09-16-2020, 08:20 AM
Last Post: hmuller
  Am I supposed to flash keyboard firmware and u-boot imgs? superkazuya 4 2,181 09-02-2020, 04:12 AM
Last Post: pfeerick
  How to flash the emmc when it has Chromium on it? U47 3 1,523 07-10-2020, 10:07 AM
Last Post: U47
  emmc image will not flash Uturn 10 3,713 04-12-2020, 06:38 PM
Last Post: D4RK
  The usage/access of the SPI flash aaspectre 2 1,319 01-06-2020, 08:14 AM
Last Post: aaspectre

Forum Jump:


Users browsing this thread: 1 Guest(s)