running on 64-bit raspbian

[erh]

pi-blaster is crashing on 64-bit raspbian.
I've traced it down to to this line:
memset(ctl->sample, 0, sizeof(ctl->sample));
in init_ctrl_data
Wondering if anyone is looking at 64-bit, or if not, any hints as to where I might go hunt for docs to figure out how to make it work.
Thanks.

[sarfata]

My first guess was that sizeof(ctl->sample) now returned 64 bits instead of 32 but looking at the code, I don't think that's it.

The structures are properly defined as 32bits and this should work on 32 and 64 bits.

typedef struct {
  uint32_t info, src, dst, length,
     stride, next, pad[2];
} dma_cb_t;

struct ctl {
  uint32_t sample[NUM_SAMPLES];
  dma_cb_t cb[NUM_CBS];
};

Maybe you are running into some memory alignment issue. What is the exact error you are getting? When you said you traced it down, how did you do this? GDB?

[erh]

Combination of gdb and adding print statements.

Program received signal SIGBUS, Bus error.
__memset_generic () at ../sysdeps/aarch64/memset.S:127
127	../sysdeps/aarch64/memset.S: No such file or directory.
(gdb) where
#0  __memset_generic () at ../sysdeps/aarch64/memset.S:127
#1  0x00000055555521a8 in init_ctrl_data ()
#2  0x0000005555553658 in main ()

[sarfata]

Next step I think would be to enable debug and compare the output on 32bit and 64 bit:

I am specifically curious to see if this worked and what the output looks like on 64bits compared to 32bits:

  /* Use the mailbox interface to the VC to ask for physical memory */
  mbox.mem_ref = mem_alloc(mbox.handle, NUM_PAGES * PAGE_SIZE, PAGE_SIZE, mem_flag);
  /* TODO: How do we know that succeeded? */
  dprintf("mem_ref %u\n", mbox.mem_ref);
  mbox.bus_addr = mem_lock(mbox.handle, mbox.mem_ref);
  dprintf("bus_addr = %#x\n", mbox.bus_addr);
  mbox.virt_addr = mapmem(BUS_TO_PHYS(mbox.bus_addr), NUM_PAGES * PAGE_SIZE);
  dprintf("virt_addr %p\n", mbox.virt_addr);

I also wonder how having the kernel in 64 bits affects the DMA controller and whether the DMA controller supports 64bits. If it does, we will need to also change the definition of dma_cb_t to use 64 pointers for src and dest.

[erh]

I have DEBUG on as well, here's the output:
If there is anything else I can do to help let me know.
I can dig in more too, but a lot of learning around DMA, etc...

DMA Channels Info: 0x37f5, using DMA Channel: 7
Using hardware:                   PWM
Number of channels:                32
PWM frequency:                 100 Hz
PWM steps:                       1000
Maximum period (100  %):      10000us
Minimum period (0.100%):         10us
DMA Base:                  0xfe007000
Requesting 69632 bytes
Alignment: 4096 bytes
mem_alloc flags:  0x1c
MBox Request:
0000: 0x00000024
0004: 0x00000000
0008: 0x0003000c
000c: 0x0000000c
0010: 0x0000000c
0014: 0x00011000
0018: 0x00001000
001c: 0x0000001c
0020: 0x00000000
MBox Response:
0000: 0x00000024
0004: 0x80000000
0008: 0x0003000c
000c: 0x0000000c
0010: 0x80000004
0014: 0x00000007
0018: 0x00001000
001c: 0x0000001c
0020: 0x00000000
mem_ref 7
MBox Request:
0000: 0x0000001c
0004: 0x00000000
0008: 0x0003000d
000c: 0x00000004
0010: 0x00000004
0014: 0x00000007
0018: 0x00000000
MBox Response:
0000: 0x0000001c
0004: 0x80000000
0008: 0x0003000d
000c: 0x00000004
0010: 0x80000004
0014: 0xbeba4000
0018: 0x00000000
bus_addr = 0xbeba4000
base=0x3eba4000, mem=0x7f8f11b000
virt_addr 0x7f8f11b000
Initializing DMA ...
Initializing DMA ... e1

[sarfata]

Thanks for sharing this. This looks good and the virt_addr is definitely aligned so that is not the issue. I agree this is going to take some digging ... let's keep this issue open for people to chime in on that specific problem.

One possible next step is to look at other projects which use the DMA controller to PWM the pins. Looks like the guys over at pigpiod even have a label for 64bits issues.

The two most interesting comments I see are:

• Cannot start pigpiod: mmap gpio failed joan2937/pigpio#259 (comment)
• and just after Cannot start pigpiod: mmap gpio failed joan2937/pigpio#259 (comment)

Based on that you could try to reboot with iomem=relaxed in your kernel command line and see if it helps (I have little hope) - or continue reading to see how they are doing the mbox communication and what are they doing different.

[splitti]

There is a lot of time gone... What about a fix or anything in this direction?