Odroid M1

[Igor]

 

[Slartibartfast9536]

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?

[N4IRS]

I have my M1 sitting here waiting for some Armbian action!

[Werner]

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.

[Stan Pak]

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.

[Neo2SHYAlien]

I'd love to be a beta tester soon when a beta images are available :)

[rpardini]

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.

 

 

[rpardini]

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

[Neo2SHYAlien]

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

[rvalle]

@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?

 

 

 

 

[rpardini]

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.

 

 

[rvalle]

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.

 

 

 

 

[rpardini]

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.

 

[rvalle]

@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

 

[rpardini]

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

[rvalle]

ok... looks like does not like the docker container from other branch.... I think. will investigate.

[Neo2SHYAlien]

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

[rvalle]

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.

 

[rpardini]

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.

 

 

[rpardini]

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. 

 

 

[Guest]

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.

[rpardini]

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)

[usual user]

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.

[mo123]

@rpardiniCan you build an Odroid M1 focal 22.05 legacy kernel Ubuntu Server image perhaps?

[usual user]

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

[usual user]

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

[markbirss]

@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

[usual user]

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

[Walter Zambotti]

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.

[Nexus]

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