Jump to content


  • Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    TRS-80 reacted to calinb in Pinebook Pro install instructions?   
    NVMe cannot be booted. (It cannot contain u-boot or tow-boot or ANY boot code.) It's not in the boot path.
    See the Pine64 wiki at https://wiki.pine64.org/index.php/Pinebook_Pro#Using_as_OS_root_drive
    The SoC does not include the NVMe boot code, so the NVMe is not in the SoC's boot order. However, using the U-Boot update script from the mrfixit2001 Debian or Arglebargle's modified script, and the modified u-boot images provided by forum user pcm720, you can now add support to boot from an NVMe drive.
    and quoted from https://wiki.pine64.org/index.php/Pinebook_Pro#Boot_devices
    Please note that PCIe, the interface used for NVMe SSD on the Pinebook Pro, is not bootable on the RK3399 and therefore is not a part of the boot hierarchy. It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires uboot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC.
    Also, wherever you put this boot code, the target kernel and /boot files must support it too and the subsequent boot priority that it provides is at the whim and discretion of its author!
    So, if you want to ditch both eMMC and SD memory as part of the boot chain and boot a system on NVMe (/ and boot), you must use SPI. Sadly, it might not work for all operating systems due to bugs or lack of kernel support:
    Here is some information on using the SPI flash device:
    You need the kernel built with SPI flash device support, which will supply a device similar to: code>/dev/mtd0
    Unfortunately, at this time, Armbian seems to have problems when the Armbian system resides on media other than the SD card! I don't know if the problem occurs when Armbian relies on a non-Armbian u-boot (eMMC u-boot) and/or even if the Armbian supplied u-boot doesn't work when it and the Armbian system are flashed to eMMC.
    I also don't know if Armbian would work with u-boot or tow-boot or something else flashed to the SPI NOR memory. My guess is it's a poor wager!
    I think I might try to copy the Armbian / system (copy files--not an image) from my Armbian SD card to my eMMC (or maybe try using my NVMe SSD too, which has been proven to be accessible when booting Armbian from the SD card). The Armbian /boot files don't look anything like the /boot files I've seen in other distros. I have "armbianENV.txt":
    verbosity=1 bootlogo=true extraargs=systemd.unified_cgroup_hierarchy=0 overlay_prefix=rockchip fdtfile=rockchip/rk3399-pinebook-pro.dtb rootdev=UUID=f57dd6bf-3737-40f9-95b0-376895bc2055 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    I wonder if it (the Armbian SD card /boot code) would load and run the system from eMMC or NVMe, if I simply change the rootdev=UUID entry to match the desired target. (and also change the fstab entry in the target).
    Again, I don't know how this file works. What does "usbstoragequirks" do? That's a scary label!
    The Slackware PBP aarch64 distro only supports booting a system on NVMe from an SD card. (Slackware devs don't even officially support eMMC, which they freely admit they don't trust as reliable hardware, because it's cheap NAND memory.)  This usage model would be fine with me with my Armbian system! Once booted, the SD card can be unmounted and removed.
  2. Like
    TRS-80 reacted to calinb in Pinebook Pro install instructions?   
    I might find time to work on this. I'm loving my latest SD install of Armbian Jammy KDE Fusion and I'd like to copy it from my SD card to on my PBP NVMe drive (or at least my eMMC). I've done this sort of thing with my PBP in the past and even had Manjaro running with / and /boot on my NVMe drive. I also wrote a crude dual boot script to toggle the boot between systems on NVMe and eMMC.
    I installed PCM720's Uboot code but stopped short of risking its install to SPI.
    I've always had strange boot problems from time to time with my PBP though. When I had Manjaro installed to NVMe (/boot and /), I had two occasions when a Manjaro apt-get upgrade killed the boot with the system entirely on NVMe. Luckily I had backups. I think both boot failures happened when a kernel update was included in the upgrade. Stritt (Manjaro forum mod) and I never got to the bottom of it though. Once I recovered the system by building a new kernel package from source and installing it to the broken system. Then it worked from NVMe again so I came to the conclusion that it wasn't actually a kernel change that caused it but, rather, something else associated with it.
    Here's the PCM720 thread and one of my posts. PCM720 provides links to his code earlier in the thread. It's difficult to find his most recent code so I'll try to find it and provide a link here.
    I don't post on the Pine64 forum anymore though. Pine64 forum mod, Arwen, was far too aggressive in the censorship of posts right after COVID broke. Geesh--II was a DivX forum mod for years back when it was a nearly unique and very popular forum (as was doom9 :))  and, I never needed to censored anyone--especially for a general off-hand comment that wasn't even directly associated with an event like COVID.
  3. Like
    TRS-80 got a reaction from gounthar in How to get Armbian running on a X86_64 with multiboot?   
    Yep, by now they are available in the store!
    Too bad I had to move and been spending money like a drunken sailor buying things for the new place.  I might not have enough left now for a PBP. 
  4. Like
    TRS-80 got a reaction from Igor in Armbian 22.05 (Jade) Release Thread   
    Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
    On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
    Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
  5. Like
    TRS-80 got a reaction from Werner in Armbian 22.05 (Jade) Release Thread   
    Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
    On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
    Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
  6. Like
    TRS-80 reacted to hmof in ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!   
    So I have this working on bullseye by using the Armbian edge kernel (linux-image-edge-meson64, 5.17.5-meson64 in my case) with zfs from bullseye-backports. The important part was the new kernel headers I think, as the previous kernel (linux-image-current-meson64, 5.10.123-meson64) appears to be missing module.lds needed to build any out of tree module. I think the same problem would occur with jammy because the kernel package is the same.
    This looks like it was fixed in January 2021 in https://github.com/armbian/build/pull/2545, but meson64 still has an unfixed 5.10 kernel as current in 22.05.3, while some other boards have 5.15 (and some have earlier versions) which has the fix, and so does the meson64 edge kernel 5.17.5.
  7. Like
    TRS-80 reacted to Werner in Armbian related videos / video documentation thread!   
    Who's that weird guy in the woods
  8. Like
    TRS-80 got a reaction from lanefu in Armbian 22.05 (Jade) Release Thread   
    Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
    On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
    Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
  9. Like
    TRS-80 reacted to schwar3kat in Armbian 22.05 (Jade) Release Thread   
    It has been diabolically difficult to identify this issue.   Good news is that it is not a build issue, and it's not a reversion of the lan0 bug.   I have flashed around 100 images and done countless power-downs and reboots.  Each time I thought that I was making progress, more testing disproved it.    The initial workaround did seem to resolve the issues, but they still occur if enough reboots are done.   Even older builds have the issue if enough reboots are done.  It seems that newer builds are just more sensitive to the issue.

    At one point I thought that there were two different issues for Debian and Ubuntu builds because the fixes were different, but more testing proved that the fixes didn't stick permanently.  Symptoms are also variable, from the more common intermittent drop-outs and slow-downs to the less common total loss of lan0 NIC or total loss of networking. 
    In my environment, the issues can be completely eliminated by disabling IPv6.  Using armbian-config to do this does not work!  
    The armbian-config method adds lines to /etc/sysctl.conf but unfortunately this does not disable IPv6.
    Ipv6 must be disabled by adding extraargs="ipv6.disable=1" to armbianEnv.txt.

    The cause seems like it might be related to the resolvconf-pull-resolved.service and NetworkManager and RTL8153B, and is intermittent, but once it has stopped working correctly, it is problematic to get it working again without a power-down (on Ubuntu, apt-get --reinstall install resolvconf then reboot fixes it temporarily). 

    I suspect that my IPv4 NAT environment is sometimes confusing resolvconf or some other networking component on this board and leaving somethings in networking in a corrupt state.  I don't have the same issue with my H5 and H3 boards.

    I will change the work-around instructions to reflect my findings.
  10. Like
    TRS-80 got a reaction from gounthar in How to get Armbian running on a X86_64 with multiboot?   
    I have been wanting to buy one for what seems like months (a year?) now and they have not been able to do a production run due to the supply chain shortages (mainly screens, apparently).  I follow them pretty closely, there was some hope maybe after CNY 2022 but then they announced no they could not source screens after all.
    So your information is really timely @hexdump, thanks a lot for that. 
  11. Like
    TRS-80 got a reaction from Igor in Armbian 22.05 (Jade) Release Thread   
    Sorry could not make the meeting.  I just read the notes.
    I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow.
    I'll try to hang out in IRC.
  12. Like
    TRS-80 got a reaction from Werner in Armbian 22.05 (Jade) Release Thread   
    Sorry could not make the meeting.  I just read the notes.
    I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow.
    I'll try to hang out in IRC.
  13. Like
    TRS-80 got a reaction from lanefu in Armbian 22.05 (Jade) Release Thread   
    Sorry could not make the meeting.  I just read the notes.
    I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow.
    I'll try to hang out in IRC.
  14. Like
    TRS-80 reacted to schwar3kat in armbian-next development   
    I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying.   It does seem faster though.

    Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing.
    but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134

    Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy.  No build errors.

    Orangepi-r1 (H2) build system failed near the end.  019.000.create_board_package.log
    --> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ]
    --> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ]
    The annoying 6.8 MiB html log file is a pain to parse. 

    I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs?

    Can I switch off the time wasting and annoying markdown / html logging behaviour?
    I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.
    LOG_ENABLE_EXTENSION=no, didn't do it.
    Is it possible to keep the split .tmp files on error / build fail?
  15. Like
    TRS-80 reacted to going in armbian-next development   
    I think we should do exactly the opposite.
    As soon as the author realizes that his codebase has begun to create stable images for the family\branch, he can invite the most active members of this group to test and fix bugs.
    That is, errors, changes must be made in this branch. While the master should remain stable and not create problems for the current work.
  16. Like
    TRS-80 reacted to rpardini in armbian-next development   
    Here's some info on armbian-next status:
    - In development since October/2021 (thus 7 months)
    - Currently sitting at 189 commits, almost all lib/**/*.sh files are changed.
    - More than 17 rounds of manual merges performed manually against master. Sometimes we have 1-2 weeks of delay, but it's mostly master-equivalent. Each round takes 2-5 hours of carefully reviewing every commit that landed on master and maybe rewriting it.
    - Huge changes around logging and error control. Errors now stop the build. Logs contain actionable information.
    - Rewritten kernel building and packaging. There's no more packaging patches or builddeb hacks. Kernel-headers support cross compiles across all arches. No more byteshift patch. Still needs tuning.
    - Completely changed git handling, specially for kernel. This still needs handling of previously git://, now http:// bundle downloading as reported above, and caching.
    - Patch hashing is half-rewritten, still needing work. Now same code can both actually patch and produce hashes, making it consistent. "fasthash"
    - apt-cacher-ng configuration for local usecase is now under Armbian control.
    - 100% working without any external/downloadable toolchains.
    - full support for building any arch under any other arch, including "reverse cross-compiles" and running of rkbin/fip x86-only binaries.
    - source code is now properly formatted according to shellfmt, and 90% of shellcheck warnings are squashed. A lot remains still.
    - 20x faster kernel rebuilds, 2-3x faster full builds due to consolidated make invocations, benefitting from bintree caching as well as ccache.
    - most compression points changed to zstd, yielding multicore (de-)compression and thus much faster image building during cache hits.
    - full support for DKMS modules, eg nvidia-drivers and ZFS, under any cross compile scenario.
    - data channel for metadata communication, config extraction, matrix generation etc by having stdout clean for machine data. logs to stderr.
    - per-build TMPDIR affecting and protecting all `mktemp` invocations
    - all traps rewritten under a cleanup/trap manager.
    - full HTML-based, single-file, full build log artifact. no more output/debug.
    - many others I forget.
    All that said, I've still a ton of stuff pending before this can 100% replace current master:
    - EXTRAWIFI-style manual patching of things is not idempotent nor proven working with "fashhash" and probably causes full kernel recompiles, negating previous benefits until fixed.
    - (server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.
    - kernel-headers will probably be unified with kernel-sources, since they contain mostly the same stuff.
    - extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.
    - certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

    Some few brave souls like @NicoD, @Rich Neese, and @going have actually tried armbian-next and every single try there's stuff to fix, thanks for trying and reporting.
    TL,DR: armbian-next is doing well, thanks. Work continues. It might not be ready for merge, will it ever be? I will keep it rebased as much as possible. There's no pressure. Try it out, and report. Thanks!

  17. Like
    TRS-80 reacted to rpardini in Odroid M1   
    I've some images, but they're really quite far from usable right now.
    Vendor kernel 4.19 I can't get HDMI to work. Everything else works. I'm using it to build Armbian itself and works great with NVMe and the 8gb RAM.
    Mainline 5.18-rcX has working HDMI, but no NaNeng PHY, so no PCIe/NVMe, no USB3, and no SATA. tobetter is working, also work in quartz64a and other rk3586/8 will benefit this.
    nand-sata-install will not work with this unless I find a way to flash uboot to SPI (and this remove petitboot, but there is no official petitboot recovery from HK yet)
    and mainline u-boot is even further away, so little chance of that.
  18. Like
    TRS-80 reacted to rpardini in Armbian 22.05 (Jade) Release Thread   
    Yes. I don't think it's even near being merge-able right now, small bugs but are showstoppers for most people, and I can't handle them all by myself in such timeframe, including handling all the Jammy fixes and a dozen rockchip kernels, extlinux, nand-sata-install, etc.
    And once merged a whole slew of things will show up (extras buildpkgs, prebuilt, rootfs caching, repo publishing, git bundle stuff, most of the GHA stuff that normal developers hardly ever run).
    The concepts behind armbian-next are almost fully realized, but the fruits still have to be collected. Otherwise it seems pointless...
    I will keep it rebased as much as possible, so the effort lives on, only without pressure.
    Before merge, documentation has to be written too, so that will take a while.
    work continues!
  19. Like
    TRS-80 reacted to hexdump in How to get Armbian running on a X86_64 with multiboot?   
    @gounthar - if you are looking for arm laptops for use with linux, then you should also consider arm chromebooks. best supported are the mediatek mt8183 based kukui and the snapdragon 7c based trogdor devices - nearly everything is working for them with mainline with only very few to no patches required and they are available used or new really cheap (by a factor lower than any other arm laptop option). both have 8 cores, 4gb (some 8gb) ram and 64+/-gb fast emmc. performance wise they are above odroid n2 level. if you can get (not easy due to supply issues) or build (there are a few docs with instructions online) a suzyqable you even get features like a serial console on a laptop which you usually never get. the build quality and reliability of such chromebooks is usually way higher as for average sbc's and with mainline on the above mentioned series you get: panfrost gpu support, working suspend/resume and power saving modes, working wifi, bt, sound and for most of them even camera(s). maybe have a look at cadmium: https://github.com/Maccraft123/Cadmium or my linux on arm chromebooks page: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks to get started.
    the best supported other arm laptop is the a few years old lenovo c630 (not the chromebook version) and it is still missing some basic functionality here and there (sleep/suspend etc.). another option - the pinebook pro - is in a different performance and quality league (sadly downwards).
    best wishes - hexdump
  20. Like
    TRS-80 got a reaction from haajee in Rock Pi 4B (RK3399) Sound Broken After Latest Kernel Update   
    Next time @MichaIng (or anyone, really) please 'flag' the post to bring it to (all) moderator attention.  I only happened to notice your request because I was skimming through the All Activity feed like I usually do.
  21. Like
    TRS-80 got a reaction from giddy in New Board Maintainer Q&A   
    I received at least one PM so far that I did not know the answer to.
    So, rather than all of us spend a lot of effort duplicating info, I thought maybe good idea to compile these in one place.  Especially as we have an influx of new Board Maintainers at the moment.
    I also encourage people to stop by IRC and say hello.  I shall also endeavor to copy the most useful bits from IRC into this thread as they come up.  Maybe later can be distilled even further into some docs page or ...?  Anyway...
    So, first up:
    Q: How /what checks/tests to run?
    A: OK, I guess I thought armbian/autotests was more about that (long in development hardware), however looking again now it seems it's actually just a script which can be run on its own, just directly on SBC (even without that test rig).  Amirite?
  22. Like
    TRS-80 got a reaction from Willy Moto in So, you want to run a file server?   
    This is not so much a 'Tutorial' or a 'Review' as it is an overview (and/or starting point for further research) of some things to consider when setting up a file server, some in general and then some more particular to SBC.
    In the simplest case, you could attach almost any drive to almost any board, by any number of ways, and you have yourself 'a file server.'  However with even a small amount of effort, there are so many better ways to do things nowadays.  We have a lot more interesting hardware choices, advanced filesystems, etc. and so those are mostly what I want to talk about.
    But first, some context.
    Dedicated distros vs simple directory sharing
    Personally I am not a fan of dedicated distros like FreeNAS, OMV, etc. as I consider them to be too 'heavy weight' and single solution specific.  I mean, if you need some/all of those features, or you like them or whatever, then great, use them.
    However, a 'file server' is one of the simplest use cases of a 'server' and I am sure one which almost everyone buying a SBC will do at some point.  IMO, all one needs to do is simply share some folder(s) via either NFS (if your network is mostly GNU/Linux machines) or Samba/SMB (if your network is mostly Windows machines).  And that's it, you're done!  Simple, lightweight, and using standard protocols (well, a little less 'standard' in case of Windows, but I digress ).
    You could also add any of the software included in the 'all in one' solutions in first paragraph on a 'piece by piece' basis, if/when you need them.  Personally I am more of a fan of starting small (vanilla Armbian base) and then adding things you need one by one.  But you are of course free to do whatever you want.
    Setting any of that up, or debating about it, is considered off-topic for this thread, as there are tons of resources already around the Internet about those things.  So I want to focus on other, (IMO) more interesting, aspects.  You are welcome to make your own thread with a different focus, of course.
    Important note about hardware RAID
    RAID, in case you were unaware, means "Redundant Array of Independent Disks."
    For a looooooong time, I (and I think many others with SOHO NAS perspective) thought that 'hardware RAID was the only proper way to do it' but in the course of researching ZFS I eventually became convinced otherwise.  In fact, apparently, historically 'big-iron' filesystems (Solaris, others) were always run with software RAID in the enterprise as there are a lot of advantages to that.
    Just think about it.  If your hardware RAID card dies, you need to replace it with exactly the same model, before you can even begin to recover your data.  With software RAID, you just re-connect drives and you are back in business (with ZFS, you can even connect them in any random order, amazing!).
    In particular if you are using ZFS, hardware RAID controllers are not recommended.  I am not sure how much this applies to other similar software RAID systems, but it would stand to reason that it does (IMO).
    Hardware controllers are also typically very expensive and proprietary.  Where software RAID uses readily available and inexpensive commodity hardware (while actually increasing reliability).  All of which is why I have become such a big fan of it, whether we are talking about ZFS (which I like) or some other software RAID solution you may prefer instead.
    Now, with that out of the way, onward!
    Assuming you came to similar conclusions as I did in previous section already, this is where our decision making process really begins in earnest IMO.  As the way I see it, choice of file system will dictate topology, which will in turn dictate choice of hardware (which SBC to buy).
    Of course if you already bought some SBC, you are in a different boat (and working backwards, from my point of view ).  Anyway, you will have to adapt accordingly (and/or buy different hardware).  However, if you are already there, go to 'Historical Overview' section, and maybe you can find some solution there which will work with the hardware you already have.
    Now, back on track, we are really lucky nowadays, thanks to F/LOSS, to have some industrial grade, software based filesystems available to us mere mortals! 
    I like ZFS, but certainly, opinions will differ.  Some people like btrfs, in fact I got into a lengthy (but IMO informative) debate with @tkaiser about that.
    Then there are other distributed things like Ceph (and others) which I will admit to knowing less about.  If you do, kindly add your thoughts to the thread when you have a moment.
    Point being, hardware setup for someone like me (using ZFS) or even someone using btrfs will be perhaps quite different than someone using something distributed like Ceph.  Just keep that in mind.
    Historical Overview (SBC Hardware)
    I want to cover some of things which came before, as I think they are relevant to understanding where we are today.
    In the beginning, there was darkness.  Wait, let me fast forward a bit. 
    I will start with the creation of Armbian.  Which happened, in fact, because Igor was trying to set up a file server on a cubietruck.  True story (and like I said, you are not alone, this is a common use-case)!    Anyway, many of us bought (A20 based) cubietruck back then, because they sold a small power adapter board which made this easy and they also had a SATA connector right on the board.  I think they were one of first to do this in fact (I could be wrong).
    After that, a lot of us used (more powerful Samsung Exynos5 based octo-core) ODROID-XU4, along with a good quality USB to SATA adapter with UASP.  That one in particular was recommended by tkaiser a long time ago, however -- as of time of writing this post -- PINE64 still sell it in their store(!).  And it may be an 'okay' solution if you have some (especially, USB3 capable) board laying around that you just want to use.  Some people are still using this today.  But we have a lot better options now.
    Then RK3399 came on the scene.  Which was very exciting, because these support not only PCIe, but they are also 64-bit (which is required for ZFS).  Unfortunately, it took literally years for these to become really stable.  Lucky for you, this is all in the past by now.  And so, currently, many people will probably recommend RK3399 as a file (or other) server.
    There are a lot of other boards out there, which I do not have as much experience with.  But I also try to note only historically significant developments here (at least the way I see them).  If you have any to add, please comment below or contact me somehow (PM or IRC) and I will edit this post and add them.
    Usage (other than file server)
    As I already stated, almost any cheap board can be a (minimal) 'file server.'  From that point of view, more powerful boards (like RK3399, or others) are overkill.  However maybe you want better throughput.  Or more disks.  Or, like me, you want to run advanced filesystem like ZFS (also with more disks).
    Another thing which happens is that, once you handle the simple case of serving files, before you know it you will probably want to start doing more than that.  You may already have some more demanding requirements in mind beforehand.
    For all these reasons, a slightly more powerful (and more expensive) board may be a better choice, as you will not be limited in the future.  But if you are very sure about your needs and wants, and have perhaps other boards on your network to handle processing intensive tasks, this may not apply to you.  Just something to consider.
    Hardware Recommendations (RK3399 based)
    For reasons mentioned at end of 'Historical Overview' section, many of us are fans of RK3399 based devices nowadays.
    Within this subset, you will get a lot of opinions.    I know because I spent literally years asking people (including developers), while I was waiting for RK3399 to mature.  Some developers think certain vendors make crappy hardware (and maybe they are right).  Or they prefer the boards they know and develop on (naturally, IMO).  Some vendors support the project a lot more than others (PINE64, notably, do not support Armbian at all to my knowledge).  So you will have to do some amount of your own research, and form your own opinion here.
    I don't want to discount any of the above criteria too much.  However, in the end, at least for me, one criteria bubbled to the top.  And that was direct PCIe (or SATA) support.  Since we are talking about RK3399 here, this means PCIe support.  Which of course is in the SoC, but that is not what I am talking about.  I am talking about putting a standard PCIe physical interface directly on the board.
    This way, you can buy any standard cheap/dumb PCIe to SATA adapter card.  You can keep spares.  You will be able to obtain them for the foreseeable future.
    By contrast, you can certainly rig up your own adapters, cables, etc. from GPIO.  But personally, I find that fiddly and it doesn't strike me as the most reliable.  I know some people are doing this just fine though.
    Another way, is that many vendors sell some sort of HAT, which provides SATA connectivity.  However I find this short-sighted and -- quite frankly -- self-serving.  What if they are out of stock, or stop making them?  You are out of luck.  Or you would need to revert to the above option (rigging up cables and adapters).  It's good for them selling add-on hardware though I guess -- hence my 'self-serving' comment -- but maybe not the best for you and me in terms of keeping our important data available and up and running, on a long term basis.
    Therefore I say, skip all of that and go with a board that has a standard physical PCIe right on the board.
    And AFAIK, there is only one (standalone SBC) RK3399 that meets that description, which is ROCKPro64.  Of course, I am not the first to come to same conclusion, in fact there is a whole thread where myself and some other like-minded folks discuss using ROCKPro64 as NAS.
    I say 'standalone SBC', because I almost forgot...
    Helios 64
    These of course are no longer made, and Kobol, our once partners, have unfortunately closed up shop.  However they still come up for sale on the forums from time to time (usually in Kobol Club but could be anywhere).
    Here you would be getting a more integrated solution, often including a nice case, for perhaps a bit more money.
    Some people have had problems with stability though, which I am not sure were ever fully worked out.  Have a look through Kobol club (linked above) and form your own opinion.
    Hardware Recommendations (not RK3399 based)
    ODROID HC4 was also brought up today, when this subject came up in IRC, by @rpardini as that is what he uses.  This is an interesting alternative to the above, except Amlogic (S905X3) based (like a lot of TV boxes).  Which to me means two things:
    1. It almost certainly requires blobs.
    2. It's probably cheaper than RK3399.
    Well in fairness ROCKPro64 probably requires some blobs, too.  But somehow I get the impression that Amlogic are really obnoxious with their blobs, and I am not a fan of them as a company because of this.  Surely a developer will need to correct me here. 
    Anyway, I am not sure how it compares in processing power.  I suspect less than RK3399(?).  However for media transcoding, it may actually be better (perhaps hardware decoders(?), speculation on my part).
    Also for simple 'file server' use-case, in particular with Ceph or something like that, it becomes more interesting IMO.  Again, quoting rpardini from IRC today: "scale out, not up."
    There are newer SoCs, like RK3566 and others.  At this time, they are a lot like RK3399 was early on.  Very exciting, but not able to realize their full potential due to lack of (software/Linux) development.
    The consensus among developers seems to be that RK3566 development should go faster/easier than RK3399 development, because of all the ground work that was laid in the course of the latter.  Maybe that's true, but we are still talking about some time.  Maybe less years, but still significant time.
    If/when this changes, I will try and remember to update the post.  Feel free to ping me by posting, I should get notified.
    Possibly anything in NAS category.  Which I mostly covered already (above, in more detail) but can always change in future.
    Certainly I forgot (or don't know about) some others.  I have shared what I learned from my research the last several years while looking for solution for myself.  However I do want to make this a more general resource that we can all point to, so please discuss, and I will be happy to edit this post later on and add relevant info.
    To clarify, I am not talking about 'any SBC which can be made into a file server' which is almost any of them, but rather particular hardware which is interesting for some specific reason(s), especially currently (or perhaps historically, which I would add to that section).
  23. Like
    TRS-80 got a reaction from Matthijs Kooijman in Improving / simplifying first-run services using systemd features   
    Don't be discouraged if people don't see this right away.  Maybe bump it again later.  Well, here, take my bump. 
    Those warnings are to scare off the tidal waves of people seeking free support through the back door, not for actual well thought out propositions like you are making here. 
    Did you try playing with this locally yet?
  24. Like
    TRS-80 got a reaction from gounthar in How to get Armbian running on a X86_64 with multiboot?   
    Do you have something against regular vanilla Debian?  As a long time Debian user myself, I would feel much more out of my depth on Manjaro, personally.
  25. Like
    TRS-80 got a reaction from TonyMac32 in Odroid C2 general   
    Nice chart!  So nice, in fact, that I will spare you the rms sermon. 
  • Create New...