Bookworm upgrade availability soon ?

Started by stanlog, June 14, 2023, 12:17:03 PM

Previous topic - Next topic

olimex

Thanks for your feedback! We always appreciate it.
Moving to Bookworm and latest kernel is of course something we also want bad but there are lot of obstracles to do it. Not everything is supported in upstream kernel and as A64 is already considered as "old" SOC probably no one is / will be working on this, and this is far behind our own capabilities.

I asked one of our Linux developers about your security updates concern and this is what he answered: Bullseye is still in the support up to August 2026 and ELTS probably will extend it to 2031.

jch

> as A64 is already considered as "old" SOC probably no one is / will be working on this

In that case, what's the suggested replacement for the Olinuxino-A64?

ilario

Quote from: jch on March 22, 2025, 09:25:44 PM> as A64 is already considered as "old" SOC probably no one is / will be working on this

In that case, what's the suggested replacement for the Olinuxino-A64?

No answer, so seems that so far (2025-05-27) there is no suggested replacement.

I just realized the existence of the System-on-Module (SOM) products line, and you could consider trying those products instead. The newest being iMX8MP-SOM-4GB-IND + iMX8MP-SOM-EVB-IND combination (and maybe including also Flash-e32Gs16M but check out this topic https://www.olimex.com/forum/index.php?topic=9808.0).

Not as convenient as a Single Board Computer, as it does not have a nice box, but it looks like a viable option to me.

mossroy

Quote from: olimex on December 20, 2024, 11:33:06 AMNot everything is supported in upstream kernel and as A64 is already considered as "old" SOC probably no one is / will be working on this, and this is far behind our own capabilities.

@Olimex: does that mean that Olimex will not ever publish any bookworm image?

Quote from: olimex on December 20, 2024, 11:33:06 AMI asked one of our Linux developers about your security updates concern and this is what he answered: Bullseye is still in the support up to August 2026 and ELTS probably will extend it to 2031.

That's true for packages of Debian repositories. However, the kernel used by Olinuxino devices is not the one from Debian repos, but the one from Olimex repo.
As I wrote here 7 months ago, the current version of this kernel (5.10.180-olimex) is completely outdated, and full of CVEs.

In any case, I suppose what you wrote means that the Olinuxino-A64 devices will become completely obsolete (in terms of security) with the end of LTS support of Debian Bullseye. This is one year from now: end of June 2026, based on https://wiki.debian.org/LTS/Bullseye

I know about ELTS, but it's a commercial offer: https://wiki.debian.org/LTS/Extended. And it's not clear if they will support arm64 architecture or not. In any case, it's not cheap at all: https://www.freexian.com/lts/extended/docs/cost-estimation/ . Will Olimex pay that for its customers? I doubt so.

I remind what you wrote 2 years ago (at the beginning of this thread) about bookworm upgrade:
Quote from: LubOlimex on June 14, 2023, 01:27:39 PMWe plan to upgrade but we don't have a timeline. As soon as we test how it works and apply all fixes needed. Bookworm was released 4 days ago...

Since mainline kernel seems to work on some variants of Olinuxino-A64 (like LIME2, as reported by someone else above), would there be at least a way to make mainline Debian Bookworm work on all variants (without kernel panic), even if it would be with minimal support?
Maybe by making it ignore some hardware features if necessary (like eMMC). Even by doing some soldering on our side, if there's no other choice.

Please help us with a way to avoid trashing working devices, only because of obsolete software.

mossroy

Now that Debian 13 (Trixie) has been released, I've tested again the Debian Installer on the Olinuxino devices I have:

- Olinuxino A20-OLinuXino-MICRO: can be installed by Debian Trixie installer (with https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/). I did not test for long, but it seems to be stable

- Olinuxino A64-OLinuXino-2Ge8G-IND: The Debian installer https://deb.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/ does not start (stuck on "Booting kernel...". With "earlycon" bootarg, it seems to show it crashes on an mmc step). After replacing the dtb by the one from Olimex latest image, I could run the installer properly, and install it on the SDcard. However, I did not manage to make it start afterwards (stuck on "Booting kernel..." too, but the "earlycon" trick does not seem to give more detail)

So the problem remains with my A64 (2Ge8G) boards.
I don't care about its eMMC: is there a software or hardware solution to make it ignored? Hopefully it would help installing a regular Debian on it

mossroy

#20
I ran some tests again on an Olinuxino A64-OLinuXino-2Ge8G-IND board, to see if there was a recent version of Linux I could install on it (supported after August 2026).

I tried armbian with Armbian_community_26.2.0-trunk.493_Lime-a64_trixie_current_6.12.74_minimal.img.xz image. It's not starting at all with error message: "Unhandled Exception in EL3.". And I saw nobody using this board in their forum.

I tried the Debian installer of Debian 13 "trixie" (https://deb.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/), dated 2026-01-05, with kernel 6.12.73. It can be installed with no issue and no trick. But, when restarting on the freshly installed OS, it hangs on "Starting kernel ...", with no visible error message.

Same result with the Debian installer of Debian unstable "sid" (https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/), dated 2026-03-06, with kernel 6.12.73 too.

BUT I managed to make Debian Trixie start after forcing the kernel to use sun50i-a64-olinuxino-2Ge8G.dtb instead of the sun50i-a64-olinuxino.dtb (used by default by Debian on this board). It can be done by putting the file in dtbs/(latest kernel version)/allwinner directory of the boot partition, interrupting startup in u-boot, and typing these commands in u-boot:

setenv fdtfile allwinner/sun50i-a64-olinuxino-2Ge8G.dtb
boot

There are a few errors in the console, though:
[    7.561076] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    7.591996] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    7.827461] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    7.895088] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    7.951018] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    8.065466] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    8.401470] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    8.589256] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.596088] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.602995] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.609826] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.617300] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.677685] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.684173] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[    8.692755] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[    8.693185] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.706637] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.713384] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.720145] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.726914] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.733645] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.740131] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[    8.748700] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[    8.756350] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.763198] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.770002] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.776754] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.783643] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.790533] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.797066] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[    8.805658] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[    8.890938] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.897784] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.904617] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.911625] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.919850] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.926641] sunxi-mmc 1c11000.mmc: data error, sending stop command
[    8.933133] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[    8.941708] Buffer I/O error on dev mmcblk1, logical block 0, async page read
/dev/mmcblk0p3: clean, 80599/1733312 files, 777867/6925568 blocks
[   19.976565] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   19.983758] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   19.990588] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   19.997428] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.004302] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.011516] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.019379] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[   20.046176] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.053060] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.059950] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.066867] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.073885] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.080774] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   20.087424] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[   20.095977] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[   22.382242] sun8i-dw-hdmi 1ee0000.hdmi: Couldn't get the HDMI PHY
[   22.392831] sun4i-drm display-engine: Couldn't bind all pipelines components
[   22.764221] sun4i-i2s 1c22800.i2s: Missing dma channel for stream: 1
[   22.770765] sun4i-i2s 1c22800.i2s: ASoC: error at snd_soc_pcm_component_new on 1c22800.i2s: -22
[   22.779545] asoc-simple-card hdmi-sound: ASoC: can't create pcm 1c22800.i2s-i2s-hifi :-22
[   22.788273] asoc-simple-card hdmi-sound: probe with driver asoc-simple-card failed with error -22

