torz77

Ok, I was trying to work out what you were doing, as 1.3GB is an insanely large size for the kernel (it is 12MB on my system!), but I think I have now (and why it took so long). I'm guessing at the following. If I am incorrect, I apologise. At a guess I would say that you ran that ./compile command directly on your Odroid? Is that correct? If so, that will be why it took so long (you are meant to build the image on a different, more powerful, host device). What you did was fine, but it is (obviously) slower as it is a fairly underpowered device. Secondly, I think you are misunderstanding what you have done. I believe the file in output/images you are talking about is this (or named similar): -rw-rw-r-- 1 user root 1.4G Oct 10 13:45 Armbian-unofficial_25.11.0-trunk_Odroidc1_trixie_current_6.12.51_minimal.img This is not the kernel. This is the entire Odroid C1+ image (including boot and rootfs partitions) to be burned to SD/eMMC. It is basically an updated version of what you downloaded as a standard image. You are meant to take this file and burn it to your media, as you did with the standard image. That would be the easiest step now (copy that file off your Odroid, burn it to your eMMC, place burned image back into your Odroid and go back through first run setup). It may also be possible to just install your new kernel, which was built as part of the above process. Note: I have never done this before, but I see no reason why it shouldn't work (you can always fallback to burning the whole image if this doesn't work, just copy the .img file off first). This would leave you on Bookworm/Noble though rather than Trixie, which may be fine for you. Within the build/output/debs folder you should find a series of debian (.deb) packages. These will include the kernel (it will be the one which starts linux-image-current-meson_25.11.0-trunk_armhf__6.12.xx). You can install this with: Note: Update <kernel file name> to the correct name of your kernel sudo dpkg -i build/output/debs/<kernel file name>.deb I would also be installing any of the other deb packages in that folder with the kernel version number in the name (ie __6.12.51.xx) as most likely those packages will be required as they will have been built against your new kernel. Whichever way you go, once done, you can reclaim the space from the build process by just deleting the build folder. It is only needed for the build process to generate the images/packages. Once these images/packages have been installed, the build folder is no longer required.

I didn't test eMMC, whilst the bug occurred (it definitely impacted the SD card), but I did try using a USB drive and I can confirm (for me at least) the issue went away (the issue impacts the MMC stack, specifically), so if you have a spare USB drive hanging around, and you want an easier interim "fix" you can try putting the rootfs on a USB drive in the meantime. To be clear, the bug still did occur, but as it only impacted the SD card (which was for boot only), it only spammed my log files, but did not impact my day to day running (which with rootfs on SD, it definitely did. Made the device completely unusable pending a hard reset). I'll put the build instructions here too, because it's very simple (This was using a Debian Bookworm/Trixie host): sudo apt install git git clone --depth=1 https://github.com/armbian/build.git cd build ./compile.sh \ BOARD=odroidc1 \ BRANCH=current \ RELEASE=trixie \ BUILD_MINIMAL=yes \ BUILD_DESKTOP=no \ CLEAN_LEVEL= \ PREFER_DOCKER=no \ KERNEL_CONFIGURE=no \ COMPRESS_OUTPUTIMAGE=sha,gpg,img And that's it. Image is saved in: ./output/images

Assuming that you installed the standard image, then I suspect this is the same bug that I identified here: I submitted a PR to patch this, which has been accepted into Armbian, but it won't have flowed through into the releases yet, so you will need to build the image (instructions also linked in the subsequent post)

I can confirm that my changes have now been merged into the upstream linux_openfd repo, so I have deleted my fork. Unfortunately I am unable to edit my instructions, but hopefully it should be clear from the instructions that if my fork is unavailable, then the original repo should be used (alternatively, if a mod could edit the post to remove the reference to my fork, to make the instructions clearer, that would also be appreciated).

Firefox is called firefox-esr in Debian (Extended Support Release)

PR Has been merged. I rebuilt on commit 1cf20837d27a3c09d93395f075cc305c81b4663f and things look good. Build instructions remain the same as my last post on this /_\ _ _ _ __ | |__(_)__ _ _ _ ___ _ _ _ _ ___ / _|/ _(_)__(_)__ _| | / _ \| '_| ' \| '_ \ / _` | ' \___| || | ' \/ _ \ _| _| / _| / _` | | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| \_,_|_||_\___/_| |_| |_\__|_\__,_|_| v25.11 rolling for Odroid C1 running Armbian Linux 6.12.49-current-meson Packages: Debian stable (trixie) Support: DIY (custom image) IPv4: (LAN) 192.168.1.95, 10.8.0.1, 10.10.0.1 (WAN) ww.xx.yy.zz IPv6: 0000:1111:2222:3333:444:555:6666:7777 Performance: Load: 2% Uptime: 23:36 Memory usage: 8% of 986M CPU temp: 49°C Usage of /: 15% of 6.9G

The easiest way to do this is through a chroot (or perhaps systemd-nspawn) but how practical this is will be dependent on your end goals. I do this all the time.

At the risk of speaking too soon, I think I have found the issue. I need to revert some changes, and do some final testing, but hopefully a PR will be inbound to fix this in the next couple of days.

I have had a bit of time to do some testing (re: MMC disconnects) This bug does not appear in kernel 6.6 A version of this bug appears in 6.10, but without the full trace. Output at the point of disconnect is: [ 1082.901830] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc_noinmem:4512: inode #25776: block 1769: comm cron: unable to read itable block [ 1082.914822] EXT4-fs (mmcblk0p2): Remounting filesystem read-only or [ 8235.333023] EXT4-fs (mmcblk0p2): shut down requested (2) It is worth noting that the device is noticeably more sluggish on this kernel (not measured, and may or may not be related) On kernel 6.12 The bug manifests with a full trace: [ 1956.200890] I/O error, dev mmcblk0, sector 9337968 op 0x1:(WRITE) flags 0xc800 phys_seg 1 prio class 2 [ 1965.163111] rcu: INFO: rcu_sched self-detected stall on CPU [ 1965.165764] rcu: 0-....: (57 ticks this GP) idle=9194/1/0x40000004 softirq=13082/13083 fqs=48 [ 1965.173801] rcu: (t=2142 jiffies g=20165 q=305 ncpus=4) [ 1965.179160] CPU: 0 UID: 0 PID: 78 Comm: kworker/0:3 Not tainted 6.12.49-current-meson #1 [ 1965.179720] Hardware name: Amlogic Meson platform [ 1965.179991] Workqueue: events dbs_work_handler [ 1965.180753] PC is at __netif_receive_skb_core.constprop.0+0x4/0x10a4 [ 1965.181411] LR is at __netif_receive_skb_list_core+0xf0/0x1f4 [ 1965.181948] pc : [<c10f55bc>] lr : [<c10f674c>] psr: 80030113 [ 1965.182280] sp : f0801d14 ip : 00000000 fp : c4000000 [ 1965.182583] r10: c211a108 r9 : 00000000 r8 : c4000000 [ 1965.182874] r7 : f0801d48 r6 : c400148c r5 : c211a108 r4 : c4e09900 [ 1965.183225] r3 : c2abbd80 r2 : f0801d44 r1 : 00000000 r0 : f0801d40 [ 1965.183585] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 1965.184017] Control: 10c5387d Table: 05ad004a DAC: 00000051 [ 1965.184260] Call trace: [ 1965.184552] __netif_receive_skb_core.constprop.0 from 0xc4003640 [ 1965.262719] sched: DL replenish lagged too much [ 1990.096714] mmc0: card 0002 removed [ 1990.100368] Aborting journal on device mmcblk0p2-8. [ 1990.100590] JBD2: I/O error when updating journal superblock for mmcblk0p2-8. [ 1990.102743] ------------[ cut here ]------------ [ 1990.111672] WARNING: CPU: 0 PID: 131 at drivers/mmc/host/meson-mx-sdio.c:446 meson_mx_mmc_irq_thread+0x168/0x174 [ 1990.121734] Modules linked in: zram zsmalloc binfmt_misc snd_soc_meson_gx_sound_card snd_soc_meson_aiu snd_soc_hdmi_codec snd_soc_meson_card_utils snd_soc_meson_codec_glue snd_soc_core evdev snd_pcm snd_timer meson_ir snd rc_core soundcore meson_saradc thermal_generic_adc cfg80211 rfkill efi_pstore pstore [ 1990.148744] CPU: 0 UID: 0 PID: 131 Comm: irq/35-c1108c20 Not tainted 6.12.49-current-meson #1 [ 1990.148779] Hardware name: Amlogic Meson platform [ 1990.148791] Call trace: [ 1990.148807] unwind_backtrace from show_stack+0x10/0x14 [ 1990.148865] show_stack from dump_stack_lvl+0x54/0x68 [ 1990.148921] dump_stack_lvl from __warn+0x80/0x114 [ 1990.148980] __warn from warn_slowpath_fmt+0x184/0x18c [ 1990.149030] warn_slowpath_fmt from meson_mx_mmc_irq_thread+0x168/0x174 [ 1990.149088] meson_mx_mmc_irq_thread from irq_thread_fn+0x1c/0x7c [ 1990.149150] irq_thread_fn from irq_thread+0x138/0x21c [ 1990.149207] irq_thread from kthread+0xdc/0xf8 [ 1990.149270] kthread from ret_from_fork+0x14/0x28 [ 1990.149314] Exception stack(0xf106dfb0 to 0xf106dff8) [ 1990.149339] dfa0: 00000000 00000000 00000000 00000000 [ 1990.149365] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1990.149388] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 1990.149420] ---[ end trace 0000000000000000 ]--- [ 1990.574529] EXT4-fs (mmcblk0p2): shut down requested (2) [ 1991.000606] mmc0: new high speed SDHC card at address 0002 [ 1991.001627] mmcblk0: mmc0:0002 00000 7.32 GiB [ 1991.006695] mmcblk0: p1 p2 [ 2041.955601] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block [ 2041.961894] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block [ 2041.974376] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block If I were to speculate it looks like: initial bug introduced kernel 6.7 to 6.10 Bug was identified and the "fix"/"work around" has lead to the more verbose failure somewhere in 6.11 - 6.12 I went for the low hanging fruit first and can confirm the driver meson-mx-sdio.c is unchanged across all versions. I have also compared the DTBs: 6.6 -> 6.10 Significant changes 6.10 -> 6.12 Identical The changes looks to be the USB fix. I suspect that the issue is not with the DTB files, as the significant changes will be down to shifting phandle references by +1, I have now completely ruled out changes to the DTB. I loaded up the 6.12 kernel with the 6.6 DTB and hit the bug fairly quickly (wish I'd done this to start with, to be honest!) When I next get some time I will start diffing changes to the mmc/core and clk/meson drivers between 6.6 -> 6.10. If anyone else wants to have a crack at this in the meantime, based on the above information, then please, have at it!

So I looked into this, and unfortunately, no dice. I am happy to investigate further, if you so wish, but I'm happy enough with the way it works currently (auto patching the dtb after a kernel update) so am unlikely to go exploring further on my own. To let you know what I did: copied the dtbo to /boot/dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo Added to /boot/extlinux/extlinux.conf: fdtoverlays /dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo (I also tried with /boot prepended to the path as well, but same issue) note: I assume FDTOVERLAYS is a typo from the armbianEnv.txt days, so I went with the lowercase as that is standard for extlinux The device would not come up on the network. I plugged in an HDMI monitor and found that it would hang at: ethernet end0: renamed from eth0 Which is.... odd. I suspect one of 2 things: My entry in extlinux.conf is incorrect (entirely plausible, I'm struggling to find documentation, I've just gone on what you've said, and also changed the capitalisation!) U-Boot overlays are applied differently than fdtoverlay in Linux. It’s possible U-Boot leaves something unaligned or adds an unexpected property, and the kernel hits a corner case. I realise that the above is noway near enough information, however, connecting directly to serial is not realistic at this stage, but I can attach a netconsole if needs be, as we are reaching the kernel, and provide further output. Like I say though, I will only do this if you think there is value in it. Whilst my method might not be the preferred way, it does work, at least.

