usual user

I still have an idea for an experiment with your problem: - Blacklist the OLED display driver module so it get not autoloaded at system start I do it e.g. this way: echo blacklist ssd130x-i2c > /etc/modprobe.d/ssd130x-i2c-blacklist.conf But I don't know if it works the same way in an Armbian system. - Boot the system without the HDMI monitor connected - When the boot process is complete, i.e. all automatic graphical console device mappings are complete, modprobe explicit the OLED display driver module - Report if fbcon is no longer binding to the framebuffer device provided by the OLED driver If this works, it might serve as a workaround, because I'm not sure if the Armbian configuration framework can handle two separate graphic cards. But I'm happy to be taught better by an Armbian insider. Oh, by the way, this is not a specific ODROID-M1 problem nor is it special because the display driver uses the i2c interface. It is a general matter to support several grahic cards at the same time, it doesn't matter which interface they use to communicate. The same would happen, for example, if an additional graphics card is used, which is connected via USB adapter. This allows you to find solutions from anywhere and then learn how to configure them in Armbian for its automatisms.

Nice to hear, then I can issue my invoice now 😉 It is now your task to make my contributed knowledge easily available to all Armbian users. Prepare a PR so that my used overlay (which was applied to my provided DTB) will be included in the Armbian build system. And while you're at it, include this one (also applied to my provided DTB by default) as well. It simplifies GPIO handling and connector pinout identification immensely. If I am correctly informed, they have even simplified the overlay integration into the build system. All you have to do is make the overlay source available in an appropriate directory. To do this, I have attached the sources of both overlays to this post. Repairing the pinctrl in the base DTB is not that easy, for this you have to apply the attached patch to the board DTS and rebuild the base DTB. This is necessary so that the correct code artifacts can be integrated into the DTB, this cannot be corrected in a reasonable way with an overlay. And don't forget, you'll reap a lot of Armbian users who will be grateful for your contribution. Not to mention the fact that your desired functionality will be available out-of-the-box to everyone in the future. I'm guessing you only have the OLED display driver loaded in your system and no additional other. This then provides /dev/fb0, which in turn is assigned /dev/tty1 by the system. Usually, the console is also assigned to /dev/tty1 by default. I don't know the system you're using, but I always configure the console mapping with the kernel command line (/proc/cmdline). rk3568-odroid-m1-con1.dtsork3568-odroid-m1-lk-oled1.dtsospecify-pinctrl-for-i2c3-adapter-on-ODROID-M1.patch

That was a good question. While researching the answer, I noticed that the basic DTB wires the i2c functionality to pads that are inaccessible on this device. After appropriate correction, the i2c functionality is now available on the documented pins of the board. I plugged in my LK-OLED1 display and it works as expected: # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I re-uploaded the corrected DTB in the previous post. Please download the DTB again to replace the wrong one.

- backup your existing rk3568-odroid-m1.dtb - replace /boot/dtb/rockchip/rk3568-odroid-m1.dtb with the provided DTB - disable all currently applied overlays (the provided DTB has everything already wired up) - reboot and post the output of: # i2cdetect -y 0 rk3568-odroid-m1.dtb

I don't know what that overlay wires up but with proper wired DT you should get this: # i2cdetect -l i2c-0 i2c rk3x-i2c I2C adapter i2c-3 i2c rk3x-i2c I2C adapter i2c-6 i2c DesignWare HDMI I2C adapter

The IOs of the expansion connector are multifunction IOs, so the deault configuration does not necessarily correspond to your use case. How did you wire up the corresponding i2c bus in DT?

To build ffmpeg with the request API, you usually only need the additional commits that Jernej provides.

You're probably running the same DTB without a properly wired thermal-zones.

Moved on to 6.6.0.rc2 and can now confirm the mainline regression. USB 3.0 keeps working on my M1, but haven't checked if the rk3568 uses the same USB IP.

Not only with the NanoPC T4, I'm running the same generic kernel build on all devices with aarch64 architecture. The only thing that is device-specific is the DTB, which informs the kernel about device-specific components. There is no Armbian build system involved for me, hence my claim about the build configuration.

FWIW, I've been running 6.3.0-0.rc1 for 154 days, just rebooted to switch to 6.5.0-0.rc2. USB will continue to work as before: /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M Issue must be blamed on the build configuration, the kernel source code does not seem to introduce regression.

I'm guessing you're configuring the rc only after XWindow is already started, that way the input event device can't be added as an XWindow input device at times. Load the rc keymap during the boot process by adding it to /etc/rc_maps.cfg. E.g.: * rc-empty your-config-name.toml as last line added.

Provide output of ir-keytable and ir-keytable -t while pressing your mapped ir buttons.

Since you haven't provided any details about what keycodes you've mapped and what desktop features are assigned to them, no one can tell if what you're seeing is what to expect.

