SSD for PBP
#51
@bcnaz Another way to handle it, is to use newer boot firmware in the SPI NAND flash device. The SPI is bootable, (if I understand the Rockchip correctly). Then have this newer boot firmware in SPI allow booting off PCIe NVMe.

My own personal favorite would be Open Firmware. But, who knows if I have the skill to both modify it and trouble shoot it. Using firmware, (Open Firmware or other), in the SPI has a certain advantage in regards to disk layout. At present, their are disk image layout issues. Meaning a simple DOS or GPT partition table does not appear to be supported, (as the boot code needs to be first on the device). But, if we put the low level boot code in SPI flash, then all the other devices, eMMC, USB, SD cards & NVMe can have normal parition tables.
--
Arwen Evenstar
Princess of Rivendale
#52
(10-07-2019, 02:15 PM)Arwen Wrote: @bcnaz Another way to handle it, is to use newer boot firmware in the SPI NAND flash device. The SPI is bootable, (if I understand the Rockchip correctly). Then have this newer boot firmware in SPI allow booting off PCIe NVMe.

My own personal favorite would be Open Firmware. But, who knows if I have the skill to both modify it and trouble shoot it. Using firmware, (Open Firmware or other), in the SPI has a certain advantage in regards to disk layout. At present, their are disk image layout issues. Meaning a simple DOS or GPT partition table does not appear to be supported,  (as the boot code needs to be first on the device). But, if we put the low level boot code in SPI flash, then all the other devices, eMMC, USB, SD cards & NVMe can have normal parition tables.

      Wonder  ?

 Can the SPI be re-flashed while on the board  ?
   As much space as it appears to occupy on the board (in the wiki illustration) looks like it could have a socket rather than soldered on.

                  or would one need to 'flash'  the chip before it is installed   (or re-installed)   ?

    Luke's solution would solve the problem by only modifying the software,  but possibly increasing the boot time...   (?)

Being a SBC a graphical boot screen is kinda outta the realm of possibilities (?)
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
#53
Yes, as @Arwen mentioned, SPI would be the ideal solution. This will eventually be the best solution will use. The problem with flashing SPI is that when it fails (has happened to me) then SPI is completely bricked and you won't be able to boot anything unless you desolder the chip (or clip one leg at the very least). And this is beyond the capability of some users. So, we need to wait for a safe way of doing it.

As for graphical boot screen (uboot) - its possible. I may be wrong, but from what I remember @Mrfixit2001 actually got it to display over UART (not eDP or HDMI however - so not really useful to users). I hope this will eventually allow for booting different OSs from multiple mediums.
You can find me on IRC, Discord and Twitter


#54
what one can do if the brick happened on RockPro? shortening some pins on the extension header to cut off SPI at the reset. some jumper for doing the same on PBP for the future revisions would be a solution.
ANT - my hobby OS for x86 and ARM.
#55
In the short term, (6 months to 1 year), I do not see any stable firmware that should be flashed to the SPI NAND.
So all boot code will llikely be in eMMC, SD card or USB. Much easier to update and debug.
--
Arwen Evenstar
Princess of Rivendale
#56
***************************

When I Posted 2.5 watts, it was what the Pine Info team emailed in response to my question.
I Have Not seen any person in authority post the never exceed wattage ...

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

Tllim and or Luke

Perhaps a possibility of putting the SPI into a socket ?
Then we could use "as is" or possibly purchase a flashed SPI module prepared to our wants/needs ?
Maybe the Pine Store could sell these flashed SPI modules ?

(07-27-2019, 02:37 PM)zaius Wrote: Many users will want install a larger and faster drive.  So I'm starting this thread for questions and answers, and will update the information in this first post.

So far, there are at least five main issues:

1) The physical specifications.  They were posted earlier.  Sorry, I couldn't find the post.

2) Mounting hardware and installation.

3) Power consumption.  

"Around 2.5W reserved for NVMe drive. Please don't use the power hungry type SSD which can creates heat and power consumption issue."

https://forum.pine64.org/showthread.php?...8#pid47438

"the 3.3V regulator which is responsible for supplying the NVMe adapter can handle up to 8.25W momentarily, and isn't put under significant load by much else in the system"

https://forum.pine64.org/showthread.php?...5#pid48355
 
4) Heat. This is related to power consumption. It shouldn't make the PBP too uncomfortable to use, or make the drive or other components exceed their operating temperature.  Finding suitable drives will likely be the result of trial and error.  Fortunately, external enclosures are available, so buying a drive that runs too hot in the PBP won't be a complete loss.  Undecided
 
5) Starting up from the SSD as the system drive.

(Since I already placed my PBP order, I'm guessing I'm in the first 100, so I'm willing to do some testing on this issue.  I plan on buying two different 256 GB, then using one as a USB back-up drive.  Larger drives consume more power and produce more heat, but so far it looks like some 2TB drives should work.)

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

   SO    I decided to purchase a drive
                     It is approximately in the described parameters that have been disclosed : 
            XPG SX6000 Lite  M.2  NVMe PCIe  3.0 x4  128gb
                 R/W 1800/600 MBps
              2.15mm/ .084" thick and 22 x 80mm standard size
             .14 watt idle  .33 watt active

   Plenty big for me,  and close to the maximum specs the board can handle  ?
           Bargain Price at NewEgg.
                 (When did Newegg start charging tax ? First time I noticed)

        I just did not feel like waiting any longer

                          *****************************************
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
#57
(10-07-2019, 05:43 PM)z4v4l Wrote: what one can do if the brick happened on RockPro? shortening some pins on the extension header to cut off SPI at the reset. some jumper for doing the same on PBP for the future revisions would be a solution.

With the current PBP I suspect fine point tweezers (ideally anti-static ones ;-) ) would allow grounding of the clock pin without needing too much skill. Having said that removing them and shaking might not be a great thing so I personally chickened out and ordered a cheap CH341A instead. With that I hope I can be a bit reckless with the SPI code.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#58
What is a "CH341A" ?
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
#59
(10-08-2019, 12:55 PM)bcnaz Wrote: What is a   "CH341A"    ?

Never heard of it, myself, but I found this: CH341A Mini Programmer Schematic and Drivers, which includes a brief description.
#60
(10-08-2019, 12:55 PM)bcnaz Wrote: What is a   "CH341A"    ?

Its a USB communications chip that can, among other things, interface to SPI devices. It's a useful keyword on eBay ;-)

https://youtu.be/2Y06x1f22B0
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye


Forum Jump:


Users browsing this thread: 36 Guest(s)