I'm not sure what this adds? I saw a user struggling to get it working, I managed to get it working, so thought I would give my steps that they may help other people. I am happy to improve my instructions based on feedback from users like @SteeMan above, but I was not specifically looking for help. If my tutorial and responses are in anyway not wanted here, then feel free to delete them.

Ok, this I was not aware of. When I get a second I will try it out. I'm not sure how long editing remains open on my post, but if it works, and if I can, I will go back and edit

I mean that creating the dts and executing: sudo armbian-add-overlay openvfd.dts Results in: grep: /boot/boot.cmd: No such file or directory Overlays are not supported on Meson64 based boards. I started to investigate, but realised it was a massive rabbit hole, and what with the note in the documentation saying: I decided that directly applying the overlay to the DTB and running an /etc/kernel/postinst.d/ script following a kernel update would be my path of least resistance. If I have overlooked something, I would happily update the instructions as, clearly, using an overlay would be far more preferential. EDIT: I should add, that I also tried compiling and adding the overlay manually, and adding an armbianEnv.txt for boot, but the overlay was not loaded.

<off topic: If someone wants to tell me how to "reply" to a post on these forums, that would be appreciated!> Sadly, Meson64 does not have DTB Overlays enabled. That would, of course, be my preference. I have, however, updated my instructions to create an overlay and apply it directly to the DTB (rather than manually editing the DTB) and pointed users in the direction of postint.d if they wish to automate this (out of scope to provide specific instructions here). It should now be easier to create an overlay rather than directly apply to DTB if the user's box supports this. Unfortunately, I did not see this until I was well underway getting OpenVFD working. The box is now in production, so it is not straightforward taking it out and experimenting with it. However, having more than one way to achieve an end goal is no bad thing imho.

I've just been through this process myself. Those instructions are not close to working, and I'm not sure they ever worked. I have documented how I got the LCD display working on the T3-Mini here: