2 new DE0-Nano-SoC Kit ports missing Machinekit drivers and HDL interface code

[the-snowwhite]

opening comment moved here:

Initial CV-Socfpga HDL code is ready for testing here: https://github.com/the-snowwhite/mksoc

Binary output files can be put into a github release to bypass need for (self) Quartus compilation. (feed back / external verification needed...)

---

input for discussion of linking mksocfpga into machinekit via hostmot2 hal driver:

(I have tried to include all needed background information into the software and mk-notes folders in the mksoc repo:)

The mesa hdl code in the 1.st MkSocfpga release is included in the original provided unmodified 5i25 config version.

As to the MK software part it seemed most simple to initially provide a Avalon based uio driver interface structure, before going for something more fancy. (and redesigning the mesa sourcecode).

Hooking this uio interface into the Machinekit hostmot2 hal driver structure is providing some unexpected challanges, as to getting the auto configure part up and running:

1. the pci driver is probing and providing hardware info in this named steucture hm2_lowlevel_io_t *llio;:

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/hm2-export.c#L8

I would like to provide this (device-tree)info instead:

https://github.com/the-snowwhite/mksoc/tree/master/Software/Machinekit-Driver-notes/proc_device-tree-cats

1. the current hostmot2 autoprobe function seems to be tied into:

   static int hm2_pci_probe(struct pci_dev dev, const struct pci_device_id id) { }

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/hm2-export.c#L1608

A more generic pci less (uio inclusive) structural replacement / addition to this hostmot2 Hardware autoprobing part seems wishfull (dts based).

[mhaberler]

@the-snowwhite hm, looked at the links - but what is the open issue/deliverable?

[the-snowwhite]

I hope i understand your question correctly. (Ups I saw that subject line could be misleading, hope the correction is better) There has been a long outstanding (informal) discussion on creating a Machinekit port for the Altera Soc-Fpga platform beginning with the 100$ DE0-NANO / ATLAS dev board from Terasic in this (hijacked thread: https://groups.google.com/forum/?hl=en#!topic/machinekit/6Xv_g4Bzdvg

There has not until now been created a formal issue for completing this project so the work-log so far on this port is only on the hijacked misnamed google groups thread.

Both Charles and me got distracted by other things continuing towards getting a script up and running that could generate the sd-card image, and developing the (host2mot) interface between Machinekit into the fpga --> to drive the hardware pins, can interfaces etc.

There was talk about involving Robert N. for being able to have, downloadable images like for the BBB. And he is onto the subject now.

---

So the end (user) deliverable would be a downloadable Jessie, Machinekit image for the Nano board like the current BBB image.

Partial deliverables so far has been an attempt to make creating a new MK armhf based port easier, more transparent and more well documented.

And a fairly robust updated version of script(s) to run both the sd-card image generation +a generic one for installing a Rip Machinekit dev environment on (all ?)armhf based boards.

---

So the purpose of this issue is to pin the nano port subject and get it completed by. coordinating the collective efforts of getting the missing machinekit open source related soc-fpga code committed and available online in github.

[luminize]

Hi @the-snowwhite I think the biggest risk is that people can't follow. I'm really clueless regarding this, but also I don't have this specialised need. Meaning you'll and few others will be the champions. Now if you want this to succeed it's important that you form a group of people with who you can work towards a goal. So I'm not sure if I can do anything for you in this, other than some generic non-technical advice. But I guess that's not mandatory if you and the group you need can maintain focus and agree on small steps/deliverables to work towards that.

[RobertCNelson]

and if people are interested enough in it, i can generate *.img's right along side of the bbb machinekit image. The eewiki page is just the first step, for me to document how it was built.

BTW, right now the v4.4.0-rc5 locks up when the board goes idle, so there's lot of work to be done.

Regards,

[the-snowwhite]

Well there has been an initial image out for some time:

On Wednesday, August 26, 2015 at 12:47:31 AM UTC+2, Michael Brown wrote:

Thanks
Sockit + NANO bootable
Sd-Card image now downloadable online here:

https://drive.google.com/folderview?id=0BwyLvgyVIdi8fkdjU0xNVWJGb3JJOHFnN0dBaWV0ZDRjcEZrLXUwLWNJQm12c3pOS2V6QzQ&usp=sharing

Not very interesting for most until it actually can toggle some pins, however is available for developing, implementing and testing this port. The only new addition to the scripts I have made was to add the rootfs gen script.

• now every part / detail is now automated and customisable.

Not liking to have to reinvent the wheel: I really hope @cdsteinkuehler will provide me some scratch templates to get started on as he seems to own the concept of implementation and overview of what's needed, just not enough time:

I'm trying to follow up on this from the google group mailinglist:

 On Wednesday, September 9, 2015 at 2:16:13 AM UTC+2, Charles Steinkuehler wrote:

I've been crawling through the top-level hostmot2 VHDL code, and it's
probably not really all that hard to implement most anything.  I will
likely craft a minimal design for testing, but I _think_ it won't be
too hard to get both PWM and step/dir working (fingers crossed).

On Saturday, August 8, 2015 at 4:45:41 AM UTC+2, Charles Steinkuehler wrote:

I've been a bit behind on the open-source stuff this week (I've been
chasing a hardware glitch in the conversion from 64 to 128 bit PCIe
back-end that breaks bus-mastering DMA for my day-job), but I hope to
get my Nano board running this weekend.  I'll branch your github repo
and modify it to include the register readback stuff, which ought to
be (reasonably) simple to connect to the Mesa VHDL code.

