Pinmux - enabling SPI

Hi Selsinork,

I've not looked at SPI on the BBB, but I'm glad you're attempting it.

I've been experimenting with I2C using C meanwhile - took a lot of google-search to finally realize that

bus enumeration 0 is the I2C0 as expected, but bus enumeration 1 is actually I2C2. Where I2C1 is I have no idea : -)

Once the c code is tidied I'll post it in a separate discussion in this element14 Development Kits > BeagleBone Black > Discussions location

I noticed that I could not write to the on-board I2C device address for the power mgmt ic (on I2C0) I guess the drivers protect against that (just mentioning in case when you come to test your SPI code in case you hit the same thing with an SPI on-board device).

I2C stuff is relatively easy, done quite a bit of that previously. 

I2C0 doesn't appear to be available on the expansion headers, so is largely irrelevant, it only seems to go th the PMIC and board ID eeprom.

I2C2 is muxed onto P9 pins 19 & 20, but I2C1 doesn't appear to be muxed onto P9-17,18.  I cheated, scope while running i2cdetect in a loop is quicker than google

I don't know enough about devicetree files yet, but it seems to me that this:

i2c@4802a000 {

                        compatible = "ti,omap4-i2c";

                        #address-cells = <0x1>;

                        #size-cells = <0x0>;

                        ti,hwmods = "i2c2";

                        reg = <0x4802a000 0x1000>;

                        interrupts = <0x47>;

                        status = "disabled";

                        linux,phandle = <0x23>;

                        phandle = <0x23>;

                };

is the reason for the missing i2c adapter.

So effectively the same problem as with SPI :

spi@48030000 {

                        compatible = "ti,omap4-mcspi";

                        #address-cells = <0x1>;

                        #size-cells = <0x0>;

                        reg = <0x48030000 0x400>;

                        interrupt = <0x41>;

                        ti,spi-num-cs = <0x2>;

                        ti,hwmods = "spi0";

                        dmas = <0x5 0x10 0x5 0x11 0x5 0x12 0x5 0x13>;

                        dma-names = "tx0", "rx0", "tx1", "rx1";

                        status = "disabled";

                        linux,phandle = <0x33>;

                        phandle = <0x33>;

                };

as I2C1 and SPI0 share some pins there's some potential for conflict, so this may be a sensible default..  but I'm not sure if it's even possible to get these working while they're forced off in device tree - even supposing that we find a way to setup pinctrl to allow us physical access.

decompiling the devicetree, changing the source, recompiling it and rebooting seems like a really hard way to do things - if we're unable to turn on peripherals or mux the function to specific pins at run-time I suspect it'll be a huge barrier to experimentation.

I just stumbled upon some devicetree stuff here http://omappedia.org/wiki/Device_Tree sadly I think this gives us another splintered place to look for information - the beagleboard wiki, elinux, omappedia... where next ?

Reading through the discussion at http://marc.info/?l=linux-omap&m=135758468811237&w=2 it appears that what we're going to get is an odd situation where everything is disabled and you need to enable stuff via a devicetree overlay that's either contained in the eeprom on the cape or referenced by it somehow. So buying a breadboardbreadboard cape becomes pointless as you can't enable any of the signals you'd like to use to prototype with ? 

I really have to be missing some crucial detail somewhere... but looking at all the *.dtbo files in /lib/firmware suggests otherwise.

Hi Selsinork,

selsinork wrote:

 

decompiling the devicetree, changing the source, recompiling it and rebooting seems like a really hard way to do things

Agree. I couldn't figure out if the .dtb/.dtbo files could be loaded afterwards or not from tons of googling last night. If they can, then that is great, but right now I'm not sure. I tried getting them built up manually from the .dts last night (when I thought the I2C1 may be disabled in there), but I ran out of disk space on my VM when downloading the environment, so I've increased that now and may try again tonight to see how it goes.

shabaz wrote:

 

Agree. I couldn't figure out if the .dtb/.dtbo files could be loaded afterwards or not from tons of googling last night. If they can, then that is great, but right now I'm not sure.

they do get loaded during boot, search for bone-capemgr in the output of dmesg.  It seems that it's querying the eeproms on the capes and using that to pick a dtbo, but I've not worked out what mechanism it uses to select one yet.

This stuff isn't in the vanilla kernel.org kernel yet and from the discussions on linux-omap it doesn't seem like it'll be accepted in quite the form we see on current BBB images. So even if there's a way to load a particular dtbo file from userspace later, I suspect those tools won't get written until the interface settles down. It strikes me that you'd need to be able to both add and remove overlays for it to be of any use though

The whole DT Overlays scheme seems to be driven by the beaglebone requirements anyway, so we just have to hope that a useful outcome is reached.

but that doesn't help us today, and the BBB is still too new for google to be of much help to us

shabaz wrote:

 

Agree. I couldn't figure out if the .dtb/.dtbo files could be loaded afterwards or not from tons of googling last night. If they can, then that is great, but right now I'm not sure.

they do get loaded during boot, search for bone-capemgr in the output of dmesg.  It seems that it's querying the eeproms on the capes and using that to pick a dtbo, but I've not worked out what mechanism it uses to select one yet.

This stuff isn't in the vanilla kernel.org kernel yet and from the discussions on linux-omap it doesn't seem like it'll be accepted in quite the form we see on current BBB images. So even if there's a way to load a particular dtbo file from userspace later, I suspect those tools won't get written until the interface settles down. It strikes me that you'd need to be able to both add and remove overlays for it to be of any use though

The whole DT Overlays scheme seems to be driven by the beaglebone requirements anyway, so we just have to hope that a useful outcome is reached.

but that doesn't help us today, and the BBB is still too new for google to be of much help to us