piCore 17 Beta Releases

[Paul_123]

Team Tiny Core is pleased to announce that Tiny Core 17.0 Beta1 is available for public testing:

http://repo.tinycorelinux.net/17.x/armhf/release_candidates/RPi/
http://repo.tinycorelinux.net/17.x/aarch64/release_candidates/RPi/

This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

Since this is an beta cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.

We appreciate testing and feedback.

Changelog for 17.0 alpha1:
* kernel updated to 6.18.16
* glibc updated to 2.42
* gcc updated to 15.2.0
* binutils updated to 2.45.1
* e2fsprogs base libs/apps updated to 1.47.3
* util-linux base libs/apps updated to 2.41.2

Changes for alpha2:
* Adjust config.txt for the 32bit versions. For console HDMI support.  (The firmware framebuffer is pretty much useless anymore, this is a workaround to use the builtin kernel simple-fb)
* Include XDG_RUNTIME_DIR in .profile

Changes for Beta1:
* Upgrade to kernel 6.18.28 (Hopefully this is the kernel Raspi Releases with RaspiOS)

[Juanito]

piCore boots without problems, but the latest kernel module extensions are missing 🙂

[Juanito]

piCore64 also OK

[Paul_123]

I knew I was forgetting something.  I had them in my local staging area, but missed a few steps.   They are up now

[zharr]

Only did a quick test because some specifics of my programs broke, but I encountered no other issues I could attribute to piCore.

E.g. I need exclusive access to the 3D pipeline but the config.txt change (loading vc4-fkms-v3d) must have made the console render with the GPU/GPU, so even enabling the QPU failed. But even reverting that change, something is still submitting programs to the QPU / 3D pipeline, which prior versions didn't. lsmod shows no major differences except brcmfmac_cyw -> brcmfmac_wcc.
I don't suppose you might have an idea?

I'm not in a hurry to upgrade, though I did just encountered an issue with copy2fs.lst on 16 so I was hoping it might be fixed in 17.

[Paul_123]

I doubt you are going to be able to have exclusive access to the GPU anymore, without doing a baremetal.  The firmware configuration of the gpu is no longer supported.  Raspi says they didnot remove it from the firmware, but will not do anything about it if it’s broken.

The fkms overlay without the vc4 drivers loaded is a bandaid to force the kernel to configure the framebuffer for a console.  But to really use the gpu you will need the vc4-kms-v3d overlay, and the graphics kernel module extension.

There is a chance the made some recent changes without any notes.  I’ll be updating the kernel before I release the final version.

[zharr]

Thanks, seems indeed the legacy driver is no longer supported, and even without HDMI plugged in and nothing graphical being installed, there's something using the graphics hardware in the background for some reason. I'm not using the graphics drivers myself, just the mailbox, and occasionally write to the framebuffer from the CPU for debugging.
Anyway, seems I'll have to stick to 16.x indefinitely, it's been super stable anyway, and for an embedded device, that's all I need. Thanks!

[Paul_123]

Just curious.  What are you doing with the gpu?

[zharr]

Low-latency blob detection for tracking cameras of an optical tracking system. Essentially a coprocessor for a small, highly-specialised routine that maps very well to the QPU, written in assembly. Using the mailbox to submit these programs (the normal way) is very inflexible, blocks until all are executed, and is problematic if the QPU stalls. And since I plan to have a more advanced tiling & scheduling later, I just use the V3D registers directly to queue and wait for the programs. Hence any other program or driver interfacing with the V3D hardware will interfere. Was not a problem before, since again, I could just not load any graphics drivers.