[mhaberler]

@the-snowwhite - I think I get it now ;)

Very fruitful direction - the ARM SoC/FPGA platforms have the potential of giving great performance at low cost, and are one more nail in the coffin of soft-stepping and the "we need a base thread" hoopla

whatever you do, keep #687 in mind - meaning: having FPGA code being able to signal/interrupt a host CPU would be helpful downstream for best results

[darenschwenke]

They have some demo FPGA code doing PWM for this: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=238&No=994&PartNo=1

[cdsteinkuehler]

Example AXI register interface code is now online: https://github.com/cdsteinkuehler/AXI_Reg This is intended to be used with an soc_system defined in qsys, with the provided axi_conduit used to export an AXI bus from the qsys domain to the top-level, where it can be tied to registers (example in SoCKit_Reg.vhd) or eventually connected to a hostmot2 instance. I'll try to find some time in the next few days to actually get a chip compiled and tested.

[the-snowwhite]

:-) thanks Well I guess it's party time... Took a zip copy and will initially take a stab at migrating it to Quartus 15(0)(1) revisions I have running. Meanwhile I was able to make a fully working (machinekit installed) x86_64 cross build of the whole sd-card image, and managed to ssh in and do a latency test without problems.(just had to fix the locale) . The magic came into place by upgrading qemu and dependencies to the 2.5 SID version.

[mhaberler]

@the-snowwhite - curious: did you work off Demi's containers? if not, how?

[the-snowwhite]

@mhaberler hmm that would be a no as I have no idea of what Demi's containers is ?

The path that my intuition dragged me through was first this initial recipe as posted earlier:

Next crucial steps was this page providing very elegant and simple Debian Chroot description

that led me to using qemu-debootstrap.

the ArmHardFloatChroot page supported that notion and added the mount -t proc proc /proc thingie. However the: "create a /usr/sbin/policy-rc.d to prevent daemons from starting up inside the chroot." part I had to disable to get the mk-rip script to work.

last chroot scripting part was finding out that qemu-debootstrap had a --include= option, things could not get more simple...

the first time I ran the machinekit-rip-install-v2 script in the chroot I noticed that git clone got stuck.

Some google'ing revealed it was due to the outdated / old qemu version in jessie.

Next I found out that qemu2.5 just had been released finding this headline on Planet DebianQEMU 2.5 has just been released, [with a lot of new features](http://wiki.qemu.org/ChangeLog/2.5). As with the previous release, we have also created a [video changelog.](https://log.amitshah.net/2015/12/qemu-maintainer-interviews-for-the-2-5-release/).

More important qemu2.5 packages and dependencies are now in the Debian SID repos.

I then waded through the simple to describe (not so easy to do ?) process of manually uninstalling all the jessie qemu packages and installing the sid ones instead, the hard part here was to update all the necessary qemu2.5 depedencies. Without breaking apt-get functionality. notes and logs here.

I am convinced there is an easier and much more fail safe and elegant way of doing this (mostly scripted / automated), than my mindless tedious (time consuming) try (type), debug, fix (document) routine.

I'm still having trouble with the bind mounts (not able to unmount afterwards ..!), and still have to enter root password once or twice during mk install.

[the-snowwhite]

@cdsteinkuehler Just a short note to say DE0_Nano_Reg.qsf loads fine here and compiles following your steps with only one exception here: quartus 14.1 --> 15.1 ...! :-)

