possible aarch64 support

[ArcEye]

Issue by bjharper Sun Sep 3 03:34:00 2017 Originally opened as https://github.com/machinekit/machinekit/issues/1269

---

I have had some success compiling and running LinuxCNC on aarch64 (Ubuntu 16.04) using Realtime preempt 4.11 kernel but I am struggling a little with machine kit. I seems to always end up with an error looking for sys/io.h

Compiling machinetalk/support/sizes.c
In file included from rtapi/rtapi.h:1016:0,
                 from hal/lib/hal.h:126,
                 from ./emc/motion/motion.h:80,
                 from machinetalk/support/sizes.c:2:
rtapi/rtapi_io.h:39:43: fatal error: sys/io.h: No such file or directory
compilation terminated.
Makefile:420: recipe for target 'objects/machinetalk/support/sizes.o' failed

Basic steps is to install all dependencies then $ debian/configure -pr $ sudo mk-build-deps -ir $ cd src $ ./autogen.sh $ ./configure --with-rt-preempt --with-posix $ make -j2

Kernel im working with at the moment is development Realtime PREEEMT branch "'Linux odroid64 4.11.12-rt10 #6 SMP PREEMPT RT Sat Aug 26 17:27:03 AEST 2017 aarch64 aarch64 aarch64 GNU/Linux"

Im working on a HAL driver for the Odroid C2 and its GPIO pins so I dont know if I really need the io.h support in rtapi (no PCI interface ill be hitting GPIO registers directly hopefully) and if I need outb / inb functions then it looks like I could probably emulate them myself.

Looks like I will need to setup an aarch64 specific configuration in the machinekit source or maybe install for further dependencies for aarch64? Im compiling machinekit on an aarch64 platform also, no cross-compiling.

[the-snowwhite]

