Search results

So, wiggling GPIO pins from the M4 works! :D I couldn't find any documentation on how to do it properly or find any official drivers, so it was super dirty instead xD Just look up the registers I need to manipulate in the datasheet, convert their addresses to M4 address space, and voila: //...

There is no question that any driver on A that talks to a device D1, which M also want to talk to, will have to be synchronized. However, for device D2, D3, etc., I don't see a need for synchronizing their drivers unless M also wants to talk to those devices. At the bare minimum, the i2c driver...

This is exactly the things I've tried to talk about in my previous replies. This would be solved by writing a custom I2C driver. It would be transparent for every driver that needs to talk I2C. Exactly! It increases the complexity for M.

I still think the easiest solution is to use the HW semaphores. On the Linux side, it would be something like this to synchronize the i2c driver: --- drivers/i2c/busses/i2c-omap.c.orig 2022-08-18 23:22:38.784631762 +0200 +++ drivers/i2c/busses/i2c-omap.c 2022-08-18 23:43:04.655767062 +0200...

Crap! While writing I was thinking "I need to remember to change those variables to volatile", then I completely forgot xD I've updated the example now :oops: That's an interesting design! I didn't think about using M as a cache for A to avoid unnecessary reads. The remoteproc subsystem in...

For those of you who are a stranger to how CPUs talk to hardware, I can say that it's not really that complicated. There are exceptions of course, and this is a bit of a simplification, but the vast majority of hardware is done by connecting everything to the same big address bus. So, you wanna...

The A15 and M4 cannot perceive the other reading and writing to the memory registers that are mapped to the I2C HW. The reads and writes to the L3 main interconnect bus are synchronized by the L3 bus arbiter, but there is nothing indicating that someone else is "using" the i2c HW right now. How...

Went on a bit of an online hunt for information about the TWL6037 and here's what I gathered: The Linux device tree documentation lists the following chips as compatible with the "Palmas" series: twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) tps659038 tps65917 The...

There are definitely more complicated devices, with internal state, that can be connected to i2c. The majority of i2c devices are simple though, and more complex devices usually end up connected to SPI or some other bus instead. Just by reading the TWL6037 ADC driver, there are at least 2...

The OMAP5432 I2C HW supports multi master mode natively, which means that two masters on the same bus wouldn't cause an issue. However, this is not a multi master situation. Both processors will be accessing the very same peripheral: +---------+ Cortex-A15 ---| L3/L4 |...

Yes, it would be a horrible solution. What if the M4 has crashed and is unable to send an ack? I think hw semaphores is the way to go. The problem is that it's not multiple senders, it's two processors using the same peripheral. The device we're talking to has no idea which of the processors...

The message passing mechanism RPMSG should already handle synchronization. IIRC, rpmsg is built on two shared RAM areas - one in each direction - for messages and then interrupts to notify the other side a new message has arrived. Synchronization is part of the specs. My use case is the few...

Okay, some progress! :D I got the TI example project ping_rpmsg working, which means I can send RPMSG between the two processors. On the Linux side, it works basically like network connections: Create a socket() For sending: connect() to a remote address+processor ID send() For receiving...

Haven't had the time to continue working on this much lately, and next week I'm away again for another week. Maybe in two weeks™? :)

Well this is almost embarrassing o_O how could this have gone through QA? Here's a patch that fixes their MessageQ example code: diff -Naur ipc_3_40_01_08/packages/ti/ipc/family/omap54xx/VirtQueue.c{.orig,} --- ipc_3_40_01_08/packages/ti/ipc/family/omap54xx/VirtQueue.c.orig 2022-07-25...

Short update: Reverting this commit made their TI ex02_messageq example work! :D https://git.ti.com/cgit/ipc/ipcdev/commit/packages/ti/ipc/family/omap54xx/VirtQueue.c?id=65dd9f72be2c47457e5e5f169d59cf658b9b1d08 I'll do some more digging and see if I can come up with a bit more elegant fix :)

Okay, did some last minute testing before vacation travels. Looks like the ping_rpmsg test firmware doesn't crash. However, now I'm stuck fixing their userspace application instead. Their build system didn't pick up the headers from my kernel and got the wrong value for AF_RPMSG. Luckily, their...

What about a Freescale/NXP i.MX processors? They tend to have outstanding Linux support with good power management options. They have their ULP (Ultra Low Power) line that would probably be a good match for the Pyra. The core CPU is either Cortex-A53 or Cortex-A72, and the graphics chip is a...

Did some more experimenting today, but got stuck. The plan was to be able to run one of TI's examples, but no matter what I tried, it died on an assertion in early boot. I got the exact same issue on both TI example code (modified for OMAP5432) and their verification test code (written...

Example clock: clk32kgaudio. This is what Linux has to say about this clock: # cat /sys/kernel/debug/clk/clk_summary enable prepare protect duty hardware clock count count count rate...