To answer my own question, the solution was to remove the slot0 -> slot3
definitions from the device tree - that way, the cape manager runs, but
does not invoke the i2c driver to search for EEPROMs on the capes. This may
also speed up the boot, as it won't wait for the timeouts from each of the
We found that the manufacturer was willing to sell us as few as 10 units
with many of the large connectors left off for a unit price not much higher
than retail. We have a space-constrained application, and needed BBBs w/o
any of the 5 connectors on the "top" side in order to fit.
HTH, Andy
I've got a project going on a Beaglebone Black, where I need the I2C2 pins
(P9-19 and 20) to be timer inputs. So I've commented out the i2c2 entries
in the device tree, and have most things working. But I can't seem to get
to eMMC1 with this configuration. My theory is that the cape-manager
In my application, I would like to have a thread which is waiting for an
interrupt from one of the dmtimers. I see how this is being done through
the sysfs interface for gpio edges. Has anyone done anything similar for
the dmtimers, or have another suggestion for how to get this triggered? (I
Ok, as is usual, in hindsight, my error now seems massively idiotic. If
you call prussdrv_map_prumem, one gets a pointer to a region of memory,
whose beginning corresponds to a zero offset from the corresponding
constant table entry on the PRU. So, after having gotten that to work, I
decided
For my application, I want to write from the PRU into a large set of
circular buffers in the ARM DDR memory. Following various examples, I have
gotten this to work for small amounts of data, but when I attempt to write
"too much", I crash the Linux. To me, this is not surprising, as I don't
