[Machinekit] HM2 Clocking

[Cameron McQuinn]

Hi all,

I am looking to gain a better understanding of how the clocking for the 
Hostmot2 firmware works in mksocfpga. In the Vivado block diagram, the 
hostmot2_ip_wrap module has 3 clock ports: clklow, clkmed, and clkhigh. The TCL 
scripts to generate the Vivado projects all connect clklow and clkmed together. 
Clkmed and clklow connect to a 100MHz clock, and clkhigh connects to a 200MHz 
clock. Where did these numbers come from?

Also, in the PIN_X file for each configuration, each module has an 
associated clock tag. For instance, in PIN_ULTR_36.vhd, the PWM module has the 
ClockHighTag 
(https://github.com/machinekit/mksocfpga/blob/master/HW/VivadoProjects/avnet/ultra96/const/PIN_ULTR_36.vhd#L83).
 Is there some place in the HM2 code that defines what clock tag each module 
should have?

Thanks,
Cameron



-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/8b8a9aa3-d8c9-4266-9697-0ef62eca2f3bo%40googlegroups.com.

Re: [Machinekit] Travis CI builds of machinekit-cnc

[Cameron McQuinn]

Alright so I've been working on getting automated Docker container builds 
going, and I've run into a hiccup. As you mentioned, machinekit-cnc needs 
files from machinekit-hal to build, and the approach that I am taking to 
solve the problem is to build Docker containers for machinekit-cnc using 
the ones for machinekit-hal as a base, and installing the Debian packages 
generated from the mk-hal build into the mk-cnc containers. Here is where I 
run into a problem. The build needs header files that are provided by the 
machinekit-hal-dev package, which depends on machinekit-hal, but both 
packages provide /usr/bin/comp. When installing via apt-get install, apt 
detects that machinekit-hal-dev tries to overwrite /usr/bin/comp from 
machinekit-hal and aborts the install. This behavior can be mitigated for 
non sys_root environments by passing -o Dpkg::Options::="--force-overwrite" 
to apt. However, when those two packages are specified in a multistrap 
config, multistrap fails silently and does not install any of the 
machinekit packages.

I am not very familiar with Debian packaging, but noticed that the file 
debian/machinekit-hal.install in the mk-hal repo contains the 
line usr/bin/* which I assume sweeps up everything produced by the build 
under /usr/bin and puts it into the Debian package. Is there a way to 
exclude /usr/bin/comp from the machinekit-hal package so that we can 
install the machinekit-hal-dev package in multistrap systems?

You can follow along with what I have been doing at cmcquinn/machinekit-hal 
<https://github.com/cmcquinn/machinekit-hal> and cmcquinn/machinekit-cnc 
<https://github.com/cmcquinn/machinekit-cnc>.

Regards,
Cameron McQuinn

On Sunday, March 22, 2020 at 8:00:20 AM UTC-6, ce...@tuta.io wrote:
>
> Hi, 
> Mar 22, 2020, 03:09 by cameron...@gmail.com : 
>
> > What is the status of Travis CI builds for machinekit-cnc? I would love 
> to help get this going if needed. Let me know how I can help :) 
> > 
> The current status is that it is not working. And frankly have no idea if 
> it ever worked or was just left as a something from the original split into 
> separate repositories. I am currently trying to implement the CI/CD flow 
> based on Github Actions. (You can read about it here: 
> https://github.com/machinekit/machinekit-hal/issues/268 .) Main reason 
> for this is the higher limits for Open-Source project, it is simply in the 
> Github repository, so every fork will have it by default and Github will 
> store the artifacts for later download. 
>
> Of course, if somebody will implement Travis CI jobs, then that's good for 
> redundancy. 
>
> How I imagine it to work is following: The mk-cross-builder code was 
> integrated into Machinekit-HAL repository, so in given time some job will 
> build from it Debian images and store them in some repository (I am 
> thinking about Github Packages as it is directly connected to Github Git 
> repository and it is on one network with Github Actions workers). On this 
> will be constructed the Machinekit-HAL building and packaging. 
>
> Given that Machinekit-CNC needs for its build the Machinekit-HAL (some 
> info can be glanced from 
> https://github.com/machinekit/machinekit-cnc/pull/93 ), I was thinking 
> that Machinekit-CNC will add another onion layer to the Machinekit-HAL 
> created builder images with its own build dependencies and from this get 
> its own builder (or builder which will be capable of building both 
> Machinekit-HAL and Machinekit-CNC). 
>
> So what needs to be done is to rework the Debian packaging in 
> Machinekit-CNC ("debian" folder in root of the repository), build of the 
> specific Machinekit-CNC builder (so far it can just take the Machinekit-HAL 
> builder images from DockerHub) and the CI job. 
>
> If you have specific question, just ask. Here or on the Matrix chat. 
> Cern. 
>
> > 
> > Thanks, 
> > Cameron McQuinn 
> > 
> > -- 
> > website: http://www.machinekit.io blog: http://blog.machinekit.io 
> github: https://github.com/machinekit 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Machinekit" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to machi...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/machinekit/0bca17f7-2840-483a-9fc1-63b5a3e642fb%40googlegroups.com.
>  
>
> > 
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/d4a6d775-cb1c-4556-9cd2-807cbde080c7%40googlegroups.com.

[Machinekit] Travis CI builds of machinekit-cnc

[Cameron McQuinn]

What is the status of Travis CI builds for machinekit-cnc? I would love to help 
get this going if needed. Let me know how I can help :)

Thanks,
Cameron McQuinn

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/0bca17f7-2840-483a-9fc1-63b5a3e642fb%40googlegroups.com.

Re: [Machinekit] mklauncher "Can not find -sec DISPLAY -var INTRO_GRAPHIC"

[Cameron McQuinn]

Thanks for your help in pointing out the cause of the error. I changed back 
to kernel 4.9 and that fixed the issue.

Cameron

On Wednesday, August 8, 2018 at 1:38:19 AM UTC-6, Schooner wrote:
>
>
> On 08/08/18 03:43, Cameron McQuinn wrote: 
>
> ..was able to successfully start the config several months ago, 
> but I had to set the project aside for a while. When I returned, I 
> upgraded the kernel from 4.9 to 4.14, and upgraded machinekit and 
> QtQuickVcp to the latest versions, but didnt' change anything else. 
>
> The error in your title is consequential not causal. 
>
> The error is here. 
> I will leave those who know more about it to pinpoint what caused it.  I 
> would tend to suspect the kernel change and wonder if the firmware is 
> present or correct. 
> > Aug  8 02:01:24 socfpga rtapi:0: 4:rtapi_app:1890:user hm2_soc_ol: 
> soc_program_fpga 
> > Aug  8 02:01:24 socfpga rtapi:0: 4:rtapi_app:1890:user hm2_soc_ol: FPGA 
> overlay status: applied 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user hm2_soc_ol: 
> failed to map hm2-socfpga0 to /dev/uioX 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user hm2_soc_ol: 
> soc_mmap_fail hm2-socfpga0 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user hm2/foo: failed 
> to program fpga, aborting hm2_register 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user foo: 
> hm2_soc_ol_board fails HM2 registration 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user hm2_soc_ol: error 
> registering UIO driver: -22 
> > Aug  8 02:01:26 socfpga rtapi:0: hal_call_usrfunct(newinst,-- 
> config="firmware=zynq/dtbo/replicookie_7z020_ol.dtbo num_pwmgens=5 
> num_stepgens=5" debug=1 already_programmed=1) failed: -1 - Operation not 
> permitted 
> > Aug  8 02:01:26 socfpga rtapi:0: 1:rtapi_app:1890:user 
> hal_call_usrfunct(newinst,-- 
> config="firmware=zynq/dtbo/replicookie_7z020_ol.dtbo num_pwmgens=5 
> num_stepgens=5" debug=1 already_programmed=1) failed: -1 - Operation not 
> permitted 
> > Aug  8 02:01:26 socfpga msgd:0: hal_lib:1904:user halg_exit:293 HAL: 
> removing component 99 'halcmd1904' 
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] mklauncher "Can not find -sec DISPLAY -var INTRO_GRAPHIC"

[Cameron McQuinn]

Hi everyone,

I am trying to run a qtquickvcp-based config on my Snickerdoodle, but the 
launch fails. The linuxcnc_debug.txt file records the error "Can not find 
-sec DISPLAY -var INTRO_GRAPHIC". The config I am using is based of the 
ones created by MIchael Brown, and can be found in this 
 repo. I am trying to run the HAL 
Snickerdoodle config using the run.py python script. I am using the latest 
version of machinekit from the repo, and the latest version of QtQuickVcp 
compiled from source for armhf.

I was able to successfully start the config several months ago, but I had 
to set the project aside for a while. When I returned, I upgraded the 
kernel from 4.9 to 4.14, and upgraded machinekit and QtQuickVcp to the 
latest versions, but didnt' change anything else.

I have attached relevant log files, and am happy to provide more detail if 
necessary.

Thanks,
Cameron

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
Aug  8 02:01:22 socfpga msgd:0: startup pid=1885 flavor=rt-preempt rtlevel=5 
usrlevel=5 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  
version=v0.1~-~5d86a7e
Aug  8 02:01:22 socfpga msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc 
intrinsicslibwebsockets=2.0.3
Aug  8 02:01:22 socfpga msgd:0: configured: sha=5d86a7e
Aug  8 02:01:22 socfpga msgd:0: built:  Jul 24 2018 16:00:52 sha=5d86a7e
Aug  8 02:01:22 socfpga msgd:0: register_stuff: actual hostname as announced by 
avahi='socfpga.local'
Aug  8 02:01:22 socfpga msgd:0: zeroconf: registering: 'Log service on 
socfpga.local pid 1885'
Aug  8 02:01:22 socfpga rtapi:0: 2:rtapi_app:1890:user rtapi:0: cannot create 
core dumps - /proc/sys/fs/suid_dumpable contains 0
Aug  8 02:01:22 socfpga rtapi:0: 2:rtapi_app:1890:user you might have to run 
'echo 1 > /proc/sys/fs/suid_dumpable' as root to enable rtapi_app core dumps
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user rtapi.so default iparms: 
''
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user RTAPI:0  rt-preempt 
v0.1~-~5d86a7e init
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user rtapi: loaded from 
rtapi.so
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user hal_lib.so default 
iparms: ''
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user rtapi_app_main:195 HAL: 
initializing RT hal_lib support
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user halg_xinitfv:90 HAL: 
initializing component 'hal_lib' type=4 arg1=0 arg2=0/0x0
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user hal_heap_addmem:58 HAL: 
extending arena by 262144 bytes
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user halg_export_xfunctfv:85 
HAL: exporting function 'newinst' type 2 fp=0 owner=66
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user halg_export_xfunctfv:85 
HAL: exporting function 'delinst' type 2 fp=0 owner=66
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user halg_xinitfv:271 HAL: 
singleton component 'hal_lib' id=66 initialized
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user rtapi_app_main:199 HAL: 
RT hal_lib support initialized rc=66
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user hal_lib: loaded from 
hal_lib.so
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user accepting commands at 
ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a
Aug  8 02:01:23 socfpga rtapi:0: 3:rtapi_app:1890:user rtapi_app:0 ready 
flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-~5d86a7e
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user pid=1890 
flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-~5d86a7e
Aug  8 02:01:23 socfpga rtapi:0: 4:rtapi_app:1890:user pid=1890 
flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-~5d86a7e
Aug  8 02:01:23 socfpga msgd:0: zeroconf: registered 'Log service on 
socfpga.local pid 1885' _machinekit._tcp 49152 TXT 
"uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 
"instance=f2f28674-9aae-11e8-9c8a-c8fd19920861" "service=log" 
"dsn=tcp://socfpga.local:49152"
Aug  8 02:01:23 socfpga msgd:0: ulapi:1891:user _ulapi_init(): ulapi rt-preempt 
v0.1~-~5d86a7e loaded
Aug  8 02:01:23 socfpga msgd:0: ulapi:1891:user halg_xinitfv:271 HAL: singleton 
component 'hal_lib1891' id=70 initialized
Aug  8 02:01:23 socfpga msgd:0: hal_lib:1891:user --halcmd ping
Aug  8 02:01:23 socfpga msgd:0: hal_lib:1891:user halg_exit:293 HAL: removing 
component 72 'halcmd1891'
Aug  8 02:01:23 socfpga msgd:0: hal_lib:1891:user ulapi_hal_lib_cleanup:235 
HAL: lib_module_id=70
Aug  8 02:01:23 socfpga msgd:0: hal_lib:1891:user halg_exit:293 HAL: removing 
component 70 'hal_lib1891'
Aug  8 02:01:23 

[Machinekit] Re: Zynq uSD Image Generation

[Cameron McQuinn]

Hi Doc,

I also have a Snickerdoodle, and am working on getting Machinekit running 
on it. It still has a long ways to go before it is functional, but I am 
making progress. I wrote up some instructions for how I built my rootfs, 
and posted them in a gist 
. 
Hopefully my procedure is clear enough for you to follow.

Sometime in the next few days, I hopefully will find time to sit down and 
write a detailed forum post outline the current state of my efforts to get 
Machinekit fully up and running on Snickerdoodle, so I can get help from 
the community to overcome some problems I have run into.

Best,
Cameron

On Friday, February 16, 2018 at 4:43:30 PM UTC-7, Doc Cotton wrote:
>
> Hi Charles;
> I recently purchased one of these boards with the dual arm processor 
> hoping to use it for cnc control using machineKit. 
> https://www.crowdsupply.com/krtkl/snickerdoodle
> from the specs any thoughts on if it will work. Also linux has been ported 
> to the chip already.
> It might work for the zynq image generation?
> thanks
> Doc
>
>
> On Thursday, December 21, 2017 at 6:45:37 PM UTC-7, Charles Steinkuehler 
> wrote:
>>
>> Anyone got a recipe or scripts for generating a working Zynq uSD image 
>> that includes Machinekit?  I've got a (day-job) project that will be 
>> targeting a low-end Zynq board with HDMI in, and I'm thinking of using 
>> the Arty board: 
>>
>>
>> http://store.digilentinc.com/arty-a7-artix-7-fpga-development-board-for-makers-and-hobbyists/
>>  
>>
>> ...which has Arduino headers, meaning it would be pretty trivial to 
>> add some stepper driver to make a pan/tilt platform along with the 
>> video in. 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: RTAPI app terminates on startup

[Cameron McQuinn]

Automata,

To install the kernel modules to your rootfs image, you'll want to use 
`make modules_install`. For convenience, I added a script to my fork of the 
kernel sources to make installing kernel modules on a rootfs easier. Here 
is a link to the script: 
https://github.com/cmcquinn/snickerdoodle-linux/blob/master/install_kmod.sh. 
Copy the script into the root directory of your kernel sources, then run 
it. When you invoke it from the command line, after the name of the script, 
you should type the full path to your rootfs.

With regard to your question about what to do with .dts files, take a look 
at the Makefile I have attached to this post. I got it from extracting the 
socfpga-bit package found on deb.machinekit.io. I don't completely 
understand how this works, but the Makefile shows how it's done.

Cameron

On Friday, November 3, 2017 at 1:56:36 AM UTC-6, automata wrote:
>
> Hi Cameron,
>
> Thanks for your response. I will be trying the debian jessie rootfs image 
> you suggested.
>
> Can you provide any reference on how to copy the kernel modules from your 
> custom built kernel to the rootfs.
> The kernel I am using is the Xilinx linux-xlnx from petalinux17.02 with 
> the Preempt_rt patch.
>
> Awesome work on making the projects independent of Vivado version. Just 
> tried your repo with 2017.2. 
>
> So you have any pointers on making and deploying the device tree files. I 
> have been trying to understand it for the last two days but have not been 
> able to get anything going on the device tree front. Any pointers on what 
> to do with the .dts file generated from the 
> $carrier/$carrier$config_created/$carrier$config_ol.dts file? That file 
> essentially lists the AXI base address in the bitfile design.
>
> Thanks for the awesome work.
>
> Regards,
>
> -automata
>
> On Friday, November 3, 2017 at 1:23:34 AM UTC+5:30, Cameron McQuinn wrote:
>>
>> Hi automata,
>>
>> With regards to Linux, I have actually switched from using the ubuntu 
>> distribution provided by KRTKL to using a Debian Jessie image that I 
>> created myself using qemu-debootstrap. That way, I can just install the 
>> pre-built machinekit packages. I followed the instructions on the Debian 
>> wiki (
>> https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach),
>>  
>> and then installed the kernel modules for my custom-compiled kernel into 
>> the rootfs after debootstrap finished. I don't plan on trying to make this 
>> work on Ubuntu.
>>
>> Now to answer your question about Vivado versions. In the TCL scripts for 
>> the block diagrams, there is a section that includes the line `set 
>> scripts_vivado_version` which checks to make sure that the script is being 
>> run in the version of Vivado that generated it. If you remove that section, 
>> the script will run in any version of Vivado. The other issue is that 
>> Vivado versions after 2015.4 default to using what is called "out of 
>> context" builds for the IP, which causes problems when building the hm2 
>> firmware_id module because it tries to initialize from a file that lives in 
>> the project directory, not the IP directory. To fix this, you have to add 
>> some lines to the project template that force Vivado to use a global 
>> context when building the IPs. See this 
>> <https://github.com/cmcquinn/mksocfpga/pull/1> pull request in my 
>> personal fork of the mksocfpga repo for details.
>>
>> Let me know if you have any other questions.
>>
>> Good luck,
>> Cameron
>>
>> On Thursday, November 2, 2017 at 12:40:34 AM UTC-6, automata wrote:
>>>
>>> hi Cameron,
>>>
>>> I posted this on the snickerdoodle group by mistake. Reposting here as 
>>> the questions are mainly Machinekit related.
>>>
>>>  Repost
>>> I got the mksoc fpga project for Zturn to build on Vivado 2017.2. I have 
>>> also ported the project for Zedboard. I did this by peaking and poking at 
>>> the 2015.4 Vivado projects made by JD2 (Many thanks to the-snowwhite and 
>>> jd2).
>>>
>>> Though not being familiar with Xilinx tools or tcl, I dont know how to 
>>> generate the tcl project build scripts. I would like to try to get then 
>>> done with some guidance. My question is "Is there any plan to account for 
>>> the various versions of Vivado in the mksocfpga repository?" For each 
>>> Vivado version, do we require a new script to generate the IP wrappers and 
>>> other files?
>>>
>>> I compiled the mksocfpga bitfile and loaded it on the Zturn and Zed 
>>> bo

Re: [Machinekit] RTAPI app terminates on startup

[Cameron McQuinn]

Thanks for the tip, John. You were spot on. I check my kernel config and it 
turns out that CONFIG_PREEMPT_RT_FULL had been unset somehow. I reset that, 
re-compiled, installed the new kernel, and after rebooting, 
/sys/kernel/realtime showed up.

Cameron

On Thursday, November 2, 2017 at 8:06:25 PM UTC-6, John Morris wrote:
>
> Here's where we got that path in the first place: 
>
>  http://www.spinics.net/lists/linux-rt-users/msg09173.html 
>
> Perhaps things have changed in recent kernels, or perhaps you could 
> double-check (double-grep?) your kbuild configuration for 
> CONFIG_PREEMPT_RT? 
>
> John 
>
>
> On 11/02/2017 02:39 PM, Cameron McQuinn wrote: 
> > In order to avoid having to deal with compiling from source, I made a 
> > Debian Jessie rootfs using qemu-debootstrap, and got it up and running 
> > on my Snickerdoodle. I installed machinekit, and tried to start it, but 
> > got the same error messages, only this time without the stack smashing 
> > error. I took a look at `src/rtapi/rtapi_compat.*` like you suggested, 
> > and after splitting off `kernel_is_rtpreempt()` into a standalone test c 
> > program, I realized that my system does not have `/sys/kernel/realtime`, 
> > so `kernel_is_rtpreempt()` always returns 0. I am not sure why that file 
> > is missing, because I'm running a kernel that I patched and compiled 
> myself. 
> > 
> > Are there any other reliable ways to detect the rt_preempt kernel that I 
> > could try? I did not have a chance to try manually setting the flavor 
> > environment variable yet, but I will try that and see what happens. 
> > 
> > Cameron 
> > 
> > On Thursday, November 2, 2017 at 9:57:23 AM UTC-6, John Morris wrote: 
> > 
> > 
> > 
> > On 10/20/2017 12:51 PM, Cameron McQuinn wrote: 
> > [...] 
> >  > 
> >  > I managed to compile MachineKit from source, and am trying to 
> > start it 
> >  > using the 5i25-zynq configuration (I don't actually have a 
> > bitstream to 
> >  > program the FPGA yet, just trying to get MK running). Starting 
> > from the 
> >  > command line, MachineKit errors out because the rtapi app gets 
> >  > terminated due to "stack smashing". Output to from the terminal 
> > is as 
> >  > follows: 
> >  > 
> > [...] 
> >  > 
> >  > Interestingly, I have to "export FLAVOR=rt-preempt" in the shell 
> > before 
> >  > attempting to start machinekit, or else it tries to load 
> >  > rtapi_app_posix, which I did not compile. 
> > [...] 
> > 
> > I encountered these exact same two problems a few days ago with the 
> > amd64 Stretch packages, but can't for the life of me recall what the 
> > problem finally was.  I'm sorry to be so unhelpful here, but I'm 
> > self-flagellating my brain over it. 
> > 
> > I do remember I couldn't get a handle on the 'stack smashing' 
> problem, 
> > so I went with the flavor detection problem instead, and it took 
> > maybe a 
> > half hour to track down.  That stuff is all in and around 
> > `src/rtapi/rtapi_compat.*`.  It might have been one of those cases 
> > where 
> > there was an error somewhere along the way, but no error message and 
> > not 
> > handled.  Once I found it, I knew what the problem in my environment 
> > was 
> > and easily fixed it.  The 'stack smashing' thing just went away 
> after 
> > that, IIRC. 
> > 
> > Good luck, and please report back if/when you find it so it has a 
> > chance 
> > of being fixed for the next person. 
> > 
> >  John 
> > 
> > -- 
> > website: http://www.machinekit.io blog: http://blog.machinekit.io 
> > github: https://github.com/machinekit 
> > --- 
> > You received this message because you are subscribed to the Google 
> > Groups "Machinekit" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to machinekit+...@googlegroups.com  
> > <mailto:machinekit+unsubscr...@googlegroups.com >. 
> > Visit this group at https://groups.google.com/group/machinekit. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: RTAPI app terminates on startup

[Cameron McQuinn]

Hi automata,

With regards to Linux, I have actually switched from using the ubuntu 
distribution provided by KRTKL to using a Debian Jessie image that I 
created myself using qemu-debootstrap. That way, I can just install the 
pre-built machinekit packages. I followed the instructions on the Debian 
wiki (
https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach), 
and then installed the kernel modules for my custom-compiled kernel into 
the rootfs after debootstrap finished. I don't plan on trying to make this 
work on Ubuntu.

Now to answer your question about Vivado versions. In the TCL scripts for 
the block diagrams, there is a section that includes the line `set 
scripts_vivado_version` which checks to make sure that the script is being 
run in the version of Vivado that generated it. If you remove that section, 
the script will run in any version of Vivado. The other issue is that 
Vivado versions after 2015.4 default to using what is called "out of 
context" builds for the IP, which causes problems when building the hm2 
firmware_id module because it tries to initialize from a file that lives in 
the project directory, not the IP directory. To fix this, you have to add 
some lines to the project template that force Vivado to use a global 
context when building the IPs. See this 
<https://github.com/cmcquinn/mksocfpga/pull/1> pull request in my personal 
fork of the mksocfpga repo for details.

Let me know if you have any other questions.

Good luck,
Cameron

On Thursday, November 2, 2017 at 12:40:34 AM UTC-6, automata wrote:
>
> hi Cameron,
>
> I posted this on the snickerdoodle group by mistake. Reposting here as the 
> questions are mainly Machinekit related.
>
>  Repost
> I got the mksoc fpga project for Zturn to build on Vivado 2017.2. I have 
> also ported the project for Zedboard. I did this by peaking and poking at 
> the 2015.4 Vivado projects made by JD2 (Many thanks to the-snowwhite and 
> jd2).
>
> Though not being familiar with Xilinx tools or tcl, I dont know how to 
> generate the tcl project build scripts. I would like to try to get then 
> done with some guidance. My question is "Is there any plan to account for 
> the various versions of Vivado in the mksocfpga repository?" For each 
> Vivado version, do we require a new script to generate the IP wrappers and 
> other files?
>
> I compiled the mksocfpga bitfile and loaded it on the Zturn and Zed boards 
> with a bare metal application and was able to write to the various GPIO, 
> LEDs, and hm2_uarts using the memory map in the regmap. Need to try the 
> encoder and SPI components still. 
>
> I am stuck at the linux part. I compiled preempt RT version of the 
> petalinux kernel supplied by Xilinx. I have put up the instructions for 
> that here ( https://pastebin.com/Pk04f5At  )
>
> Using the instruction here ( 
> https://medium.com/developments-and-implementations-on-zynq-7000-ap/install-ubuntu-16-04-lts-on-zynq-zc702-using-petalinux-2016-4-e1da902eaff7
>  ) 
> I created an Ubuntu root file system image. The only change to the 
> instructions I made was which particular root file system to use and how to 
> generate the bit file. I used an Ubuntu 16.04.3 rootfs by rcn from here 
> https://rcn-ee.com/rootfs/2017-10-12/elinux/ubuntu-16.04.3-console-armhf-2017-10-12.tar.xz
>  which 
> includes a C compiler. 
>
> However, in this process I lost the ethernet connection on the Zturn 
> board. Ethernet works during uboot and u boot can get a dhcp IP. But after 
> the linux kernel boots it does not provide a wired networking interface. My 
> most likely guess is the device tree is not setup correctly.  I have been 
> reading about how to use device tree and get the ethernet port working on 
> the above system.
>
> Anyways, Using the C compiler, I compiled a dumb C application that can 
> write directly to the AXI memory mapped registers for the HM2  offsets in 
> regmap. Instructions on writing the C application here 
> 1. 
> http://fpga.org/2013/05/28/how-to-design-and-access-a-memory-mapped-device-part-two/
> 2. http://svenand.blogdrive.com/files/gpio-dev-mem-test.c
>
> From the hardware side, I have been able to use a logic analyser to test 
> the output signals.  I have also routed the Uart Rx to Uart Tx and read 
> back the data sent.  So I think hm2 fpga i.e.,  mksocfpga is working.
>
> Further I want to fall inline with the machinekit way of doing things. 
> i.e., use the mainline kernel and debian jessie or stretch filesystems and 
> U-boot-spl instead of Xilinx fsbl for the first stage boot loader. But, I 
> don't have a clue on how to go about this. 
>
> Any help and pointers are appreciated.
>
> Regards,
>
> -automata
>
> On Friday, October 20, 2017 at 11

Re: [Machinekit] RTAPI app terminates on startup

[Cameron McQuinn]

In order to avoid having to deal with compiling from source, I made a 
Debian Jessie rootfs using qemu-debootstrap, and got it up and running on 
my Snickerdoodle. I installed machinekit, and tried to start it, but got 
the same error messages, only this time without the stack smashing error. I 
took a look at `src/rtapi/rtapi_compat.*` like you suggested, and after 
splitting off `kernel_is_rtpreempt()` into a standalone test c program, I 
realized that my system does not have `/sys/kernel/realtime`, so 
`kernel_is_rtpreempt()` 
always returns 0. I am not sure why that file is missing, because I'm 
running a kernel that I patched and compiled myself.

Are there any other reliable ways to detect the rt_preempt kernel that I 
could try? I did not have a chance to try manually setting the flavor 
environment variable yet, but I will try that and see what happens.

Cameron

On Thursday, November 2, 2017 at 9:57:23 AM UTC-6, John Morris wrote:
>
>
>
> On 10/20/2017 12:51 PM, Cameron McQuinn wrote: 
> [...] 
> > 
> > I managed to compile MachineKit from source, and am trying to start it 
> > using the 5i25-zynq configuration (I don't actually have a bitstream to 
> > program the FPGA yet, just trying to get MK running). Starting from the 
> > command line, MachineKit errors out because the rtapi app gets 
> > terminated due to "stack smashing". Output to from the terminal is as 
> > follows: 
> > 
> [...] 
> > 
> > Interestingly, I have to "export FLAVOR=rt-preempt" in the shell before 
> > attempting to start machinekit, or else it tries to load 
> > rtapi_app_posix, which I did not compile. 
> [...] 
>
> I encountered these exact same two problems a few days ago with the 
> amd64 Stretch packages, but can't for the life of me recall what the 
> problem finally was.  I'm sorry to be so unhelpful here, but I'm 
> self-flagellating my brain over it. 
>
> I do remember I couldn't get a handle on the 'stack smashing' problem, 
> so I went with the flavor detection problem instead, and it took maybe a 
> half hour to track down.  That stuff is all in and around 
> `src/rtapi/rtapi_compat.*`.  It might have been one of those cases where 
> there was an error somewhere along the way, but no error message and not 
> handled.  Once I found it, I knew what the problem in my environment was 
> and easily fixed it.  The 'stack smashing' thing just went away after 
> that, IIRC. 
>
> Good luck, and please report back if/when you find it so it has a chance 
> of being fixed for the next person. 
>
> John 
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] RTAPI app terminates on startup

[Cameron McQuinn]

Hi everyone,

I am trying to get MachineKit running on a Snickerdoodle Black dev board 
from Krtkl. My goal is to eventually get mksocfpga running and build a 3D 
printer controlled remotely via MachineFace.

I managed to compile MachineKit from source, and am trying to start it 
using the 5i25-zynq configuration (I don't actually have a bitstream to 
program the FPGA yet, just trying to get MK running). Starting from the 
command line, MachineKit errors out because the rtapi app gets terminated 
due to "stack smashing". Output to from the terminal is as follows:

MACHINEKIT - 0.1
Machine configuration directory is 
'/home/snickerdoodle/machinekit/./configs/hm2-soc-stepper'
Machine configuration file is '5i25-zynq.ini'
Starting Machinekit...
*** stack smashing detected ***: rtapi:0 terminated
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

E: 17-10-20 11:16:04 dangling 'DEALER' socket created at 
hal/utils/halcmd_rtapiapp.cc:281
io started
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
E: 17-10-20 11:16:11 dangling 'DEALER' socket created at 
hal/utils/halcmd_rtapiapp.cc:281
halcmd loadusr io started
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

The lines starting with "halcmd:" are repeated until MK finally cleans 
everything up and quits.

Operating system is Ubuntu 16.04, running an rt_preempt kernel that I 
compiled from source. Running "uname -a" gives "Linux snickerdoodle 
4.9.0-rt1-snickerdoodle-68568-gfc719c0-dirty #1 SMP Tue Oct 10 19:54:36 MDT 
2017 armv7l armv7l armv7l GNU/Linux". Contents of linuxcnc.log are at 
https://pastebin.com/0UPpnCb7. Git log shows:
commit 15d5a3f6b1ac1760d3ec68c853b5c1e2e0101533
Merge: d88049e def2443
Author: Bas de Bruijn
Date:   Fri Oct 13 09:53:46 2017 +0200

Interestingly, I have to "export FLAVOR=rt-preempt" in the shell before 
attempting to start machinekit, or else it tries to load rtapi_app_posix, 
which I did not compile.

If anyone can point me towards a solution and help me get MachineKit 
running, I would be very grateful.

Thanks,
Cameron

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.