Odroid M1

[rpardini]

On 7/13/2022 at 11:51 PM, Nexus said:

Hello. Is anyone else having issues compiling desktop images for this platform? Attached are the 2 error logs that the compile script produces. I used build files from rpardini's repository; specifically the "extensions" branch. Is this the incorrect one? Thanks for any help.

Logs produced

 

Hi Nexus. It seems you're trying to build on arm64, but my code is using the u-boot + rkbins from HardKernel, which unfortunately only work on x86 / amd64. 

Also, you're better off building from "armbian/build" branch "armbian-next' instead of my "extensions" branch, which is very (very!) volatile.

[Nexus]

On 7/17/2022 at 8:06 AM, rpardini said:

 

Hi Nexus. It seems you're trying to build on arm64, but my code is using the u-boot + rkbins from HardKernel, which unfortunately only work on x86 / amd64. 

Also, you're better off building from "armbian/build" branch "armbian-next' instead of my "extensions" branch, which is very (very!) volatile.

Hello again. Thanks for that tip. I spun up an x86 Ubuntu 22.04 VM and tried again on armbian-next. Still, no luck, with this time the issue being the unavailability of the file `jammy-cli-arm64.4adfa3833e0441b5fb7bfe6607347039.tar.zst` on Armbian mirrors. Any clue on what mirror to get this/where to find it (if that is actually the issue here)? I've tried numerous different mirrors on different machines and in different configurations. Logs are attached.

Thank you very much for your help with this.

logs.tar.zst

[rpardini]

On 8/5/2022 at 10:20 PM, Nexus said:

Any clue on what mirror to get this/where to find it (if that is actually the issue here)?

 

This is most probably a bug on my side. I build with all repos and mirrors disabled (SKIP_ARMBIAN_REPO=yes) so everything is built locally, but clearly I've a bug when you don't have that option. Try with it and let me know... meanwhile I'll try to find and fix the bug.

[Nexus]

Yep, this builds! Thanks for the help!

[usual user]

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:

Spoiler

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:

Spoiler

********************************************************************************
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

********************************************************************************

/dev/disk/by-path/platform-fe2b0000.mmc:
 Timing O_DIRECT cached reads:    22 MB in  2.01 seconds =  10.95 MB/sec
 Timing O_DIRECT disk reads:  34 MB in  3.11 seconds =  10.93 MB/sec

********************************************************************************

/dev/disk/by-path/platform-xhci-hcd.0.auto-usb-0:1:1.0-scsi-0:0:0:0:
 Timing O_DIRECT cached reads:   144 MB in  2.03 seconds =  71.07 MB/sec
 Timing O_DIRECT disk reads: 160 MB in  3.01 seconds =  53.08 MB/sec

********************************************************************************

/dev/disk/by-path/platform-fd800000.usb-usb-0:1:1.0-scsi-0:0:0:0:
 Timing O_DIRECT cached reads:    32 MB in  2.08 seconds =  15.39 MB/sec
 Timing O_DIRECT disk reads:  44 MB in  3.01 seconds =  14.61 MB/sec

********************************************************************************

 

With a single job fluster run the H.264 score increases also, see fluster-run-odroid-m1.log for reference.

[Ricargr]

Hi!!

Any advance porting armbiam to the M1

thank you

[usual user]

All outstanding DT patches just landed. Thus, the essential rk3568 SOC support  is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly.

11 hours ago, Ricargr said:

Any advance porting armbiam to the M1

For the time being, you have to provide your own board DT, wait for the community support to land in mainline and trickle down into distributions, or underpaid Armbian developers provide it for free.

[rpardini]

2 hours ago, usual user said:

All outstanding DT patches just landed. Thus, the essential rk3568 SOC support  is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly

 

Very good news about landed patches. 

Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards. 

 

2 hours ago, usual user said:

or underpaid Armbian developers provide it for free

 

Yeah, here's an edge 5.19 version, which is a snapshot/git format-patch of tobetter's 5.19 at some point, rebased to 5.19.4 and now rolled-forward by armbian to 5.19.12.

It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.

It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot

CLI: https://github.com/rpardini/armbian-release/releases/download/20221007a/Armbian_20221007a-rpardini_Odroidm1_jammy_edge_5.19.14.img.xz

      👆☝️

[rpardini]

7 minutes ago, rpardini said:

It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.

It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot

 

IMPORTANT: I have NOT verified skip_spiboot = false can be set from Armbian yet. Caveat emptor! 

[c0rnelius]

Someone went through the trouble to update and re-submit; https://lore.kernel.org/linux-rockchip/20220930051246.391614-1-aurelien@aurel32.net/T/#t

If to lazy, you can pull it from here; https://github.com/pyavitz/debian-image-builder/tree/feature/patches/rockchip/rk356x/odroidm1/5.19

 

 

Last I heard everything worked but the eMMC, but that was "fixed" in V3. So hopefully that's fine now.

Edited October 7, 2022 by Cornelius

[usual user]

8 hours ago, rpardini said:

It does not carry an u-boot anymore

