Hello,
I have an alternate driver (xeno_16550A) that I would like to try to use
for one UART while using the regular omap3-serial for all the others.
Is there a way to specify in the device tree which driver to use?
Alternately, could I have some kind of dummy entry in the device tree which
I'm not 100% sure about the 512MB of memory, but I suspect you'd be fine
after the initial setup of the memory controller.. probably best to look at
the memory controller section of the technical reference manual in order to
figure that out. I don't imagine you'd have to deal with any virtual
Hello all,
I wanted to put a new Debian image on one of my Rev C BBBs that I have
sitting around. It seems that the OS boots just fine now (LEDs are blinking
as usual), but it's now showing up as Netchip Beaglebone Black when it
was something else before (maybe Texas Instruments?) and I can't
Hi guys,
The new eMMC flasher images look very complicated compared to the old
ones.. what's the story on that?
The old one was very simple, just had a few files on it and it was easy to
replace the .img.gz with your own and modify the script to use your
filename.
I've just downloaded the
Hello guys,
I have a custom carrier board powering my Beaglebone Black through the 5V
supply pins on P9 (pins 5+6, I believe).
Because I'm having issues getting my working legacy Angstrom distribution
image cloned onto new boards that have Micron flash instead of Kingston, I
decided to give a
I have a Beaglebone Black with a recent Debian image that I loaded, we have
some SPI hardware on one of those proto-board things, which works totally
fine without the cape installed.
Then we have pass through pins and a cell network modem cape sitting on top
of that, which seems to work just
Update if anyone's curious,
I actually tried temporarily pulling the cape's corresponding overlay from
/lib/firmware (I think that's where it was) and booting up that way, and
SPI came back, so I believe that may solve my problem, otherwise I just
have to modify and re-build that cape.
--
For
OK, my possible understanding at this point is this:
Cape EEPROM has a name string on it.
BBB looks at that name string first and loads the matching file device tree.
For some reason, no other device tree overlays are loaded. SPI is not a
part of the overlay for this cape (confirmed by looking
Thanks for the reply,
I believe I've already gone into the uEnv.txt and tried to explicitly do
things like disable HDMI and enable the two SPI ports, (if I remember right
I added those to "enable_partno=" or whatever the syntax was).
But when I boot with the cape plugged in it seems to have no