UMS has not interested me much so far. However, the mention still inspired me to bring forward my rebase, which was planned after the v2023.10 GA release. Now my serial console boots up with a nice little boot menu: *** U-Boot Boot Menu *** Standard Boot NVME USB Mass Storage eMMC USB Mass Storage microSD USB Mass Storage usb 0:3 nvme 0:1 nvme 0:3 nvme 0:4 mmc 1:2 U-Boot console Press UP/DOWN to move, ENTER to select, ESC to quit Now I don't even need to physically insert the SD card back and forth between the card reader and the M1 when I want to perform a firmware update from my host build system, because the M1 can now act as a card reader itself. And that even for NVME, SATA and eMMC storage. I rarely need this because I usually run updates directly from the M1, but it's still nice to have. However, this only becomes really interesting when HDMI video is also available and the EXPO menu can also be used. I guess the day is approaching when I'll finally run this on the serial console: run mmc-fw-to-sf It will transfer my self-contained firmware image build into the SPI flash. I will then lose the possibility to use outdated legacy OS forks and can only use modern operating systems with current bootflows, but if I understand correctly, I have never used anything so unmaintained 😉 But the need to press the RCY button at system startup is starting to get annoying.

There are several tools to write SPI flash. Choose whatever you're familiar with, e.g.: dd if=u-boot-meson.bin of=/dev/mtd0 The tricky part is to wire the SPI flash up in devicetree. Hardkernel seems to have declared this information to be Top Secret. I extracted this information from Pettitboot, but I only got a very unstable functionality. It took me several tries before the data was error-free written, so I'm hesitant to publish my used values. Maybe there is someone out there who knows more reliably functioning binding values and can contribute them.

With the release of U-Boot v2023.10, everyone will be able to create their own firmware on a stable basis. The only difference to other firmware builds is a make odroid-m1-rk3568_defconfig to setup a suitable configuration for the ODROID-M1. If you want to build beforehand, you need to dig mailing lists and patchwork for non-landed fixes and improvements to pick them up. As you can see here this has already happened. They use distributions that are not in any way designed specifically for the ODROID-M1 and where Petitboot is not able to support the bootflow used. And this is possible because the rk3568 SOC has sufficient mainline kernel support.

Judging by your following command excerpts, this time you did everything as required. You should now have my provided firmware build in use and it is working as expected. I.e. it is using distro-boot and should be able to boot various operating systems from USB, SD-card or eMMC as long as either a suitable legacy- (boot.scr), extlinux- (extlinux.conf) or EFI-bootflow is in place. And since it doesn't carry any OS artefacts on the firmware device and uses unmodified OS images for a single drive, OS updates should work much more reliably. In order to determine the cause and possibly find a solution, the serial console logs are mandatory. If you can't provide serial console logs, you're pretty much on your own. If it breaks for you, you have to keep the parts.

Judging by your following command excerpts, you did not do this. Since I don't know if your SD card to be prepared was really in a card reader listed as /dev/sda when you ran the command "root@odroidc4:/# dd if=/dev/zero of=/dev/sda1", I can't really tell if you chose the right device. In any case, you didn't target the entire device for the dd commands as instructed, but only the first partition (dev/sda1). The correct one here would have been "/dev/sda". Serial console logs are taken via the 4pin UART Connector for system console and are essential for proper debugging. Because you wrote my firmware in the first partition, and not at the location where it is expected by the MASKROM code, I can't tell what exactly is going on without appropriate console logs. But you have apparently corrupted the contents of the first partition enough, so that the existing firmware also uses the bootflow in the USB storage. However, the original goal is to have an SD card that contains only the firmware and no other system artifacts.

Out of curiosity, are you interested in a little experiment? If so, - prepare an entire cleared SD card (dd if=/dev/zero of=/dev/${entire-SD-card}) - dd the unpacked firmware (tar -xzf uboot-meson.tgz) that is uploaded here in place with: dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-SD-card} - dd the unmodified Armbian_23.02.2_Odroidc4_jammy_current_6.1.11 image onto your USB 3.0 storage - plug in the prepared SD card and your USB 3.0 storage into your odroid c4 - boot the odroid c4 and post the serial console log

Software that lies about true hardware specifications is nothing new. Even in this forum there are many repetitive posts about this topic.

You ignored the organization, a byte is 8 bit hence 512Mx4 x 4 chips = 1 Giga Byte.

The necessity of the "-B" parameter with the observed gpio behavior is probably due to how the gpio is wired up in the DT and how its pin control is set up there. Since I didn't know the exact use case, I only presented the basic command and left it to the user's imagination how it would ultimately be used. It's general shell usage, and if I understand the use case correctly, I'd have e.g. used something like this in a script that loads on startup: gpiomon --num-events=1 -B pull-down -f gpiochip0 9 && wall power off initiated && sleep 5 && halt You're welcome.

gpiomon is your friend, e.g.: sudo gpiomon --num-events=1 gpiochip1 97 && poweroff

To get multimedia acceleration, you'll need an OS with up-to-date mainline software releases and a DE based on Wayland. For applications based on the ffmpeg framework, you will need patched mainline ffmpeg because request-api support is not yet included in mainline out-of-the-box. In order to have HEVC decoder support for the rk3399, you still need the kernel patches, as there is still more development work to be done. For the OPI 4 LTS support you need a suitable DTB that obeys mainline bindings and a device specific firmware to boot the OS. As far as I can see, Armbian offers these two components. So all the necessary information is available to create an appropriate OS.