Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Final Releases => Topic started by: Paul_123 on June 15, 2025, 03:41:51 PM
-
Team Tiny Core is happy to announce the release of piCore-16.0. Both 32 and 64bit images are ready for download.
Changelog for 16.0.0:
* rpi-kernel and firmware 6.12.25
* glibc updated to 2.40
* gcc updated to 14.2.0
* binutils updated to 2.43.1
* e2fsprogs base libs/apps updated to 1.47.1
* util-linux base libs/apps updated to 2.40.2
* Micropython updated to 1.24.1
* OpenSSL updated to 3.4.1
* OpenSSH updated to 9.9p2 (DSA keys are no longer generated by default)
* CoreScripts updated to latest in git(piCore Branch).
* Removed Old module config file for 8192 driver.
* Update module config for rpi wireless (brcmfmac)
* Fix udev rules for proper serial console configuration.
* Updated udev rule for pi5 to not use cma.
* Added symlink from /lib/firmware -> /usr/local/lib/firmware
32bit - http://www.tinycorelinux.net/16.x/armhf/release/RPi/piCore-16.0.0.img.gz (http://www.tinycorelinux.net/16.x/armhf/release/RPi/piCore-16.0.0.img.gz) (This should run on all rpi boards)
- sha256: 92efe99b4e821a6a0c469b119db520d1e9347b04ad8c7f586614085ea7d25dd6 piCore-16.0.0-beta1.img.gz
64bit - http://www.tinycorelinux.net/16.x/aarch64/release/RPi/piCore64-16.0.0.img.gz (http://www.tinycorelinux.net/16.x/aarch64/release/RPi/piCore64-16.0.0.img.gz) (rpi zero2W, pi3, pi4, pi5)
- sha256: 797773e1c3228cf1ead52b736442becabb1bd20d6d560a6582d63d3892bbb478 piCore64-16.0.0.img.gz
Note: Image files are now just gzipped, you can just zcat the image if using dd to write your image, or some imaging tools support writing compressed images.
Note: When using 32bit images, the pi4 and pi5 will use a 64bit kernel. please make sure to look at uname if manually downloading kernel module extensions.
-
Seems something is broken with the wifi, packages and kernel modules appear to all load, but dmesg shows two failures that a prior 14.x image did not have (no 15.x dmesg log lying around, sorry):
[ 10.970348] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 10.970374] cfg80211: failed to load regulatory.db
[ 11.032375] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 11.038169] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 11.038318] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,model-zero-2-w.bin failed with error -2
[ 11.038395] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
[ 11.038732] usbcore: registered new interface driver brcmfmac
[ 12.043494] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50Edit: Forgot to mention, the symptom is the wlan0 device is missing. And thanks for the release!
-
Update your firmware packages. I change piCore16 to standardize firmware locations with Core.....(so we can share most firmware packages) I changed the piCore images in the release, but didn't realize the tce-load would not handle the symlink. I've fixed the common firmware files...
-
Thanks a bunch, now it works perfectly!
Will observe how it looks with wifi stability, even with the boot param, 15.x dropped a few packets, enough to freeze the ssh every once in a while. 16.x still drops packets at about the same rate (once every 2 seconds), but SSH feels solid, unlike 15.x. So idk if SSH just learned to cope with it better or the drops (as reported by ifconfig) are not relevant. No idea if 14.x had no dropped packets or if this is normal.
(also, I still have one bug across 13-16 left to fix but that's almost certainly specific to my program)
-
Links on this site are broken.
http://tinycorelinux.net/ports.html
http://tinycorelinux.net/16.x/aarch64/releases/RPi
http://tinycorelinux.net/16.x/aarch64/test_releases
http://tinycorelinux.net/16.x/armhf/releases/RPi
http://tinycorelinux.net/16.x/armhf/test_releases
-
Hi neonix
I think Paul_123 fixed the links:
http://tinycorelinux.net/16.x/aarch64/release/RPi
http://tinycorelinux.net/16.x/aarch64/release_candidates/RPi
http://tinycorelinux.net/16.x/armhf/release/RPi
http://tinycorelinux.net/16.x/armhf/release_candidates/RPi
-
Hi,
I've noticed a discrepancy between the arhmf and aarch64 releases in terms of SDL2 packages
The package names are inconsistent and there are fewer packages on armhf
AFAICT for release 16.x the aarch64 packages are
sdl2-dev.tcz
sdl2-image-dev.tcz
sdl2-image.tcz
sdl2-mixer-dev.tcz
sdl2-mixer.tcz
sdl2-net-dev.tcz
sdl2-net.tcz
sdl2.tcz
sdl2-ttf-dev.tcz
sdl2-ttf.tcz
and for armhf
SDL2-dev.tcz
SDL2_image-dev.tcz
SDL2_image.tcz
sdl2_mixer-dev.tcz
sdl2_mixer.tcz
SDL2.tcz
Please can we have the full set of packages for armhf with the same names as aarch64?
Many thanks.
-
posted
-
Looks like some consistency issues. Some extensions are capitalized SDL and others are lower case? Should we rename them all lower case?
-
If you could, that would be great :)
-
No problem, done
-
No problem, done
Thank you,
Keep well
-
Hi,
Thanks for the fixes,
sorry to be a pain, but some package names are slightly different between aarch64 and armhf.
Best expressed by this diff
$ diff /tmp/aarch64 /tmp/armhf
2,5c2,5
< sdl2-image-dev.tcz
< sdl2-image.tcz
< sdl2-mixer-dev.tcz
< sdl2-mixer.tcz
---
> sdl2_image-dev.tcz
> sdl2_image.tcz
> sdl2_mixer-dev.tcz
> sdl2_mixer.tcz
It would be useful if the package names are the same for aarch64 and armhf
Thanks for your help.
Keep well.
-
I looked at the repos, Looks like the sdl2_xxx is the pattern to standardize to. Should be resolved.
-
Thank you.
-
Hi Paul_123
You missed a couple:
aarch64
tinycorelinux/16.x/aarch64/tcz/sdl2-dev.tcz
tinycorelinux/16.x/aarch64/tcz/sdl3-dev.tcz
armhf
sdl2-dev.tcz
-
-dev are always -dev.
Same pattern as x86_64
-
Hi Paul_123
Sorry, my mistake.
-
Hi,
It appears that there is a bug touch screen handling in SDL2 in piCore.
For reference I'm using piCorePlayer 11.0-rc2.
The touch location reported in SDL events does not change after touching the screen, and no finger motion events are reported.
My test program yields this output even though I have moved my finger far away from the position i put my finger down before raising my finger off the screen
FDN: 0703, 0585 -> FDN: 0703, 0585
FUP: 0703, 0585 -> FUP: hit: 0675, 0525 0737, 0525
FUP: 0703, 0585
This indicates that the co-ordinates for the SDL_FINGERUP, event always match that of the preceding SDL_FINGERDOWN event.
And no events appear to be generated for SDL_FINGERMOTION.
This is the section of code producing that output, in a SDL_PollEvent loop.
case SDL_FINGERMOTION:
{
SDL_Point pt = {
.x = (int)(event.tfinger.x*screen_width),
.y = (int)(event.tfinger.y*screen_height)
};
translate_point(&pt);
input_printf("FMO: %04d, %04d\n", (int)(event.tfinger.x*screen_width), (int)(event.tfinger.y*screen_height));
bool selected = false;
for(widget* widget=view.list->tail.prev; widget != NULL; widget=widget->prev) {
if (widget->hidden) { continue;}
if (!selected) {
widget->focussed = SDL_PointInRect(&pt, &widget->input_rect) && (!widget->focus_disabled);
widget->highlight = widget->focussed;
selected = widget->highlight;
} else {
widget->focussed = false;
widget->highlight = false;
}
}
} break;
case SDL_FINGERDOWN:
{
input_printf("FDN: %04d, %04d -> ", (int)(event.tfinger.x*screen_width), (int)(event.tfinger.y*screen_height));
SDL_Point pt = {
.x = (int)(event.tfinger.x*screen_width),
.y = (int)(event.tfinger.y*screen_height)
};
translate_point(&pt);
bool selected = false;
for(widget* widget=view.list->tail.prev; widget != NULL; widget=widget->prev) {
if (widget->hidden) { continue;}
if (!selected) {
widget->focussed = SDL_PointInRect(&pt, &widget->input_rect) && (!widget->focus_disabled);
widget->highlight = widget->focussed;
widget->pressed = widget->focussed;
selected = widget->highlight;
} else {
widget->focussed = false;
widget->highlight = false;
widget->pressed = false;
}
}
input_printf("FDN: %04d, %04d\n", pt.x, pt.y);
} break;
case SDL_FINGERUP:
{
input_printf("FUP: %04d, %04d -> ", (int)(event.tfinger.x*screen_width), (int)(event.tfinger.y*screen_height));
SDL_Point pt = {
.x = (int)(event.tfinger.x*screen_width),
.y = (int)(event.tfinger.y*screen_height)
};
translate_point(&pt);
for(widget* widget=view.list->tail.prev; widget != NULL; widget=widget->prev) {
if (widget->hidden) { continue;}
widget->pressed = false;
if (SDL_PointInRect(&pt, &widget->input_rect) && widget->focussed) {
input_printf("FUP: hit: %04d, %04d %04d, %04d\n",
widget->input_rect.x, widget->input_rect.y,
widget->input_rect.x + widget->input_rect.w,
widget->input_rect.y, widget->input_rect.h
);
widget->focussed = false;
widget->highlight = widget->focussed;
widget_dispatch_action(widget);
} else {
widget->focussed = false;
widget->highlight = false;
}
}
input_printf("FUP: %04d, %04d\n", pt.x, pt.y);
} break;
-
What indications are there that this is an OS issue? If this is an SDL error, perhaps you will get more traction on the SDL forums.
Looking at github, there are issues around Mouse/Finger Motion and up/down events.
-
:o didn't think to look there :-[, I assumed that this "essential" feature was fully functional given that SDL3 is now current.
I'll have a dig and see if I can attach the touch screen to a linux x86 desktop and see what results I get there.
Thanks.
-
You may need to look at sdl3, since that is where most development is happening, and the raspi linux drivers are quite modern. I have a feeling that you are going to get major differences depending on if you using 1) standard linux frambuffer 2) Xorg 3) Wayland
There's a reason I've stayed away from graphics development as much as possible.
-
You may need to look at sdl3, since that is where most development is happening, and the raspi linux drivers are quite modern. I have a feeling that you are going to get major differences depending on if you using 1) standard linux frambuffer 2) Xorg 3) Wayland
There's a reason I've stayed away from graphics development as much as possible.
Hmmm.... I could only see a single component for sdl3 in the https://repo.picoreplayer.org/repo/16.x/aarch64/tcz/
libsdl3 and libsdl3-dev
AFAICT there should also be image and ttf components?
Am I missing something?
-
I'll take a look
-
sdl3_image and sdl3_ttf posted
-
sdl3_image and sdl3_ttf posted
Thank you very much!
I'll get down to porting port my code to SDL3 and give it a shot.
-
I'm seeing this with piCore-16.0 on an RPi3 B
Linux boxrpi3c 6.12.25-piCore-v7 #29 SMP Sat Apr 26 13:30:03 EDT 2025 armv7l GNU/Linux
[ 95.248489] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 95.334240] Loaded X.509 cert 'benh@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 95.336209] Loaded X.509 cert 'romain.perier@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 95.338149] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 95.340127] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 95.340316] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 95.340342] cfg80211: failed to load regulatory.db
[ 95.446720] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 95.459138] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 95.459321] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.bin failed with error -2
[ 95.459429] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
[ 95.459663] usbcore: registered new interface driver brcmfmac
[ 96.462735] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
..the firmware extension is the latest - is it a similar problem to the RPi0 reported earlier?
-
I’ll have to look, the firmware is a symlink mess from raspi. Do you have an updated regdb.tcz loaded?
-
Yes, I have the latest regdb
-
That is failing too, are you sure you aren’t still using the beta initrd which doesn’t have the symlink from /lib/firmware to /usr/local/lib/firmware
-
version reports 16.0, but yes, it's missing the symlink - when I add it things work :-[
-
I’ll start updating os-release as I do betas. I am just being lazy updating them once for each version
-
Been using 16.0 for a while now, and only now noticed ntp is broken...
ntp relies on the openssl-1.1.1 package, but it's not in its dependencies - libevent technically depends on openssh.tcz, but that does not pull in openssl-1.1.1 either.
So probably the issue is that libevent might actually rely on openssl-1.1.1 instead of openssl, I'm not sure, but without this package, ntpd can't load:
ntpd: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
One more thing, I just noticed openssh, openssl, and ca-certificates come preinstalled.
In my case, the way my setup scripts worked, it assumed them to be up-to-date, and so I was using outdated ca-certificates.
Already, there were a few CAs removed in the most up-to-date ca-certificates TCE.
Of course that might just be my scripts, but considering their nature, that might be a potential security issue.
Are they ever updated in standard operating conditions where packages are installed via tce-load?
-
Hi zharr
... it assumed them to be up-to-date, and so I was using outdated ca-certificates. ...
----- Snip -----
... Are they ever updated in standard operating conditions where packages are installed via tce-load?
When ca-certificates gets installed, tce-load executes:
/usr/local/tce.installed/ca-certificateswhich runs the script:
/usr/local/sbin/update-ca-certificates
-
ntp relies on the openssl-1.1.1 package
I'll look at recompiling it.
-
updated ntp posted - not tested
-
updated ntp posted - not tested
Thanks a lot, just tested, it works without openssl-1.1.1 now!
When ca-certificates gets installed, tce-load executes:
/usr/local/tce.installed/ca-certificateswhich runs the script:
/usr/local/sbin/update-ca-certificates
Ah missed that, makes sense. Thanks
-
updated ntp posted - not tested
Actually, nevermind, it did work initially, but there's a new error now:
daemon control: got EOFI'm not sure when or why this started, or why it worked at first.
I'll downgrade ntp for now and see over time if that also happens with openssl-1.1.1
EDIT: Nevermind, I might have a bad SD, will check again tomorrow.
-
I'd like to use busybox-httpd. I believe that the httpd module is not compiled into the busybox in 16.0. It is busybox config file available somewhere? I don't mind compiling - it would be a real help if I could start with the standard version, then just add the httpd module.
-
The extension is busybox-httpd.tcz The configs are in the 15.x release folders. Busybox did not get updated for 16.x
http://repo.tinycorelinux.net/15.x/aarch64/releases/RPi/src/busybox/