Sunday, November 20, 2016

DE0-Nano-Soc update on SD card Images

In my last entry I mentioned problems with the new SD card image and my use of a previous image.

This has now been resolved.

There was what equated to a typo in the device name specified in the .ini file for the sample configuration.
(I say 'equated', because the name was deliberate, but when it was deprecated in favour of a common one across Altera and Zynq platforms, the sample config was not updated)
Thus anything based upon the sample, as mine was, did not work.

The image build system is in the process of being regenerated, once some other glitches are straightened out.

There is now an image with the repo as of 14/02/2017 here
It includes the multicore code, with the updated hm2_soc_ol driver and
it has a 512MB swap partition, which makes it easier to rebuild and use both cores without running out of memory.

In my last entry, I also advocated the use of gparted to extend the rootfs partition to use the available SD card space.

Having twice had failures using gparted to do just this with SD cards recently, I have hit upon a successful command line strategy.

The images consist of a 1M uboot partition and an approx 3.6G rootfs partition.
If we use the designations on my desktop (which has a lot of other disks), they
/dev/sdf1 uboot
/dev/sdf2 rootfs

Because there are no partitions after /dev/sdf2, it is possible to delete the partition, then create a new one starting at exactly the same sector, but encompassing the whole SD card.
Then we need to fix up the file system and expand it to the new partition size.

# check it is as you expect                                                                              
$ fdisk -l /dev/sdf                                                                                                
$ umount /dev/sdf2                                                                                             
$ fdisk /dev/sdf                                                                                                    
# command d to delete partition                                                                     
# select partition 2                                                                                          
# w to write to disc                                                                                         
$ fdisk /dev/sdf                                                                                                    
# n to add, primary partition, same start sector as before, select full size    
# w to write to disc                                                                                         
# now fix the file system                                                                                 
$ e2fsck -f -y /dev/sdf2                                                                                        
# resize the filesystem                                                                                     
$ resize2fs /dev/sdf2                                                                                           

Usual caveats apply, back up any data etc. but works fine for me with a card that gparted just hung for 10 mins and produced an error with.

If you create the rootfs partition slightly smaller than full disk size, you can go back into fdisk and create a 3rd partition, then format that as swap and enter it into the /etc/fstab file.

$ fdisk /dev/sdf

# n add primary partition number 3 use full size

# w to write to disc

$ mkswap /dev/sdf3

$ echo "UUID=<output-from-mkswap-here> none swap sw 0 0" >> /etc/fstab

Helps greatly if you are actually rebuilding machinekit in-situ.

Or you can use the swapfile method detailed in Michael's gist . 
Cat skinning methods are plentiful 😼

Friday, November 18, 2016

DE0-Nano_Soc and the DB25 interface board - real world testing

You will recall, that a while back, Charles Steinkuehler announced the completion of the initial work to get the DE0-Nano board running with machinekit and FPGA programmed to act as a Mesa 5i25 replacement

In the next stage, Charles designed a DB25 connected interface board, with pin-outs matching the P2 and P3 headers on a 5i25.

I finally got hold of one of these interface boards, courtesy of the surface mount component soldering skills of Bas de Bruijn.

There was a comparatively simple way for me to test its capabilities.
I already had a turret knee-mill in my workshop, that I had converted to Machinekit and which utilised a 5i25 and 7i76 Mesa combo.

I simply needed to unplug the DB25 lead from the 5i25 to 7i76 and connect instead to the interface board P2.
I was utilising an encoder on the 5i25 second header, so I connected this to the interface board P3.

  • First steps.

I already had a SD card image built by Michael Haberler to run the board and program the FPGA.

( These images are now deprecated, use: )

You will need package bmap-tools to write this to SD and verify.

Then use gparted to expand the second (rootfs) partition to the full size of the remaining space on the card.
You could also create a swap partition if space allows, then edit /etc/fstab to use this.

  • Setting up the image
Quite uniquely, the NIC does not have a preset MAC code and one has to be set
Michaels gist deals with how to do this, via a UART connection into something like CuteCom.
You need to enter any keystroke whilst in the first stage of boot, set the environment to include the MAC address and then trigger a reboot.

=> env default -a
## Resetting to default environment
=> setenv ethaddr ba:d0:4a:9c:4e:ce
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
=> reset

At the second boot you will get a terminal prompt,
default user is machinekit, password machinekit

Do a sudo apt-get update and install any extra packages you require, 
but do NOT apt-get upgrade if you are using this image, because there is a later one, and upgrading will overwrite its components and I could not get that one to work.

  • Running 
(This section assumes familiarity with 5i25 configs.)

The only changes I needed to make to my config for the mill were at the top of the ini and hal files

CONFIG="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo num_encoders=2 num_stepgens=4"


loadrt trivkins
loadrt tp
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES  tp=tp kins=trivkins
loadrt hostmot2 debug_idrom=1 debug_modules=1


NB. if you copy & paste from the sample config, note that tp=tp kins=trivkins is commented out in that config

The eagle eyed amongst you may have spotted that I specified encoders=2 in the config line

Each header on the 5i25 and thus the Nano, only has 4 stepgens and 1 encoder, what this does is effectively enable the second DB25 header output socket on Charles's interface board (equivalent to the header P2 on the 5i25) and the encoder.01 can be accessed from that.

I use the second encoder solely for a hardware pendant MPG on this mill, all the IO for the switches etc on that pendant go onto the 7i76 and are dealt with on the primary header. 

It really was as simple as that.

I ssh'd into the Nano from another computer, using X forwarding
(ie. ssh -X machinekit@192.168.1.XX
entered the /home/machinekit/machinekit directory which houses the pre-built RIP build.

Invoke `machinekit`, select the relevant config and it worked seamlessly, just as it had before.

This is a major achievement by Charles Steinkuehler, Michael Haberler, Michael Brown and Devin Hughes in particular.

Much kudos to them all.