1. 29
  1.  

  2. 12

    The highlight, to me: 720mA on load (CPU Stress with performance governor).

    This is much better than the rpi situation, where it started (original model 1B) at around that much, then skyrocketed and never went back down. Suggests the heatsink (which looks very good) is there for robustness, and not really needed.

    That’s a good job. I am tempted to get one.

    1. 5

      Mainline Linux support for AmLogic Meson SoCs seems quite good. The somewhat older S905X chip works with upstream Linux, Lima/Panfrost, and Mesa.

      CoreELEC supports the newer S905X3, but it looks like they’re on Linux 4.4 right now.

      1. 4

        Tempting, but I’m curious about a few things:

        • It mentions OpenGL ES 3.2 support. The official ARM drivers support ES 3.2 but only for a few select situations (mostly Android), and getting them to actually function on arbitrary linux distros is nontrivial. What’s the graphics support actually like?
        • Does it annoyingly route almost all network and disk I/O through USB like the RPi does?
        1. 3

          I just ordered one. If you like I can run some tests for you when it comes in. I had a C2 years ago and at least for that device network and disk were routed to the SOC.

          1. 1

            If you feel like it. If you get graphics working well then glxinfo | grep OpenGL should have the info I want.

            1. 2

              Here you go. This is with Ubuntu 20.04 pre-installed default from their emmc module. The vendor string might be due to me doing export DISPLAY=:0 to get around the display not being available in my headless setup.

              root@odroid:~# glxinfo | grep OpenGL
              OpenGL vendor string: VMware, Inc.
              OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)
              OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.0.4
              OpenGL core profile shading language version string: 3.30
              OpenGL core profile context flags: (none)
              OpenGL core profile profile mask: core profile
              OpenGL core profile extensions:
              OpenGL version string: 3.1 Mesa 20.0.4
              OpenGL shading language version string: 1.40
              OpenGL context flags: (none)
              OpenGL extensions:
              OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.4
              OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
              OpenGL ES profile extensions:
              
              1. 1

                Thanks! That’s certainly… something, though it kind of raises more questions than answers. VMWare and llvmpipe suggest it’s a software OpenGL renderer, which means it’s emulating a GPU instead of actually using the hardware available. If the setup is headless, without any X server running and no display plugged in, then that may or may not be influencing it. If you’re doing X forwarding then it often can’t do much of any use with the GPU hardware anyway.

                Interpreting this is always kinda a black art on Linux, since almost all GPU drivers use Mesa to some degree or another, whether they’re binary blobs or open source drivers, and while Mesa is pretty good at choosing the best driver it has available, I’ve yet to find a way to get it to explain to me why it’s choosing a particular driver and which ones it’s choosing among. I mostly just rely on distro packages to do the correct black arts for me. If anyone has any pointers, I’d love to hear more.

                1. 1

                  Well, turns out that it’s the same with an hdmi cable plugged in and displaying out to a TV. No idea why it shows up as VMWare ¯_(ツ)_/¯

                  1. 1

                    Glad to help. I’ll give glxinfo another go once I get an hdmi cable and get this hooked up to my TV.

            2. 3

              Does it annoyingly route almost all network and disk I/O through USB like the RPi does?

              I’m not sure, but does this help? https://wiki.odroid.com/_detail/odroid-c4/c4_blockdiagram_rev0.4.png?id=odroid-c4%3Aodroid-c4

              1. 2

                It does help, if I’m reading it correctly. Looks like the GigE and SD go through their own interfaces instead of piggybacking off of USB. Thanks!

            3. 2

              Is there a nice case for this? I guess it is not the same form factor as RaspberryPi?

              1. 2

                For mobile use, wide input voltage and full-size HDMI sells it for me (if software support is ok, which is a big if).

                Yes, those are the two problems I have with RPi4 in my tough backpack environment: The first got fried on a buck converter that failed in open mode, the second broke my flimsy micro-HDMI adaptor on the first day out.

                1. 1

                  I would really like something like this to use as a desktop / small server to run in my office next to my laptop. But, I want at least 8 GB of RAM for various reasons. Does anyone have a recommendation for something with more memory but a similar footprint / power draw?

                  1. 2

                    I think the amount of RAM is likely to have a direct impact on power usage so that might be a tough ask. (Not to mention the cost of memory starting to swamp the rest of the components on the mainboard.)

                    In my (admittedly limited) experiments I’ve found 4GB to be a pretty generous amount for the setups this kind of ARM SBC can really handle. For example, a base install of Manjaro ARM will happily idle in ~150MB of memory, and you’re likely to hit CPU and I/O limits before you start hitting swap or OOM.

                    Just out of curiosity, what kind of workload were you imagining that would need that much RAM but still run comfortably on a quad-core 2GHz ARM 5X cpu?

                    1. 2

                      Just out of curiosity, what kind of workload were you imagining that would need that much RAM but still run comfortably on a quad-core 2GHz ARM 5X cpu?

                      I guess you’re probably right. Though, my current laptop has 12GB of RAM, and it hovers about 4-5GB used on OpenBSD, running mostly web browsers and an Emacs session. It’s probably unrealistic to think I’m going to be running multiple browsers on that machine, though.

                      1. 2

                        Browsers (esp. Chromium and Firefox) are really bad on this front. I run a webkit-based browser on my ARM machines (specifically qutebrowser) and find it uses something like 25-40% of the resident memory for a similar set of open tabs, not to mention almost infinitely less idle CPU.

                  2. 1

                    Can’t wait for Raspberry Pi to launch one with 32G RAM, hopefully competition will drive others to follow the suit ;-)

                    1. 2

                      Not necessarily soldered. SO-DIMM and M.2 should be an instant hit, but doesn’t exist yet, or I would have bought it.