You've removed the only part I used from your image, but don't worry, if the rumors come true that Rockchip is releasing ATF sources, I'll create my own firmware and replace petitboot completely.

 

6 hours ago, Cornelius said:

Last I heard everything worked but the eMMC, but that was "fixed" in V3. So hopefully that's fine now.

For 6.1.0-rc1 you only need this patch set for the board dts, everything else has landed. It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".

[rpardini]

15 hours ago, usual user said:

You've removed the only part I used from your image

 

Damn it, I can't get even one right. Do not worry, the u-boot building code is still alive in another branch. I just got no time to work it, and it's very messy not ready for release (eg is amd64 only).

 

That said I squashed the rest into 👉 https://github.com/armbian/build/pull/4267 against master 👈 (not armbian-next) -- someone gotta build it and review though. It should even have working overlays...

 

15 hours ago, usual user said:

[For 6.1.0-rc1...] It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".

 

That's great news. Hopefully we can then move the 5.19 edge to current and add 6.1-rcX as edge, with a single patch? that'd be sweet.

 

[usual user]

11 hours ago, rpardini said:

Damn it, I can't get even one right.

No reason to regret, I do not expect any significant new development in the legacy firmware and there is therefore no need to rebuild it again and again.

 

11 hours ago, rpardini said:

I just got no time to work it, and it's very messy not ready for release (eg is amd64 only).

That was the reason why I appreciated your work, I could go the lazy way and take what you provided without having to build it myself.

 

11 hours ago, rpardini said:

Hopefully we can then move the 5.19 edge to current and add 6.1-rcX as edge, with a single patch?

You can have it already with 6.0.0 with only a few backport patches. See here for reference. But 6.1.0-rc1 is only round about a week away.

 

On 10/7/2022 at 10:41 PM, rpardini said:

I have NOT verified skip_spiboot = false can be set from Armbian yet.

Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.

[rpardini]

7 hours ago, usual user said:

Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.

 

No, not all -- I took tobetter's tree from the start, and just stuck with it. I'm not "insisting" on it at all. I'm 100% open to:

1) replace with clean mainline patchset against 6.x (still separate kernel deb from rockchip64)

2) unite with rockchip64, when the rest of it is at 6.1+ too. this would require .config merge too and who knows what else.

 

Don't hesitate to send me an -rc tag number and the patchset / .config and I'll drop it in there asap

[usual user]

On 10/9/2022 at 6:11 PM, rpardini said:

Don't hesitate to send me an -rc tag number and the patchset / .config and I'll drop it in there asap

I just used tobetter's tree at the beginning to learn what components are needed for the M1. But then very quickly I started to get the patches directly from the mailing lists (patchwork) to have the last improvements. I just made preparations to build my 6.1.0-rc1 kernel package with these out-of-tree patches next week:

Spoiler

linux-0020-drm-from-list.patch
linux-1000-drm-rockchip.patch
linux-1001-v4l2-rockchip.patch
linux-2001-v4l2-wip-iep-driver.patch

 

If I'm not completely wrong, Armbinan also applies these patches in one way or another. But they are not M1 specific either. Now add this set and that's it. I didn't check it, but with "linux-0001-rockchip-from-6.1.patch" it should also work with 6.0.0 sources. There's a lot of unnecessary stuff in it, but with 6.1.0-rc1, the set is no longer necessary anyway.
When it comes to the .config, it becomes difficult, my kernel package is built as a generic kernel, i.e. one build for all supported devices of the same architecture. I'm happy to provide my .config, but it fluctuates a lot and is therefore a snapshot. For the M1 support I only changed four config options from "m" to "y" to get my personal preferences and additionally built the module for the SPI controller. Everything else is like I use it for all my other devices.

Board DTS is in flight.

With ATF and DT rebase mainline firmware gets closer.

Edited October 17, 2022 by usual user

[relict]

Unless I'm mis-reading, it looks like most of this stuff will now land in 6.2?

 

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v6.2-armsoc%2Fdts64

 

[rimmer]

hello ,I tried to compile kernel from https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v6.2-armsoc%2Fdts64 on gentoo system on odroid m1 ,thanks to Ondrej Famera https://www.famera.cz/blog/computers/gentoo-minimal-odroid-m1.html ,but it fails on nvme root file system ,it not recognise root partition   

[Igor]

1 hour ago, rimmer said:

but it fails on nvme root file system ,it not recognise root partition

 

I don't know if with Armbian this works but this would be the very first question. Start here: https://github.com/armbian/build/pull/4267 Since things are not even merged, it means support is in poor state. And kernel branches you found won't bring much changes - we have (i assume all) this with patches. As most problems for this platform are not in the kernel but below.

[Igor]

On 10/25/2022 at 4:23 PM, relict said:

Unless I'm mis-reading, it looks like most of this stuff will now land in 6.2?

 

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v6.2-armsoc%2Fdts64

 

If those people are signed as testers, then I am sure no bugs can be found. 

[rimmer]

 

Yes, you are right, the support of this board is really poor from the manufacturer, but I hope it will improve over time. I think it doesn't matter what distribution I use (armbian is great, I use it myself for Odroid C4), I just wanted to contribute my further knowledge to the community, I'm not a developer, just a user.

