Custom Mint-19.2 with Linuxcnc

More
22 Mar 2020 13:10 #161096 by cncbeagle
BeagleBrainz your 3/8 RTAI version runs fine on the PC I actually use on my hobby CNC machine and solves my original issue. This PC doubles as my garage general purpose PC. I was unable to get some other functions I use running on Wheezy. Everything runs fine on Mint 19. I am looking for a replacement for this PC and had considered the ASRock J4105 board I use in another application. This forum has helped me understand that is not a good choice for my simple parallel port machine.

I had looked at some Dell Optiplex PCs on Ebay which now seems a better path. My goal is to reduce the PCs footprint as well as a little boost in performance. Someday I may go the Mesa route but right now there is very little incentive.

Thank you for all your help.

John
The following user(s) said Thank You: BeagleBrainz

Please Log in or Create an account to join the conversation.

More
22 Mar 2020 14:10 #161108 by BeagleBrainz
If you can find an Asrock J3355B that might be the go. I use one myself and can confirm that it has a parallel port and will boot in legacy mode.
Apart from the advantage of the MESA card doing the step & direction and extra I\O is by choosing an Ethernet card it saves you the hassle of finding a PC or MB with a Parallel Port.
I have a “dumpster find” early Intel iMac that can run a RT_PREEMPT version of Mint. Not the most straight forward of installs but it is possible.
But now that I have the issue with the whole UEFI and single core I have to get to the bottom of it.

Please Log in or Create an account to join the conversation.

More
24 Mar 2020 01:17 #161304 by Bari
Replied by Bari on topic Custom Mint-19.2 with Linuxcnc
EFI is not enabled in the Kconfig for the RTAI kernel.

Please Log in or Create an account to join the conversation.

More
24 Mar 2020 04:09 #161318 by BeagleBrainz
Ok This is the situation.

The only variable in the 2 situations is the boot method selected via the setup of the computer. Absolutely nothing else is changed.

Situation A:
I go into the BIOS of my machine and select legacy boot only.
I select the USB stick to boot from.
Machine boots and I get the isolinux boot menu.
I choose the RTAI kernel to boot which is first selection and default.
The kernel and initrd are loaded vis isolinux.
Machine boots to a Live session and desktop is shown.
I can connect to my wireless net work and do all the usual things.
Running cat /proc/cpuinfo shows both cores.
Running latency histogram report both cores
Shutdown in the usual manner.

Situation B:
I go into the BIOS of my machine and select UEFI boot only.
I select the USB stick to boot from, same stick as before (actually as the HDD does not have a EFI partition the usb stick is all it can boot from)
Machine boots and I get the grub boot menu.
I choose the RTAI kernel to boot which is first selection and default.
The kernel and initrd are loaded vis grub. I am not trying to directly the kernel via UEFI, I am using a boot manager.
Machine boots to a Live session and desktop is shown.
I can connect to my wireless net work and do all the usual things.
Running cat /proc/cpuinfo shows only core.
Running latency histogram report both core.
Shutdown in the usual manner.

Now I know EFI is not enable in the config. I am not trying to directly the kernel via UEFI, I am using a boot manager.
I am not expecting to have any access to any EFI whilst the OS is running. I don't care about this.
What is causing legacy boot method to report 2 cores to the RTAI kernel and only a single via UEFI ?
When booting a vanilla kernel via either method 2 cores are reported.
When booting a RT_PREEMPT kernel via either method 2 cores are reported.

The images I created are based on a vanilla Mint 19.2 image and the only changes are the Linuxcnc being preinstalled and the relevant kernel being added, with some extra support packages. The initrd is changed from lz to gz compression, but there is no issue with loading the initrd, otherwise the affected kernel would not boot to the desktop.

From what I can see the main component that can be enabled in the kernel. (which has been disabled)

CONFIG_EFI_STUB—This option, accessible as Processor Type and Features -> EFI Runtime Service Support -> EFI Stub Support, is the critical feature that adds the EFI stub loader to the kernel. You must check this option if you're to use this feature.


