(10-09-2019, 03:39 PM)z4v4l Wrote: I think, the first thing, that needs to be clarified is distinguishing between the ROM code boot ordering and uboot ordering and therefore - between where uboot could be placed and where OS could. the term "hardcoded" is confusing, basically it makes sense only if it refers to the ROM code, - the only "hardcoded" thing in this chain. its boot ordering is given in the rk3399 manual and I posted it above.
I agree that makes sense, so the Wiki should be re-written. Although, given conflicting information, I'll wait to give others a chance to post additions and corrections here.
(10-08-2019, 05:45 PM)z4v4l Wrote: Just for clarification. rk3399 ROM code boot order is this:
1. SPI NOR
2. SPI NAND
3. eMMC
4. SD
5. USB OTG*
* - USB is used not as mass storage device interface, so sticks can't be used, but as an interface for remote downloading the payload through a rockchip custom protocol.
The datasheet listing for components only lists SPI NOR. Is there a SPI NAND installed on the PBP? If not, then the hardcoded ROM boot order for the PBP is: SPI NOR, eMMC, SD, USB OTG. Correct?
Currently, the Wiki states "This boot order is different then the default hard-coded boot order of the SoC: SPI, eMMC, USB 2.0, USB 3.0, SD card" which lists USB before SD.
(10-09-2019, 03:39 PM)z4v4l Wrote: it's important to distinguish for everybody to get it (finally). so, you need to have uboot at one of those and only those interfaces to get booting happen. and the order will be that and can't be changed. the next thing is clarifying of what uboot can boot (the OS) from. here, the order is not as important since you can change it, in boot.scr or whatever uboot script/commands. so, the answer from where uboot can boot the OS is those interfaces, that are supported by the provided uboot version. as I understand, it can do USB but can't PCIe. and the orders currently mentioned in the wiki most probably refer to the way uboot scripts/boot commamds are currently configured (however I think it's a mix of that and the ROM code order, because I doubt uboot will search linux on SPI).
So to clarify, in order to work, uboot can only be placed on the devices listed in the above ROM code boot order?
This leads me to believe that "At this time, the boot order for the custom uboot (on eMMC) on the default Debian + MATE build is: SD, USB 2.0, eMMC" means the SPI firmware is flashed to point to uboot on the eMMC. Is that correct? Then uboot on the eMMC looks for an OS on the SD, then USB 2.0, then eMMC?
10-10-2019, 03:11 PM
(This post was last modified: 10-10-2019, 03:32 PM by z4v4l.)
Quote:The datasheet listing for components only lists SPI NOR. Is there a SPI NAND installed on the PBP? If not, then the hardcoded ROM boot order for the PBP is: SPI NOR, eMMC, SD, USB OTG. Correct?
NAND is not present, the order is correct.
Quote:So to clarify, in order to work, uboot can only be placed on the devices listed in the above ROM code boot order?
Of course! Unless uboot can be split into parts and distributed through several storages with one part loading another. but anyway, that first part (let's call it SRAM part - because it gets loaded into SRAM) can be only on devices from that list (obviously). and also, again, USB is not as USB mass storage, but as USB OTG, connected to another computer (host) and exchanging data/commands through a custom protocol (you need to use rockchip tools on the host). this option is not even for uboot, but only for its early components (basically for the rockchip blobs for memory initialzation), so it is quite useless for the general public (unless they are ready to try to understand rockchip's wiki and tools ).
for the sake of completeness, here is a short excerpt of the block scheme on what ROM code does with that mask ROM mode (USB OTG).
Quote:Initialize USB port.
1.Wait request for download DDR image code
2.Download DDR image code to internal SRAM
3.Run DDR image code
4.Wait request for download loader image code
5.Download loader image code to DDR
6.Run loader image
Quote:This leads me to believe that "At this time, the boot order for the custom uboot (on eMMC) on the default Debian + MATE build is: SD, USB 2.0, eMMC" means the SPI firmware is flashed to point to uboot on the eMMC. Is that correct? Then uboot on the eMMC looks for an OS on the SD, then USB 2.0, then eMMC?
is SPI flashed? with what? it's not. when it is, it's uboot there, the firmware is uboot (in all possible components - rockchip blobs, SPL/TPL, ATF etc), there is nothing else over there. when SPI is not flashed, uboot is on eMMC and gets loaded from there. uboot looks for the OS, based on how its environment variables and scripts are configured (this is what depends on the builds and what is changeable by users in the scope of uboot possibilities).
ANT - my hobby OS for x86 and ARM.
(10-10-2019, 03:11 PM)z4v4l Wrote: is SPI flashed? with what? it's not. when it is, it's uboot there, the firmware is uboot (in all possible components - rockchip blobs, SPL/TPL, ATF etc), there is nothing else over there. when SPI is not flashed, uboot is on eMMC and gets loaded from there. uboot looks for the OS, based on how its environment variables and scripts are configured (this is what depends on the builds and what is changeable by users in the scope of uboot possibilities).
Thank you for your response. So the PBP ships with a blank SPI?
Also, just to be clear, this is uboot on the eMMC: https://www.denx.de/wiki/U-Boot/
yes, it is empty. just as with any pine devices with SPI flash. unless you flash it with the scrpits, provided by ayufan. then the same uboot gets there. did you think, that there is something else, that goes into SPI flash?
ANT - my hobby OS for x86 and ARM.
the uboot env variables goes into SPI (doing `saveenv` in uboot prompt)
(08-06-2019, 02:57 PM)MrTester Wrote: (08-06-2019, 01:13 PM)zaius Wrote: (08-06-2019, 06:35 AM)thequux Wrote: The Intel 660p seems to be that unicorn; cheap and 0.1W according to https://ark.intel.com/content/www/us/en/...2-qlc.html . That power consumption seems shockingly low, so who knows how accurate it really is, but one would *think* that Intel knows how to measure it properly.
Thanks, it is only available in 2TB, 1TB, and 512GB.
Here is more information about the WD Blue SN500 which has a different edge-connector:
http://products.wdc.com/library/SpecShee...-00076.pdf
Here is more information about the WD Black SN750 NVMe SSD:
http://products.wdc.com/library/SpecShee...-00054.pdf
It looks like most manufacturers are using this https://bapco.com/products/mobilemark-2014/ or this https://bapco.com/products/mobilemark-2018/ which only runs on Windows. If there is a similar testing application that runs under Linux on the PBP, that might help early SSD adopters share useful information.
Following this thread, and reviewing the datasheets with limited data (avg R/W in what Atemp, R/W load? ). My guesses we should have a "Best Bet" suggestions and all the early adopters run tests and/or extracts from Smart .
Ill keep my eye on the price for Intel® SSD 660p @ $36 USD for 128 and $54 USD for 256 not bad for a give it a shot hardware.
https://www.amazon.com/Intel-760P-256GB-...BL3T9&th=1
Hi, I know the bandwidth is beyond the PBP's upper limit of around 1.5GB/s, but has anyone considered the Intel 760p NVMe SSDs?
https://www.intel.com/content/www/us/en/...eries.html
Looking at the 512GB drive, power draw is stated as 25mW while Idle, and 50mW while active. Sounds almost perfect. Comes in 128GB, 256GB, 512GB, 1024GB and 2048GB variants, priced from $57--$399.
11-02-2019, 09:16 AM
(This post was last modified: 11-02-2019, 09:17 AM by Arwen.
Edit Reason: Remove extra quoted posts
)
(11-02-2019, 03:15 AM)Feakster Wrote: Hi, I know the bandwidth is beyond the PBP's upper limit of around 1.5GB/s, but has anyone considered the Intel 760p NVMe SSDs?
https://www.intel.com/content/www/us/en/...eries.html
Looking at the 512GB drive, power draw is stated as 25mW while Idle, and 50mW while active. Sounds almost perfect. Comes in 128GB, 256GB, 512GB, 1024GB and 2048GB variants, priced from $57--$399. They look good. Wish they had specified the burst power draw.
It does appear that the use one of the NVME lower power settings. We, (us Pinebook Pro owners that use NVMEs), may have to investigate how to enable lower power settings at boot. May cost a little performance, but the benefits will likely outweigh the cost. (Reduced heat and increased battery life.)
Of course, now I have to re-visit my avoidance of Intel products, (due to the massive CPU security problems that they created in their need to produce faster CPUs than their competition).
--
Arwen Evenstar
Princess of Rivendale
Since many of us have received our PBPs already, I was wondering if we now have any confirmed working SSDs that met the requirements of the PBP. If anyone does, I think it'd be great information to add the the device wiki.
11-10-2019, 10:37 AM
(This post was last modified: 11-10-2019, 10:59 AM by bcnaz.)
Well it appears we have two obstacles to overcome :
1) Getting the PBP to boot from the PCIe/NVMe, seems the booting firmware is a bit of a challenge
There are some pretty good people working on it.
>Some including Luke have mentioned a 'work-around' that may work....
2) There is also the limits imposed by the ultra low power available from inside the PBP itself.
IF you want to install a NVMe into your desktop it is no problem... Even if you had to put in a bigger power supply, no big deal.
> but when each single watt matters, you could destroy something on this little computer. !
> I have spent a more than a few hours trying to dig up more info on these fantastic NVMe drives, they mostly list idle and active watts, but very few list maximum watts.
.. > I have requested more info, but have not got any responses yet.
....> There is not a huge market for "high Performance drives in ultra low powered laptops"
Maybe someone could talk Toms Hardware into doing an article on putting NVMe's into laptops....?
(11-10-2019, 10:37 AM)bcnaz Wrote: Well it appears we have two obstacles to overcome :
1) Getting the PBP to boot from the PCIe/NVMe, seems the booting firmware is a bit of a challenge
There are some pretty good people working on it.
>Some including Luke have mentioned a 'work-around' that may work....
2) There is also the limits imposed by the ultra low power available from inside the PBP itself.
IF you want to install a NVMe into your desktop it is no problem... Even if you had to put in a bigger power supply, no big deal.
> but when each single watt matters, you could destroy something on this little computer. !
> I have spent a more than a few hours trying to dig up more info on these fantastic NVMe drives, they mostly list idle and active watts, but very few list maximum watts.
.. > I have requested more info, but have not got any responses yet.
....> There is not a huge market for "high Performance drives in ultra low powered laptops"
Maybe someone could talk Toms Hardware into doing an article on putting NVMe's into laptops....?
There is also the problem of making it fit without hitting the touch pad.....
LINUX = CHOICES
**BCnAZ**
Donate to $upport
your favorite OS Team
(11-10-2019, 09:49 AM)tophneal Wrote: Since many of us have received our PBPs already, I was wondering if we now have any confirmed working SSDs that met the requirements of the PBP. If anyone does, I think it'd be great information to add the the device wiki.
Currently, there is a hardware problem with the NVMe adapter. So we need to wait until the extra parts get shipped. Then as more users have SSD drives
properly installed, we can gather information about their experience with different drives.
However, since the SDD market keeps changing, it might be best for the Wiki to link to this thread. I also have concerns about the Wiki being perceived as endorsing specific brands or products.
|