[EV3 - help wanted]: Use DMA for display SPI

[laurensvalk]

We currently have an IRQ implementation for the EV3 display. Since we have to write big continuous buffers we should be using the EDMA for this. All the necessary config can be found here but I could not get it to work in our driver.

The DMA does not seem to write any data, or perhaps reads only zeros. Could it be that the MMU/Cache is not configured properly? Do we need to do this in our firmware or maybe in u-boot? Note that that EV3RT driver is in turn based on the ev3dev driver. I have taken a minimal combination of both, stripping away almost all of the Linux stuff.

On a related note: I got some unusual behavior when I originally had the buffers as large static arrays in the driver module. They seemed to cause out of bound reads or writes, as adjacent variables (according to the elf map file) got bad values. I was able to work around this by putting the buffers in a dedicated spot with the linker file. Putting them there is probably not a bad thing, but we really shouldn't have to do that just to work around memory problems, so maybe there is something deeper going on here.

[erik-thompson-seattle]

I'll start diving into this once I get my build system setup.

[dlech]

but we really shouldn't have to do that just to work around memory problems,

Actually, for DMA, yes you should have to do things like this. It is modifying the memory without the CPU having any knowledge and vice versa. In Linux there is a special CMA allocator for creating large, continuous buffers for use with DMA. Carving out a dedicated RAM hardware address range works too.

Another way we deal with it in Linux for smaller buffers is to use the __align__ attribute to ensure that the part of a struct that is passed to DMA lives in a cache line separate from the other members of the struct.

as adjacent variables (according to the elf map file) got bad values

This is very much a typical thing that happens when memory is in the same CPU cache line that is being accessed by DMA. A typical mode of failure is something like this: DMA gets one copy of a block of memory (aka cache line), modifies it and writes it back while at the same time the CPU modified something else in the same block. The CPU's changes get written over with what the DMA read before.

I'll start diving into this once I get my build system setup.

Don't be shy about asking questions. I have quite a bit of experience with this hardware on Linux at the kernel driver level. 😄

[laurensvalk]

The memory issues commented on above were happening with the current IRQ driver, not the DMA attempt (which did not work at all).

The DMA implementation used in EV3RT does indeed call a cache clean function, but maybe we are missing some other MMU setup steps early on to make this work properly.

The same TI library functions are available in our repository already so we can call them if we need to.

While u-boot could play a role, I did confirm that the EV3RT driver does work with the U-boot version we are using and vice versa, so it is not as simple as that.

Thanks @erik-thompson-seattle for taking a look!

[erik-thompson-seattle]

I have been spending this week ramping up on DMA and kernel driver work by watching content from https://www.youtube.com/@johannes4gnu_linux96

I will start to review the EV3 codebase around the display SPI next.

[laurensvalk]

We've just posted a standalone version of the Texas Instruments StarterWare for EV3. Other than the fact that this runs with u-boot, this gets very close to how TI expects things to work on this processor.

The following example works:

examples/evmAM1808/uart/uartEcho.c

These two do not:

examples/evmAM1808/uart_edma/uartEcho.c
examples/evmAM1808/cache_mmu/uartEdma_Cache.c

@dlech, Maybe this could help us figure out why DMA is not working, entirely independently from Pybricks driver code?

[laurensvalk]

I'm able to run some code without u-boot as well, though not yet a full example. I'll try to get that running and push it above. That should get us as close to the bare TI examples as it gets.

[laurensvalk]

Now updated the repo to boot the basic IRQ UART echo example without u-boot altogether, so things are very close to the original TI code now. Ideally, we could now find why examples/evmAM1808/uart_edma/uartEcho.c is still outputting garbage.

(It looks like the bootloader is already setting up enough DDR to get things working, so maybe we technically don't need u-boot. It would still be nice to include so people can still use ev3dev effortlessly by just plugging in the microSD card though.
Does anyone know if the EV3 bootloader source was ever released? Based on its output and jump address, I have a hunch that it is based on the bootloader example in the aforementioned StarterWare repo. We don't really need to know this. It's just to get a slightly better understanding of how things might work and which things are already enabled.)

[dlech]

Does anyone know if the EV3 bootloader source was ever released?

I guess you mean the first-stage bootloader that is in the EEPROM and not the second stage bootloader (U-boot)? No, that was never released. We can use i2cdump on ev3dev to read it though and reverse engineer it if we need to.

[laurensvalk]

Though on the bright side, the included edma example for an internal transfer (examples/evmAM1808/edma/edmaTest.c) does work, so maybe things are pretty close.

Welcome to EDMA/QDMA example application.

edma3Test: Data write-read matching PASSED.
edma3Test PASSED.

EDMA/QDMA application is successfully completed.

Does anyone know if the EV3 bootloader source was ever released?

I guess you mean the first-stage bootloader that is in the EEPROM and not the second stage bootloader (U-boot)? No, that was never released. We can use i2cdump on ev3dev to read it though and reverse engineer it if we need to.

Right. I don't suppose we truly need it at the moment.