PR #22 breaks usability of firmware package - cleanup needed

[mhaberler]

@the-snowwhite OK, now that #22 is merged, we need to finish the job, i.e. actually make it usable, because currently it is not:

• You chose to rename the firmware file to the (somewhat meaningless) 'DE0_NANO' - can I encourage to work with Charles on issue #9 and come up with a file naming scheme which transports some meaning? I need to have this resolved and know the results of this issue so I can make the necessary changes to packaging. We cannot continue to make up random names as we go along.
• the build process creates a lot of files:

jenkins@mah2:~/workspace/mksocfpga/HW/QuartusProjects/DE0_NANO_SOC_GHRD/output_files$ ls -lt
total 49768
-rw-r--r-- 1 root root  1544312 May 20 01:13 DE0_NANO.rbf
-rw-r--r-- 1 root root       25 May 20 01:13 DE0_NANO.done
-rw-r--r-- 1 root root    22335 May 20 01:13 DE0_NANO.flow.rpt
-rw-r--r-- 1 root root 11774721 May 20 01:13 DE0_NANO.sta.rpt
-rw-r--r-- 1 root root    11927 May 20 01:13 DE0_NANO.sta.summary
-rw-r--r-- 1 root root     4326 May 20 01:12 DE0_NANO.asm.rpt
-rw-r--r-- 1 root root  4724618 May 20 01:12 DE0_NANO.sof
-rw-r--r-- 1 root root    28385 May 20 01:12 DE0_NANO.jdi
-rw-r--r-- 1 root root      586 May 20 01:12 DE0_NANO.sld
-rw-r--r-- 1 root root  2080398 May 20 01:11 DE0_NANO.fit.rpt
-rw-r--r-- 1 root root      672 May 20 01:11 DE0_NANO.fit.summary
-rw-r--r-- 1 root root      681 May 20 01:11 DE0_NANO.fit.smsg
-rw-r--r-- 1 root root    79294 May 20 01:11 DE0_NANO.pin
-rw-r--r-- 1 root root  4545944 May 20 01:07 DE0_NANO.map.rpt
-rw-r--r-- 1 root root      511 May 20 01:07 DE0_NANO.map.summary
-rw-r--r-- 1 root root     5926 May 20 01:03 DE0_NANO.map.smsg
-rw-r--r-- 1 root root   646253 May 20 01:01 DE0_NANO.merge.rpt
-rw-r--r-- 1 root root      506 May 20 01:01 DE0_NANO.merge.summary

Which one of these should be included in the package? I assume (in the minimum) DE0_NANO.pin. Any others? please specify - somebody (i.e. me) will have to add those files.

• the previous package had a dts and a dtb file for the 3.10 kernel included. This build does not. Please explain if this build is supposed to work with the 3.10 kernel at all, or not. If yes - I guess this is https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/hm2reg_uio-irq.dts but the firmware pathname does not match the build artefact.
• If not, this does have implications: anybody using my current image with 3.10 and doing an update will get what? does she need to upgrade to the 4.1 kernel before? If this merge breaks compatibility please add a note to https://github.com/machinekit/machinekit/issues/915 and state what is required.
• the instructions in https://github.com/machinekit/mksocfpga/blob/master/docs/IRQ-mod_readme.md should be mutated into a postinst script which automate these steps at package install time.
• the note on dtc install can be deleted as it is superfluous - the kernels have a matching dtc packaged
• The reference to subversion does not make any sense to me?
• non-working command here: sudo dkms remove sudo dkms remove hm2reg_uio/0.0.2 --all
• it seems this firmware has a higher limit on the number of stepgens. What are the overall limits?
• this directory commits a binary and a .o file - can you remove it?
• same here - also, one of the two C files is superfluous - can you remove it?
• it is pointless to add machinekit configurations in this repository - they are not packaged, and they collect dust. If there is a working configuration, it should go into the machinekit repo, not this one, and refer to the matching firmware. Nobody looks here for configs.

[the-snowwhite]

First I have 2 commits: 1 . Cleaning up the SW/MK/mksocmemio and SW/MK/uio_irq_test/ folders. (I kept the binaries for now as it makes it easy to wget download and use these utilities after a chmod +x). I would expect the mksocmemio utility to end same place and just as available as the as the mesaflash utility. I don't know about the uio irq test utility.

2. Some error corrections in the irq-uio readme + a disclamier about the uio_pdrv_genirq driver not working with the current u-boots / kernels for the debian-8.4-machinekit-de0-armhf-2016-04-27-4gb.img sd-image.

I got this to work only by copying the rootfs onto my own sd-image (with more simple u-boot / kernel)

This is my 4.1 kernel patchset:

https://github.com/the-snowwhite/soc-image-buildscripts/blob/4.1-ltsi-rt/SD-Image-Gen/socfpga-4.1-ltsi-rt-changeset.patch

This is my u-boot 2016.03 patch:

https://github.com/the-snowwhite/soc-image-buildscripts/blob/4.1-ltsi-rt/SD-Image-Gen/u-boot-v2016.03-changeset.patch

[the-snowwhite]

You chose to rename the firmware file to the (somewhat meaningless) 'DE0_NANO' - can I encourage to work with Charles on issue #9 and come up with a file naming scheme which transports some meaning? I need to have this resolved and know the results of this issue so I can make the necessary changes to packaging. We cannot continue to make up random names as we go along.

