WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: piCore 14.1 (32 and 64 bit) release  (Read 2304 times)

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
piCore 14.1 (32 and 64 bit) release
« on: December 16, 2023, 11:02:40 AM »
Team Tiny Core is happy to announce the release of piCore-14.0.  Both 32 and 64bit images are ready for download/testing.

Changes since 14.0
-rpi-kernel 6.1.68
-pi[5] support on the 64bit image.
    ******WARNING********
    You need to be running a bootloader on your pi[5] 2023-11-20 or newer or piCore will fail to boot on a pi[5]
    use rpi-imager to create an sdcard with the latest bootloader image, boot your device with that card, when you get a green screen, then you can write the piCore64-14.1 image and boot.

32bit - http://www.tinycorelinux.net/14.x/armv7/releases/RPi/piCore-14.1.0.zip  (This should run on all rpi boards except pi5)
64bit - http://www.tinycorelinux.net/14.x/aarch64/releases/RPi/piCore64-14.1.0.zip  (rpi zero2W, pi3, pi4, pi5)

Offline elcouz

  • Newbie
  • *
  • Posts: 23
Re: piCore 14.1 (32 and 64 bit) release
« Reply #1 on: January 06, 2024, 07:45:09 AM »
Thanks Paul_123

Offline zharr

  • Newbie
  • *
  • Posts: 29
Re: piCore 14.1 (32 and 64 bit) release
« Reply #2 on: April 16, 2024, 04:38:49 AM »
Hey, thanks for the updates!
I'm wondering in what extension I can find libvcsm.so with 14.x?
From 13.x to 14.x it seems to be gone from the package that previously had it.
libatomic was also missing but found in gcc_libs.tcz thanks to the forum.
libmmal and it's related libraries are also gone, though with MMAL being deprecated that is not too surprising.
But VCSM is still a crucial element of interacting with the hardware

The reason I'm trying to upgrade in the first place is because I'm facing a kernel wifi driver crash while checking the RSA SSH host keys that openssh generated itself on first boot - about half the time, my Pi Zero 2 boots without the wlan0 device because it's driver crashed (OpenSSH would then regenerate the RSA key on next boot, so I assume that's why it didn't crash).
FYI, it's the same error message+code on the same code line as this issue).