It seems to work, even if I did not test more than a few hours. However, there are some issues:

- a few kernel crashes reported on the console. I did not see any visible consequence, though:
[ 1330.457436] INFO: task kworker/0:1H:153 blocked for more than 1208 seconds.
[ 1330.465883]       Tainted: G         C         6.12.73+deb13-arm64 #1 Debian 6.12.73-1
[ 1330.474004] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1330.481915] task:kworker/0:1H    state:D stack:0     pid:153   tgid:153   ppid:2      flags:0x00000008
[ 1330.491353] Workqueue: mmc_complete mmc_blk_mq_complete_work
[ 1330.497120] Call trace:
[ 1330.499639]  __switch_to+0xf4/0x168
[ 1330.503200]  __schedule+0x398/0xf18
[ 1330.506748]  schedule+0x30/0x130
[ 1330.510036]  schedule_timeout+0x138/0x180
[ 1330.514103]  __wait_for_common+0xdc/0x270
[ 1330.518167]  wait_for_completion+0x28/0x40
[ 1330.522324]  mmc_wait_for_req_done+0x34/0x108
[ 1330.526738]  mmc_wait_for_req+0xb4/0x108
[ 1330.530712]  mmc_wait_for_cmd+0x70/0xb8
[ 1330.534596]  __mmc_send_status+0x80/0xd8
[ 1330.538575]  mmc_blk_mq_rw_recovery+0x60/0x3d8
[ 1330.543089]  mmc_blk_mq_poll_completion+0x80/0x220
[ 1330.547965]  mmc_blk_mq_complete_work+0x58/0x98
[ 1330.552575]  process_one_work+0x178/0x3e0
[ 1330.556652]  worker_thread+0x204/0x3f0
[ 1330.560475]  kthread+0xe8/0xf8
[ 1330.563599]  ret_from_fork+0x10/0x20
- restarting the board does not work: it stops, the console displays "systemd-shutdown[1]: Syncing filesystems and block devices.", but the device does not restart
- running any command that triggers update-initramfs (like a kernel upgrade, or installing cryptsetup for example) ends up with an error "Unsupported platform 'Olimex A64-Olinuxino-2Ge8G-IND". That's because this dtb file refers to this model name, for which there is no dtb provided with Debian kernel, that provides only models "Olimex A64-Olinuxino" (sun50i-a64-olinuxino.dts) and "Olimex A64-Olinuxino-eMMC" (sun50i-a64-olinuxino-emmc.dts)

So it's not really usable for now. But, at least, there is some hope.

@Olimex: your help would be really welcome to find a sustainable way to use a regular Debian Trixie on this variant of Olinuxino A64. For example by providing an appropriate dtb, or a dtb overlay (dtbo) over one provided by Debian.