Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: Fiddler on March 26, 2011, 06:27:48 AM
-
Robert,
First of all let me say thanks to you and all of your team members on providing the simplest and most powerful Linux I have worked with in all my experiments over the last year. The hard work and dedication of you and your team is greatly appreciated.
Basically, I have worked with many standard Linux distributions and the -rt patched kernel attempting to get the fastest and most consistent interrupt response to a PCI bus hardware event. This has been an effort for more than 1 year. After learning all the cpu isolation and irq balance techniques with the IOAPIC interface provided by the Linux kernel I decided to return to my roots and test what I had learned on the latest TinyCore 3.5.1.
It turns out that the standard TinyCore 3.5.1 kernel is faster and more consistent than all the rest I have tested. I took this long detour because TinyCore did not have a -rt patched kernel option for me to test. I made many attempts to rebuild and patch the kernel and failed miserably.
Bottom Line, I am working on an industrial application in which I would like to use TinyCore 3.5.1 with the -rt patch and see if I can improve the current 15 to 20 microsecond response I am currently obtaining. Could you or one of your team members help me with detailed instructions on how to apply the -rt patch and re-build TinyCore for the latest kernel?
Edit: Title change - RS
-
download patched kernel source and its config from
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/src/kernel/ (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/src/kernel/)
download latest rt (PREEMT RT) patch for tc kernel (it is currently 2.6.33.3) from kernel.org
extract sources
cd to linux
apply rt patch
cp kernel config to .config
make oldconfig
make menuconfig (if you want to make changes)
make bzImage
make modules
that's all to compile rt kernel for tc
after that you need to remaster tinycore.gz or microcore.gz with new modules
see remastering section at wiki (remastering and custom kernel)
http://wiki.tinycorelinux.com/ (http://wiki.tinycorelinux.com/)
-
the rt kernel is always a good thing, if that goes well I hope it be shared in some way :P
-
the rt kernel is always a good thing, if that goes well I hope it be shared in some way :P
What is an rt kernel, I asked myself, that Vinnie hopes Fiddler will one day share with us?
So I did the Google thing and found out that an rt kernel or its brother the RealTime kernel is a patched kernel that can be used on real-time system applications where CPU response time must be exactly known in advance. That is to say in a normal kernel the latency time for the CPU to respond is unknown in advance because it depends on the general load of the system at a given moment. This unknown latency time would be unacceptable in a real-time production environment where CPU responses must occur within strict delays. Hence the rt patches for an already configured distro kernel or the same patches to make a RealTime kernel from the kernel's vanilla sources.
The answer to my initial question was interesting to me and I thought that any other uninformed person like myself reading this thread might like to be clued in as well. Good luck to you Fiddler.
-
Next question, what is the negative impact of rt patch? Why Linux kernel's are not realtime by default?
BTW, this is a good starting point for the curious:
https://rt.wiki.kernel.org/
-
i remember some features from PREEMPT RT project is already imported to mainline linux tree
rt kernel is important for time critical applications such as a control application where you must calculate a control signal every sampling period, and the actual time when the signal is sampled is important for deterministic behaviour of the system
simple control application with just a proportional gain
e=x - xd
u=-k*e
x: system state
xd: desired state
e: error
k: proportional gain (>0)
u: control signal
http://en.wikipedia.org/wiki/Control_theory (http://en.wikipedia.org/wiki/Control_theory)
with a standart linux kernel you can not guarantee the deterministic behaviour of such systems, but with preempt rt kernel hard rt requirements gained with a latency of a few micro seconds
-
the production of music benefits much of a kernel rt, just create two labels in the syslinux with different kernel depending on what you want to do
-
Usually one loses throughput on a RT kernel, while gaining less latency.
-
Very understandable explanation curaga.
I take a little ot, If I had to do the procedure that I have expressed previously with microcore64.gz and bzImage64 (for example with label "core64" to boot) and pointing to the same ./tce directory, should work without problems (of course having a 64bit architecture), or I might have some problems with loading programs?
-
You might hit the module dependency issue - the KERNEL variable in dep files is replaced on download for the running kernel's version.
-
happy end :)
http://farm6.static.flickr.com/5094/5563588591_f1abb885be_b.jpg (http://farm6.static.flickr.com/5094/5563588591_f1abb885be_b.jpg)
-
;) great Arslan S.
@curaga: :o , in practice, though some programs in the repo have both 32bit and 64bit dependencies, during download the right ones are chosen, is correct?
but a 64bit architecture can start any 32bit software?
-
Yes, if you download say wireless-tools it will choose the right set of modules (32/64-bit).
The 64-bit MC can run all 32-bit software.
-
I think I understand: wireless-2.6.33.3-tinycore and wireless-2.6.33.3-tinycore64, or also alsa-modules-2.6.33.3-tinycore and alsa-modules-2.6.33.3-tinycore64 have tinycore/tinycore64 descriptor.
This is a nice dilemma, if one wants to reuse the same package.
If .dep is chosen to download and not dinamically assigned i think that the only way to save space is create a second folder ./tce for restore (example tce64) and aymlink all the packages that are not modules (and therefore do not contain *2.6.33.3*) in it.
Anyway, thanks for the clarification :)
-
Fiddler, Thanks for your kind words on our project.
As you can see, even when I am away for a day, that we have an amazing community of extremely knowledgeable individuals. Therefore It is always best not to direct a question or request to any one individual. I have taken the liberty to edit your topic removing "Hopefully, this Message and Request will be read by Robert Shingledecker" and changed to read "Tiny Core with Real Time Kernel?" That way it is more easily recognized what this topic is about. It will also more benefit others interested in this topic.
Thanks for your interest in our project.
-
ok i am eager to submit rt kernel and images according to
http://forum.tinycorelinux.net/index.php?topic=8923.0 (http://forum.tinycorelinux.net/index.php?topic=8923.0)
first i am going to create a project at gitorious, a build system which will output remastered tinycore, microcore images
second share the link to project
finally submit built images to be hosted by TC
as told in the link above i cannot use microcore or tinycore in built images and kernel
kernel will be named something like 2.6.33.3-l1-rt19
how about naming images ? is this fine ?
tinyrt.gz
micrort.gz
-
@Arslan
The cpio would only have the modules, not be a full remaster. This way it can be added fairly easily on many bootloaders, or included in a remaster with the many existing scripts.
There's no need to do a full remaster, and we would only host the module cpio, but if you want to do a remaster in addition, that's fine too.
edit: And of course, with a modules-only cpio, one can update TC without issue.
-
where to submit custom kernel and modules, tcesubmit ?
-
PM me where I can download them, and I'll upload the bzImage and modules cpio. The module extensions should go to tcesubmit.
-
Hi Guys,
I would like to explore the application of TC in a small machine control application.
Have a a real time TC kernel would be a great start.
I some one already has built one of these, would you mind sharing it so that I can experiment.
I do not have much lknowledge on how to build a kernel, so if someone has build as an extension that would be great for me.
Cheers
Peter.
-
http://distro.ibiblio.org/tinycorelinux/3.x/contrib/
-
Thanks Robert.
-
Ok.
I have downloaded the bzimage.rt and the cpio stuff.
Now what do I do with them?
I gather I simply set up my boot loader to use bzimage.rt instead of bzimage but what do I do with the cpio bit?
It is a .gz file. Do I somehow istall this in the tce directory?
Peter.
-
Practically speaking this may depend on capabilities of bootloader used.
Either add comma separated to 'initrd=' parameter or concatenate the additional cpio archives with those of base TC or MC.
This subject has been discussed in detail in more than one thread of this forum.
Also search wiki for "dynamic remaster", the priniciple of loading multiple initramfs's is the same ;)
-
I am still a bit lost.
I am a novice.
I am using Grub to boot.
I tried cat bzImage.rt rt-modules.cpio.gz >tinyrt.bz
I then changed my to kernel tinyrt.bz but it did not boot correctly.
Got stuck trying to load extensions and report earlier something about .....-rt19..... not found.
Clearly I am doing soething wrong.
-
Clearly.
You have to concatenate the cpio of original base (e.g. tinycore.gz) with optional cpio archives.
The kernel remains untouched.
Besides from that, this is really getting off-topic in regard to the thread, as it is about loading multiple initrd's regardless of a real time kernel.
-
Sorry if this was a little off topic.
(I thought the topic was Tiny Core with Real Time Kernel)????
But you helped me get the RT Tiny core up and going.
So what I did was substitute in the boot menu file (for grub):
bzImage.rt replaces bzImage
tinyRT.gz replaces tinycore.gz
(tinyRT.gz was simply created by cat tinycore.gz rt-modules.cpio.gz > tinyRT.gz)
Thanks.
;D
Peter.
-
Ok.
So now I have the real time version of TC up and going.
I have tested with a simple program and it appears that the real time parts are working, how ever the High Resolution Timers are not working as expected. They appear not to be enabled correctly??? The resolution defaults to 3.33ms which is too course for effective real time applications.
Is there some way to change this?
I would like the HRTs to be able to be used down to about 10us if that is possible.
Peter.
-
I'm not familiar with RT, but both HPET and high res timers are enabled in that config. Perhaps it's just a config toggle somewhere in /sys or /proc/sys.
-
It appears that the HRT resolution is tied to the value of a jiffie which is 1/300 second (based on HZ being set to 300 in the kernel of Tiny core. At least in the RT patched version anyway).
-
If so, then you wouldn't be able to get lower times than 1ms on any distro's RT kernel. 1000Hz is the max in linus' tree. Only Con's allows higher base timing than that, and even then many things break.
-
I am just reporting what I have observed. My CRO does not lie. I can not get a square wave out of the port pin that I am monitoring with a half period of less than 3.333ms. I am using a call to clock_nanosleep() to establish the port write delay. Even with a time set of only 50000 nanoseconds I still get a 3.333ms delay.
The rt-patch is definetely working as the wave form on the port pin is indeed square as I expect. If I resort back to the standard TC kernel then the wave form moves all over the place with system activity as I would expect.
There must be a setting in the rt-patch config files that have been used with TC (or in the original TC build itself) that establish these timing limits.
Does anyone know where these are and how to change them?
Peter.
-
It appears from some further investigation that my PC hardware is the problem. No HPET!!! The on board timer hardware is not of the appropriate type to support the higher resolution.
>:( >:( >:(
-
After I have worked with many Linux distributions (Debian, RedHat, SuSE, Finnix, Sidux, Slitaz - to mention some of them) and tried -rt patched kernel attempting to use Linux in real-time applications, I definitively attached to Tiny Core.
I must say many thanks to Robert and Team for their work. They gave us a clean and flexible platform which, among many other things, can effectively be used in solving the real-time problems.
At this occasion I would like to add some suggestions to help using a real-time kernel in the Tiny Core.
Very good support for preemptable rt-patched kernel can be found on the http://www.osadl.org/
Latest stable real-time kernel is 2.6.33.7 with 2.6.33.7.2-rt30 patch. As can be seen on this site, since kernel 2.6.39 - all real-time stuff will be included in mainline Linux .
Regarding 3.333ms problem, in a standard kernel config file CONFIG_HZ_1000=y option can be used, which will increase task repetition frequency to 1 kHz.
For experimenting with higher frequency tasks, "ck" patches available on the http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/ can be used. Those patches rise CONFIG_HZ up to 10000.
I have succsesfuly tried 2.6.39.1 with hz-raise_max.patch.
-
You may want to use set_rlimits!
-
Hi Guys,
After playing around a bit. It appears that Tiny Core with RT should do what I want, even if my hardware is limited to 3.33ms jiffie times. Yes I could change this, but it will be a bit of a compromise performance vs latency. The 3.33ms seems to work ok at present.
TC seems like a great little platform for embedded work.
Well done to all involved.
Peter.
-
happy end :)
http://farm6.static.flickr.com/5094/5563588591_f1abb885be_b.jpg (http://farm6.static.flickr.com/5094/5563588591_f1abb885be_b.jpg)
Hello
I have updated the kernel to full preempt rt, but according to tests, the kernel is not running in real time. Can you help me?
(https://preview.ibb.co/fRYEFJ/help.png)