piCore-11.0alpha1a released

[emanspeaks]

Ah, thanks for the help. I really needed something hooked into the Linux commands, so I created a custom TCZ that overwrites the /etc/init.d/rc.shutdown script with one that calls my custom script first.

This particular workaround (making a new TCZ) won’t work for the bugs I mentioned previously regarding the Python stuff, though. Luckily I can work around the Python bugs in other ways.

Thanks for your work on this stuff! It is perfect for my Pi4 embedded project, and am glad there is a version that works for this Pi!

[mung]

I may get some time free this weekend and would like to try compile specific for picore-11 do you have details of the environment you used to compile picore or what packages are required to make a self compiling picore environment?

cross compiler?
or which raspberry pi dist ubuntu or other?? (I found building on raspbian buster fails with segfault when run on picore)
any compiler options or switches used?

[mung]

So I wasted some more time playing with this and realise it is too hard a problem for me to solve.

I have some thoughts:

my problem is probably not due to bad libs, I copied the raspbian 2.28 libs into the picore image and everything was the same(i.e. X runs but my code double free segfaults)
raspbian kernel does some weird things with vdso libs maybe?
I should have tried to save the /proc/config.gz
best way to get a working kernel maybe to grab the /proc/config.gz from raspbian then enable squashfs and initrd and recompile?
The problem maybe due to my code or not, its some old X codes that have not been changed in over 10 years and contain alot of old Xlib stuff from Xfree86 from over 20 years ago.

There is no problem running on raspbian buster or stretch. but picore is showing double frees and segfaults on loading pixmaps.

I doubt I will follow this up in the near future, I may check back in a month or two, but the problem is most probably due to my code if anyone suspects it is a picore kernel problem and have some tests/suggestions/information to offer I will give it a go when I come back to it.

[bmarkus]

Applications built for Raspbian usually do not run on piCore, not because of Kernel but the heavy dependency chain. piCore kernel is based on Raspbian kernel with very few changes required for piCore. Using a custem kernel wouldn't help in your case. The solution is to rebuild it in piCore.

[mung]

Applications built for Raspbian usually do not run on piCore, not because of Kernel but the heavy dependency chain. piCore kernel is based on Raspbian kernel with very few changes required for piCore. Using a custem kernel wouldn't help in your case. The solution is to rebuild it in piCore.

I really have no experience of compiling/debugging this stuff, but the Xserver I compiled on raspbian buster seems to run with no memory problems on picore11 but the X apps have problems with pixmap segfaults. They all only depend on the base C libs(pthread,crypt,z,util,m,c, and ld) raspbian also does some strange kernel vdso stuff for memory handling dependent on arch. I think the problems are due to the code I am compiling and maybe gcc is too strict or not strict enough in checking datatype?

When I copied across raspbian buster base libs into picore image everthing seemed to boot/run fine on a pi4 and a pi zero (using same initrd). I suppose you use seperate initrd to allow people to choose minimal required image but if a general image dist is created it would save repeated initrd image with only /lib/modules/?? being different (I think adding the 4 raspbian /lib/modules/ trees adds maybe 3Mb to initrd but allows any pi to boot from same initrd).

I am guessing I will not even be thinginig about the tinkerboard kernel for 6months, but there could possibly be simple option for adding second initrd mount for the /lib/modules/ kernel dependent (memory handling vdso link into kernel etc) that allow a general pi/ARMcore image for any ARM system.

I don't know if it is worth the extra effort though as superH maybe the prefered future platform for my application?

Anyways any advice.........

Is there a compile/install guide for picore (would 'tce-load -i compiletc squashfs-tools' be sufficient to compile C code and build a tcz?)

I am wondering what method is used/suggested for adding permanent storage and swap space for a picore dev environment.

Would a VM image for a dev environment be available/possible? this would allow everyone that wants to compile a tcz to be working from same environment.

[Juanito]

Is there a compile/install guide for picore (would 'tce-load -i compiletc squashfs-tools' be sufficient to compile C code and build a tcz?)

If you want to compile for piCore, it would be better to use the 9.x stable release. You can see examples of how to compile, for example, here:

http://tinycorelinux.net/9.x/armv7/tcz/src/geoclue/compile_geoclue

..there is also an extension making section in the wiki.

Most of the time on an RPi3 swap space is not required, but you can create a swap file if required.

[mung]

Is there a compile/install guide for picore (would 'tce-load -i compiletc squashfs-tools' be sufficient to compile C code and build a tcz?)

If you want to compile for piCore, it would be better to use the 9.x stable release. You can see examples of how to compile, for example, here:

http://tinycorelinux.net/9.x/armv7/tcz/src/geoclue/compile_geoclue

..there is also an extension making section in the wiki.

Most of the time on an RPi3 swap space is not required, but you can create a swap file if required.

Okay, thanks for advice Juanito

This stuff really is too much difficult and I am not sure what to do, I probably should follow your advice but I am not sure it is inline with the eventual goal of getting the picore image working on the tinkerboard and possibly beagle also. I have been testing on a pi4 and pizero so not sure is picore9 works on the pi4?

Tracking the 9 release for something that is probably due for later 2020 makes me worry there will end up more backporting.

I am also torn between using ARMBIAN or raspbian for the main dev environment and having to chase down dep conflicts.

Anyways I think maybe I discovered the problem could be due to the framebuffer depth defaulting to 16bits in picore and the app code only handles 32bits pixels so all the XcreateImage calls malloc wrong.

I did try editiing config.txt with  framebuffer_depth=32
But did not seem to change anything from segfaulting and showing 16bpp alloc.

I am probably wrong on that guess but its the best guess I have so far, unfortunately I am shelving this until I get some other stuff done.

Probably return to this when picore11 gets to beta or release.

[mung]

Yeah so I just had a thought that maybe fbset would work, and it did so there are probably no problems now, compiling on raspbian does not seem to have any problems, it was a compound fault due to picore having strange video config and the old codebase having very poor screen depth handling.

and also the cmdline(3).txt  and config.txt() options seem to have no effect on framebuffer.

I think I used fbset -xres 1280 -yres 720 -depth 32

Not sure which Xserver but its probably the last XFree86 release of kdrive with a few extra hacks which were done for some x86 hardware.

I can get on with other things, and maybe will return in a few months with some tinkerboard hacks (if things do not go too pear shaped).

[emanspeaks]

I can get on with other things, and maybe will return in a few months with some tinkerboard hacks (if things do not go too pear shaped).

I might recommend starting a new thread for your project if you continue down the path of porting this to other boards. It seems tangential to the piCore release discussion.

[bmarkus]

so not sure is picore9 works on the pi4?

No, it doesn't.