------------------------------------------------
Altera Embedded Command Shell

Version 15.1 [Build 185]
------------------------------------------------

on Jessie

[mhaberler]

@the-snowwhite @cdsteinkuehler - just noting there are several docker containers out there with Altera Quartus and the Xilinx toolchain

a docker container might be a good way to package the somewhat involved setup+build process for FPGA code

[the-snowwhite]

@mhaberler @cdsteinkuehler - there is now a full mesa 5i25 clone in the mksoc(fpga) iotest branch:

I'm able to access the mesa controller thru this code: (in the software folder)

// Open /dev/mem
    if ( ( fd = open ( "/dev/mem", ( O_RDWR | O_SYNC ) ) ) == -1 ) {
        printf ( "ERROR: could not open \"/dev/mem\"...\n" );
        return ( 1 );
    }
    printf("/dev/mem opened fine OK \n");

    // get virtual addr that maps to physical
    virtual_base = mmap( NULL, HW_REGS_SPAN, ( PROT_READ | PROT_WRITE ), MAP_SHARED, fd, HW_REGS_BASE);

    if ( virtual_base == MAP_FAILED ) {
        printf ( "ERROR: mmap() failed...\n" ); 
        close ( fd );
        return ( 1 );
    }
    printf("region mmap'ed  OK \n");

    // Get the address that maps to the LEDs
    h2p_lw_axi_mem_addr=virtual_base + ( ( unsigned long  )( ALT_LWFPGASLVS_OFST + HM2REG_IO_0_BASE ) & ( unsigned long)( HW_REGS_MASK ) );

.....

            value[j] = *((uint32_t *)(h2p_lw_axi_mem_addr + index+j));

and: ((uint32_t )(h2p_lw_axi_mem_addr + index+j)) = xxx...;

So what would be the most direct way to to give the new baby a quick spin ? (The system should see it as a "normal" mesa 5i25 card [without configure..])

BTW the makefile + dts-dtb(/rbf).sh file in script folder + u-boot env note.txt provide everything needed for the fpga test part...

[the-snowwhite]

and now to sleep zzzz....... :-)

[cdsteinkuehler]

On 1/20/2016 9:50 AM, Michael Brown wrote:

@mhaberler @cdsteinkuehler - there is now a full mesa 5i25 clone in the mksoc(fpga) iotest branch:

WOW Great news!

So what would be the most direct way to to give the new baby a quick spin ? (The system should see it as a "normal" mesa 5i25 card [without configure..])

If you review the hostmot2 driver, you will see the generic driver as well as an interface driver specific to the communications method used to "talk" to the FPGA (ie: hm2_pci.c, hm2_eth.c, hmt_7i42.c (lpt), etc). You just need to make a version of this file for the SoC that can talk to the FPGA register space. The rest of the drive should then read the configuration ROM from the FPGA and adjust itself accordingly.

See the "Architecture" section of the readme for an overview:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/mesa-hostmot2/README#L62-L83

Charles Steinkuehler charles@steinkuehler.net

[the-snowwhite]

@RobertCNelson the needed devicetree(socfpga.dtb) and fpga config file (socfpga.rbf) can be put online with short notice. (and also compiled with the free online quartus_lite 15.1 ) I'm still stuck with official 3.10-ltsi-rt kernel. Due to not being able to get networking to work with the mainline 4.15-ltsi-rt patched release. Experience an endless boot loop with the current build instructions you have online, and have not have time to test out swapping the kernel to the 4.15-rt patched version that does boot on this board...

@mhaberler @cdsteinkuehler I feel that coming from the perspective of hdl programming, makes me mess up what should be a simple task ?

https://github.com/machinekit/machinekit/pull/864/files

How hard should it be to replace a pci driver structure with an uio one ? BTW the mksoc project is finished, and some documentation effort has been made...

[the-snowwhite]

I have edited the top post to reflect current status. Document an comprehensive overview of the (hw) hdl project. And to formulate an inclusive strategy to get the last (software handoff) implementation process finished. :-)

[the-snowwhite]

@luminize I have been very aware of the " soup of un-comprehensiveness" cloaking this project. So I have given my best shot at describing the (now production ready) fpga project part in clear terms: Seen from hindsight.
https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/MESA-Source-Structure.md