As to keping current functionality (without irq's), the only difference is that the soc_system.rbf file is renamed to the lesser unspesific DE0_NANO.rbf in the DE0_NANO_SOC_GHRD quartus project folder. This is only the first logical step towards better binary file names.

The ones in the DE1_SOC_GHRD folder would the be named DE1_SOC.rbf, the ones in the

SoCkit_GHRD folder would then become SOCKIT.rbf

A small but important step forward following the:

DE0_Nano_SoC_DB25 example...

[the-snowwhite]

the build process creates a lot of files: Which one of these should be included in the package? I assume (in the minimum) DE0_NANO.pin. Any others? please specify - somebody (i.e. me) will have to add those files.

The pin file you are refering to is for the Altera Cyclone chip and has very little relevance for hostmot2 pinouts.

Interresting files could be:

.done --> only contains compile time/date: .flow.rpt --> compile options and some more info .asm.rpt --> compiled files (binary outputs)

[the-snowwhite]

the previous package had a dts and a dtb file for the 3.10 kernel included. This build does not. Please explain if this build is supposed to work with the 3.10 kernel at all, or not.

Yes works with your image on 3.10 kernel, only difference is that the binary .rbf output file is renamed to DE0_NANO.rbf, for all compilations made in the DE0_NANO_SOC_GHRD folder.

No new functionality . (period)

If yes - I guess this is https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/hm2reg_uio-irq.dts but the firmware pathname does not match the build artefact.

Nope this is a device tree overlay fragment meant for kernel 4.1+ Is totally unusable on the legacy 3.10 kernel. This is part of the Devicetree Framework, where loading the (compiled) device tree overlay fragment Automaticially loads the kernel built in default unmodified uio driver (uio_pdrv_genirq), And also is able to configure the fpga with a specified bitfile (.rbf). In one go.

[the-snowwhite]

NOTE: The interrupt / irq functionality can with great pain be ported back to work with the 3.10 kernel, I would instead recommend getting the omap-builder mksocfpga image online as the 4.1-ltsi-rt kernel and devicetree stuff now has become very much mature.

This was not the case when we decided to get the first image out ASAP.... (Back then 3.10 was the only solid option).

[the-snowwhite]

it seems this firmware has a higher limit on the number of stepgens. What are the overall limits?

The overall limit for any/all hostmot2 hdl core(s) is 64 (I read somewhere).

I may have bumped the number of stepgens from 8 --> 10 in the:

PIN_G540x2_34.vhd

Hardware config somewhere along the way.....

Only using some of the functionality in the hal config, does none or very minimal difference in the fpga.

[mhaberler]

you state in

set period to roughly 1ms (1kHz)
and enable timer 1 interrupt:
    sudo ./mksocmemio -w 7200 211812352
    sudo ./mksocmemio -w a00 2

can you explain how you arrive at the value 211812352 to get a 1mS period?

I need an expression, not a manifest value so the period can be configured by a module argument.

does http://freeby.mesanet.com/regmap DPLL base rate = (clocklow/2^DDSSize*DPLLPreScale)*BaseRateRegisterValue still apply?

[the-snowwhite]

I have not done that math.

On my first dso measurements I noticed that the high pulse was around the 1ms stated, however that gave a total dpll clock period at half the required base clock frequency of 1 Khz. So looking for a simple way to double the frequency I found this in same file:

0x7200 DPLLControlRegister0

Bits 0..23  On writes = PLimit (phase adjustment limit)
        On reads = Filtered Phase Error
Bits 24..31 DPLL Prescale

So reading the default dpll prescale value gives this:

machinekit@mksocfpga:~$ ./mksocmemio -r4 7200
    mksocfpgamemio: read write hm2 memory locatons by cmmandline arguments  
    /dev/uio0 opened fine OK 
    region mmap'ed  OK 
    mem pointer created OK
Program name: ./mksocmemio    input option = r 
Read only 
Address 29184   value = 0x19FFF141 

where the first to hex values give the (2x4bit) 8 Bits 24..31 DPLL Prescale value.

hex         dec
19           25
C            12
B            11

So I just changed this value until the Dpll clock period (on the dpll clock pin gipo[33])was as close to 1ms (1Khz) on my DSO.

and then converted the hex value back to decimal (the mksocmemio app only accepts decimal input values) 0x0C000000 converts to 211812352 in decimal.

So halving the prescale value gives double the frequency as expected.

[the-snowwhite]

About getting the irq stuff to work with your:

debian-8.4-machinekit-de0-armhf-2016-04-27-4gb.img

sd-image I'm facing 3 hurdles.

1. u-boot + uboot env variables prevent proper booting of 4.1 kernel (networking goes missing). (current workaround: install my own u-boot, and then reset u-boot environment variables to the default and save them).
2. The Machinekit rip install needs to be updated from git, and then recompiled to pull in the new hm2_soc_ol driver.
3. I still need to use the device-tree-compiler script to get hold of a working dtc compiler that builds the dtbo file without errors. (So how do I get the 4.1 kernel package to include the dtc binary ?)

[mhaberler]

let's stay on topic - this is about the current PR the image issue is https://github.com/machinekit/machinekit/issues/915

nobody EVER will find your comment here. Over at #915 it makes sense because other people will see it.