Which means even if I tried the kernel would not boot via EFI directly. This is not what I'm trying to do. I want to find why only 1 core is either found or reported to linux kernel when choosing a UEFI boot and the kernel & initrd are loaded by grub.
Unfortunately I have only access to one UEFI bootable computer, the computer that runs my cnc machine can boot via UEFI but I can not access it at the moment. If I could it would help determine if it was a firmware issue with my T530 Thinkpad or if the same behaviour was seen on the cnc computer a kernel issue.

EFI is not enabled in the Kconfig for the RTAI kernel.


Seems a bit terse :( Either you haven't fully read my description or I haven't been clear enough and there has been a misunderstanding for whatever reasons us humans misunderstand each other.

As an experiment I replaced grub's bootx64.efi with a efi shell renamed to bootx64.efi just to see if the shell would load and that part of the onboard EFI implementation as ok. I did not try to boot from the shell. Later the correct file was copied to the USB stick to replace the previous one.

Please Log in or Create an account to join the conversation.

More
28 Mar 2020 06:09 #161780 by adamj12b
Hello BeagleBrainz,

First off, Fantastic work!! This really helps the community!

I installed your RTAI + Mate version here: forum.linuxcnc.org/9-installing-linuxcnc...cnc?start=140#159389 and think I may have found a solution that corrects the following 2 issues you have listed.

  • If screen doesn't show login prompt move the mouse in circles for a few seconds

  • Login screen issue is an entropy issue that shows up with fast fast machines and/or SSDs

  • My system is a J1900 processor with 8GB of DDR3 memory and SSD disk. It is very fast to boot and fit the symptoms perfectly. After s little research I found Haveged details here: community.linuxmint.com/software/view/haveged which maintains the entropy pool when there is not enough mouse/keyboard use to fill the pool. Thats why the mouse needs to be moved around, to fill the pool.

    This seems to have fixed the issue for me. Hope it can help someone else too!

    -Adam

    Please Log in or Create an account to join the conversation.

    More
    28 Mar 2020 06:49 #161782 by BeagleBrainz
    Cheers Adam

    Yeah I saw that a few weeks ago, never got around to researching it a great deal. If you reckon it works next update I'll add it to the list of installed packages.

    Thanks for the feedback, much appreciated
    Rob

    Please Log in or Create an account to join the conversation.

    More
    29 Mar 2020 01:46 #161902 by adamj12b
    Hi Rob,

    I have tested the fix of installing "haveged" in a VM instance and it did in-fact fix the entropy issue.

    Original boot was 300 seconds before "crng init done" showed up in dmesg. After installing haveged, the dmesg shows "crng init done" occuring around 6.5 seconds and the system instantly comes up with the login.

    I think this corrects the issue.

    -Adam
    The following user(s) said Thank You: tommylight, zack

    Please Log in or Create an account to join the conversation.

    More
    30 Mar 2020 20:43 #162141 by adamj12b
    Hi Rob,

    I was finishing up my configuration when I found that this image (19.2 Mate RTAI) crashes hard when launching LinuxCNC with a Mesa 6i25. I don't even get a kernel panic, it just locks up solid. I have tested this on the installed system and the live image with the same results. Nothing is even logged to kern.log so I have no idea why its dying.

    Im probably going to move back to the preempt image to get running but preempt latency was 76us while RTAI ws 11uS.

    -Adam

    Please Log in or Create an account to join the conversation.

    More
    30 Mar 2020 20:50 #162142 by andypugh

    adamj12b wrote: Im probably going to move back to the preempt image to get running but preempt latency was 76us while RTAI ws 11uS.


    If you are running a 6i25 then latency is almost irrelevant, 76µs is perfectly acceptable.

    Please Log in or Create an account to join the conversation.

    More
    30 Mar 2020 21:28 #162146 by BeagleBrainz
    That would be one for the kernel guys.
    Unfortunately I can’t do much testing with RTAI as I don’t have the hardware to work with it .

    Please Log in or Create an account to join the conversation.

    Time to create page: 0.150 seconds
    Powered by Kunena Forum