Slartibartfast9536 Posted April 24, 2022 Posted April 24, 2022 Wonderful 😃🤩 I just ordered the M1 and would love to start with Armbian instead of the hardkernel ubuntu, which already now has a pretty old kernel 4.19.219 with EOL in 2024. Do you have an idea, when Armbian could eventually be available for the M1? 0 Quote
N4IRS Posted April 28, 2022 Posted April 28, 2022 I have my M1 sitting here waiting for some Armbian action! 0 Quote
Werner Posted April 29, 2022 Posted April 29, 2022 On 4/24/2022 at 6:39 AM, Slartibartfast9536 said: Do you have an idea, when Armbian could eventually be available for the M1? There is no ETA for any boards/functions since we do not have much (human) resources to deal with everything In theory support should be possible with moderate effort since essential functions for RK3568 are there because @balbes150brought use support for Station P2 which is built around the same SoC. 0 Quote
Stan Pak Posted April 30, 2022 Posted April 30, 2022 This is quite interesting board and it would be really nice to have the Armbian powering it. What makes the board good are the features, like: 8GB RAM - awesome! M.2 SSD connector - so the drive can be added with very low profile and no wires. I wished there were 2x M.2 connectors to easily create RAID.1 mirrors. Additional SATA so more drives can be connected or even the hub for NAS applications. Solid heatsink. Price is on the level of other 4GB RAM models of Odroid. Theses boards can be easily stacked to create compact but powerful clusters that make no noise and fit nicely into the closet data-center. 1 Quote
Neo2SHYAlien Posted May 3, 2022 Posted May 3, 2022 I'd love to be a beta tester soon when a beta images are available :) 0 Quote
rpardini Posted May 7, 2022 Posted May 7, 2022 I've some images, but they're really quite far from usable right now. Vendor kernel 4.19 I can't get HDMI to work. Everything else works. I'm using it to build Armbian itself and works great with NVMe and the 8gb RAM. Mainline 5.18-rcX has working HDMI, but no NaNeng PHY, so no PCIe/NVMe, no USB3, and no SATA. tobetter is working, also work in quartz64a and other rk3586/8 will benefit this. nand-sata-install will not work with this unless I find a way to flash uboot to SPI (and this remove petitboot, but there is no official petitboot recovery from HK yet) and mainline u-boot is even further away, so little chance of that. 1 Quote
rpardini Posted May 8, 2022 Posted May 8, 2022 (edited) Ok some images are up for testing. Both HKs' 4.19 and tobetter's 5.18-rcX were updated. Maybe something is fixed. Tobetter commits signal support for PCIe. For those who are brave: https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_legacy_4.19.219.img.zst (probably no HDMI) https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst (probably no PCIe/SATA/USB3) EDIT: old images removed. Look for later posts for newer ones unzstd them, burn to SD, insert SD, power on. recommend to use UART Have fun @Neo2SHYAlien @Stan Pak @N4IRS @Slartibartfast9536 @Igor Edited May 22, 2022 by rpardini pulled images that didn't work 3 Quote
Neo2SHYAlien Posted May 9, 2022 Posted May 9, 2022 (edited) 12 hours ago, rpardini said: unzstd them, burn to SD, insert SD, power on. @rpardini thank you for your work. Unfortunately I have only NVMe on my board. I test just in case to install the provided images via petitboot microusb, but without success. p.s I found an old SD card but my board dont start at all with sdcard in it. I will get a new one later Edited May 9, 2022 by Neo2SHYAlien add SD card info 0 Quote
rvalle Posted May 11, 2022 Posted May 11, 2022 @rpardini maybe I can test. I don't need or want HDMI.... I am trying to make sense of your code. The code is in your rpardini/extensions branch, but was it from armbian-build/master? You seem to be working from another branch with scripts split in a tree, right? 0 Quote
rpardini Posted May 11, 2022 Posted May 11, 2022 1 hour ago, rvalle said: I am trying to make sense of your code. Don't try too hard. Most things don't make sense. 😉 Find the board file, then the family, and understand the hooks that are in place and when they're called. 1 hour ago, rvalle said: The code is in your rpardini/extensions branch, but was it from armbian-build/master rpardini/extensions is my work branch. It's a huge mess. Don't waste your time... Everything you need for the M1 is already in armbian/build in branch 'armbian-next'. The ODROID-M1 uboot code is very convoluted right now since I'm using vendor uboot's "make.sh" in addition to Armbian's own. Also a custom partitioning scheme is required, also implemented in a hook in the board file. It can _only_ be built on x86 right now due to vendor's use of amd64-only rkbins there. So right now this is very not standard. If/when this board stabilizes I'll work on making it less messy. 0 Quote
rvalle Posted May 12, 2022 Posted May 12, 2022 17 hours ago, rpardini said: Everything you need for the M1 is already in armbian/build in branch 'armbian-next'. Ohh, thanks for this, I did not notice. I just want to build the image with a patch of mine too. See if we are lucky and get it to work. Are you using Tobetter code from Hardkernel? We have a discussion over there because most modules are disabled in the kernel even if they have nothing to do with the actual silicon. He is looking into it, be aware. 0 Quote
rpardini Posted May 12, 2022 Posted May 12, 2022 1 hour ago, rvalle said: I just want to build the image with a patch of mine too. See if we are lucky and get it to work. Should be doable, patch dirs are empty so just drop stuff in there. 1 hour ago, rvalle said: Are you using Tobetter code from Hardkernel? We have a discussion over there because most modules are disabled in the kernel even if they have nothing to do with the actual silicon. He is looking into it, be aware. legacy == 4.19 from HK official repo. edge == 5.18-rcX from tobetter's repo. both with vendor u-boot so all moving targets, tobetter has finally taken to rebasing his branch. 0 Quote
rvalle Posted May 12, 2022 Posted May 12, 2022 @rpardini any idea why I get this from docker-shell when switching to the armbian_next branch? fatal: not a git repository: /root/armbian/../.git/modules/build 0 Quote
rpardini Posted May 12, 2022 Posted May 12, 2022 3 hours ago, rvalle said: I get this from docker-shell Eh, no idea. Fragments of code handling docker are scattered all over the codebase, and haven't been properly handled yet in armbian-next. (1-line explanation: armbian-next has error control enabled, and command invocations that previously failed and were ignored now make the build stop). Would be great if you could explain the use case for what you're trying to do... 0 Quote
rvalle Posted May 12, 2022 Posted May 12, 2022 ok... looks like does not like the docker container from other branch.... I think. will investigate. 0 Quote
Neo2SHYAlien Posted May 12, 2022 Posted May 12, 2022 On 5/8/2022 at 7:28 PM, rpardini said: Ok some images are up for testing. Both HKs' 4.19 and tobetter's 5.18-rcX were updated. Maybe something is fixed. Tobetter commits signal support for PCIe. For those who are brave: https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_legacy_4.19.219.img.zst (probably no HDMI) https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst (probably no PCIe/SATA/USB3) unzstd them, burn to SD, insert SD, power on. recommend to use UART Have fun @Neo2SHYAlien @Stan Pak @N4IRS @Slartibartfast9536 @Igor I tested with a new SD card still wont to boot at all. I tested with same SD card ubuntu image from hardkernel and there is no problem with booting. I suppose there is something in the partitioning. I used for UART adapter an old ardoino uno but didn't get any proper output 0 Quote
rvalle Posted May 12, 2022 Posted May 12, 2022 53 minutes ago, rpardini said: Would be great if you could explain the use case for what you're trying to do... Traditionally I use LVM in our Storage in our servers, and we started doing it on the ARM64 servers too. I am using this with Raspberry PIs and now with Armbian too. I also use cloud-init for server customization, just like ubuntu does with the RPI image now. This is very good, as you can create users, add keys, install packages, set networking... extend partitions, all in an standard way. So, the requirements for my Armbian image are, an extra vfat partition for cloud-init metadata, and the ROOT to be created with LVM instead of just ext4. I managed to implement most with user extensions, except the Dockerfile that required extra packages and configurations, and also I had to patch the partitioning part of the script, in a similar way the CRYPT extension does, as the root filesystem will come from mapper and not from the root device, this is not possible to do from an extension. I have it working for the HC4 in the master branch. I want to port it to the M1 and possibly XU4. 1 Quote
rpardini Posted May 15, 2022 Posted May 15, 2022 On 5/12/2022 at 5:59 PM, Neo2SHYAlien said: I tested with a new SD card still wont to boot at all. Thanks for testing, I'll test some future build and report back when I'm confident it boots. I messed up some (unrelated to M1) initrd stuff in those builds. 0 Quote
rpardini Posted May 15, 2022 Posted May 15, 2022 On 5/12/2022 at 6:04 PM, rvalle said: I also use cloud-init for server customization Cool stuff, thanks for the explanation. I've similar setup, although I don't use root LVM, and cloud-init meta is in /boot ext4 or /boot/efi (vfat). Partitioning is quite complex intermingled code between partitioning proper, calculating sizes, and setting up filesystems. I've added hooks to be able to "override it all" but haven't had time to make it better composable, much less in bash. But what I was asking about was the your original mention of "docker-shell" or something, for image build? kernel build? I've probably messed that up in -next. 0 Quote
Guest Posted May 15, 2022 Posted May 15, 2022 Tried the test images and couldn't get them to boot. Odroid Ubuntu works on the same eMMC I'm using. Excited for the armbian release. Trying to make an Umbrel server and can't get it working with the Odroid Ubuntu. 0 Quote
rpardini Posted May 22, 2022 Posted May 22, 2022 Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days. tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time. This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used. eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card. unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD). https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst (4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work) 2 Quote
usual user Posted May 28, 2022 Posted May 28, 2022 On 5/22/2022 at 9:15 AM, rpardini said: Ok here's a new version, 5.18-rc7 from tobetter's tree. Thank you for providing your firmware. I borrowed it to use fedora on my ODROID-M1. I built my kernel only with the essential commits from tobetter's tree necessary for the ODROID-M1. If I switch to 5.19.0-rc1, I can skip more commits that have already landed. The firmware in the SPI flash supports distro-boot to a certain extent, but is ultimately not usable. Your firmware is usable, but has no HDMI and USB keyboard support. And also can't cope with a compressed kernel. Whether I build the firmware myself in a timely manner, I have not yet decided. Probably I will first take care of a stable working kernel and use your firmware until then. 0 Quote
mo123 Posted June 3, 2022 Posted June 3, 2022 @rpardiniCan you build an Odroid M1 focal 22.05 legacy kernel Ubuntu Server image perhaps? 0 Quote
usual user Posted June 5, 2022 Posted June 5, 2022 Here is another contribution with an overlay to create a collection to define a unified GPIO naming scheme for the 40-pin connector of different devices. So that if e.g. user space addresses "con1-07", it does not matter on which device it is executed. It will always access pin 7 of the 40 pin connector. The mapping is done in an one off effort via a devicetree-overlay and you get portable user space tools. However, this must be done in a collaborative effort, as no one has access to all devices to create the collection of overlays. Users can then reuse tools written for a specific task regardless of the current device and have no mapping problems like e.g. with WiringPi. With the attached overlay applied via: [root]# fdtoverlay --input rk3568-odroid-m1.dtb --output rk3568-odroid-m1.dtb rk3568-odroid-m1-con1.dtbo /sys/kernel/debug/gpio looks like this: Spoiler gpiochip0: GPIOs 0-31, parent: platform/fdd60000.gpio, gpio0: gpio-4 ( |cd ) in lo IRQ ACTIVE LOW gpio-5 ( |vcc5v0-usb-otg ) out lo gpio-6 ( |vcc5v0-usb-host ) out hi gpio-11 (con1-28 ) gpio-12 (con1-27 ) gpio-13 (con1-33 ) gpio-15 ( |blue:heartbeat ) out lo gpio-16 (con1-11 ) gpio-17 (con1-13 ) gpio-22 ( |red:power ) out hi ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/fe740000.gpio, gpio1: gpiochip2: GPIOs 64-95, parent: platform/fe750000.gpio, gpio2: gpio-88 (con1-21 ) gpio-89 (con1-19 ) gpio-90 (con1-24 ) gpio-91 (con1-23 ) gpio-94 ( |reset ) out hi gpiochip3: GPIOs 96-127, parent: platform/fe760000.gpio, gpio3: gpio-106 (con1-15 ) gpio-109 (con1-05 ) gpio-110 (con1-03 ) gpio-111 ( |PHY reset ) out hi ACTIVE LOW gpio-118 (con1-16 ) gpio-119 (con1-18 ) gpio-120 (con1-12 ) gpio-121 (con1-22 ) gpio-122 (con1-26 ) gpio-123 (con1-32 ) gpio-124 (con1-36 ) gpio-125 (con1-35 ) gpio-126 (con1-08 ) gpio-127 (con1-10 ) gpiochip4: GPIOs 128-159, parent: platform/fe770000.gpio, gpio4: gpio-135 ( |gpio-regulator ) out hi gpio-142 (con1-31 ) gpio-145 (con1-29 ) gpio-148 (con1-07 ) rk3568-odroid-m1-con1.dtbo 0 Quote
usual user Posted June 9, 2022 Posted June 9, 2022 (edited) Ok, I went on to 5.19.0-rc1. I was able to skip a lot of mainline commits from tobetter's tree because they landed, and for the remaining WIP commits, I switched to more recent ones. Some of the WIP commits are already in staging and will land sooner or later. Spoiler [PATCH 012/130] arm64: dts: rockchip: Add sata nodes to rk356x landed [PATCH 018/130] arm64: dts: rockchip: add rk356x dwc3 usb3 nodes landed [PATCH 032/130] arm64: dts: rockchip: add rk356x sfc support landed [PATCH 046/130] clk: rockchip: Mark hclk_vo as critical on rk3568 landed [PATCH 048/130] arm64: dts: rockchip: enable otg/drd operation of usb_host0_xhci in rk356x landed [PATCH 049/130] usb: dwc3: reorder dwc-of-simple compatibles superseeded by enable-usb-support-on-rk356x.patch [PATCH 050/130] usb: dwc3: convert dwc3-of-simple to use match-data superseeded by enable-usb-support-on-rk356x.patch [PATCH 051/130] usb: dwc3: add rk3568 dwc3 support superseeded by enable-usb-support-on-rk356x.patch [PATCH 052/130] drm/rockchip: Refactor IOMMU initialisation landed [PATCH 053/130] drm/rockchip: Embed drm_encoder into rockchip_decoder landed [PATCH 054/130] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder landed [PATCH 055/130] drm/rockchip: dw_hdmi: rename vpll clock to reference clock landed [PATCH 057/130] drm/rockchip: dw_hdmi: add rk3568 support landed [PATCH 059/130] drm/rockchip: dw_hdmi: add regulator support landed [PATCH 061/130] drm/rockchip: dw_hdmi: Use auto-generated tables superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 062/130] drm/rockchip: dw_hdmi: drop mode_valid hook superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 063/130] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 064/130] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 066/130] arm64: dts: rockchip: rk356x: Add VOP2 nodes superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 067/130] arm64: dts: rockchip: rk356x: Add HDMI nodes superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 071/130] drm/rockchip: Make VOP driver optional landed [PATCH 072/130] drm: rockchip: Add VOP2 driver landed [PATCH 076/130] PCI: dwc: rockchip: add legacy interrupt support landed [PATCH 077/130] arm64: dts: rockchip: add rk3568 pcie2x1 controller superseeded by Add-rk3568-PCIe2x1-controller.patch [PATCH 079/130] dt-bindings: rockchip: Add Hardkernel ODROID-M1 board Signed-off-by: Dongjin Kim DT [PATCH 080/130] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board Signed-off-by: Dongjin Kim DT [PATCH 083/130] phy: rockchip: Support pcie v3 superseeded by RK3568-PCIe-V3-support.patch [PATCH 084/130] PCI: rockchip-dwc: add pcie bifurcation superseeded by RK3568-PCIe-V3-support.patch [PATCH 085/130] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes superseeded by RK3568-PCIe-V3-support.patch [PATCH 086/130] arm64: dts: rockchip: rk356x: Add HDMI audio nodes DT [PATCH 087/130] (DO NOT MERGE) ODROID-M1: add more peripherals Signed-off-by: Dongjin Kim DT [PATCH 088/130] (DO NOT MERGE) ODROID-M1: add sound devices nodes Signed-off-by: Dongjin Kim DT For those who are interested, I have attached glmark2 logs. The performance is not yet overwhelming, only the basic functionalities have just landed. But the graphical desktop works pretty decently. So the fine-tuning season is open. And with the hantro decoder wired up, hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run.log for reference. Went on to 5.19.0-rc2. And with the ir-receiver wired up, my RC-100 works out of the box. Quote [ 15.372741] rc rc1: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc1 [ 15.377569] rc rc1: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter [ 15.397831] input: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc1/input3 gpiochip0: GPIOs 0-31, parent: platform/fdd60000.gpio, gpio0: gpio-4 ( |cd ) in lo IRQ ACTIVE LOW gpio-5 ( |vcc5v0-usb-otg ) out lo gpio-6 ( |vcc5v0-usb-host ) out hi gpio-11 (con1-28 ) gpio-12 (con1-27 ) gpio-13 (con1-33 ) gpio-15 ( |blue:heartbeat ) out lo gpio-16 (con1-11 ) gpio-17 (con1-13 ) gpio-18 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-22 ( |red:power ) out hi ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/fe740000.gpio, gpio1: Rant: Why doesn't editing allow spoilers to be created with sections of code? glmark2-wayland-odroid-m1.logfluster-run.log Edited June 14, 2022 by usual user 1 Quote
markbirss Posted June 18, 2022 Posted June 18, 2022 (edited) @usual user Thanks for testing 5.19.0-rc2 kernel support I am using the remote i got with my Odroid-C2 for Android on my Odroid-M1 https://www.odroid.nl/odroid-ir-remote Edited June 18, 2022 by markbirss 0 Quote
usual user Posted June 18, 2022 Posted June 18, 2022 (edited) On 6/18/2022 at 8:29 PM, markbirss said: I am using the remote i got with my Odroid-C2 The type of remote control does not matter as long as it operates near the 38kHz carrier frequency and a suitable rc_keymap.toml is loaded. The reason I used the RC-100 is because I'm using the SD card I originally set up for my NanoPC-T4, and there this remote was configured for rc-empty. Therefore, it worked out of the box. Went on to 5.19.0-rc3. And with the Enable-JPEG-Encoder-on-RK3566-RK3568.patch, a JPEG encoder is also available (videoX-infos.log). MGLRU is also pulled in again but only to see if it does not cause regressions with Odroid M1. Edited June 22, 2022 by usual user 1 Quote
Walter Zambotti Posted July 1, 2022 Posted July 1, 2022 On 6/10/2022 at 1:11 AM, usual user said: Ok, I went on to 5.19.0-rc1. I was able to skip a lot of mainline commits from tobetter's tree because they landed, and for the remaining WIP commits, I switched to more recent ones. Some of the WIP commits are already in staging and will land sooner or later. Reveal hidden contents [PATCH 012/130] arm64: dts: rockchip: Add sata nodes to rk356x landed [PATCH 018/130] arm64: dts: rockchip: add rk356x dwc3 usb3 nodes landed [PATCH 032/130] arm64: dts: rockchip: add rk356x sfc support landed [PATCH 046/130] clk: rockchip: Mark hclk_vo as critical on rk3568 landed [PATCH 048/130] arm64: dts: rockchip: enable otg/drd operation of usb_host0_xhci in rk356x landed [PATCH 049/130] usb: dwc3: reorder dwc-of-simple compatibles superseeded by enable-usb-support-on-rk356x.patch [PATCH 050/130] usb: dwc3: convert dwc3-of-simple to use match-data superseeded by enable-usb-support-on-rk356x.patch [PATCH 051/130] usb: dwc3: add rk3568 dwc3 support superseeded by enable-usb-support-on-rk356x.patch [PATCH 052/130] drm/rockchip: Refactor IOMMU initialisation landed [PATCH 053/130] drm/rockchip: Embed drm_encoder into rockchip_decoder landed [PATCH 054/130] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder landed [PATCH 055/130] drm/rockchip: dw_hdmi: rename vpll clock to reference clock landed [PATCH 057/130] drm/rockchip: dw_hdmi: add rk3568 support landed [PATCH 059/130] drm/rockchip: dw_hdmi: add regulator support landed [PATCH 061/130] drm/rockchip: dw_hdmi: Use auto-generated tables superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 062/130] drm/rockchip: dw_hdmi: drop mode_valid hook superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 063/130] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 064/130] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 066/130] arm64: dts: rockchip: rk356x: Add VOP2 nodes superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 067/130] arm64: dts: rockchip: rk356x: Add HDMI nodes superseeded by drm-rockchip-RK356x-VOP2-support.patch [PATCH 071/130] drm/rockchip: Make VOP driver optional landed [PATCH 072/130] drm: rockchip: Add VOP2 driver landed [PATCH 076/130] PCI: dwc: rockchip: add legacy interrupt support landed [PATCH 077/130] arm64: dts: rockchip: add rk3568 pcie2x1 controller superseeded by Add-rk3568-PCIe2x1-controller.patch [PATCH 079/130] dt-bindings: rockchip: Add Hardkernel ODROID-M1 board Signed-off-by: Dongjin Kim DT [PATCH 080/130] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board Signed-off-by: Dongjin Kim DT [PATCH 083/130] phy: rockchip: Support pcie v3 superseeded by RK3568-PCIe-V3-support.patch [PATCH 084/130] PCI: rockchip-dwc: add pcie bifurcation superseeded by RK3568-PCIe-V3-support.patch [PATCH 085/130] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes superseeded by RK3568-PCIe-V3-support.patch [PATCH 086/130] arm64: dts: rockchip: rk356x: Add HDMI audio nodes DT [PATCH 087/130] (DO NOT MERGE) ODROID-M1: add more peripherals Signed-off-by: Dongjin Kim DT [PATCH 088/130] (DO NOT MERGE) ODROID-M1: add sound devices nodes Signed-off-by: Dongjin Kim DT For those who are interested, I have attached glmark2 logs. The performance is not yet overwhelming, only the basic functionalities have just landed. But the graphical desktop works pretty decently. So the fine-tuning season is open. And with the hantro decoder wired up, hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run.log for reference. Went on to 5.19.0-rc2. And with the ir-receiver wired up, my RC-100 works out of the box. Rant: Why doesn't editing allow spoilers to be created with sections of code? glmark2-wayland-odroid-m1.log 23.95 kB · 2 downloads fluster-run.log 16.93 kB · 1 download The glmark2 scores are disappointing. Those scores are lower than my N2 (non plus) at 600 plus/minus on X and mid 1300 plus/minus on Wayland. 0 Quote
Nexus Posted July 13, 2022 Posted July 13, 2022 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 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.