rpardini Posted July 17, 2022 Posted July 17, 2022 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. 2 Quote
Nexus Posted August 5, 2022 Posted August 5, 2022 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 0 Quote
rpardini Posted August 8, 2022 Posted August 8, 2022 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. 1 Quote
usual user Posted August 17, 2022 Posted August 17, 2022 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. 0 Quote
Ricargr Posted October 7, 2022 Posted October 7, 2022 Hi!! Any advance porting armbiam to the M1 thank you 0 Quote
usual user Posted October 7, 2022 Posted October 7, 2022 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. 0 Quote
rpardini Posted October 7, 2022 Posted October 7, 2022 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 👆☝️ 1 Quote
rpardini Posted October 7, 2022 Posted October 7, 2022 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! 0 Quote
c0rnelius Posted October 7, 2022 Posted October 7, 2022 (edited) 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 0 Quote
usual user Posted October 8, 2022 Posted October 8, 2022 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". 0 Quote
rpardini Posted October 8, 2022 Posted October 8, 2022 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. 0 Quote
usual user Posted October 9, 2022 Posted October 9, 2022 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. 0 Quote
rpardini Posted October 9, 2022 Posted October 9, 2022 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 0 Quote
usual user Posted October 9, 2022 Posted October 9, 2022 (edited) 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 1 Quote
relict Posted October 25, 2022 Posted October 25, 2022 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 0 Quote
rimmer Posted October 29, 2022 Posted October 29, 2022 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 0 Quote
Igor Posted October 29, 2022 Author Posted October 29, 2022 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. 0 Quote
Igor Posted October 29, 2022 Author Posted October 29, 2022 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. 0 Quote
rimmer Posted October 29, 2022 Posted October 29, 2022 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. 0 Quote
Igor Posted October 29, 2022 Author Posted October 29, 2022 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? 0 Quote
rimmer Posted October 29, 2022 Posted October 29, 2022 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. 😇 0 Quote
j0ta Posted October 29, 2022 Posted October 29, 2022 I've build it on v6 kernel on Odroid M1 Debian 11 Using branch for-next 0 Quote
Igor Posted October 29, 2022 Author Posted October 29, 2022 Images with 4.19, 5.19, 6.1RC will be generated once merged: https://github.com/armbian/build/pull/4368 0 Quote
usual user Posted October 30, 2022 Posted October 30, 2022 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. 2 Quote
Igor Posted October 30, 2022 Author Posted October 30, 2022 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. 0 Quote
usual user Posted October 31, 2022 Posted October 31, 2022 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. 0 Quote
Igor Posted October 31, 2022 Author Posted October 31, 2022 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. 0 Quote
j0ta Posted November 1, 2022 Posted November 1, 2022 (edited) 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 0 Quote
Werner Posted November 2, 2022 Posted November 2, 2022 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. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.