Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: bmarkus on November 10, 2019, 08:24:48 AM
-
First version of piCore-11.0 released. It is a very first alpha version based on 4.19.81 kernel and expected to work with all boards, including RPi4. There is a common, single SD card image however for convenience can be downloaded from all architecture specific directories:
http://tinycorelinux.net/11.x/armv6/test_releases/RPi/
http://tinycorelinux.net/11.x/armv7/test_releases/RPi/
http://tinycorelinux.net/11.x/armv7l/test_releases/RPi/
No TCZ's uploaded yet. If you need a kernel module, use the full module archive:
http://tinycorelinux.net/11.x/armv6/releases/RPi/src/kernel/
http://tinycorelinux.net/11.x/armv7/releases/RPi/src/kernel/
http://tinycorelinux.net/11.x/armv7l/releases/RPi/src/kernel/
-
Do you have any system outline information available?
I am wondering about things like a list of packages/libraries and their versions and what compiler settings used.
And a rather long list of questions below:
Is an X11 server available?
Is all code ARMv6 based?
Does the boot use init or systemd?
What is the boot process i.e. how does the thing bootstrap (what bootloader, how is kernel selected, initrd file, squashfs, ???
Finally any idea about running with the asus tinker board (I have run raspbian on tinkerboards simply by copying the raspbian root fs and some minor changes over a standard tinker os image), I am wondering what kernel options are required for a tinycore boot squashfs and also bootstrap files to load the kernel and set root partitions etc.
-
mung
in general I kindly advice to get familiar with previous versions of piCore and study repositories and read forum posts. piCore is not a generic distribution like Raspbian but a toolkit targeting mainly embedded applications, therefor X11 wqill come after the main CLI tools, servers, etc. All extensions built for armv6. piCore is a RPi variant of Tiny Core Linux with the same basic philosophy. No systemd at all.
I have never seen a tinkerboard, but if Raspbians run it, piCore can.
Take a Raspberry board, ply with it first to learn piCore.
Regards,
Béla
-
mung
in general I kindly advice to get familiar with previous versions of piCore and study repositories and read forum posts. piCore is not a generic distribution like Raspbian but a toolkit targeting mainly embedded applications, therefor X11 wqill come after the main CLI tools, servers, etc. All extensions built for armv6. piCore is a RPi variant of Tiny Core Linux with the same basic philosophy. No systemd at all.
I have never seen a tinkerboard, but if Raspbians run it, piCore can.
Take a Raspberry board, ply with it first to learn piCore.
Regards,
Béla
Thanks for reply, I could still do with some more info though I may try loading the image on a rpi this weekend I would rather have some details of system components you used before I try making tests.
I have tried to help you improve this by adding a half assed wiki addition that anyone interested could add information to:
http://wiki.tinycorelinux.net/picore:installation
I am hoping if I try your alpha image there will be option to cat /proc/config.gz ???
And I assume packages should be a simple: mount package.tcz package -t squashfs -o loop,ro
[EDIT]: Fixed code tags. Rich
-
Hi mung
Welcome to the forum. Just wanted to let you know, code tags get wrapped in [] , not <>.
-
hi Mung,
Have you read the "Into the Core" book yet?
http://tinycorelinux.net/book.html
This great little book explains the principles behind TinyCore and most of it applies to piCore.
The piCore boot partition closely resembles the standard Raspbian boot partition, so no need to document it as it will quickly be out-of-date. Just refer to Raspbian documentation.
regards
Greg
regards
Greg
-
I seem to have found a bug. I noticed I was seeing different behavior with and without the "showapps" bootcode. I traced it back to /usr/bin/tce-bootload, where the print statements with the flush keyword fail. I know that keyword is a fairly recent addition (docs say it was added in Python 3.3), and despite "sys.version" from micropython reporting 3.4.0, it does not recognize this keyword. Looked through their issues on GitHub and didn't see any about this, but I didn't dig too deep, nor did I confirm that any newer versions fix the problem.
The workaround is to remove the flush keywords from prints.
There is also a rogue color in the prints that never gets reset back to normal text, so the console was just in yellow until I reset the terminal.
I can only confirm these on the armv7l build.
There are also a number of Python warnings about comparison between byte and str that seem to be related to importing the tc module in general. Nothing causing actual problems as far as I can tell, though.
-
I have just had problems with some very old bit rotten code I thought I would try compile and fails on the alpha image.
I tried compile this from latestest tinkerboard armbian (https://www.armbian.com/tinkerboard/) but with a raspbian root filesystem as I sort of assumed from ( piCore boot partition closely resembles the standard Raspbian boot partition, so no need to document it) that raspbian would be compatible to do a tcz compile and some of the stuff worked but it seems there maybe some serious incompatiblities between libc-2.29.so on tc and raspbian libc-2.28.so.
I seem to get segfaults that do not occur on raspbian.
I messed around for a couple of hours then finally thought maybe its the libs that are the problem, (I wish I had thought of it first but did not as seemed a list of libs are not necessary)
Unfortunately I don't have time to try a dogfood compile.
Maybe another week I have some spare time.
-
/opt/shutdown.sh is also not executing on shutdown. Not sure if that is new/expected behavior or not. I'd like to add something to this script, though, so I am trying to think of a workaround that would make it work without a fix to the core and remaster.
-
Hi emanspeaks08
/usr/bin/exitcheck.sh calls /opt/shutdown.sh on the x86 version. I would expect piCore to do the same.
-
/opt/shutdown.sh is also not executing on shutdown. Not sure if that is new/expected behavior or not. I'd like to add something to this script, though, so I am trying to think of a workaround that would make it work without a fix to the core and remaster.
How do you shutdown the system, which command used?
-
I've tried with both halt and reboot, but neither are printing the echo statements/performing the commands I have put in the shutdown.sh script. If you can't recreate the issue, definitely let me know and I'll see if I can dig in further myself.
-
Hi emanspeaks
Check for /usr/bin/exitcheck.sh.
-
Hi emanspeaks
To reboot:
exitcheck.sh rebootTo turn the machine off:
exitcheck.sh poweroff
-
I've tried with both halt and reboot, but neither are printing the echo statements/performing the commands I have put in the shutdown.sh script. If you can't recreate the issue, definitely let me know and I'll see if I can dig in further myself.
halt/reboot are the original Linux commands. If you want backup, you must explicitly use TC's own backup script first or the script others adviced.
-
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!
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
so not sure is picore9 works on the pi4?
No, it doesn't.