[HN Gopher] The Banana Pi M7
       ___________________________________________________________________
        
       The Banana Pi M7
        
       Author : rcarmo
       Score  : 34 points
       Date   : 2024-06-16 17:19 UTC (5 hours ago)
        
 (HTM) web link (taoofmac.com)
 (TXT) w3m dump (taoofmac.com)
        
       | COGlory wrote:
       | Is there any decent router software that will run on ARM? 2x2.5
       | Gbe is tempting for that price.
        
         | ftth_finland wrote:
         | Why bother when you can get a complete X86 mini pc for less?
         | 
         | Just pick up an N100 with 4x2.5G ports.
        
           | rcarmo wrote:
           | It depends. I am also testing N100 (and N97) machines, but
           | for other reasons. Pricing will vary a lot depending on the
           | number of interfaces, case, etc.
        
         | rcarmo wrote:
         | Most of the RK3588 boards I test support OpenWRT, and some are
         | purpose-built for it.
        
         | yjftsjthsd-h wrote:
         | It's not that hard to manually make it a router by setting some
         | sysctls and iptables rules.
        
       | yjftsjthsd-h wrote:
       | > And yes, documentation and software support are still a bit of
       | a mess, but that's par for the course with these boards-and the
       | M7 is at least better supported than most.
       | 
       | And that's why Raspberry Pi keeps winning:\
        
         | 1oooqooq wrote:
         | when even the very closed source pi wins, it shows the whole
         | ecosystem is doomed.
         | 
         | open source and open hardware lost.
        
           | ahepp wrote:
           | Open source software seems to be winning? I mean, the whole
           | point is that people want SBCs running Linux.
           | 
           | I think it's probably fair to say that open source hardware
           | is not winning. I'm not sure I'd say it's "losing", the
           | BeagleBoard exists and seems to do alright for itself if
           | that's what you want.
        
           | sqeaky wrote:
           | When you say "closed source pi", are you referring to the
           | hardware or the software that ships with? My experience with
           | the Raspberry Pi is that it's been a very open platform and
           | that there's tons of options for me and that licensing has
           | never been a problem but also never tried to take a CPU off
           | and Transplant it to a new board or something.
        
           | Vt71fcAqt7 wrote:
           | Pretty sure the issue is that the RK3588 drivers are not
           | upstreamed into Linux/U-Boot etc. This is the issue with most
           | ARM CPUs in this area like the Broadcom ones RPi is using.
           | Which is why they have Raspberry Pi OS to ship you the
           | drivers. The first good ARM CPU to actually get mainlined
           | will probably see more sales.
           | 
           | RK3588 upstreaming project: https://www.collabora.com/news-
           | and-blog/blog/2024/02/21/almo...
           | 
           | Risc-V JH7110[0] upsteam status:
           | https://rvspace.org/en/project/JH7110_Upstream_Plan
           | 
           | [0] used in https://www.starfivetech.com/en/site/boards
        
           | asddubs wrote:
           | hardware is closed source but in software the pi does open
           | source better. they develop and mainline kernel drivers for
           | their hardware
        
         | rcarmo wrote:
         | Well, I've had extremely good results with Armbian for server
         | stuff, which is why I've always tried testing with that.
         | Networking, standard peripherals, etc. all work, so the only
         | real oddities are still GPU and specialized hardware support...
        
           | bayindirh wrote:
           | The problem with Armbian is, while it's neatly packed and
           | made with a lot of care, you lose board-specific
           | capabilities, esp. in Rockchip systems.
           | 
           | Using Armbian for OrangePi 5B means losing hardware
           | accelerated video encoding, AI acceleration, etc. But, I
           | bought the board for these features.
           | 
           | I'd either use OrangePi's own, short living Debian image with
           | all the features or an Armbian build which I won't be able to
           | update cross-release but will be supported and developed,
           | losing all the differentiating features of the board.
           | 
           | There's no winning here. This is why Raspberry Pi is winning.
        
             | rcarmo wrote:
             | Actually, the new Armbian releases do have GPU support (I
             | mention that in my piece).
        
               | bayindirh wrote:
               | How about video encoding? I want to use mine as an on
               | demand video encoder for a custom project.
        
               | einsteinx2 wrote:
               | Maybe try reading TFA? There's a whole section on
               | transcoding.
        
               | bayindirh wrote:
               | The article states:
               | 
               | Update: Like I mentioned above, in the weeks since I
               | fleshed out this draft Armbian came out with an Ubuntu
               | Noble version with improved MESA/VPU support, but I
               | haven't had time to test it yet. I'll update this post
               | when I do.
               | 
               | Which is what I'm asking. The article doesn't contain
               | information on media transcoding _with Armbian_ , and I
               | asked the question to learn whether there is more info on
               | that. Otherwise, OrangePi's image already does what I
               | want.
               | 
               | Video encoding has a lot of patents attached to it, so
               | the access to that IP block is not always open source due
               | to plethora of reasons. It's a very non-ideal situation
               | for non-embedded use, hence the question.
        
               | rcarmo wrote:
               | Video transcoding already worked with the version I
               | tested.
        
               | bayindirh wrote:
               | Thanks, that's great. I'll give it a go, then.
        
               | rcarmo wrote:
               | The Jellyfin version I tested comes with an ffmpeg build
               | with RK3588 support.
        
       | guccigav wrote:
       | Is it just me or is there an influx of Raspberry Pi alternatives
       | trending lately ever since the IPO?
        
         | nineteen999 wrote:
         | There has been a ton of them since the original Raspberry Pi
         | was released .. both Banana Pi and Orange Pi first came out 10
         | years ago, I think
        
       | dekhn wrote:
       | I've found with all the SBCs, the booting story is pretty sad. In
       | particular, I've got a pile of more-or-less powerful but
       | uninteresting SBCs (Raspberry Pis of multiple generations,
       | OrangePi 5+, etc). I find that putting the OS on these machines
       | is always quirky and failures to boot from SD are extremely hard
       | to debug.
       | 
       | From what I can tell these systems don't have a "BIOS" or UEFI or
       | other bootloader that has a command line that supports USB
       | keyboard, console display, and iterating over boot devices. TBH
       | what I really want is an embedded copy of linux in an on-board
       | firmware that boots me into a minimal filesystem with busybox-
       | like toolkit, with the ability to use it to mount filesystem and
       | boot a kernel from there.
       | 
       | Maybe I'm missing this feature in OrangePi 5+ but a lot of my
       | devices involve hooking up to a full monitor, a full keyboard,
       | and then serially testing each of my SD cards until one can
       | actually boot the OS. I much prefer my Intel NUCs (eveyrthing
       | from the wimpiest to the most powerful) although Intel exited
       | that business (IIRC they handed the NUC tech to Asus?).
        
         | aseipp wrote:
         | FWIW, there are working and usable ports of EDK2 to the RPi4
         | (not sure about v5) so you can just throw the image on an
         | attached USB drive. The FSBL then boots the EDK2 image, which
         | can then load a generic UEFI image like normal. I used that
         | reliably for quite a while; Fedora's generic UEFI aarch64 ISO
         | worked out of the box with no extra fiddling, just burned it to
         | a separate USB stick and booted the installer.
         | 
         | There's also some in progress ports of EDK2 to RK3588, and
         | various other boards, though there's often some missing
         | features as they need to be implemented properly in EDK.
         | 
         | Really, there's two parts to the whole story, the second being
         | device enumeration, that gets handled by either a device tree
         | blob (DTB) or via ACPI. For UEFI that means that either the
         | UEFI build you're using needs to come with the DTBs pre-
         | configured and embedded inside it so they can be passed to the
         | OS you boot up. Or your device/build will be configured to use
         | ACPI. (The story here is actually weirder than that on some
         | devices where e.g. they have ACPI that requires enumeration,
         | but they expose the actual raw DTBs from _that_ , which you
         | then pass on to the kernel, so you actually have to handle
         | both.)
         | 
         | UBoot also has a minimal EFI implementation that you can use,
         | though I don't know how much it implements or if a random
         | generic AArch64 linux ISOs will work with it. Last I checked
         | modern UBoot can even netboot over HTTPS these days, too, so if
         | it could do all the above on a supported board, that would be
         | awesome.
        
       | dr_kiszonka wrote:
       | Would any of the tested smaller LLMs, be good for fixing
       | grammatical and stylistic errors in emails? (Think Grammarly
       | local.)
        
         | rcarmo wrote:
         | phi3:instruct does a good job with simple summarization. I
         | haven't tested it for grammar checking (I am focusing on
         | automation and tool use), but it would likely work.
        
       | e12e wrote:
       | Anyone know if the wifi6 support extend to hostapd? Can this be
       | setup as a decent wifi router under Linux (or *bad)?
        
       ___________________________________________________________________
       (page generated 2024-06-16 23:02 UTC)