Ipc driver 2: Electribe boogaloo

[vananasun]

There's still some work to be done, but this'll do for now.
Data can be transmitted, and there's also a function to request data from the other side.

• HostDMA runs in stop+interrupt mode. Everything fires in bursts except for the last block of data.

• Do you think using EDMA3 in the EMIFA driver would actually increase performance? Each transfer can never be more than 16 words. Since factory firmware has burst mode turnt off, that could be an indication that KORG's driver does something special, like using EDMA3 CPU side. It could prove useful to peek Ghidra for looped writes/reads to the MMR at SOC_EMIFA_CS2_ADDR; which is mapped to the HostDMA FIFO.
  As for CPU-side performance improvements, it's still possible to unroll the data read loops, but it'd be marginal benefit

• Transmission headers are stored 0x00000000 between 0x0000003F on the DSP external RAM, this is currently just some fixed magic number, and perhaps it should even be moved into cache.

• There are some edge cases/error handlings to be finished. In particular, it'd be good to be able to actually error HostDMA to see if the recovery mechanism works properly, currently I tried by simulating DMA errors in the HostDMA ISR, but that is not entirely the same as a real error.

• DSP->CPU data read requests have to be properly tested still, by now I expect them to work, but then again, I think it's about time we first add a printing bridge from DSP->CPU to allow for print debugging. I agree SPI would be the best option.

• Test with -DDEBUG. The DSP makefile has a new thing called -DBLACKFIN that's to distinguish platform

[vananasun]

i accidentally left this in

[enorrmann]

hi ! can you provide an example of using this feature from the application layer ?
thanks !

[vananasun]

hi ! can you provide an example of using this feature from the application layer ? thanks !

https://github.com/vananasun/freetribe.git test-ipc-sys23 it has a nice little sequencer demo, in cpu system23.c You have this code:

static uint32_t test_terug[64];
static void _test(void *ctx, t_ipc_status status) {
    if (IPC_FAILED == status) {
        ft_printf("IPC_FAILED callback");
        return;
    }

    ft_printf("terug gekregen: %08X", (uint32_t)ctx);
    for (int32_t p = 0; p < 64; p += 8) {
        ft_printf("%04X %04X %04X %04X %04X %04X %04X %04X",
            *(volatile uint16_t*)(test_terug+p+0),
            *(volatile uint16_t*)(test_terug+p+1),
            *(volatile uint16_t*)(test_terug+p+2),
            *(volatile uint16_t*)(test_terug+p+3),
            *(volatile uint16_t*)(test_terug+p+4),
            *(volatile uint16_t*)(test_terug+p+5),
            *(volatile uint16_t*)(test_terug+p+6),
            *(volatile uint16_t*)(test_terug+p+7)
        );
    }
}
static int timah;
    if (timah++ % 15 == 0) {
        ft_printf("Sturen");
        if (IPC_QUEUE_FULL == dev_dsp_ipc_read(0x00000060, test_terug, 64, _test, (void*)0x23AC1D23)) {
            ft_printf("IPC_QUEUE_FULL");
        }
        // if (IPC_QUEUE_FULL == dev_dsp_ipc_transfer(0x00000060, (const uint32_t*)0xC0000000, 71, _test, (void*)0x23AC1D23)) {
        //     ft_printf("IPC_QUEUE_FULL");
        // }
    }

that's essentaially all there is to it. DSP gets the same functions. Think of it as memcpy across CPU<->DSP

[bangcorrupt]

Do you think using EDMA3 in the EMIFA driver would actually increase performance? Each transfer can never be more than 16 words.

It should take some load off the CPU. The EDMA has a lot of features for multidimensional transfers, we should be able to transfer arbitrary length arrays of 4 byte words in 16 word chunks with a single DMA event.

could be an indication that KORG's driver does something special, like using EDMA3 CPU side.

As far as I can tell, the factory firmware doesn't use DMA at all on the CPU. Some drivers are interrupt driven, others use polling with a timeout.

If the debug printing commit works as a standalone feature, it might be better as a separate pull request. I still don't have any of my gear set up, so I can't actually test anything for a while.

[vananasun]

It should take some load off the CPU.

After studying EDMA3 and embedded topics a lot I definitely agree that EDMA3 transfers should be integrated into the EMIFA driver. It would be useful to sketch out together somewhere what the EDMA3 driver implementation should and shouldn't be able to do. To sum up use cases:

• EDMA3 as a non-blocking memcpy
• EDMA3 to (de-)interleave audio buffers
• EDMA3 integrated into all peripheral drivers
• EDMA3 ping pong buffer (supports LCD and other devices)
• EDMA3 to end world hunger

Some drivers are interrupt driven, others use polling with a timeout.

Does this mean they didn't squeeze all the juice out of the KORG's processing power? Good news!!

debug printing commit

Just comment it out while testing, it's merely printf built on top of ft_print. However, common/macros.h is a header that CPU and DSP share and belong into this PR imo.

don't have any of my gear set up

By the way I got a J-Link clone coming and an RPI setup, but I didn't wanna destroy my electribe by soldering the header. I tried taping the fucking thing like a noob but then I short circuited my electribe so do u know some non-permanent or destructive way to attach the JTAG header?

[bangcorrupt]

It would be useful to sketch out together somewhere what the EDMA3 driver implementation should and shouldn't be able to do.

#7

Does this mean they didn't squeeze all the juice out of the KORG's processing power?

Whether it's a clever design for reduced power and deterministic timing, or they just didn't get that far is impossible to tell. I say we add support for everything the hardware can do, then profile performance to choose which parts we want in what situations.

non-permanent or destructive way to attach the JTAG header

Your best option is to solder the header, or get someone to do it for you, any competent laptop repair technician could do this. I had to increase the temperature quite a lot when soldering the ground pin, as the PCB ground plane absorbs all the heat.

I couldn't find any hook probes small enough to get all pins attached next to each other. Also, any temporary connection will move and gradually wear through the plating on the PCB. A poor electrical connection will make the software impossible to debug.