[Igor]

16 minutes ago, rimmer said:

I think it doesn't matter what distribution

 

Technically? Support wise? It adds unnecessary complexity. We are using controlled environment to rule out most stupid troubles and to save time. Stupid troubles can be big time wasting elements. 

 

Most of the distributions usually don't have developers & maintainers for core components. They ship vendor prepared firmware, our firmware, pure mainline ... or something in between.  Best working kernel is vendors (when hw is released) while mainline always remain in pretty raw state also after years. We keep that operational, starting with some features, adding more. Some are coming from mainline, some from our labs. Some might never come to the main Linux tree and we could maintain features nobody else. And a lot faster then mainstream. Mainstream turn around is slow, time consuming, commonly poorly tested. Most of troubles we have in stable branches are coming from mainline, from that "doesn't matter" space. 

 

Morally?

If you are asking for support on 100% my personal expense - my time is most important value. Not yours is. Technical support for Armbian users or even supporters that help us pay the bill they are generating to the technical  infrastructure (electricity) is on the edge of possible. We can't finance people out of that. And since we have very limited resources, 3rd party Linux users are simply always last to be serve. There are many things you have reported or we find but are not fixed yet. First sorting out that, then 3rd party problems. Fair?

 

[rimmer]

Yes, time is important for everyone, everyone uses it in their own way. Today's time is difficult for everyone. I'm not asking for 100% support, I'm just trying to share my experiences and that's all. 😇

[j0ta]

I've build it on v6 kernel on Odroid M1 Debian 11

 

Using branch for-next

 

[Igor]

Images with 4.19, 5.19, 6.1RC will be generated once merged:

https://github.com/armbian/build/pull/4368

[usual user]

13 hours ago, Igor said:

Images with 4.19, 5.19, 6.1RC

4.19 legacy makes sense if you want to use functionalities for which there is no support in mainline for the rk3568 SoC yet. But this also requires special userspace software that can use these proprietary interfaces.

5.19 doesn't make much sense, because it requires backporting everything that has already landed in 6.1.0-rc. Especially if you use the tobetter tree to pull from because it is based on very early WIP patches that contain bugs that are already fixed in mainline.

As far as I know, 6.1.0-rc contains all mainline code available for the rk3568 SoC. So there is currently nothing relevant to add. For the ODROID M1 support only the source for the rk3568-odroid-m1.dts is missing. This can be easily added by cherrypicking the relevant commits from the maintainer tree. Or you build from linux-next and have the full preview on 6.2.0-rc1. But from the point of view of the ODROID M1, this only adds the rk3568-odroid-m1.dts out-of-the-box.

 

IMHO you should start with 6.1.0-rc for the ODROID M1 and mainline kernel support. Everything else is unnecessary work that does not provide any advantages over 6.1.0-rc. Of course, all distribution dependent additions can still be applied, but from the point of view of the ODROID M1 they are not absolutely necessary.

[Igor]

5 hours ago, usual user said:

IMHO you should start with 6.1.0-rc for the ODROID M1 and mainline kernel support.

You are right. I have remove everything. 6.1.0-rc boots and its good enough to start with.

[usual user]

10 hours ago, Igor said:

6.1.0-rc boots and its good enough to start with.

PINE64 does an excellent job documenting the state of development for mainline development. Although it is for the rk3566 SoC, it is one to one transferable for the rk3568 SoC. Except for the rkvdec2 support, the support is pretty much on par with the rk3399 SoC. And the good thing, everything has already landed in mainline and all userspace software that have support for the rk3399 SoC also work unmodified for the rk3568 SoC. So except for the 4K decoder support, devices with the rk3568 SoC are already quite suitable for everyday use. I am very confident that the rkvdec2 support is only a matter of time and then 4K media can be enjoyed impeccably.
I would now only wish that all board manufacturers provide equivalent documentation for there devices, as PINE64 has shown here. This would simplify mainline usability immensely and one wouldn't have to deal with legacy forks, but I think that remains a pious wish.

[Igor]

4 minutes ago, usual user said:

does an excellent job documenting

 

That is good for generating an image / impression they have something to do with software development, while its quite the opposite. They never helped Armbian in any way, not with a cent, and if you read this https://blog.brixit.nl/why-i-left-pine64/ ... 

 

13 minutes ago, usual user said:

I would now only wish that all board manufacturers

Others support development, not dealing just with promotion.

[j0ta]

Everything is working, the only problem I notice was after installing the upgrades the ip address changes and breaks the

RX Today info with

Error: No interface matching "end0" found in database. 

changing the ip to the one before doesn't solve it

any idea how to fix it ?

 

 

Also installing ufw throw some line while installing the config files like grep / instead of \ or something like that.

purging it and installing it again removed the error

 

Using: Sid server

 

Thanks and great job !

Edited November 1, 2022 by j0ta

[Werner]

8 hours ago, j0ta said:

Sid server

Tried stable userspace like Bullseye or Jammy? I would not rely on any errors from an experimental/unstable userspace.