Part 3. will be about how (and hopefully not so much why) to implement uio driver probing functionality into machinekit, that will auto-detect this and future implementations through the provided device-tree info..... and also handle things like (the known fro BBB) device-tree overlays.

Part 2. is something about the hostile inherited environment of old fashioned static un-flexible, non-reconfigurable hardware. Having imposed current software limitations, that need to be thought out towards being geared for more flexible dynamic on the fly reconfigurable devices. (this discussion I will try my best to ignore and get through by pointing towards working on part 3. (device-tree probing) which is strictly non-related to the mksoc hardware project and so needs a new separate issue, with a very crisp and clear workplan description as opposed to how this issue started out..! )

[cdsteinkuehler]

Yes, both the Mesa VHDL and driver code are pretty difficult to wrap your head around, but despite that (and the additional fact that the VHDL code differs from my personal style guidelines), it's actually very well put together and provides a LOT of flexibility. Now if we could just get Peter to use some form of version control! ;-)

[luminize]

@the-snowwhite I'm afraid I cannot help you other than support/tip you when you get to documenting. Like manpages and such.

You and Charles are the field experts :)

On 23 Jan 2016, at 21:32, Michael Brown notifications@github.com wrote:

@luminize I have been very aware of the " soup of un-comprehensiveness" cloaking this project. So I have given my best shot at describing the (now production ready) fpga project part in clear terms: Seen from hindsight.

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/MESA-Source-Structure.md

Part 3. will be about how (and hopefully not so much why) to implement uio driver probing functionality into machinekit, that will auto-detect this and future implementations through the provided device-tree info..... and also handle things like (the known fro BBB) device-tree overlays.

Part 2. is something about the hostile inherited environment of old fashioned static un-flexible, non-reconfigurable hardware. Having imposed current software limitations, that need to be thought out towards being geared for more flexible dynamic on the fly reconfigurable devices. (this discussion I will try my best to ignore and get through by pointing towards working on part 3. (device-tree probing) which is strictly non-related to the mksoc hardware project and so needs a new separate issue, with a very crisp and clear workplan description as opposed to how this issue started out..! )

— Reply to this email directly or view it on GitHub.

[unseenlaser]

Thanks Michael for the work so far , this is fantastic , iv'e been wrapping my head around the code too , but after reading your docs etc , it's made it so much easier to understand . i know your Pain ! LOL .

cant wait to hook a board ,

On 23 January 2016 at 20:33, Michael Brown notifications@github.com wrote:

@luminize https://github.com/luminize I have been very aware of the " soup of un-comprehensiveness" cloaking this project. So I have given my best shot at describing the (now production ready) fpga project part in clear terms: Seen from hindsight.

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/MESA-Source-Structure.md

Part 3. will be about how (and hopefully not so much why) to implement uio driver probing functionality into machinekit, that will auto-detect this and future implementations through the provided device-tree info..... and also handle things like (the known fro BBB) device-tree overlays.

Part 2. is something about the hostile inherited environment of old fashioned static un-flexible, non-reconfigurable hardware. Having imposed current software limitations, that need to be thought out towards being geared for more flexible dynamic on the fly reconfigurable devices. (this discussion I will try my best to ignore and get through by pointing towards working on part 3. (device-tree probing) which is strictly non-related to the mksoc hardware project and so needs a new separate issue, with a very crisp and clear workplan description as opposed to how this issue started out..! )

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/843#issuecomment-174219121 .

The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the RcTechnix network. RcTechnix will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.

RcTechnix reserves the right to monitor and record e-mail messages being sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring effective operation.

(c) RcTechnix

[the-snowwhite]

;-) very welcome ;-) thanks

On 24/01/16 14:38, Sarah Armstrong wrote:

Thanks Michael for the work so far , this is fantastic , iv'e been wrapping my head around the code too , but after reading your docs etc , it's made it so much easier to understand . i know your Pain ! LOL .

cant wait to hook a board ,

On 23 January 2016 at 20:33, Michael Brown notifications@github.com wrote:

@luminize https://github.com/luminize I have been very aware of the " soup of un-comprehensiveness" cloaking this project. So I have given my best shot at describing the (now production ready) fpga project part in clear terms: Seen from hindsight.

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/MESA-Source-Structure.md

