Uses for SPI Flash
#11
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. Big Grin 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.
ANT - my hobby OS for x86 and ARM.
#12
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.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#13
(09-30-2019, 04:47 AM)ayufan Wrote: 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?
#14
(10-01-2019, 06:14 AM)kalpazanius Wrote:
(09-30-2019, 04:47 AM)ayufan Wrote: 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 ;-) .
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#15
> 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
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#16
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).
--
Arwen Evenstar
Princess of Rivendale
#17
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! Big Grin I am busy creating UEFI for a couple of them. Angel Big Grin 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. Big Grin
ANT - my hobby OS for x86 and ARM.
#18
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.
[Image: PBPL_S.jpg]
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#19
(10-03-2019, 03:33 AM)danielt Wrote: 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.
[Image: PBPL_S.jpg]

      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.
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
#20
This peaks my interest more than it should given how dangerous it is Big Grin

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.


Possibly Related Threads…
Thread Author Replies Views Last Post
  No boot after Manjaro flash PBcurry 14 5,158 10-03-2022, 08:33 PM
Last Post: wdt
  U-Boot with direct NVMe boot support for eMMC/SPI Flash pcm720 125 212,332 09-27-2022, 07:41 AM
Last Post: olyavi
  How can I flash SPI so that I can boot from NVMe? codingpanic 5 5,750 08-24-2021, 05:07 AM
Last Post: codingpanic
Question erase spi flash aiminick 1 2,250 04-07-2021, 06:50 AM
Last Post: tophneal
  Booting to sdcard stopped working after emmc flash techiedog 3 3,840 12-31-2020, 06:30 PM
Last Post: Anarethos
  Flash non-bootable eMMC? midnightcheese 2 2,167 12-24-2020, 08:01 AM
Last Post: midnightcheese
  U-Boot on SPI flash - discussion Arwen 20 21,241 09-16-2020, 08:20 AM
Last Post: hmuller
  Am I supposed to flash keyboard firmware and u-boot imgs? superkazuya 4 5,717 09-02-2020, 04:12 AM
Last Post: pfeerick
  How to flash the emmc when it has Chromium on it? U47 3 4,325 07-10-2020, 10:07 AM
Last Post: U47
  emmc image will not flash Uturn 9 12,076 04-04-2020, 07:02 AM
Last Post: jiyong

Forum Jump:


Users browsing this thread: 1 Guest(s)