[Solved] Instructions on updating TinyCore 11 to Real Time?

[pditty]

I hope everyone is staying safe during the COVID-19 Pandemic.

I need to create a bootable iso image and wanted to ask if anyone had updated instructions for making TinyCore 11+ Real-Time or can help me figure out what I'm doing wrong.  I feel like I've looked at everything on the web regarding this topic but I still can't get it to boot into the gui.

I've looked at the RTAI link from 2016 http://j.bamiere.free.fr/RTAI/ModOp.htm#mozTocId601179.

Creating a custom tinycore kernel http://wiki.tinycorelinux.net/doku.php?id=wiki:custom_kernel

Remastering example https://github.com/elazarl/customize_tinycorelinux/blob/master/README.md

Another example here https://github.com/on-prem/tinycore-kernel/blob/master/Makefile

Creating Purpose TinyCore Images https://fabianstumpf.de/articles/tinycore_images.htm

Extract and Repack scripts https://github.com/elazarl/customize_tinycorelinux

Here is what I've been doing so far....

#1. Download the pre-patched 5.4.3 kernel from tinycore src/kernel directory
#2. Extract the kernel and then patch with the 5.4.3 rt patch using these instructions https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup
#3. Copy config-5.4.3-tinycore from the src/kernel directory to the extracted Linux-5.4.3 directory and rename to .config
#4. Run make oldconfig (selected #4 for Preempt and all other options were defaults)
#5. Run make bzImage
#6. Run make modules
#7. From tinycore distribution_files I downloaded the rootfs.gz file
#8. Extracted rootfs using 'zcat /tmp/rootfs.gz | sudo cpio -i -H newc -d'
#9. Ran make INSTALL_MOD_PATH=/<extracted rootfs>/lib/modules modules_install firmware_install
#10. Went into that <extracted rootfs>/lib/modules directory and created kernel.tclocal symlink to point to /usr/local/lib/modules/5.4.3-tinycore/kernel/
#11. Ran this command from <extracted rootfs>/lib/modules/<kernel name> "find . -name "*.ko" -exec gzip -9 '{}' \;"  to find and compress all the .ko files to .ko.gz
#12. Opened modules.dep, modules.builtin, and modules.order in a text editor and globally replaced all the .ko with .ko.gz extensions so they were referenced correctly.
#13. Compressed this rootfs by running "sudo sh -c "find . | cpio -o -H newc | gzip -2" > core.gz" at the root level
#14. Copied core.gz to the iso boot directory that was created when I ran tinycore-extract.sh found at https://github.com/elazarl/customize_tinycorelinux
#15. Copied bzImage from compiled Linux image in step #5 to the boot directory created from tinycore-extract.sh and renamed it vmlinuz
#16. Ran a modified script to build the iso.

#!/bin/bash
OUTPUTISO="tinycoreRT-04032020.iso"
ROOTFS="/home/me/TinyCore/test_04012020/initrd/core"
VOLUMEID="tinycoreRT-04032020"
BOOTARGS=""

TMPDIR="/home/me/TinyCore/test_04012020/iso"
chmod 755 "${TMPDIR}"


# alter isolinux config to use our changes
ISOLINUX_CFG="${TMPDIR}/boot/isolinux/isolinux.cfg"
sed -i 's/prompt 1/prompt 0/' "${ISOLINUX_CFG}"
sed -i "s/append/append cde ${BOOTARGS}/" "${ISOLINUX_CFG}"

# build a new iso
xorriso -as mkisofs -iso-level 3 -full-iso9660-filenames -volid "${VOLUMEID}" \
        -eltorito-boot boot/isolinux/isolinux.bin -boot-load-size 4 \
        -eltorito-catalog boot/isolinux/boot.cat -boot-info-table \
        -no-emul-boot -output "${OUTPUTISO}" "${TMPDIR}/"

[Juanito]

So you can boot to a console prompt?

[pditty]

Yes, I can.

[Juanito]

If you start Xvesa/Xfbdev/Xorg-7.7 as per the first line of .xsession do you get an error message?

[pditty]

It flashes so fast but this is what it says...

Booting Core 11.1
Running Linux Kernel 5.4.3-rt1-tinycore
Checking boot options... Done.
Starting udev daemon for hotplug support ... Done.
Scanning hard disk partitions to create /etc/fstab
Setting Language to C Done.
Possible swap partition(s) enabled.
Loading extensions...|

And then it kicks me to the command prompt.
tc@box:~$

Does that help at all?

[Juanito]

When you land at the command prompt, enter the fist line of .xsession as a command.

[pditty]

I entered.

Xvesa -br -screen 1024x768x32 -shadow -2button -mouse /dev/input/mice,5 -nolisten tcp -I > /dev/null 2>&1 &

And I get a black screen and can't do anything but power down.

[pditty]

