Thanks Cameron, I will try out your suggestions.
Regards, -automata On Sunday, November 12, 2017 at 5:28:49 AM UTC+5:30, Cameron McQuinn wrote: > > 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 >>>> 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:21:14 PM UTC+5:30, Cameron McQuinn >>>> wrote: >>>>> >>>>> 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 [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
