Version for Odroid M1?

Hi,

Has anyone tried one of the other ROCKCHIP based versions on the Odroid M1? Or if there is a build planned for the M1?

Cheers!

There not yet an Armbian image available as far as I can https://forum.armbian.com/topic/20260-odroid-m1/
Means, we would need to wait on these guys to create the base image first.

Not sure if there is an image available from Hardkernel directly.

thanks – Hardkernel have a fairly stock Ubuntu 20.04LTS, I was looking for something as light as possible.

Cheers

hmm we don’t support Ubuntu. Did you found a Debian based image? If yes, you could try to use our install script.

You could try this Debian 10 image,
http://ppa.linuxfactory.or.kr/images/raw/arm64/buster/debian-buster-server-odroidm1-20220410.img.xz

Probably we are able to generate an image with the mainline kernel build tobetter users for the Ubuntu image: https://forum.odroid.com/viewtopic.php?f=217&t=44462

Would you mind to open an image request on our GitHub repo?

Done - Odroid M1 : Image Request #5476

Will an image for the Odroid M1 be available for download soon? I have an M1 running Ubuntu Server 20.04.

we don’t have any ETA. The missing Debian base image is the challenge still.

For forging a custom image I need a developer sample first. I didn’t manage to all Hardkernel about it yet.

I am giving up to get M1 because it’s already few months Armbian still working in progress and same as debian 11 , The M1 overall performance result was disappointed i prefer to stick with N2+ and wait for the raspberry pi 5 ,

But I’m glad that my system, which I put together for my NanoPC-T4 over a year ago, works on an equal footing with my Odroid-M1. What was necessary for this were only some inflight patches for the kernel and of course suitable firmware. As firmware I could use those that rpardini provided with his image. This was necessary because there is no mainline uboot available yet that petitboot can replace. The amount of patches will drop dramaticly with the release of 6.0.0-rc1 because everyting has landed. Only the board devicetree file will be missing, but this is a small thing. The rest of user space is not Odroid-M1 specific, it has to be up to date like for any other device.
In terms of performance, to expect that it can keep up with an N2+ is already a wrong assumption due to the lower hardware spec of the SOC. However, it is always sufficient to operate a graphical desktop very well usable. But most importantly, 8GB of MEMORY.

It’s really depends what you used for , For me i like N2+ cpu and gpu performance for retro gaming and nextcloud , Of course i want to see the Odroid M1 running for nextcloud because of the nvme storage, I perfer install nextcloud and letsencrypt on dietpi without typing that much command .

But i heard many ppl talking about rpi 5 already . M1 or Rpi i will definitely choose rpi .

People talking about the RPI5 since last year already. But nobody knows when it will be released. Next, even if released it would need to become available on stores. At the moment not that much SBCs are available on the market for a regular price.

Luckily i purchsed a 8gb pi4 for $150 CAD ($116 USD) 3 months ago on amazon.ca it’s a flash sell and after 2 days all sold out , but now its colleting dust after N2+ on my hands .

I saw $169.99 CAD pi 4 8gb on amazon.ca last month but sold out very quickly like 1 day only.

Ok, I went on to 6.0.0-rc1. A big pile of in-fligth commits have landed and only a few WIP commits are left over:

Subject: [PATCH v11 11/24] drm/rockchip: dw_hdmi: Use auto-generated tables
Subject: [PATCH v11 12/24] drm/rockchip: dw_hdmi: relax mode_valid hook
Subject: [PATCH v11 13/24] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
Subject: [PATCH v11 14/24] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz
Subject: [PATCH v4 1/5] dt-bindings: phy: rockchip: add PCIe v3 phy DT
Subject: [PATCH v4 2/5] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf DT
Subject: [PATCH v4 3/5] phy: rockchip: Support PCIe v3
Subject: [PATCH v4 4/5] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes DT
Subject: [PATCH v2 2/3] arm64: dts: rockchip: Add VPU support for RK3568/RK3566 DT
Subject: [PATCH 079/130] dt-bindings: rockchip: Add Hardkernel ODROID-M1 board DT
Subject: [PATCH 080/130] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board DT
Subject: [PATCH 087/130] (DO NOT MERGE) ODROID-M1: add more peripherals DT
Subject: [PATCH 088/130] (DO NOT MERGE) ODROID-M1: add sound devices nodes DT
Subject: [PATCH v5 3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x DT

They are basically general improvements to dw_hdmi and phy support for PCIe v3 with the rk3568 that are still in the works. The rest is devietree related and I hope it lands soon, because then everyone has out-of-the-box support with a pure mainline build.
NVME gives nice tranfer rates:


Hardkernel ODROID-M1
CPU 0-3: schedutil 408 MHz - 1992 MHz
6.0.0-0.rc1.13.fc34.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 15 19:33:39 CEST 2022
hdparm -ITt --direct /dev/disk/by-path/${device}


/dev/disk/by-path/platform-3c0800000.pcie-pci-0002:01:00.0-nvme-1:
Timing O_DIRECT cached reads: 2140 MB in 2.00 seconds = 1070.61 MB/sec
Timing O_DIRECT disk reads: 3272 MB in 3.00 seconds = 1090.64 MB/sec


The scores of a fluster run for the available codecs shows quite conformity:


Hardkernel ODROID-M1
CPU 0-3: schedutil 408 MHz - 1992 MHz
6.0.0-0.rc1.13.fc34.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 15 19:33:39 CEST 2022


Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 128/135 tests successfully in 306.906 secs


Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 59/61 tests successfully in 42.984 secs


A thing where an N2+ can’t really keep up:


Hardkernel ODROID-N2Plus
CPU 0-1: schedutil 1000 MHz - 2016 MHz
CPU 2-5: schedutil 1000 MHz - 2400 MHz
6.0.0-0.rc1.13.fc34.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 15 19:33:39 CEST 2022


Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2-Gst1.0
Using 1 parallel job(s)
Ran 4/135 tests successfully in 837.075 secs


Running test suite JCT-VC-HEVC_V1 with decoder GStreamer-H.265-V4L2-Gst1.0
Using 1 parallel job(s)
No result, System crash


While the H.265 test the VPU even crashes and can only be reactivated by restarting the system.
An rk3399 SBC is of course much further:


FriendlyElec NanoPC-T4
CPU 0-3: schedutil 408 MHz - 1416 MHz
CPU 4-5: schedutil 408 MHz - 1800 MHz
6.0.0-0.rc1.13.fc34.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 15 19:33:39 CEST 2022


Running test suite JCT-VC-HEVC_V1 with decoder GStreamer-H.265-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 121/147 tests successfully in 392.621 secs


Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 129/135 tests successfully in 155.843 secs


Running test suite VP9-TEST-VECTORS with decoder GStreamer-VP9-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 227/303 tests successfully in 439.894 secs


Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0
Using 1 parallel job(s)
Ran 59/61 tests successfully in 25.600 secs


I am working as well at the Odroid M1 at the moment:

The good news is: Petitboot offers now to install on the SSD bullyese in stable condition (no work in progress anymore) !!!

So, I initiated the install and it went flawless…very, very cool.

I thought: Now lets run the Dietpi-Script as we have now at least a bullseye system and the script wants to see this…well…did it and it went through without any error (generic device as we have here a RK3568B2).

I was happy to type reboot (SSH, under root) to start dietpi first time…

But the start does not go through:

“No root device specified. Boot arguments must include a root = parameter (initramfs)”

So, I guess something goes wrong when trying to setup dietpi’s ramsdisk.

Please let me know if/how I can fix this (rudimentary Linux knowhow)…or if this will be too complicated to fix myself (with your advise obvisously).

I want to make the M1 to work…if Dietpi cant be run on it now that we have a stable BULLSEYE…i will just re-install the normal debian system with petitboot