Since I'm using the cde directory from the current image do I need to do anything with the copy2fs.lst and onboot.lst files?  They have references to .tcz files but if I created the kernel as well as the rootfs where would they even be?

[xor]

And I get a black screen and can't do anything but power down.

Are you sure you are using the right patch!

https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/

[Juanito]

Ah sorry, you needed to run "Xvesa -br -screen 1024x768x32 -shadow -2button -mouse /dev/input/mice,5 -nolisten tcp -I", but you could probably try "startx" first.

[curaga]

So it sounds like the system isn't even trying to start X, but at least Xvesa was available. Look into ~/.profile, see which condition fails.

[pditty]

How can I tell by looking at the .profile?  I don't see Xserver or text in my /etc/sysconfig directory, but should I?

Screenshot of my .profile is attached

[pditty]

I don't know if this helps, but I noticed that if I create an etc/sysconfig/Xserver file and put the string 'Xvesa' in it i can then run startx and it brings me to the TC blue screen (no icons) and the mouse doesn't work.  But it looks like its trying to do something.

[pditty]

Also, if I turn on syslog and compare my realtime build to the Tinycore-current.iso build this is what each of them look like.

Tinycore-current.iso
Apr 20 18:55:56 box authpriv.notic sudo:    tc : TTY=unknown ; PWD=/mnt/sr0/cde/optional ; USER=root ; COMMAND=/usr/local/bin/umount -d /mnt/test
Apr 20 18:55:56 box authpriv.notic sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/sh

Whereas on my real time build i get this..
Apr 20 19:05:10 box authpriv.notic sudo:    tc : TTY=unknown ; PWD=/mnt/sr0/cde/optional ; USER=root ; COMMAND=/usr/local/bin/umount -d /mnt/test
Apr 20 19:05:10 box daemon.info init: starting pid 812, tty '/dev/tty1': '/sbin/getty -nl /sbin/autologin 38400 tty1'

I don't ever see the real time version log in as root.

[xor]

 

Are you sure you are using the right patch!

https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/

https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.4/older/

patch-5.4.3-rt1.patch.gz                           17-Dec-2019 21:06    207K
patch-5.4.3-rt1.patch.sign                         17-Dec-2019 21:06     438
patch-5.4.3-rt1.patch.xz                           17-Dec-2019 21:06    170K

+Performance
+~~~~~~~~~~~
+Some basic tests were performed on a quad Intel(R) Xeon(R) CPU E5-2697 v4 at
+2.30GHz (36 cores / 72 threads). All tests involved writing a total of
+32,000,000 records at an average of 33 bytes each. Each writer was pinned to
+its own CPU and would write as fast as it could until a total of 32,000,000
+records were written. All tests involved 2 readers that were both pinned
+together to another CPU. Each reader would read as fast as it could and track
+how many of the 32,000,000 records it could read. All tests used a ring buffer
+of 16KB in size, which holds around 350 records (header + data for each
+entry).
+
+The only difference between the tests is the number of writers (and thus also
+the number of records per writer). As more writers are added, the time to
+write a record increases. This is because data pointers, modified via cmpxchg,
+and global data access in general become more contended.
+
+1 writer
+^^^^^^^^
+ runtime: 0m 18s
+ reader1: 16219900/32000000 (50%) records
+ reader2: 16141582/32000000 (50%) records
+
+2 writers
+^^^^^^^^^
+ runtime: 0m 32s
+ reader1: 16327957/32000000 (51%) records
+ reader2: 16313988/32000000 (50%) records
+
+4 writers
+^^^^^^^^^
+ runtime: 0m 42s
+ reader1: 16421642/32000000 (51%) records
+ reader2: 16417224/32000000 (51%) records
+
+8 writers
+^^^^^^^^^
+ runtime: 0m 43s
+ reader1: 16418300/32000000 (51%) records
+ reader2: 16432222/32000000 (51%) records
+
+16 writers
+^^^^^^^^^^
+ runtime: 0m 54s
+ reader1: 16539189/32000000 (51%) records
+ reader2: 16542711/32000000 (51%) records
+
+32 writers
+^^^^^^^^^^
+ runtime: 1m 13s
+ reader1: 16731808/32000000 (52%) records
+ reader2: 16735119/32000000 (52%) records
+
+Comments
+^^^^^^^^
+It is particularly interesting to compare/contrast the 1-writer and 32-writer
+tests. Despite the writing of the 32,000,000 records taking over 4 times
+longer, the readers (which perform no cmpxchg) were still unable to keep up.
+This shows that the memory contention between the increasing number of CPUs
+also has a dramatic effect on readers.
+
+It should also be noted that in all cases each reader was able to read >=50%
+of the records. This means that a single reader would have been able to keep
+up with the writer(s) in all cases, becoming slightly easier as more writers
+are added. This was the purpose of pinning 2 readers to 1 CPU: to observe how
+maximum reader performance changes.