Tiny Core Base > piCore Final Releases

piCore 14.1 (32 and 64 bit) release

<< < (3/3)

zharr:
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

zharr:
Hey,
I've posted a lot about upgrading from 13.x, and it seems at least some system packets are compiled for armv8 from 14.x onward (tested rpi-vc.tcz, /usr/local/lib/libvcos.so, in both 14.x and 16.x) - even in the armv6 repository of 14.x, and of course the armhf repository of 16.x. This means, they won't work on the pi zero 1.3, which I still need to support.

Sadly, due to factors outside of piCore (namely, regression in camera stack, perhaps specific to the OV9281), I cannot upgrade to 16.x (and 15.x still has wifi stability issues), so for now I'm stuck on 14.x.

Would it be possible to fix these packaging issues for sad, old 14.x? I hope to be able to upgrade to 16.x in the future once the camera stack regression has been sorted out, but cannot for now.
Should you do another 14.x release (I know it's super old...), it'd also be great if you could include the i2c-mux drivers that broke third-party camera drivers if they're missing.
For now I'll try to ad-hoc a fix just like for i2c-mux by trying to patch in older armv6 kernel modules.
Thanks!

Paul_123:
rpi-vc was always supplied directly from raspberry pi’s repo.   It is obsolete at raspberry pi.  Everything that they still offer has been moved to other packages.

No we don’t go back and release old versions.

Just put the driver that in a extension

zharr:
The following command shows only the rpi-vc package is affected (of the packages installed on my development piCore 14.1 image)

--- Code: ---find /usr/local/bin -exec sh -c "readelf -A {} 2>&1 | grep 'Tag_CPU_arch: v8' ; if [[ \$? != 1 ]]; then echo {} ; fi" \;
--- End code ---

So I extracted subset of files that are still in the 14.x rpi-vc.tcz from the 13.x rpi-vc.tcz and loaded it ontop with a custom tcz.
Similarly ofc the two missing i2c-mux kernel modules (drivers/i2c/i2c-mux.ko and drivers/i2c/muxes/i2c-mux-pinctrl.ko), both v6 and v7.
And I'm happy to report it seems to work.


--- Quote from: Paul_123 on July 04, 2025, 01:43:58 PM ---rpi-vc was always supplied directly from raspberry pi’s repo.   It is obsolete at raspberry pi.  Everything that they still offer has been moved to other packages.

--- End quote ---
Technically... yes. Guess I'll have to rewrite a bit to get rid of all remaining legacy userspace code and use kernel drivers directly.

zharr:

--- Quote from: Paul_123 on July 04, 2025, 01:43:58 PM ---rpi-vc was always supplied directly from raspberry pi’s repo.   It is obsolete at raspberry pi.  Everything that they still offer has been moved to other packages.

--- End quote ---
Alright, so afaik the libraries and tools currently still in rpi-vc should still be supported, as they expose functionality that simply does not exist otherwise.
I've now gone ahead and reimplemented what I needed from them in my code (some ioctls and reading from device files), but I'm pretty sure this is NOT meant to be done in user code, but in these libraries.

Now I'm unsure if you mean that upstream raspberry pi compiled and distributed the binaries in rpi-vc, and if so, only did so for armv8, in which case, where did you get these binaries from?
Because I'd then bring that issue to raspberry pi themselves.
If you did compile it for piCore, then at least for 16.x I'd suggest to fix it. I'm not sure of the userbase of piCore but these tools are specifically useful for stuff close to hardware (e.g. HW accelerated computing for embedded devices) which I do believe piCore is a great match for (that's why I'm using it).

Navigation

[0] Message Index

[*] Previous page