I can find the../sysdeps/aarch64/memcpy.S here: However I have no idea about how to get this source file into "play"... Or if it would be better to workaround the memcpy assem function and just use some sort of c pointer assignment ? (I'm very faint at understanding c pointers)

[the-snowwhite]

OK Success I found a workaround for the memcpy function and Now I'm able to do:

halrun
loadrt hostmot2
newinst hm2_soc_ol hm2-socfpga0 already_programmed=1 -- config="num_pwmgens=1 num_stepgens=1" debug=1

And exit again without any errors and the linuxcnc.log looks as its supposed to. Some of the commits on my arm64-work extension branch need to be refined (as I had to break some rules due to needing some obscured USERMODE_PCI flagged dependencies.

@zultron Do I understand correctly that you would prefer the aarch64 work to be introduced via your older arm64 branch instead of on top of the current official machinekit-hal repo ?

[zultron]

There seems to be some confusion as to whats aarch64 and whats armhf I initially thought the BBB X15(AI) was 64-bit however: the: BBAI is Cortex-A15 --> armv7,armhf toolchain The Ultra96 / Xilinx Zynq UltraScale+ MPSoC ZU3EG A484 is Cortex A53 --> ARMv8-A aarch64/arm64 toolchain.

This stil leaves TARGET_PLATFORM_BEAGLEBONE stuck to the 32-bit armhf and not aarch64 ? (the aarch64 toolchain thrown lots of errors about prubin.xxx unless these parts are disselected)

Ah, thanks for clearing that up. My confusion; I've also been playing with a RPi4. I reverted that change.

I also added TARGET_PLATFORM_SOCFPGA to the aarch64 build; is this desired? It will build the hm2_soc_ol and hostmot2 modules, and the mksocmemio executable.

@zultron Do I understand correctly that you would prefer the aarch64 work to be introduced via your older arm64 branch instead of on top of the current official machinekit-hal repo ?

No, that was an accident. I rebased onto the latest master and force-pushed the branch; take a look.

Ok so I worked thru applying the @zultron inb()/outb() fixes (plus some crude hacks for adding missing USERMODE_PCI dependable linuxcnc/userpc hostmot2.c requirements)

[...]

Some of the commits on my arm64-work extension branch need to be refined (as I had to break some rules due to needing some obscured USERMODE_PCI flagged dependencies.

I'm so sorry for anyone who has to touch this build system. My heart goes out to you. I cleaned up the USERMODE_PCI and packaging stuff in my commits e5cd27ac and fc648a3b.

Enabling USERMODE_PCI will also reintroduce the requirements for inb()/outb(), though, right? Sorry for my ignorant question: Why do you need USERMODE_PCI for the hm2 driver? Is the FPGA a PCI device on the Ultra96?

I also picked over your memcpy.S commit.

So take a look at my [branch]. I don't have time to test right now, but I'm hoping it contains everything your branch does.

We still need to figure out how to address the missing inb()/outb(), if mksocfpga does indeed require PCI support. We may have to implement an equivalent for ARM architectures.

[zultron]

Enabling USERMODE_PCI will also reintroduce the requirements for inb()/outb(), though, right? Sorry for my ignorant question: Why do you need USERMODE_PCI for the hm2 driver? Is the FPGA a PCI device on the Ultra96?

[...] We still need to figure out how to address the missing inb()/outb(), if mksocfpga does indeed require PCI support. We may have to implement an equivalent for ARM architectures.

Here is the related failure in my Travis CI instance.

So the question that still stands, is USERMODE_PCI required for Ultra96 support, and if so, any ideas for implementing inb()/outb() replacements?

[the-snowwhite]

I would rather introduce a new global variable: HAS_FPGA (or HAS_SOC_FPGA) than revert to using USERMODE_PCI. (this will reintroduce too much unneeded stuff)

The usermode_pci requirement only (AFAIK) blocks 3 HAS_FPGA needed files these ones here: rtapi/userpci/device.o \  rtapi/userpci/firmware.o \  rtapi/userpci/string.o In the (top) src/Makefile their folder is included before the (local) BUILD_HOSTMOT2 variable is introduced and the BUILD_HOSTMOT2 variable also doesn't reach into the folder of the last 3 needed files for the device-tree probing stuff. In the (top) src/Makefile it is perhaps possible to move these 2 constructs down to below the point where the BUILD_HOSTMOT2 variable is introduced and set. This only leaves the problem with getting a variable in place (HAS_FPGA ?) that like the (Global ?) USERMODE_PCI can reach into this Submakefile with a construct like:

ifeq ($(USERMODE_PCI):$(HAS_FPGA),yes)

or straight:

ifeq ($(HAS_FPGA),yes)

The HAS_FPGA variable could also be used to get out of tying the FPGA stuff to cpu architectures..

[the-snowwhite]

Having said all that... Images come to my mind that (low cost) arm(64) socs are beginning to have pci support, so this is probably needing to be fixed.. upstream (rather now than later ?). Perhaps someone has an Idea of how inb()/outb() and (the missing) memcpy are handled nowadays with armsocs that have pci support ?

[the-snowwhite]

@zultron On testing your latest branch only 1 commit is missing:

---

first half of this one diff is below

diff --git a/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c b/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c
index bad9b90fa..b2fafacee 100644
--- a/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c
+++ b/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c
@@ -603,7 +603,7 @@ static int instantiate(const int argc, char* const *argv)
        nread = read(fd, blob, st.st_size);
        if (nread != st.st_size) {
            LL_ERR("reading '%s': expected %zu got %u - %s\n", brd->descriptor,
-                (unsigned) st.st_size, nread, strerror(errno));
+                (size_t) st.st_size, (unsigned) nread, strerror(errno));
            return -EINVAL;
        }
        close(fd);

This fix also compiles on the current (non arm64) dovetailautomata armhf docker

---

As for the missing inb()/outb() I've settled on keeping the USERMODE_PCI flag and including the @ArcEye provided sys/io.h file (only) in the arm64 docker build images like in this commit:

[the-snowwhite]

OK @zultron I took a (actually some) shot(s) at building machinekit-cnc arm64 debs and finally arrived at something installable and able to successfully run axis gui sim (I/O testing will follow tomorrow as its really late here now). Actual commits are in this branch. :-)

[the-snowwhite]

@zultron My (c code) workaround for the missing memcpy.S is only able to read pins not write. Digging further I found out the the memcpy function comes via: libglibc and is included in the aarch64 glib package:

machinekit@mksocfpga-ultra96-soc:~$ nm -D /lib/aarch64-linux-gnu/libglib-2.0.so.0 | grep memcpy
             U memcpy
             U __memcpy_chk

These last lines of my aarch64 package build are perhaps an indication of a libglibc link error:

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/machinekit-hal-posix/usr/libexec/linuxcnc/rtapi_msgd was not linked against libatomic.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/machinekit-hal-posix/usr/bin/hy_vfd debian/machinekit-hal-posix/usr/bin/gs2_vfd were not linked against libglib-2.0.so.0 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/machinekit-hal-rt-preempt/usr/bin/gs2_vfd debian/machinekit-hal-rt-preempt/usr/bin/hy_vfd were not linked against libglib-2.0.so.0 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/machinekit-hal-rt-preempt/usr/libexec/linuxcnc/rtapi_msgd was not linked against libatomic.so.1 (it uses none of the library's symbols)
dh_gencontrol
dpkg-gencontrol: warning: package machinekit-hal-posix: unused substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: package machinekit-hal-posix: unused substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: package machinekit-hal-rt-preempt: unused substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: package machinekit-hal-rt-preempt: unused substitution variable ${shlibs:Depends}

[the-snowwhite]

I'm stuck at the memcpy issue I just created a new aar64 rip build with the updated arm64 branches here: Builder machinekit-hal machinekit-cnc

---

Here is the gdb backtrace from the rip-build:

root@ultra96:~# gdb /home/linaro/machinekit-hal/libexec/rtapi_app_rt-preempt /home/linaro/core
Reading symbols from /home/linaro/machinekit-hal/libexec/rtapi_app_rt-preempt...done.

warning: core file may not match specified executable file.
[New LWP 4136]
[New LWP 4141]
[New LWP 4140]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `rtapi:0                                                                       '.
Program terminated with signal SIGBUS, Bus error.
#0  0x0000007fba85ec68 in memcpy () from /lib/aarch64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x7fba403000 (LWP 4136))]
(gdb) backtrace
#0  0x0000007fba85ec68 in memcpy () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007fb8f7712c in hm2_soc_read (this=0x7fba134ee0, addr=260, buffer=0x7fc47af960, size=8) at hal/drivers/mesa-hostmot2/hm2_soc_ol.c:179
#2  0x0000007fb8f9faf4 in hm2_register (llio=0x7fba134ee0, config_string=0x7fba214e40 <error: Cannot access memory at address 0x7fba214e40>)
    at hal/drivers/mesa-hostmot2/hostmot2.c:1475
#3  0x0000007fb8f77c58 in hm2_soc_register (brd=0x7fba134e88, fwid=0x0, fwid_len=0, inst_id=82) at hal/drivers/mesa-hostmot2/hm2_soc_ol.c:477
#4  0x0000007fb8f78230 in instantiate (argc=4, argv=0x55b917a020) at hal/drivers/mesa-hostmot2/hm2_soc_ol.c:605
#5  0x0000007fba1718d0 in create_instance (fa=0x7fc47afb98) at hal/lib/hal_comp.c:507
#6  0x0000007fba1532ac in hal_call_usrfunct (name=0x5585061060 "newinst", argc=4, argv=0x55b917a020, ureturn=0x7fc47afc94) at hal/lib/hal_funct.c:192
#7  0x0000005585049e1c in do_newinst_cmd (comp="hm2_soc_ol", instname=<error reading variable: Cannot access memory at address 0x0>, args=..., pbreply=..., 
    instance=<optimized out>) at rtapi/rt-preempt/rtapi_app.cc:511
#8  0x000000558504debc in rtapi_request (loop=<optimized out>, socket=0x55b9169e00, arg=<optimized out>) at rtapi/rt-preempt/rtapi_app.cc:928
#9  0x0000007fbac728e0 in zloop_start () from /usr/lib/aarch64-linux-gnu/libczmq.so.4
#10 0x000000558504d440 in mainloop (argc=<optimized out>, argv=<optimized out>) at rtapi/rt-preempt/rtapi_app.cc:1414
#11 0x0000005585047fd4 in main (argc=3, argv=0x7fc47b0e98) at rtapi/rt-preempt/rtapi_app.cc:1769
(gdb) 

---

culprit is:

---

hostmot2.c:1475 if (!llio->read(llio, HM2_ADDR_CONFIGNAME, name, 8)) { HM2_ERR("error reading HM2 Config Name\n"); r = -EIO; goto fail0; }

---

hm2_soc_ol.c:179 memcpy(buffer, brd->base + addr, size);

---

If the memcpy routine instead is defined as this c functiom `void myMemCpy(void dest, void src, size_t n) { // Typecast src and dest addresses to (char ) char csrc = (char )src; char cdest = (char *)dest;

// Copy contents of src[] to dest[] for (int i=0; i<n; i++) cdest[i] = csrc[i]; } `

Reads perform well however no writes work

[the-snowwhite]

OK but odd

memcpy in aarch64 libglibc.so has a different/broken read functionality: This is tested both in my arm64 rip build and aarch64 package build ultra96 images in hm2_soc_ol.c: replacing only the read function with the c function like this:

static void myMemCpy(void *dest, void *src, size_t n) 
{ 
// Typecast src and dest addresses to (char *) 
char *csrc = (char *)src; 
char *cdest = (char *)dest; 

// Copy contents of src[] to dest[] 
for (int i=0; i<n; i++) 
    cdest[i] = csrc[i]; 
} 

//
// these are the "low-level I/O" functions exported up
//
static int hm2_soc_read(hm2_lowlevel_io_t *this, u32 addr, void *buffer, int size) {
    hm2_soc_t *brd = this->private;

#ifdef WARN_ON_UNALIGNED_ACCESS
    /* hm2_read_idrom performs a 16-bit read, which seems to be OK, so let's allow it */
    if ( ((addr & 0x1) != 0) || (((size & 0x03) != 0)  && (size != 2))) {
    LL_ERR( "hm2_soc_read: Unaligned Access: %08x %04x\n", addr,size);
    }
#endif
    myMemCpy(buffer, brd->base + addr, size);
    return 1;  // success
}

makes me able to set and read / write pins, but not much more as memcpy is used to read in many places, I can attempt reinstalling /lib/aarch64-linux-gnu/libglib-2.0.so.0

[the-snowwhite]

Well I hope someone has some more solid suggestions as to why memcpy is having memory violation problems on the aarch64 platform, and perhaps can point out what I'm unable to see....

[zultron]

Sorry, @the-snowwhite, I don't have any hardware to look at your memcpy() problem on.

#0  memcpy () at ../sysdeps/aarch64/memcpy.S:102
102     ../sysdeps/aarch64/memcpy.S: No such file or directory.

I think this error really means that memcpy() is returning ENOENT, and not that the memcpy.S file is missing. That's surely related to the bus error. I've never encountered one of those, but wikipedia says it's similar to a segmentation violation except that it refers to an invalid address.

I'd start by reverting the myMemCpy() patch and looking at the operands to memcpy() to see if they're valid or not, brd->base + addr first.

If the hm2-related unit tests don't run correctly, that could be an easy place to start a rapid debugging cycle of run-test/tweak-source/build/repeat iterations.

Good luck!

Let me ask one more time, why does hm2_soc_ol.c need #include "rtapi_io.h"? There aren't actually any inb() and outb() function calls there. Can you just remove the #include and drop the more lengthy inb()/outb() replacement?

[the-snowwhite]

@zultron hm2_soc_ol.c does NOT need #include "rtapi_io.h" (I removed it) The reason for the inb()/outb() replacement is for all the PCI related stuff that gets dragged in by the USERMODE_PCI flag of which the Socfpga platform strictly only needs the stuff in the: src/rtapi/userpci/ folder. However up the line I see the the next arm64 user may have a board with a pci slot and wants to add a "normal" mesa card, Then the PCI_BASE_ADDRESS can be adjusted and everyone is happy ?

---

memcpy: First I'm able to get the MyMemCpy function to do I/O work if I set it to copy the bytes backwards (Count Top to down), problem is I get a 240 ns (low) glitch every 1000 ms(baseperiod) If I set a pin to high. I have been searching for the actual string.h prototype used, to see if the operands to memcpy are valid and found it here I think:

The definition reads:

__BEGIN_NAMESPACE_STD
/* Copy N bytes of SRC to DEST.  */
extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
         size_t __n) __THROW __nonnull ((1, 2));

I have no clue as to what void *__restrict does.

[the-snowwhite]

Excerpt from the arm porting guide

64-bit data models
There are various standard data models in use today. They differ mainly in the size
defined for integers, longs and pointers.

64-bit Linux implementations use LP64 and this is supported by the defined A64-LP64
Procedure Call Standard A64-LP64. Other PCS variants may be defined which support
LLP64 (used by 64-bit Windows) and ILP32 (a variant which can ease porting 32-bit
software which doesn’t need 64-bit addressing and can also improve performance of
applications which use a lot of pointers but do not require 64-bit addressing).
When compiling for ARMv7-A, you will most likely have used a data model equivalent
to what is shown as ILP32 in the table.
Note that the ARM compiler for ARMv8 accepts __int64 as a synonym for “long long”.

[the-snowwhite]

@ArcEye @zultron The hm2_soc_ol driver has only been living in a 32-bit environment so far, in aarch64 all pointers (and size_t's) are without warning's(in gcc6.3) enlarged to 64 bit thus being able to: "swallow" garbage in the higher 32 bits ? the error message above points to a 40-bit address:

Cannot access memory at address 0x7fba214e40>

I basicilly don't comprehend pointers in C so If someone could look at the hm2_soc_ol code and the

hm2->llio->write(hm2->llio, hm2->pwmgen.pwm_mode_addr, hm2->pwmgen.pwm_mode_reg, (hm2->pwmgen.num_instances * sizeof(u32)));

Method of read/write addressing with regard to size_t and pointers being expanded from 32 to 64 no matter if they are defined properly or not. I would be very grateful for your assessment...

[the-snowwhite]

@zultron this commit Undo's the requirement of USERMODE_PCI for the arm(64) TARGET_SOCFPGA_PLATFORM and the inb()/outb() replacement.

---

However it does not solve the memcpy problem

[the-snowwhite]

Browsing the arm64 porting whitepaper linked above I find following statement I don't quite understand (on page 18)

In pointer arithmetic, variables which are added or subtracted from pointers should be
declared as ptrdiff_t as an int (as well as being signed) may not be large enough to 
hold the difference between two pointers.

memcpy(buffer, brd->base + addr, size);

brd->base + addr

brd->base --> 64 bit pointer addr u32

The note doesn't mention multiplying .... But what does:

the variable should be declared as ptrdiff_t as an int

mean and how do I test doing that ?

[zultron]

The reason for the inb()/outb() replacement is for all the PCI related stuff that gets dragged in by the USERMODE_PCI flag of which the Socfpga platform strictly only needs the stuff in the: src/rtapi/userpci/ folder. However up the line I see the the next arm64 user may have a board with a pci slot and wants to add a "normal" mesa card, Then the PCI_BASE_ADDRESS can be adjusted and everyone is happy ?

Ah, I'm starting to understand.

Can we wait until someone actually wants PCI support on ARM before trying to implement something? My thinking is that platforms that have PCI hardware may actually have supporting software, for example [this Samsung CPU].

This inb()/outb() issue as it affects the aarch64 build is really about tweaking the build system to enable just the supported and needed bits of code, and disabling the unsupported and unneeded bits. Can you try to replace USERMODE_PCI with BUILD_DRIVERS in cases like this where we want to build non-PCI drivers?

You're right that down the road PCI support will surely no longer happen to fall along CPU architecture lines, and will need to be enabled on a per-platform basis. When that time comes, in order to keep the build generic for packaging purposes and to reduce configuration requirements for users, we'll devise a better scheme, perhaps along the lines of the flavor rework that @cerna and I have been discussing. For now, I'd like to keep things simple even if not future proof.

memcpy: First I'm able to get the MyMemCpy function to do I/O work if I set it to copy the bytes backwards (Count Top to down),

Because there's overlap between the dest and src memory areas? Have you looked at memmove() to replace memcpy()?

__BEGIN_NAMESPACE_STD
/* Copy N bytes of SRC to DEST.  */
extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
       size_t __n) __THROW __nonnull ((1, 2));

I have no clue as to what void *__restrict does.

Me neither, but here's an explanation:

I'll have to look at the 32/64 bit issues later, and that's not my strong suit, either. Hopefully @ArcEye will have better insight.

In any case, this sounds like real progress. Good luck knocking out this problem, and with luck it'll be the last.

[dkhughes]

Did they change the bus size of the interface between the FPGA on the 64 bit chip and the CPU? The llio write calls the hm2_soc_ol driver which invokes the uio driver and reads memory mapped locations in the FPGA.

With zynq, this size was set at 32-bits and that matched the hardware bitfile bus size that I made in the Vivado projects. I don't have 64 bit Xilinx hardware to test this for you though.

[dkhughes]

As I recall, PCI support was required to get the hardware to function properly on zynq. Wholesale disabling it would be detrimental I think.

With the 32-bit arm in the zynq, kernel config was very important, and pci had to be enabled even without PCI hardware included in the bit design.

[cerna]

I have been following this discussion from afar and so keeping my mouth mostly shut on basis that I have never ever held anything aarch64.

But at a first glance, I don't like the use of void pointer with pointer arithmetic in memcpy and typecasting to char pointer in your myMemCpy function. Also, by some discussions the void pointer arithmetic is illegal.

[the-snowwhite]

@dkhughes Great to hear from you again... Hardwarewise: I have set the cpu <-> fpga bus to be 32-bits (can be set up to 128), and it seems like the hm2 to cpu bus is operating correctly as I'm able to use the mksocmemio utility to toggle (tested to at least) pins GPIO 0-15 on my board by using the hm2 memory locations 0x1100(ddr reg) and 0x1000(set/read bit). So I'm certain the problem has to do with the pointer math not scaling properly to LP64

[dkhughes]

Yeah, looking back at how we handled the mmap into the virtual memory space looks a little questionable when you throw in the option to have multiple bit width processors. void * arithmetic is non standard and handled by a GCC extension. I honestly have no idea how it would handle adding that uint32 address value to a 64 bit void pointer, but it probably isn't working right - I imagine it's doubling the value and your getting invalid access errors since you're trying to read memory that process doesn't have mapped.

I feel like we should change base to a uint32_t from a void (to match the address argument type), and do all of the address arithmetic as uint32's, then cast back to void* for memcpy commands.

We'd have to change the initialization code a little - the biggest call being here https://github.com/the-snowwhite/machinekit-hal/blob/master/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c#L350 where we find the virtual address of the first register in the HM2 peripheral.

I can look at doing this on the zynq today, but like I said, you'd have to do the testing on 64-bit arm since I don't have access.

[dkhughes]

Found the details with GCC. It assigns the sizeof(void) to 1.

The hm2_pci driver uses a void * for it's virtual base also. Are there any issues with running hm2_pci cards on amd64l? I think it's working correctly, but maybe the arm uio driver is expecting something different.

[cerna]

@dkhughes You mean this:

static int hm2_pci_read(hm2_lowlevel_io_t *this, u32 addr, void *buffer, int size) {
    hm2_pci_t *board = this->private;
    int i;
    u32* src = (u32*) (board->base + addr);
    u32* dst = (u32*) buffer;

    /* Per Peter Wallace, all hostmot2 access should be 32 bits and 32-bit aligned */
    /* Check for any address or size values that violate this alignment */
    if ( ((addr & 0x3) != 0) || ((size & 0x03) != 0) ){
        u16* dst16 = (u16*) dst;
        u16* src16 = (u16*) src;
        /* hm2_read_idrom performs a 16-bit read, which seems to be OK, so let's allow it */
        if ( ((addr & 0x1) != 0) || (size != 2) ){
            rtapi_print_msg(RTAPI_MSG_ERR, "hm2_pci_read: Unaligned Access: %08x %04x\n", addr,size);
            memcpy(dst, src, size);
            return 1;  // success
        }
        dst16[0] = src16[0];
        return 1;  // success
    }

//    rtapi_print_msg(RTAPI_MSG_ERR, "pci_read : %08x.%04x", addr,size);
    for (i=0; i<(size/4); i++) {
        dst[i] = src[i];
//        rtapi_print_msg(RTAPI_MSG_ERR, " %08x", dst[i]);
    }
//    rtapi_print_msg(RTAPI_MSG_ERR, "\n");
    return 1;  // success
}

They don't use the void * in the memcpy function calls, they (@cdsteinkuehler ?) don't use memcpy at all.

And yes, GCC returns sizeof(void*) as a 1, but you have to know - and I don't - what plus one in memory means, as a natural number is size-less unit.

[dkhughes]

board->base is the void * I'm referencing. You can see it's definition here:

https://github.com/machinekit/machinekit-hal/blob/master/src/hal/drivers/mesa-hostmot2/hm2_pci.h#L135

For that read function example copied, this line is the void * addition since the cast is after the addition scope:

u32* src = (u32*) (board->base + addr);

They is the original author of hm2 drivers here I think. It was done before I worked on Zynq and hm2_soc_ol stuff.

[cerna]

For that read function example copied, this line is the void * addition since the cast is after the addition scope:

Yeah, you are right. I cannot read.

However, I also wonder what effect typecasting to u32 has on memcpy and others.

[dkhughes]

Good question.

I've reverted hm2_soc's read and write functions back to match the PCI driver reference (access memory through array instead of only memcpy). If I can figure out why I'm getting segfaults in haltalk now I'll be able to test it 32-bit and push a branch up for @the-snowwhite to try on his hardware.

[dkhughes]

Okay, I pushed the changes here:

https://github.com/JDSquared/machinekit-hal/tree/hm2_soc_lp64

Compiles and runs on the Zynq.

It now accesses correctly aligned reads via u32 pointers instead of a void pointer and memcpy. The void ptr arithmetic is still there. hm2 designates addresses as byte values, so sizeof(void) returning 1 matches the assumption the previous authors made. Give this a shot and see if it gets you farther. Post any errors and we can keep marching.

I'm still not a fan of the void arithmetic, maybe an explicit cast to a char* would be less.... unsettling. I think we should fix both drivers if we make the change to one.

[cerna]

Looking into git, both Machinekit and LinuxCNC trees, it was changed from memcpy (in the _hm2pci.c) to the current for loop in Machinekit and while loop in LinuxCNC because of some Glibc and KERNEL 3.2. It would probably be prudent to check if the memcpy problem still exists or the function can be used.

Quick look into Glibc gives that the Android people are using memcpy even for overlapped memory and Glibc people are enabling them. (Not sure if the same is true for this aarch64 situation, didn't look into it too much.)

[the-snowwhite]

:-) OK got the ball rolling @cerna thanks for the (pointer) push This is as far I get before going to bed (really ..really late..) machinekit@mksocfpga-ultra96-soc:~$ cat /var/log/linuxcnc.log

Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: startup pid=5764 flavor=rt-preempt rtlevel=5 usrlevel=5 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=v0.2~arm64-memwork~17b43a357
Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=concurrencykit 0.5.2   libwebsockets=2.0.3
Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: configured: sha=17b43a357
Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: built:      Sep 18 2019 04:02:42 sha=17b43a357
Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: register_stuff: actual hostname as announced by avahi='mksocfpga-ultra96-soc.local'
Sep 18 06:05:52 mksocfpga-ultra96-soc msgd:0: zeroconf: registering: 'Log service on mksocfpga-ultra96-soc.local pid 5764'
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 2:rtapi_app:5769:user rtapi:0: cannot create core dumps - /proc/sys/fs/suid_dumpable contains 0
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 2:rtapi_app:5769:user you might have to run 'echo 1 > /proc/sys/fs/suid_dumpable' as root to enable rtapi_app core dumps
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi.so default iparms: ''
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user RTAPI:0  rt-preempt v0.2~arm64-memwork~17b43a357 init
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 3:rtapi_app:5769:user libcgroup initialization failed: (50001) Cgroup is not mounted
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi: loaded from rtapi.so
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hal_lib.so default iparms: ''
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi_app_main:195 HAL: initializing RT hal_lib support
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_xinitfv:90 HAL: initializing component 'hal_lib' type=4 arg1=0 arg2=0/0x0
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hal_heap_addmem:58 HAL: extending arena by 262144 bytes
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_export_xfunctfv:85 HAL: exporting function 'newinst' type 2 fp=0 owner=66
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_export_xfunctfv:85 HAL: exporting function 'delinst' type 2 fp=0 owner=66
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_xinitfv:271 HAL: singleton component 'hal_lib' id=66 initialized
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi_app_main:199 HAL: RT hal_lib support initialized rc=66
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hal_lib: loaded from hal_lib.so
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user accepting commands at ipc:///tmp/0.rtapi.0536ad21-9579-4658-9c3f-ac267230cc22
Sep 18 06:05:52 mksocfpga-ultra96-soc rtapi:0: 3:rtapi_app:5769:user rtapi_app:0 ready flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:05:53 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user pid=5769 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:05:53 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user pid=5769 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: ulapi:5770:user _ulapi_init(): ulapi rt-preempt v0.2~arm64-memwork~17b43a357 loaded
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: ulapi:5770:user halg_xinitfv:271 HAL: singleton component 'hal_lib5770' id=70 initialized
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user --halcmd ping
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user halg_exit:293 HAL: removing component 72 'halcmd5770'
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user ulapi_hal_lib_cleanup:235 HAL: lib_module_id=70
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user halg_exit:293 HAL: removing component 70 'hal_lib5770'
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user halg_exit:315 HAL: hal_errorcount()=0
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5770:user halg_exit:316 HAL: _halerrno=0
Sep 18 06:05:53 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user pid=5769 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: ulapi:5775:user _ulapi_init(): ulapi rt-preempt v0.2~arm64-memwork~17b43a357 loaded
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: ulapi:5775:user halg_xinitfv:271 HAL: singleton component 'hal_lib5775' id=74 initialized
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user --halcmd -kf
Sep 18 06:05:53 mksocfpga-ultra96-soc msgd:0: zeroconf: registered 'Log service on mksocfpga-ultra96-soc.local pid 5764' _machinekit._tcp 0 TXT "uuid=0536ad21-9579-4658-9c3f-ac267230cc22" "instance=9b2f5c36-d9c9-11e9-83d6-000ec6e1e19a" "service=log" "dsn=ipc:///tmp/0.log.0536ad21-9579-4658-9c3f-ac267230cc22"
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hostmot2.so default iparms: ''
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_xinitfv:90 HAL: initializing component 'hostmot2' type=1 arg1=0 arg2=0/0x0
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hostmot2: loaded from hostmot2.so
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2_soc_ol.so default iparms: 'debug=0 no_init_llio=0 num=0 already_programmed=0'
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_xinitfv:90 HAL: initializing component 'hm2_soc_ol' type=1 arg1=0 arg2=0/0x0
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2_soc_ol: loaded from hm2_soc_ol.so
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user do_newinst_cmd: instargs='already_programmed=1 -- config="num_pwmgens=1 num_stepgens=1" debug=5'
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_inst_create:59 HAL: rtapi: creating instance 'hm2-socfpga0' size 368
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2_soc_ol: mapping pre-programmed hm2_soc_ol_board hm2-socfpga0
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2_soc_ol: hm2 cookie check OK, board name is ='AVNTULTR'
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0: parsing config string "num_pwmgens=1 num_stepgens=1"
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0: final config:
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_encoders=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_mencoders=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_absencs=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_resolvers=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_pwmgens=1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_3pwmgens=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     sserial_port_0=00000000#012                    sserial_port_1=00000000#012                    sserial_port_2=00000000#012                    sserial_port_3=00000000
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_stepgens=1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_bspis=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_dbspis=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_uarts=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_pktuarts=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_dplls=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_leds=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     enable_raw=0
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     enable_adc=0
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     num_capsensors=-1
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hm2/hm2_ultr.0:     firmware=(NULL)
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_param_newfv:143 HAL: creating parameter 'hm2_ultr.0.io_error'
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hm2/hm2_ultr.0: invalid llio cookie, got 0x00000000, expected 0x55AACAFE
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hm2/hm2_ultr.0: FPGA failed to initialize, or unexpected firmware?
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hm2_ultr.0: hm2_soc_ol_board fails HM2 registration
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hm2_soc_ol: error registering UIO driver: -22
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: hal_call_usrfunct(newinst,already_programmed=1 -- config="num_pwmgens=1 num_stepgens=1" debug=5) failed: -1 - Operation not permitted
Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hal_call_usrfunct(newinst,already_programmed=1 -- config="num_pwmgens=1 num_stepgens=1" debug=5) failed: -1 - Operation not permitted
Sep 18 06:05:57 mksocfpga-ultra96-soc msgd:0: hal_lib:5769:rt hm2: loading Mesa HostMot2 driver version 0.15
Sep 18 06:05:57 mksocfpga-ultra96-soc msgd:0: hal_lib:5769:rt hm2_soc_ol: loading Mesa AnyIO HostMot2 socfpga overlay driver version 0.9
Sep 18 06:06:04 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user pid=5769 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user halg_exit:293 HAL: removing component 76 'halcmd5775'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user ulapi_hal_lib_cleanup:235 HAL: lib_module_id=74
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user halg_exit:293 HAL: removing component 74 'hal_lib5775'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user halg_exit:315 HAL: hal_errorcount()=0
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5775:user halg_exit:316 HAL: _halerrno=0
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: ulapi:5778:user _ulapi_init(): ulapi rt-preempt v0.2~arm64-memwork~17b43a357 loaded
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: ulapi:5778:user halg_xinitfv:271 HAL: singleton component 'hal_lib5778' id=84 initialized
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user --halcmd stop
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user hal_stop_threads:360 HAL: threads stopped
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user halg_exit:293 HAL: removing component 86 'halcmd5778'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user ulapi_hal_lib_cleanup:235 HAL: lib_module_id=84
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user halg_exit:293 HAL: removing component 84 'hal_lib5778'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user halg_exit:315 HAL: hal_errorcount()=0
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5778:user halg_exit:316 HAL: _halerrno=0
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user pid=5769 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~arm64-memwork~17b43a357
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user hal_stop_threads:360 HAL: threads stopped
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user unload_usr_cb:604 HAL: comp halcmd5805: sending SIGTERM to pid 5805
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:293 HAL: removing component 80 'hm2_soc_ol'
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user free_inst_struct:131 HAL: calling custom destructor(hm2_soc_ol,hm2-socfpga0)
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user  'hm2_soc_ol' unloaded
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:293 HAL: removing component 78 'hostmot2'
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user  'hostmot2' unloaded
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi_app_exit:205 HAL: removing RT hal_lib support
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit_thread:324 HAL: 0 threads exited
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:293 HAL: removing component 66 'hal_lib'
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:315 HAL: hal_errorcount()=1
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:316 HAL: _halerrno=0
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:151 HAL: HAL heap heap status
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:153 HAL:   arena=262144 totail_avail=260736 fragments=1 largest=260736
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:157 HAL:   requested=1288 allocated=1288 freed=0 waste=0%
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:151 HAL: global heap heap status
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:153 HAL:   arena=787136 totail_avail=262304 fragments=2 largest=262264
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_heapstatus:157 HAL:   requested=524678 allocated=524736 freed=32 waste=0%
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_memory_usage:168 HAL:   strings on global heap: alloc=198 freed=29 balance=169
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_memory_usage:175 HAL:   RT objects: 377  alignment loss: 6  (1%)
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_memory_usage:177 HAL:   hal_malloc():   3
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user report_memory_usage:179 HAL:   unused:   261447
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user halg_exit:320 HAL: hal_sweep: 14 objects freed
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user rtapi_app_exit:213 HAL: RT hal_lib support removed successfully
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user  'hal_lib' unloaded
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user RTAPI:0 exit
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 4:rtapi_app:5769:user  'rtapi' unloaded
Sep 18 06:06:05 mksocfpga-ultra96-soc rtapi:0: 3:rtapi_app:5769:user exiting mainloop (by remote command)
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: ulapi:5805:user _ulapi_init(): ulapi rt-preempt v0.2~arm64-memwork~17b43a357 loaded
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: ulapi:5805:user halg_xinitfv:271 HAL: singleton component 'hal_lib5805' id=88 initialized
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user --halcmd shutdown
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5769:rt hm2: ignoring request to unregister hm2_ultr.0: not found
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5769:rt hm2: unloading
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user halg_exit:293 HAL: removing component 90 'halcmd5805'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user ulapi_hal_lib_cleanup:235 HAL: lib_module_id=88
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user halg_exit:293 HAL: removing component 88 'hal_lib5805'
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user halg_exit:315 HAL: hal_errorcount()=0
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: hal_lib:5805:user halg_exit:316 HAL: _halerrno=0
Sep 18 06:06:05 mksocfpga-ultra96-soc msgd:0: rtapi_app exit detected - scheduled shutdown
Sep 18 06:06:07 mksocfpga-ultra96-soc msgd:0: msgd shutting down
Sep 18 06:06:07 mksocfpga-ultra96-soc msgd:0: zeroconf: unregistering 'Log service on mksocfpga-ultra96-soc.local pid 5764'
Sep 18 06:06:07 mksocfpga-ultra96-soc msgd:0: log buffer hwm: 0% (14 msgs, 1156 bytes out of 524288)
Sep 18 06:06:07 mksocfpga-ultra96-soc msgd:0: normal shutdown - global segment detached
machinekit@mksocfpga-ultra96-soc:~$ 

Last 3 commits here got the board to start registering (with the memcpy functions) (bus fault disappeared on exactly this one (2nd last))

this failed construct is where I got to Sep 18 06:05:57 mksocfpga-ultra96-soc rtapi:0: 1:rtapi_app:5769:user hm2/hm2_ultr.0: invalid llio cookie, got 0x00000000, expected 0x55AACAFE

[the-snowwhite]

Hmm for some reason (your) yesterdays discussion (before my former post) first got pushed forward to me now. @dkhughes I'll look into testing your branch asap...

[the-snowwhite]

:-) OK I now have hardware step pulses via axis gui ...:-) Very much thanks to all contributors I have the full patch set Including @zultron 's and @dkhughes commits here: arm64 Machinekit-cnc patches here: I have compiled both with @zultron 's current (arm64 updated)master branch @dkhughes thank you again for dragging me out of the mud ... :-)