Part 3. will be about how (and hopefully not so much why) to implement uio driver probing functionality into machinekit, that will auto-detect this and future implementations through the provided device-tree info..... and also handle things like (the known fro BBB) device-tree overlays.

Part 2. is something about the hostile inherited environment of old fashioned static un-flexible, non-reconfigurable hardware. Having imposed current software limitations, that need to be thought out towards being geared for more flexible dynamic on the fly reconfigurable devices. (this discussion I will try my best to ignore and get through by pointing towards working on part 3. (device-tree probing) which is strictly non-related to the mksoc hardware project and so needs a new separate issue, with a very crisp and clear workplan description as opposed to how this issue started out..! )

— Reply to this email directly or view it on GitHub

https://github.com/machinekit/machinekit/issues/843#issuecomment-174219121 .

The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the RcTechnix network. RcTechnix will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.

RcTechnix reserves the right to monitor and record e-mail messages being sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring effective operation.

(c) RcTechnix

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/843#issuecomment-174299055.

[the-snowwhite]

:-) Thanks enjoy ;-)

On 24/01/16 14:38, Sarah Armstrong wrote:

Thanks Michael for the work so far , this is fantastic , iv'e been wrapping my head around the code too , but after reading your docs etc , it's made it so much easier to understand . i know your Pain ! LOL .

cant wait to hook a board ,

On 23 January 2016 at 20:33, Michael Brown notifications@github.com wrote:

@luminize https://github.com/luminize I have been very aware of the " soup of un-comprehensiveness" cloaking this project. So I have given my best shot at describing the (now production ready) fpga project part in clear terms: Seen from hindsight.

https://github.com/the-snowwhite/mksoc/blob/master/Software/Machinekit-Driver-notes/MESA-Source-Structure.md

Part 3. will be about how (and hopefully not so much why) to implement uio driver probing functionality into machinekit, that will auto-detect this and future implementations through the provided device-tree info..... and also handle things like (the known fro BBB) device-tree overlays.

Part 2. is something about the hostile inherited environment of old fashioned static un-flexible, non-reconfigurable hardware. Having imposed current software limitations, that need to be thought out towards being geared for more flexible dynamic on the fly reconfigurable devices. (this discussion I will try my best to ignore and get through by pointing towards working on part 3. (device-tree probing) which is strictly non-related to the mksoc hardware project and so needs a new separate issue, with a very crisp and clear workplan description as opposed to how this issue started out..! )

— Reply to this email directly or view it on GitHub

https://github.com/machinekit/machinekit/issues/843#issuecomment-174219121 .

The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the RcTechnix network. RcTechnix will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.

RcTechnix reserves the right to monitor and record e-mail messages being sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring effective operation.

(c) RcTechnix

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/843#issuecomment-174299055.

[RobertCNelson]

@the-snowwhite even 4.5.0-rc1 randomly reboots. ;)

I think we are stuck with altera's git repo for awhile..

[the-snowwhite]

I was able to have some success with your roots and applying the official 4.15.17 ltsi.rt patch released December. Right until I tried enabling the uio generic irq module in the kernel and recompiled. This led to echo totally disappearing. I finally managed to reactivate the ethernet device only by reverting to altera repo version and using the dtb from the kernel folder on first boot,... ... Anyway since fpga manager is first due in 4,4 kernel not much seems to be lost,,, I had an accident (pci related) when I tried to hook into machinekit via device tree info detection and a uio driver pandant to the existing pci one in my. And was only able to convey my general idea before having to gear down and reboot / restituate. I will put forward the concrete solution purposal asap. On 25 Jan 2016 18:42, "Robert Nelson" notifications@github.com wrote:

@the-snowwhite https://github.com/the-snowwhite even 4.5.0-rc1 randomly reboots. ;)

I think we are stuck with altera's git repo for awhile..

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/843#issuecomment-174598716 .

[the-snowwhite]

It should be fairly easy and straight forward for someone else to setup the mesa driver and get it working with the information provided. https://github.com/machinekit/machinekit/issues/865

I hope the issue formulation is made well enough so that others now are able to step in and help get it up and running......

[the-snowwhite]

I have fixed the broken sd-image gen script in mksok repo so it provides a basic working jessie image with the kernel from altera's repo. Machinekit armhf jessie packages are available and instillation works on that image. hdl code is done, and final driver implementation moved out to separate issue. https://github.com/machinekit/machinekit/issues/865 So...