Dave Kimble Posted November 26, 2018 Posted November 26, 2018 I appreciate people want to do all sorts of things with their SBCs, but the usage of "cheap PC" must be common, and users will have the expectation of connecting up a HDD or SSD. So I was thinking: how about a M.2 slot instead supporting PCIe x4 so we can buy the biggest, fastest and cheapest per GB SSDs around. You could then eliminate the TF slot, micro-SD cards and eMMC modules, and the system could boot off the drive in the normal Linux manner. I'm not sure where the "support for PCIe x4" comes from, or how much this would affect the price. In the same way, I will probably never use GPIO pins, or IR receivers, cameras, touchscreens, on-board microphones, or alternative (to HDMI) audio outputs, so they can all be eliminated as bloat in the PC model. I believe Orange Pi is just one person, who can design things OK, but has no idea what market he is designing for. Perhaps he could be approached and put on the right track for mutual benefit. Your thoughts welcome.
sfx2000 Posted November 26, 2018 Posted November 26, 2018 I think much is around capability of the SoC in use, and the potential market... keep in mind what the market really is for budget SBC's There aren't many SoC's in this price range that might accommodate your wishes for an NVME M.2 slot - move up in price a bit, and there are Intel NUC oriented boards
Igor Posted November 26, 2018 Posted November 26, 2018 5 hours ago, Dave Kimble said: In the same way, I will probably never use GPIO pins, or IR receivers, cameras, touchscreens, on-board microphones, or alternative (to HDMI) audio outputs, so they can all be eliminated as bloat in the PC model. That's why we have single board computers "in all" possible form factors: 5 hours ago, Dave Kimble said: I believe Orange Pi is just one person A few more https://www.cnx-software.com/2017/07/15/office-factory-business-model-and-ambitious-plans-of-shenzhen-xunlong-software-orange-pi-maker/ 5 hours ago, Dave Kimble said: but has no idea what market he is designing for Market is saturated and makers have to get more creative with the design.
hjc Posted November 26, 2018 Posted November 26, 2018 11 hours ago, Dave Kimble said: how about a M.2 slot instead supporting PCIe x4 so we can buy the biggest, fastest and cheapest per GB SSDs around. I guess what you said (M.2 without PCIe x4) is M.2 SATA. From the perspective of storage protocol they have no differences from normal SATA and mSATA SSDs, and normal SATA SSDs are even cheaper and probably with better heat dissipation. You'd find a lot of Armbian-supported boards with SATA ports (either native SATA or USB3 attached SATA). There are also boards with mSATA slot available. 11 hours ago, Dave Kimble said: You could then eliminate the TF slot, micro-SD cards and eMMC modules, and the system could boot off the drive in the normal Linux manner. Try any board with SPI NOR flash. BTW, "slots" or "pins" are really cheap components, they worth nothing comparing to chipsets.
chwe Posted November 26, 2018 Posted November 26, 2018 18 hours ago, Dave Kimble said: In the same way, I will probably never use GPIO pins, or IR receivers, cameras, touchscreens, on-board microphones, or alternative (to HDMI) audio outputs, so they can all be eliminated as bloat in the PC model. assuming that nobody uses it cause you don't use it is kind of.. Clearly a bunch of people don't use GPIOs. Sarcastically 90% of the SBCs will collect dust as soon as 'it's not funny anymore' so they don't even need an SoC.. As @Igor pointed out.. there are a bunch of SBCs for different use-cases.. Connectors are mostly cheap, so they solder as much as possible on it.. E.g. for the HC1 I would love to have at least an I2C bus and some GPIOs wired out.. (for some DS18b20 ore something like that to monitor the temperature).. If you want performance you'll have to pay for it anyway no matter if there are only a few or a bunch of connectors.. See RK3399 boards.. Something else you've to consider.. you need some storage for the bootloader.. Normally those SoCs can't boot directly from SATA.. you either need an SD-Card, eMMC or SPI flash.. Here as well SD-Card is just the 'most convenient' way of doing it. Not much can go wrong and in case it does.. just reflash it. 1
Dave Kimble Posted November 26, 2018 Author Posted November 26, 2018 Quote Chwe: ... you need some storage for the bootloader.. Normally those SoCs can't boot directly from SATA... Isn't that simply because of the way initrd/initramfs has been written? - I know, let's get the bootloader from the slowest/most unreliable device we have. Quote hjc; Try any board with SPI NOR flash. BTW, "slots" or "pins" are really cheap components, they worth nothing comparing to chipsets. I'm not trying to save money here, just getting the fastest solution for the "PC model" SBC. I remember putting my first SSD into a EeeNetbook and being amazed at the speed of the boot. Quote Igor: Market is saturated and makers have to get more creative with the design. I'm suggesting that "creative" means "more focused on the actual task", one of which is "PC Model". One special case of which could be your own mail server set up by iRedMail. Others might be Routers, Robotics, ATA phone adapters... what else?
chwe Posted November 27, 2018 Posted November 27, 2018 20 hours ago, Dave Kimble said: Quote Chwe: ... you need some storage for the bootloader.. Normally those SoCs can't boot directly from SATA... Isn't that simply because of the way initrd/initramfs has been written? - I know, let's get the bootloader from the slowest/most unreliable device we have. You may need to get familiar with the bootprocess of ARM boards compared to x86... there's no BIOS in armworld.. http://linux-sunxi.org/Boot_Process can be a starter.. Quality SD cards aren't that unreliable (for sure not comparable with quality SSD cards.. but ok-ish).. but if you go for the cheapest.. well I would call it a 'not our problem'.. 20 hours ago, Dave Kimble said: EeeNetbook and being amazed at the speed of the boot. Speed. define speed, speed at boot doesn't really matter IMO.. if it's 10 seconds or 30seconds until your board is up and running.. does it really matter? Armbian is normally up within >20 seconds expect first boot.. I'm more interested in speed once it booted up.. also known as performance.. 20 hours ago, Dave Kimble said: I'm suggesting that "creative" means "more focused on the actual task", one of which is "PC Model". https://libre.computer/products/boards/roc-rk3399-pc/ the pc-a-like model... 20 hours ago, Dave Kimble said: One special case of which could be your own mail server set up by iRedMail. the cheapest one you can find.. a mail-server for a few mail addresses shouldn't be as resource hungry.. e.g. all H3 oranges or bananas or Libre Computers or nanopis or A20 boards or whatever you want to use.. 20 hours ago, Dave Kimble said: Others might be Routers, BPi R1, BPiR2, Clearfog PRO, Clearfog base, Espressobin 21 hours ago, Dave Kimble said: Robotics, every board which works fine with an RT kernel.. beagle bones etc. 21 hours ago, Dave Kimble said: ATA phone adapters I don't think that's really an use-case but for sure there's a RPi HAT for something like that..
Dave Kimble Posted November 28, 2018 Author Posted November 28, 2018 Quote Chwe: You may need to get familiar with the bootprocess of ARM boards compared to x86... there's no BIOS in armworld.. I never said anything about BIOS. Initrd/initramfs contains the code that decides where to get the fs from and where to put it and mount it. If every SBC has a micro-SD card (that costs more than the SBC) then initrd will be on the micro-SD. But if every PC-model has a SSD, then you would get it from that. If that's not right, you haven't said how. Which reminds me, the individual board pages have a feature set (in blue boxes). Have these been translated into a spreadsheet so that they can be viewed/interrogated as a whole set? That would be very useful for choosing a board.
chwe Posted November 29, 2018 Posted November 29, 2018 On 11/28/2018 at 1:08 AM, Dave Kimble said: I never said anything about BIOS. Initrd/initramfs contains the code that decides where to get the fs from and where to put it and mount it. and that's why I said: On 11/27/2018 at 8:15 PM, chwe said: You may need to get familiar with the bootprocess of ARM boards compared to x86... without the bootloader (u-boot) our arm boards can't boot from *random media* most of them can boot either over SDIO (means SD-Card or eMMC) or SPI (means a little SPI flash with 2-16MB space)... That's a way before Initrd comes into the game.. Those SoCs are (mostly) made for cheap TV-boxes.. we just have to keep this in mind sometimes...
Dave Kimble Posted November 30, 2018 Author Posted November 30, 2018 Yes, but if some SBCs were designed to be focused on the "PC-model", which always expects an SSD to be present, with a boot-flag set to identify it, then the bootloader would know where to find it. This would mean a change to the bootloader code, of course - a change to a better (faster, more reliable, cheaper and LESS HARDWARE BLOAT) solution than current SBCs that have unfortunately inherited from TV-boxes and RPi-lookalikes, which serve their own perfectly valid purpose, but don't suit the "PC-model". I know current SBCs are not like that now. I am talking about a change that could be proposed by Armbian Group to Steven Zhao of OrangePi, and be in existence in 6 months.
martinayotte Posted November 30, 2018 Posted November 30, 2018 11 hours ago, Dave Kimble said: which always expects an SSD to be present, with a boot-flag set to identify it, then the bootloader would know where to find it. Current U-Boot is able to detect SSD present on any USB ports, and can boot from it without any issue ...
valant Posted November 30, 2018 Posted November 30, 2018 Literally every current SBC SoC ROM code gets its payload from SPI NOR flash, eMMC, SD. Without these interfaces your M.2 paradise dream won't even start. And by the way, having a normal PCIe slot is way much better than everything else, with M.2 includingly. With the former you can attach M.2 expansion card and have what you want, but as well can upgrade it or attach something else. This is why I like how it's done with RockPro most. other rk3399 boards have screwed PCIe up.
valant Posted November 30, 2018 Posted November 30, 2018 1 minute ago, valant said: Literally every current SBC SoC ROM code gets its payload from SPI NOR flash, eMMC, SD. Without these interfaces your M.2 paradise dream won't even start. This is the whole answer. And by the way, having a normal PCIe slot is way much better than everything else, with M.2 includingly. With the former you can attach M.2 expansion card and have what you want, but as well can upgrade it or attach something else. This is why I like how it's done with RockPro most. other rk3399 boards have screwed PCIe up.
Dave Kimble Posted November 30, 2018 Author Posted November 30, 2018 5 hours ago, valant said: Literally every current SBC SoC ROM code gets its payload from SPI NOR flash, eMMC, SD. Yes, one of them is "needed" and the rest is hardware bloat - once you have read the Boot ROM, why have a chain of micro-SD cards or eMMC modules, or a PCIe slot and a PCIe expansion card and a M.2 device? And if the Boot ROM always points to the M.2 device, you don't need the Boot ROM either, so that's bloat too. I don't know why we are still discussing what "literally every current SBC" does.
valant Posted November 30, 2018 Posted November 30, 2018 39 minutes ago, Dave Kimble said: Yes, one of them is "needed" and the rest is hardware bloat - once you have read the Boot ROM, why have a chain of micro-SD cards or eMMC modules, or a PCIe slot and a PCIe expansion card and a M.2 device? And if the Boot ROM always points to the M.2 device, you don't need the Boot ROM either, so that's bloat too. I don't know why we are still discussing what "literally every current SBC" does. Boot ROM doesn't "point" to anything, this is a tiny piece of code inside of the SoC, CPU executes first when starts. This code loads its payloads - next stages of the firmware - from one of those media into SRAM and hands off control there. And currently, no ROM codes of SBCs could use anything except SPI NOR, NAND, eMMC or SD. M.2 is just a connector - for either PCIe, SATA or USB3 interfaces. None of those are supported by current ROM codes. Except USB can be used for transfering payloads through some custom vendor defined protocol - not an ordinary mass storage use case. Why they aren't supported? Because neither SATA nor NVMe (that uses PCIe) nor USB mass storage devices were "ordinary" for mobile devices, from which SBCs' SoCs come. As of "why have so many devices/interfaces", well, who would decide the best choice? There are diferent needs and budgets. From many points of view - software components placement and board vendor/user perspective. For the firmware, the best places to have been put in are SPI NOR chips, boot areas, "partitions", of eMMC modules. for the OS - it depends on the price users are ready to pay. Will it be a cheap SD card, medium priced eMMC module or exteremely expensive NVMe SSD. Having SD cards or eMMC modules as main storage devices on these platforms doesn't make these not "PC" like. These are PCs but they are mini PCs and the mentioned interfaces fit well this defintion. For example, without them, and only with the M.2 SATA/NVMe SSD option, SBCs won't be "affordable" things for "tinkering" anymore. And why on the planet one can be bothered by having an SD card slot on the board?
martinayotte Posted December 1, 2018 Posted December 1, 2018 3 hours ago, Dave Kimble said: I don't know why we are still discussing what "literally every current SBC" does. As it been mentioned earlier in this thread, try to understand how most of ARM boot process is working ... Otherwise try to argue any thing you wish with ARM.org president, because we live with hardware design, it is NOT Armbian issue !
Dave Kimble Posted December 1, 2018 Author Posted December 1, 2018 Valant, I don't know so much about "a cheap micro-SD card" - Amazon (AU) has cheapest 32 GB micro-SDs for AU$11.95 . And cheapest 32 GB M.2 SSDs for AU$24.67 which is hundred of times faster. Converters from 2.5" SATA 3 to M.2 SSD cost about AU$13, so the price of M.2 slot alone would be about AU$6, if that. Boot ROM does "point to" something - the ROM code specifies (points to) the device to get the payload from. If it currently has a code for micro-SD but not for M.2 SSD, then my suggestion becomes "a new ROM code for M.2 SSD" which is always present in the PC-model. Since on PC-model SBCs, the Boot ROM always points to M.2 SSD, the boot ROM is not needed and is bloat. Martinayotte, it IS an Armbian issue if we can recommend a better boot process and have OrangePi build it for us, saving OPi some space on his boards and unnecessary cost in the hardware components. If "ARM Standard" is to have a Boot ROM with ROM codes 1=micro-SD, 2=eMMC, then why not 3=M.2 SSD ?
Igor Posted December 1, 2018 Posted December 1, 2018 5 hours ago, Dave Kimble said: it IS an Armbian issue Nope. If initial boot (loading u-boot/"BIOS") is not possible other way than from slow media SD/eMMC/SPI we can't improve even wanted. Not to mention that our resources are extremely underpowered and R&D is our private cost so the questions of "why?" is always present. There are certain designs, where u-boot can be loaded directly from SATA https://wiki.solid-run.com/doku.php?id=products:a38x:software:development:u-boot but generally this is not the case. ARM standard is diversity, that there are no standards. And Armbian is making a standard out of this mess.
Dave Kimble Posted December 1, 2018 Author Posted December 1, 2018 Well if it is not an Armbian issue, can you give me Steven Zhao's email address and I'll try and sell the idea to him directly?
Igor Posted December 1, 2018 Posted December 1, 2018 18 minutes ago, Dave Kimble said: Well if it is not an Armbian issue Armbian as community certainly have an impact on the hardware design but is not designing hardware. We, you and me, are together in this. 18 minutes ago, Dave Kimble said: Steven Zhao's email address He is They are doing a board design (wiring the components) and is are limited with the chip design itself. Chip is designed elsewhere -> Allwinner/RockChip/* is making a chip based on ARM corp. design. See, it's complicated and you can't get there just like that. 18 minutes ago, Dave Kimble said: sell the idea Idea about what? Perhaps this is designed this way by purpose? Look on this problem from other perspectives.
Dave Kimble Posted December 1, 2018 Author Posted December 1, 2018 Quote Igor: Idea about what? The idea is: those people wanting a cheap PC solution will ALWAYS want to add an SSD to their system, preferably a big one and preferably much faster than the SATA-3 theoretical maximum (6 Gbps). M.2 SSD in fact. They then don't want to have to buy a micro-SD card just to hold the bootloader, or have cheap and nasty microphones, or alternative sound outputs (from HDMI), or RPi cameras, or unusual screens, or GPIO pins. They WILL want gigabyte ethernet and 4GB of RAM and LARGE copper heatsinks. I realise he will be building using someone else's chips, but no one has described a difficulty that needs a micro-SD and TF-slot to make things work. I hate bloat, both hardware and software, and am also working on cutting down on Ubuntu bloat.
Tido Posted December 1, 2018 Posted December 1, 2018 7 hours ago, Dave Kimble said: it IS an Armbian issue if we can recommend a better boot process and have OrangePi build it for us http://www.orangepi.org/orangepiplus2e/ IIRC this SBC received some ideas of the community, especially @tkaiser was after some features. IIRC he and others were having discussion AND NOW BIG surprise in the Orange Pi Forum Wooohuuuu http://www.orangepi.org/orangepibbsen/forum.php Not here, no no. Not here. Over at OPi, where the HW developers are.
chwe Posted December 1, 2018 Posted December 1, 2018 48 minutes ago, Dave Kimble said: The idea is: those people wanting a cheap PC solution will ALWAYS want to add an SSD to their system, preferably a big one and preferably much faster than the SATA-3 theoretical maximum (6 Gbps). and that's not true at at all.. even the cheap often intel based 'minicomputers' are mostly based on eMMC. Spoiler I know this term was originally reserved for such monsters: some numbers to think about: Allwinner H3 is from 2014 Rockchip RK3399 is from 2016 Allwinner H6 is from 2017 those chips aren't the newest when they enter the SBC market. If a boardmaker limits his board to SSDs he'll limit himself to a specified market so I'm quite confident that this won't happen. Why should he? Wiring out and SDIO interface (for SD or eMMC) costs him a few cents and he'll catch a few or a bunch of customers as well (depending on the price of the board in question). e 1 hour ago, Dave Kimble said: I realise he will be building using someone else's chips, but no one has described a difficulty that needs a micro-SD and TF-slot to make things work. SDIO is an rather simple interface and common for TV boxes (eMMC). Those SoCs are mostly used for TV-Boxes so you might need to order 'a few 100k' SoCs until an SoC maker is interested to ramp up a 'special version' for your purpose. Except the fruit Pi board armbian doesn't support there aren't/isn't (m)any SBC makers which sell so many boards. 1 hour ago, Dave Kimble said: M.2 SSD in fact. They then don't want to have to buy a micro-SD card just to hold the bootloader, or have cheap and nasty microphones, or alternative sound outputs (from HDMI), or RPi cameras, or unusual screens, or GPIO pins. They WILL want gigabyte ethernet and 4GB of RAM and LARGE copper heatsinks. You want it doesn't mean everyone wants it.. Currently if you don't want all this 'hardware bloat' go for an AMD/intel based thingie.. Arm boards are more for those who want GPIOs, who want the freedom to boot from different medias, sometimes who want an camerainterface etc. A cheap PC replacement based on ARM is currently not really the most obvious use-case. And even then, I would never suggest they should go for an SSD-boot only board. IMHO SPI NOR is the way to go and guess what (this list doesn't claims to be complete): OrangePi Zero: 2MB SPI flash ROC-RK3399-PC: 16MB SPI flash ROCKPro64: 16MB SPI flash La Frite: 16MB SPI etc.. Put your bootloader there and when *random interface* is supported by u-boot you can boot your linux from it.. The BROM on SoC is likely never touched by the boardmakers. As long as a SoC maker doesn't have 'desktop replacement' as a use-case it will not happen. 8 hours ago, Dave Kimble said: And cheapest 32 GB M.2 SSDs for AU$24.67 which is hundred of times faster. proof for your claim? or only reading specs? 8 hours ago, Dave Kimble said: If "ARM Standard" is to have a Boot ROM with ROM codes 1=micro-SD, 2=eMMC, then why not 3=M.2 SSD ? cause 1&2 is more or less the same.. both are SDIO interfaces (which are not that different from SPI) whereas 3 is a complete different story.. 8 hours ago, martinayotte said: As it been mentioned earlier in this thread, try to understand how most of ARM boot process is working ... just a kind remember.. This suggestion was to avoid this bloated discussion which is senseless as long as you don't understand how an SBC boots.. 2 hours ago, Dave Kimble said: Steven Zhao's email address and I'll try and sell the idea to him directly? http://www.orangepi.org/ there you'll find it on the bottom... It's not our job to give you stuff you'll find by visiting the boardmakers web-site..
martinayotte Posted December 1, 2018 Posted December 1, 2018 13 hours ago, Dave Kimble said: If "ARM Standard" is to have a Boot ROM with ROM codes 1=micro-SD, 2=eMMC, then why not 3=M.2 SSD ? Again, you didn't understand how Boot ROM, which is located inside the SoC by manufacturer (not by Steve Zhao), is involved in the boot process. BROM is involved only a faction of second to boot U-Boot, then U-Boot is involved only few seconds to finally boot the kernel, which can of course be located on SSD. Since you've compared often ARMs to PCs, let me ask you a question : Did you ever saw a PC without any BIOS booting directly from SSD ? I doubt ... In other words, U-Boot is a bit like BIOS, although lot of differences, the Intel or AMD CPUs are not aware by themselves how to initialize a SATA or an M2 interface. Even if it could, they are not aware if a SSD is formatted in FAT/NTFS/EXT4 or whatever filesystem. It is up to BIOS, or U-Boot in case of Arm, to give at least a small intelligence to a brainless CPU.
valant Posted December 1, 2018 Posted December 1, 2018 17 hours ago, Dave Kimble said: Valant, I don't know so much about "a cheap micro-SD card" - Amazon (AU) has cheapest 32 GB micro-SDs for AU$11.95 . And cheapest 32 GB M.2 SSDs for AU$24.67 which is hundred of times faster. Converters from 2.5" SATA 3 to M.2 SSD cost about AU$13, so the price of M.2 slot alone would be about AU$6, if that. Boot ROM does "point to" something - the ROM code specifies (points to) the device to get the payload from. If it currently has a code for micro-SD but not for M.2 SSD, then my suggestion becomes "a new ROM code for M.2 SSD" which is always present in the PC-model. Since on PC-model SBCs, the Boot ROM always points to M.2 SSD, the boot ROM is not needed and is bloat. Martinayotte, it IS an Armbian issue if we can recommend a better boot process and have OrangePi build it for us, saving OPi some space on his boards and unnecessary cost in the hardware components. If "ARM Standard" is to have a Boot ROM with ROM codes 1=micro-SD, 2=eMMC, then why not 3=M.2 SSD ? Oh well. "ROM code" is not a number, that points somewhere and this magically makes it "load" the next stages. It is instructions, the code, in the sense as an OS is the code... So, for adding to the ROM code other interfaces support to load from, you need to write that code and flash it into a CPU. And now, the most interesting part. Again, M.2 is a connector and nothing more. You attach either SATA/AHCI things to it or PCIe/NVMHCI things or USB3/xHCI/UASP to it. And now, imagine, - all those aren't the easiest pieces of hardware. ROM code runs in the most limited envinronment ever possible. Nothing works yet. It's something like a few of KBs worth. And that code needs to setup for example AHCI/SATA and try to do something with it. Even on PCs, this is not the case, since, I guess, x86 processors' "ROM code" only cares about NOR chips having BIOS/UEFI there. Basically, it strats up from the hardcoded address running some XIP code on the NOR chip. It's the easiest way. So, ARM ROM codes aren't the dumbest ones yet. Get it finally? Nobody will ever add AHCI/NVMHCI/xHCI support to the ROM code, it's technically impossible. So for you, here is the receipe: 1) you choose the board with the small NOR chip for the firmware (UEFI, uboot, if the latter could qualify for being called that ) flashed there. as well, the board should have ... what you dream about - M.2 connector. 2) you attach there your SSD and setup your firmware to boot the OS of your choice from there 3) finally, you happily desolder SD card slot and/or eMMC module. The "bloat" is gone, you are happy. Enjoy. I mean you need to become an SBC board vendor for satisfying such whims. No sane manufacturers will do that for their money.
Recommended Posts