Uses for SPI Flash

[z4v4l]

it's not a durable to wearing out SLC NAND flash, it's NOR flash, it is NOT intended for what you are talking about, der geist der maschine. you already have brought a lot of confusion in this thread and keep on with this, even despite you know of the power of internet and doing research on it before stating something, then why you said it's unreliable to use, when it's not. creating uncertainty. the OP stated what he wants to do with it and it's acknowledged it's possible (given all the hassles of fighting with uboot are expected to deal with xD). putting there a FS and making it a general purpose volume is just stupid, because it's 16MBs, - you easily can use a USB stick gigabytes worth instead. with cryptographic keys again, this tiny storage won't make it any more secure - it's freely accessible. as of the real erase/program cycles this chip can endure, i don't know, i am typing this from a tablet, so can't check the specification, but i am almost sure, it's not this big as you claim. but it doesn't matter, because of so many other reasons. for example - what exactly wear leveling mechanism are you going to use? UBI/UBIFS? YAFFS2? the former dropped support for even MLC NANDs, i don't know if they even support NOR. anyway, you would need to recompile your kernel adding all the needed stuff there, configuring them properly. only for 16MB of a very slow storage (made for FW). .... good luck with that.

Edit. Yes, the specification states min 100000 E/P cycles durability. But this only fact doesn't justify hammering it imo. I just don't believe it will endure this much writings. if it is so stable, why SSDs break so often? look at this from this perspective - your normal x86 laptop has the same SPI NOR flash for BIOS/UEFI. would you be comfortable with rewritting it say once a week? I wouldn't. even knowing it's 100000 E/P cycles durable. It's a firmware storage device. period. btw, one of the reasons why uboot is mostly on  eMMC/SD on SBCs, is because it's easier to "play" with it for "tinkerers". For PBP on the other hand, which is a consumer device, it's much more important to have a consistent, reliable boot mechanism. users can easily mess up with their SD cards, forgetting what they put there and thus creating troubles for themselves, whereas having uboot on the permanently soldered SPI NOR chip and thus - always having a working "BIOS" inside, would be much better for them. just as with every laptop.

[danielt]

I hope to use my SPI for firmware (and if needed also storage of any hardware unique values such as MAC addresses) since I'd like to shift that out of eMMC and make it easier to use generic off-the-shelf distros.

I might also set up a tiny read-only Linux distro for disaster recovery. The remaining few MB should be just enough for a kernel and userspace that can fetch images over the network and write them to eMMC.

[kalpazanius]

You can have image that has uboot behaving this way: preferring SD over eMMC.

Booting from the spi flash with SD over eMMC preference still does have an advantage: it makes it possible to wipe-out or re-partition the eMMC, and even if something is messed up it will be still able to recover without the need of a screwdriver.
There is a catch, though - if you mess up u-boot in the SPI flash then you will be in trouble. I think that on RockPro the boot priority is selectable using a jumper. So I wonder - what's the boot priority on PBP and is it also jumper selectable?

[danielt]

You can have image that has uboot behaving this way: preferring SD over eMMC.

Booting from the spi flash with SD over eMMC preference still does have an advantage: it makes it possible to wipe-out or re-partition the eMMC, and even if something is messed up it will be still able to recover without the need of a screwdriver.
There is a catch, though - if you mess up u-boot in the SPI flash then you will be in trouble. I think that on RockPro the boot priority is selectable using a jumper. So I wonder - what's the boot priority on PBP and is it also jumper selectable?

I saw the following in the RockPro docs to forcefully avoid SPI boot (e.g. prevent the SPI device from observing the clock by shorting it out on the 40 pin header):
https://wiki.pine64.org/index.php/ROCKPr...booting.29

I haven't seen the production schematics for PBP but there is no 40 pin header and the pre-production drawings didn't offer any comfortable equivalent. You apply the same short directly to the pins of  the flash chip... but I doubt I'm coordinated enough to pull it off reliably. 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 ;-) .

[danielt]

> I haven't seen the production schematics

... but they have recently landed in the wiki so I will have taken a look fairly soon:
https://wiki.pine64.org/index.php/Pinebo...ifications

[Arwen]

Now the real question for us hardware moders, is can we replace the 16MByte, (aka 128Mbit), SPI Flash with something larger?

I'd want to research getting something better than u-boot, perhap Open Firmware.

I've done this type of hardware change before, (can't call it hacking, due to the public perception of the word). If I remember correctly, I changed out a 256 byte flash device for 8KB. Not that hard. Of course, that was before surface mounting was the norm. (Arg, don't tell anyone I am that old!)

Perhaps I will have time to review the schematics, (though not this weekend).

[z4v4l]

16 MB of storage should be way enough for any sane firmware. if I understand correctly, on most PCs such chips are 2-4 MB. pine put a huge NOR flash chip then! it's soldered on board, so you can replace it only doing that crazy stuff only hardcore "tinkerers" do, -  things I am even afraid to think of.
as of "something better, than uboot". that would be very anticipated and fantastic! but, there is no Open Firmware implementation for these boards. you need to create it! I am busy creating UEFI for a couple of them. despite a long break in that affair, I haven't abandoned the idea. I even posted screenshots of early stages of it, but it's toooo early.

[danielt]

AFAICT from the part numbers the SPI FLASH is SOIC/SOP8. In other words it is surface mount but has a relatively large feature size combined with a low pin count. I don't intend to replace it... but if I did wear anything out experimenting with writeable partitions than I'd be pretty relaxed about fixing it.

Actually the picture on the wiki shows it nicely, it is labelled #29 and you can see the difference in pin spacing versus almost every other component on the board.

[bcnaz]

AFAICT from the part numbers the SPI FLASH is SOIC/SOP8. In other words it is surface mount but has a relatively large feature size combined with a low pin count. I don't intend to replace it... but if I did wear anything out experimenting with writeable partitions than I'd be pretty relaxed about fixing it.

Actually the picture on the wiki shows it nicely, it is labelled #29 and you can see the difference in pin spacing versus almost every other component on the board.

      Not that I would attempt that myself,  too many years since I touched heat to a circut board...
   BUT If I did , I think I would just cut the legs high and use them to solder the new device to.
    Maybe ugly that way, but less likely to do any damage...
      AND  once you screw the case together nobody else will see it.

[PakoSt]

This peaks my interest more than it should given how dangerous it is

How does one flash the SPI chip? I mean, what tools are needed and can it be done safely directly on the board (in case of bad image)?

Would something like this guide be a good start or am I completely missing the mark?
Test clips are cheap anyway, would be interesting if they can be combined with that Adafruit guide.