[the-snowwhite]

@dkhughes @cdsteinkuehler + others I have created an issue for the mksocfpga workout

[the-snowwhite]

@zultron Sorry that the aarch64 solution didn't do much for your upcoming BBAI rollout, however I have now had time to test the new aarch64 patches and builder compiled for armhf and this works as its supposed to (just as before),. I'm not really in a position to test running the new commits on a pc (or beaglebone), too see if anything breaks there..... So:

What are the next steps before you are ready for pushing your arm64 master branch to the online builder ?

---

Do the aarch commits need some more polishing ? (there is no point in pushing them before the builder is updated)

Who Is able test out the machinekit-hal machinekit-cnc commit lists on pc/beaglebone ?

---

Should we finish this off under a new issue:

Aarch64 implemention

?

[zultron]

@the-snowwhite

IIRC, the work in the mk-cross-builder repo itself is done; no more changes needed there. In order to support aarch64 on Buster, we still need libck-dev:arm64 packages from @ArcEye (who recently said GitHub issue updates weren't making it into his email inbox), but that shouldn't stop a merge to support Stretch right away.

As for your arm64-lp64 branch, it looks good to me. I fixed up my own branch based on your changes, and massaged in some new improvements. Note I did replace your 1bebc5b87 with the simpler af4f92774467ce9341bdddc5243b23a36b3774a1; your other commits should be untouched.

Do you know what caused the problem behind 1d9df370dc5450dbdedab1c8979d6d449f3cc407, "Fix message print string format"? I found the other format specifier in the same line needed the opposite treatment, and I'm not sure what would have changed to cause the error. See the error message in the 0802354e17181388b49abb97f606029a92f8cd84 commit log.

Fantastic work, @the-snowwhite, I'm very excited!

[ArcEye]

we still need libck-dev:arm64 packages from @ArcEye

@zultron I replied when you first mentioned this. I don't have anything to build it with. I am pretty sure that I just took the sid libck packages, (which looked to use the correct libs and source versions, but had just not been backported to Buster for some reason) tested them against Buster and then put them in the repo.

Should be no reason why you cannot do the same ( the testing that is ). If it works I can add to the repo when arm64 is added, for now you can just amend your /etc/apt/sources.list and specifically use the sid repo to download ck-dev. https://packages.debian.org/sid/arm64/libck-dev/download.

I am having a bit of a sabbatical at present, so not really following all that goes on.

[the-snowwhite]

@zultron about the problem behind 1d9df37 I think it's due to a compiler update it surfaced. I has been there (long) before the arm64 work size_t nread = 0; , LL_ERR("reading '%s': expected %zu got %u - %s\n", brd->descriptor,(unsigned) st.st_size, nread, strerror(errno)); Perhaps because I have been using linaro gcc 7 (or the aarch64 gcc 6.3) where these types of warnings have been upgraded to errors:

BTW: thanx for updating my (primitive) 1bebc5b commit

[the-snowwhite]

@zultron @ArcEye I have just tested out building and testing arm64 buster debs successfully with following steps:

BUILD: mk-cross-builder: Add libck-dev from sid to buster

---

INSTALL: Installing the debs I ram across an old now relevant issue

Short version: This missing run-time dependency issue was fixed by installing python-gnome2 and missing dependencies from stretch

[the-snowwhite]

About the missing Buster dependencies: Build libck:

This can be installed either via this method into the builder (for all arch's)

or copied into the machinekit repo as @ArcEye has suggested

---

Missing buster Install requirements: Besides that python-gnome2 is no longer in sid

I found this info when searching for what happened to python-gnome2

since python-gnome2 (and python-gconf) are now missing in both sid and debports

I made a list (compiled from https://www.debian.org/distrib/packages ) of the availability of the dependencies that got installed when I installed the python-gnome2 package from stretch in my arm64 buster setup:

---

Get:27 http://ftp.dk.debian.org/debian stretch/main arm64 python-gnome2 arm64 2.28.1+dfsg-1.2 [145 kB]
not in sid or debports

Get:25 http://ftp.dk.debian.org/debian stretch/main arm64 python-gconf arm64 2.28.1+dfsg-1.2 [51.6 kB]
not in sid or debports

Get:26 http://ftp.dk.debian.org/debian stretch/main arm64 python-pyorbit arm64 2.24.0-7.2 [58.1 kB]
in sid debports (arm64 only)

Get:21 http://ftp.dk.debian.org/debian stretch/main arm64 libgnomeui-0 arm64 2.24.5-3.1 [282 kB]
in sid debports newer version than stretch

Get:8 http://ftp.dk.debian.org/debian stretch/main arm64 liborbit-2-0 arm64 1:2.14.19-2+b1 [206 kB]
also in sid newer version than stretch

Get:12 http://ftp.dk.debian.org/debian stretch/main arm64 libgnome2-common all 2.32.1-5 [936 kB]
also in sid newer version than stretch

Get:13 http://ftp.dk.debian.org/debian stretch/main arm64 libgnome-2-0 arm64 2.32.1-5+b1 [465 kB]
also in sid newer version than stretch

Get:20 http://ftp.dk.debian.org/debian stretch/main arm64 libgnomeui-common all 2.24.5-3.1 [513 kB]
also in sid newer version than stretch

Get:24 http://ftp.dk.debian.org/debian stretch/main arm64 liborbit2 arm64 1:2.14.19-2+b1 [108 kB]
also in sid newer version than stretch

Get:9 http://ftp.dk.debian.org/debian stretch/main arm64 libbonobo2-0 arm64 2.32.1-3+b1 [247 kB]
also in sid debports same version as stretch

Get:10 http://ftp.dk.debian.org/debian stretch/main arm64 libgnomevfs2-common all 1:2.24.4-6.1 [760 kB]
also in sid debports same version as stretch

Get:19 http://ftp.dk.debian.org/debian stretch/main arm64 libgnome-keyring0 arm64 3.12.0-1+b2 [77.0 kB]
in sid debports same version as stretch

Get:7 http://ftp.dk.debian.org/debian stretch/main arm64 libbonobo2-common all 2.32.1-3 [243 kB]
also in sid same version as stretch

Get:11 http://ftp.dk.debian.org/debian stretch/main arm64 libgnomevfs2-0 arm64 1:2.24.4-6.1+b2 [452 kB]
also in sid same version as stretch

Get:16 http://ftp.dk.debian.org/debian stretch/main arm64 libbonoboui2-common all 2.24.5-4 [137 kB]
also in sid same version as stretch

Get:17 http://ftp.dk.debian.org/debian stretch/main arm64 libbonoboui2-0 arm64 2.24.5-4 [130 kB]
also in sid same version as stretch

Get:18 http://ftp.dk.debian.org/debian stretch/main arm64 libgnome-keyring-common all 3.12.0-1 [59.5 kB]
also in sid same version as stretch

Get:22 http://ftp.dk.debian.org/debian stretch/main arm64 libgnomevfs2-extra arm64 1:2.24.4-6.1+b2 [354 kB]
also in sid same version as stretch

---

I have no idea of which applications that(still) require the python-gnome2 (and python-gconf) packages.

If python-gnome2 (and python-gconf) still are needed in Machinekit buster I would suggest copying them (and their dependencies) into the machinekit repo before activating buster builds...

[the-snowwhite]

@zultron @ArcEye I must admit my trigger finger is itching with this(mk-hal) and then that(mk-cnc) However this activates both machinekit-hal/machinekit-cnc arm64 builds and buster builds. I'm afraid the current build system will choke on both, unless the libck suggestions are handled first so that the online builder can be readied for the arm64/buster production run.

---

the missing buster python-gnome2 (and python-gconf) packages issue are just runtime issues that can wait until someone actually tries to test run buster :-)

[ArcEye]

@the-snowwhite I have not been following this much, you will need to give me a clear overview.

There is already presently a Buster builder setup. Is the the arm64_10 docker ready to produce packages, or does it require libck-dev to be available first?

@zultron 's other dockers put the machinekit deb repo in the sources list and pull libck-dev from there, so that seems the best course

I can add it from sid when I create the repo arm64 flavour if required.

The other issues with Buster and sid are indicative of why we need to get the -cnc side supplied from linuxcnc and just maintain the -hal side. All the python based GUIs etc will crumble to dust before long and we don't want to be the ones having to replace them.

[ArcEye]

OK - done http://deb.machinekit.io/debian/dists/buster/main/binary-arm64/Packages now contains the arm64 version of libck-dev and libck0

Let me know when you have sorted out the docker so that it can pull them and tested it.

[ArcEye]

@the-snowwhite

If python-gnome2 (and python-gconf) still are needed in Machinekit buster I would suggest copying them (and their dependencies) into the machinekit repo before activating buster builds...

This suggests that it is unused and was only ever added for halgui, which in turn is not now used https://github.com/LinuxCNC/linuxcnc/issues/341

We may be OK to remove it as a dependency from Buster and above in machinekit-cnc, which is where it appears.

[ArcEye]

We may be OK to remove it as a dependency from Buster and above in machinekit-cnc, which is where it appears.

I have put in 3 PRs to remove that reference anyway. It is useless having a dep that does not exist in that distro.

[the-snowwhite]

@ArcEye Unless libck is arm64 specific I think armhf, i386 and amd64 versions need to be added also

[the-snowwhite]

OK I have just built the arm64 flavor of mk-cross-builder out of my fork of @zultron 's master branch

It pulls in the new mk libck packages fine

Get:3 http://deb.machinekit.io/debian buster/main arm64 libck0 arm64 0.6.0-1.1 [19.4 kB]
Get:4 http://deb.machinekit.io/debian buster/main arm64 libck-dev arm64 0.6.0-1.1 [272 kB]

[ArcEye]

Unless libck is arm64 specific I think armhf, i386 and amd64 versions need to be added also

They are all there, have been for about 3 months since I added them for @zultrons new dockers

[the-snowwhite]

Great Then only piece I see missing is the arm64 PR to https://github.com/Dovetail-Automata/mk-cross-builder ...