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.

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

I just tried decompiling the entire dtb to make a couple of mods (I wanted to go to 400kHz I2C and enable pruss) and then recompiling and sticking it back into /boot, but now it hangs on boot, so I'll have to re-flash it.

It was a drastic step but I thought I'd take the risk! The compiler was here.

I used the version of dtc supplied with angstrom and it worked ok. There's a log showing what I did over in one of the other threads about killing off the heartbeat led.

For all the talk of being able to have it show up as a storage device on a USB connected computer, that's problematic for two reasons - you can't see your dtb files from there and you need the kernel to boot and load the usb gadget driver before it works.

You'll still be able to get into u-boot over the serial console, perhaps there's something you can do from there to replace a working dtb?

For all the advantages of the onboard eMMC, if it becomes easy to brick the board (albeit not permanently), then I'm not so sure it's worth it.

As a last thought, you can probably get debian or some such like on a microSD, hold the button to boot from it, then access the eMMC to repair the dtb that way..

Hi Selsinork,

I used the actual dts source files this time (instead of extracting from the .dtb) and this time it worked ok (the clock is now 400kHz). Maybe I made a typo the first time. I'll check out the heartbeat thread to learn more about this dts stuff (and I may unsolder the blue LEDs to replace with green ones,

I too was wondering if I could do something at the u-boot stage, but in the end I just left it for 45 mins to reload the flash, but I may investigate that later.

Hi Selsinork,

A quick question, do you see /dev/uio0...7 files on your board?

At the same time as enabling the 400kHz I2C, I have enabled the PRU in the dts, but before when I messed up, I was using the older image (now I'm on the 8th May image), so I'n not sure if the /dev/uio0..7 which I see now is a result of the new image(it wasn't in the old image), or because of the PRU enablement that I changed in the dts.

I've tried building up one of the PRU examples, and finally it appears to run, so now I may spend some time learning the bare minimum assembler.

I'm still using the original image with the 3.8.6 kernel. There seems to be a fair number of differences, no uio* ircomm* for me, but I do have dri & fb0 which you don't. presumably there's other differences in the newer image as well.

t