Any help finding libvcsm or resolving the crash is appreciated.
(Note I'm using armv6/v7 not aarch64 since I need compatibility with the Zero 1)
Thanks!
« Last Edit: April 16, 2024, 04:41:27 AM by zharr »

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
Re: piCore 14.1 (32 and 64 bit) release
« Reply #3 on: April 16, 2024, 10:43:53 AM »
The rpi-vc package should be available in 14.x, but yes all of that stuff is obsolete going forward.

The linked issue was resolved on our end before we released, so I've never seen the issue on piCore 12,13 or 14.   The crash would have nothing to do with ssh keys vs wifi, and is more likely something with your access points you are connecting to.

Offline zharr

  • Newbie
  • *
  • Posts: 29
Re: piCore 14.1 (32 and 64 bit) release
« Reply #4 on: April 16, 2024, 03:03:32 PM »
Thanks for the reply!

I do indeed use the rpi-vc package, but now I checked them and in 13.x, it contains 23 libraries (in /usr/local/lib), including libvcsm, but in 14.x it only contains libbcm_host, libdebug_sym, libdtovl, libvchiq_arm and libvcos.
I can try to copy it from 13.x to see if it still works. I don't think libvcsm should be deprecated, in contrast to MMAL I don't know what it would be replaced with.
Though seeing how in this issue, VCSM had to be fixed for MMAL 64bit support, it does seem that VCSM and MMAL support is intrinsically linked. Which would be super unfortunate because I actually require VCSM+DMABUF even while using V4L2 instead of MMAL. So maybe it is "correct" that it's gone from aarch64, but I'm not sure about the 32bit OS yet. Maybe I'll check if the current 32Bit Rasberry Pi OS still has libvcsm.so.

EDIT: Can confirm, it doesn't, libraspberrypi installs libbcm_host.so but not mmal nor vcsm. Very unfortunate. Will try old libvcsm

As for the wireless crash, the device driver crashes and does not show up even when never connecting to any access point, so that's not it.
Boot once, let openssh create the host keys, reboot and dmesg has the crash in RSA key check, and wlan0 is not there. Maybe I am missing sha256sum or something similar as the issue suggests.
Alternatively, do you know of a way to prevent openssh from generating the RSA key on boot (or any key at all - can do manually)? Then it should respect that there's no RSA key and it should just work afaik.
Or maybe I'll just delete the RSA key after openssh starts and hope it's ok even when client wants to use RSA.
« Last Edit: April 16, 2024, 03:25:36 PM by zharr »

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
Re: piCore 14.1 (32 and 64 bit) release
« Reply #5 on: April 16, 2024, 04:10:27 PM »
as long as you save the keys, but running a backup, then they dont regenerate.  But as I said, that has nothing to do with wifi.

Offline zharr

  • Newbie
  • *
  • Posts: 29
Re: piCore 14.1 (32 and 64 bit) release
« Reply #6 on: April 16, 2024, 04:37:00 PM »
You're right, I made a wrong connection seeing rsa in the crash.
But I can confirm the wifi device driver still crashes every second boot, with no wifi connected, no openssh running, no nothing.
Bare system set up with wifi packages, no wifi-related commands in boot*.sh.
After boot I checked iwconfig as to whether wlan0 was there or not, then I've written dmesg to file and backed up the file.
Around half the time, the wifi device driver crashed.
1 good
2 crash
3 good
4 crash
5 good
6 crash
7 crash
8 good (no log + back up)
9 good (no log + back up)
10 crash

So it appears to be random and not dependant on any files I backed up, since between the 9th and 10th try nothing should've written to the SD card but it still flipped from a working wifi device to a crashing one.
I'll do more tests tomorrow, but I attached the first crash (second boot) dmesg log which includes the error stack:
Code: [Select]
[   11.118580] WARNING: CPU: 0 PID: 582 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x14c/0x174
...
[   11.120209] cfg80211: Problem loading in-kernel X.509 certificate (-22)
« Last Edit: April 16, 2024, 04:41:44 PM by zharr »

Online Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11221
Re: piCore 14.1 (32 and 64 bit) release
« Reply #7 on: April 16, 2024, 05:17:05 PM »
Hi zharr
Possibly a timing issue that's right on the edge.
Maybe the RNG isn't initializing fast enough?

A couple of threads on RNG:
https://forum.tinycorelinux.net/index.php/topic,26385.0.html
https://forum.tinycorelinux.net/index.php/topic,23917.0.html

Offline zharr

  • Newbie
  • *
  • Posts: 29
Re: piCore 14.1 (32 and 64 bit) release
« Reply #8 on: April 16, 2024, 05:30:36 PM »
Thanks, I'll look into that tomorrow.

But so far, I've tried to get vcsm to work on 14.x with some success by making a merged 13.x - 14.x rpi-vc (and rpi-vc-dev) version.
Sadly, the camera does not work anymore, but I have an emulation mode that uses VCSM buffers instead of camera frames (which were also allocated with VCSM just the same), and that does work on 14.1.

I can also confirm the same wifi driver crash does not seem to occur on that 14.1 frankenstein system, so far got wlan0 device working on every boot.

So now I just need to get /dev/camera0 to work and then I can switch to 14.x with old vcsm. I'll do that tomorrow along with an attempt to get rng fixed on 13.x

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
Re: piCore 14.1 (32 and 64 bit) release
« Reply #9 on: April 16, 2024, 07:56:37 PM »
Looking at that dmesg from your 13.x system, perhaps we never did fix that kernel.  Just upgrade to 14.1

But the old vc stuff is going away fast.  Raspi wants to get away from the closed source code.

Offline zharr

  • Newbie
  • *
  • Posts: 29
Re: piCore 14.1 (32 and 64 bit) release
« Reply #10 on: April 17, 2024, 02:33:11 AM »
Ok makes sense, will do.
Just FYI regarding vcsm:
Unfortunately there's a specific bug on the Pi Zero that prevents the TMU of the QPU to access the camera frames if they were supplied by V4L2 itself (even with MMAP and all those options, which SHOULD be equivalent to VCSM for all I know), and the only workaround I have is allocating the VCSM buffers myself and making V4L2 use them via DMABUF.
I may be able to allocate the buffers through the mailbox interface (not sure if they are fully equivalent to VCSM), but I don't think there's an interface to convert them to DMABUF without vcsm.
If you want to see some madness for fun, here's my debugging of that.
So I seem to have no choice right now but to use old vcsm code, because I need it.

Will do a minimal vcsm package and try if that still breaks the camera or if there is some external change needed to configure V4L2