26 Replies Latest reply on Jul 18, 2013 1:19 PM by shabaz

    Pinmux - enabling SPI

      As the Black has a new 3.8.x generation kernel, omap_mux has gone and we're in the realms of using pinctrl for setting up the pins on the expansion headers.

       

      Looking through the bonescript library it appears to try omap_mux and if that fails it just reverts to treating the pin as a gpio. That's all very well until you want to enable a PWM, UART, SPI etc.

       

      So does anyone know what magic is needed on the black ?   I'm suffering here from plenty of information on enabling SPI on the original beaglebone with a 3.2.x kernel, but basically zero info on the current state for the Black.

       

      /proc/config.gz says CONFIG_SPI_OMAP24XX=y and I've loaded spi-dev, still no /dev entries for spi and the pinmux settings look wrong.  I'm missing something or doing something wrong I'm sure, but right now it seems as if going through /dev/mem, behind pinctrl's back, might be the only way ?

        • Re: Pinmux - enabling SPI
          shabaz

          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).

            • Re: Pinmux - enabling SPI

              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.

                • Re: Pinmux - enabling SPI
                  shabaz

                  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.

                    • Re: Pinmux - enabling SPI

                      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

                    • Re: Pinmux - enabling SPI
                      shabaz

                      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.

                        • Re: Pinmux - enabling SPI

                          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..

                            • Re: Pinmux - enabling SPI
                              shabaz

                              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.

                              • Re: Pinmux - enabling SPI
                                shabaz

                                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.

                                 

                                bbb_dev.png

                                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.

                        • Re: Pinmux - enabling SPI

                          In the process of digging through the details of how to enable some of the extra peripherals through devicetree and what pinmux settings are required I came across some things in the tables on p71 & 73 of the BBB_SRM that I couldn't get my head around or that didn't look quite right.

                          Unfortunately working out if the table was even correct was less than easy as you need to cross correlate a table in the am3359 datasheet with a horribly akwardly formatted table in the AM335x Technical ref manual that's spread out over nearly 30 pages and see if that matches what's in the BBB_SRM.

                           

                          A lot of cut&pasting and processing with perl later I came up with my own version of the tables from the BBB_SRM, since I already did all the work, I thought I'd save anyone else the trouble and share them with you here.

                           

                          The mapping of pins on P8 & P9 to pin numbers on the SoC come from the BBB_SRM, that was then used to map to the data from the am3359 datasheet and TRM. The functions marked with a * are the default for that pin after reset, but your kernel can obviously change those before you get access. You need the pinmux register offset to understand what the pinctrl settings in the devicetree files are doing.

                           

                          Hope you find it useful..

                           

                           

                                

                          P8










                          PinCPU PinPin NamePinmux register offsetmode 0mode 1mode 2mode 3mode 4mode 5mode 6mode 7
                          1GND









                          2GND









                          3R9GPMC_AD60x818gpmc_ad6mmc1_dat6




                          *gpio1_6
                          4T9GPMC_AD70x81Cgpmc_ad7mmc1_dat7




                          *gpio1_7
                          5R8GPMC_AD20x808gpmc_ad2mmc1_dat2




                          *gpio1_2
                          6T8GPMC_AD30x80Cgpmc_ad3mmc1_dat3




                          *gpio1_3
                          7R7GPMC_ADVn_ALE0x890gpmc_advn_ale
                          timer4



                          *gpio2_2
                          8T7GPMC_OEn_REn0x894gpmc_oen_ren
                          timer7



                          *gpio2_3
                          9T6GPMC_BEn0_CLE0x89Cgpmc_be0n_cle
                          timer5



                          *gpio2_5
                          10U6GPMC_WEn0x898gpmc_wen
                          timer6



                          *gpio2_4
                          11R12GPMC_AD130x834gpmc_ad13lcd_data18mmc1_dat5mmc2_dat1eQEP2B_inpr1_mii0_txd1pr1_pru0_pru_r30_15*gpio1_13
                          12T12GPMC_AD120x830gpmc_ad12lcd_data19mmc1_dat4mmc2_dat0eQEP2A_inpr1_mii0_txd2pr1_pru0_pru_r30_14*gpio1_12
                          13T10GPMC_AD90x824gpmc_ad9lcd_data22mmc1_dat1mmc2_dat5ehrpwm2Bpr1_mii0_col
                          *gpio0_23
                          14T11GPMC_AD100x828gpmc_ad10lcd_data21mmc1_dat2mmc2_dat6ehrpwm2_tripzone_inputpr1_mii0_txen
                          *gpio0_26
                          15U13GPMC_AD150x83Cgpmc_ad15lcd_data16mmc1_dat7mmc2_dat3eQEP2_strobepr1_ecap0_ecap_capin_apwm_opr1_pru0_pru_r31_15*gpio1_15
                          16V13GPMC_AD140x838gpmc_ad14lcd_data17mmc1_dat6mmc2_dat2eQEP2_indexpr1_mii0_txd0pr1_pru0_pru_r31_14*gpio1_14
                          17U12GPMC_AD110x82Cgpmc_ad11lcd_data20mmc1_dat3mmc2_dat7ehrpwm0_syncopr1_mii0_txd3
                          *gpio0_27
                          18V12GPMC_CLK0x88Cgpmc_clklcd_memory_clkgpmc_wait1mmc2_clkpr1_mii1_crspr1_mdio_mdclkmcasp0_fsr*gpio2_1
                          19U10GPMC_AD80x820gpmc_ad8lcd_data23mmc1_dat0mmc2_dat4ehrpwm2Apr1_mii_mt0_clk
                          *gpio0_22
                          20V9GPMC_CSn20x884gpmc_csn2gpmc_be1nmmc1_cmdpr1_edio_data_in7pr1_edio_data_out7pr1_pru1_pru_r30_13pr1_pru1_pru_r31_13*gpio1_31
                          21U9GPMC_CSn10x880gpmc_csn1gpmc_clkmmc1_clkpr1_edio_data_in6pr1_edio_data_out6pr1_pru1_pru_r30_12pr1_pru1_pru_r31_12*gpio1_30
                          22V8GPMC_AD50x814gpmc_ad5mmc1_dat5




                          *gpio1_5
                          23U8GPMC_AD40x810gpmc_ad4mmc1_dat4




                          *gpio1_4
                          24V7GPMC_AD10x804gpmc_ad1mmc1_dat1




                          *gpio1_1
                          25U7GPMC_AD00x800gpmc_ad0mmc1_dat0




                          *gpio1_0
                          26V6GPMC_CSn00x87Cgpmc_csn0





                          *gpio1_29
                          27U5LCD_VSYNC0x8E0lcd_vsyncgpmc_a8gpmc_a1pr1_edio_data_in2pr1_edio_data_out2pr1_pru1_pru_r30_8pr1_pru1_pru_r31_8*gpio2_22
                          28V5LCD_PCLK0x8E8lcd_pclkgpmc_a10pr1_mii0_crspr1_edio_data_in4pr1_edio_data_out4pr1_pru1_pru_r30_10pr1_pru1_pru_r31_10*gpio2_24
                          29R5LCD_HSYNC0x8E4lcd_hsyncgpmc_a9gpmc_a2pr1_edio_data_in3pr1_edio_data_out3pr1_pru1_pru_r30_9pr1_pru1_pru_r31_9*gpio2_23
                          30R6LCD_AC_BIAS_EN0x8EClcd_ac_bias_engpmc_a11pr1_mii1_crspr1_edio_data_in5pr1_edio_data_out5pr1_pru1_pru_r30_11pr1_pru1_pru_r31_11*gpio2_25
                          31V4LCD_DATA140x8D8lcd_data14gpmc_a18eQEP1_indexmcasp0_axr1uart5_rxdpr1_mii_mr0_clkuart5_ctsn*gpio0_10
                          32T5LCD_DATA150x8DClcd_data15gpmc_a19eQEP1_strobemcasp0_ahclkxmcasp0_axr3pr1_mii0_rxdvuart5_rtsn*gpio0_11
                          33V3LCD_DATA130x8D4lcd_data13gpmc_a17eQEP1B_inmcasp0_fsrmcasp0_axr3pr1_mii0_rxeruart4_rtsn*gpio0_9
                          34U4LCD_DATA110x8CClcd_data11gpmc_a15ehrpwm1Bmcasp0_ahclkrmcasp0_axr2pr1_mii0_rxd0uart3_rtsn*gpio2_17
                          35V2LCD_DATA120x8D0lcd_data12gpmc_a16eQEP1A_inmcasp0_aclkrmcasp0_axr2pr1_mii0_rxlinkuart4_ctsn*gpio0_8
                          36U3LCD_DATA100x8C8lcd_data10gpmc_a14ehrpwm1Amcasp0_axr0
                          pr1_mii0_rxd1uart3_ctsn*gpio2_16
                          37U1LCD_DATA80x8C0lcd_data8gpmc_a12ehrpwm1_tripzone_inputmcasp0_aclkxuart5_txdpr1_mii0_rxd3uart2_ctsn*gpio2_14
                          38U2LCD_DATA90x8C4lcd_data9gpmc_a13ehrpwm0_syncomcasp0_fsxuart5_rxdpr1_mii0_rxd2uart2_rtsn*gpio2_15
                          39T3LCD_DATA60x8B8lcd_data6gpmc_a6pr1_edio_data_in6eQEP2_indexpr1_edio_data_out6pr1_pru1_pru_r30_6pr1_pru1_pru_r31_6*gpio2_12
                          40T4LCD_DATA70x8BClcd_data7gpmc_a7pr1_edio_data_in7eQEP2_strobepr1_edio_data_out7pr1_pru1_pru_r30_7pr1_pru1_pru_r31_7*gpio2_13
                          41T1LCD_DATA40x8B0lcd_data4gpmc_a4pr1_mii0_txd1eQEP2A_in
                          pr1_pru1_pru_r30_4pr1_pru1_pru_r31_4*gpio2_10
                          42T2LCD_DATA50x8B4lcd_data5gpmc_a5pr1_mii0_txd0eQEP2B_in
                          pr1_pru1_pru_r30_5pr1_pru1_pru_r31_5*gpio2_11
                          43R3LCD_DATA20x8A8lcd_data2gpmc_a2pr1_mii0_txd3ehrpwm2_tripzone_input
                          pr1_pru1_pru_r30_2pr1_pru1_pru_r31_2*gpio2_8
                          44R4LCD_DATA30x8AClcd_data3gpmc_a3pr1_mii0_txd2ehrpwm0_synco
                          pr1_pru1_pru_r30_3pr1_pru1_pru_r31_3*gpio2_9
                          45R1LCD_DATA00x8A0lcd_data0gpmc_a0pr1_mii_mt0_clkehrpwm2A
                          pr1_pru1_pru_r30_0pr1_pru1_pru_r31_0*gpio2_6
                          46R2LCD_DATA10x8A4lcd_data1gpmc_a1pr1_mii0_txenehrpwm2B
                          pr1_pru1_pru_r30_1pr1_pru1_pru_r31_1*gpio2_7












                          P9










                          PinCPU PinPin NamePinmux register offsetmode 0mode 1mode 2mode 3mode 4mode 5mode 6mode 7
                          1GND









                          2GND









                          33.3V









                          43.3V









                          5VDD_5V









                          6VDD_5V









                          7SYS_5V









                          8SYS_5V









                          9PWR_BUT









                          10A10









                          11T17GPMC_WAIT00x870gpmc_wait0gmii2_crsgpmc_csn4rmii2_crs_dvmmc1_sdcdpr1_mii1_coluart4_rxd*gpio0_30
                          12U18GPMC_BEn10x878gpmc_be1ngmii2_colgpmc_csn6mmc2_dat3gpmc_dirpr1_mii1_rxlinkmcasp0_aclkr*gpio1_28
                          13U17GPMC_WPn0x874gpmc_wpngmii2_rxerrgpmc_csn5rmii2_rxerrmmc2_sdcdpr1_mii1_txenuart4_txd*gpio0_31
                          14U14GPMC_A20x848gpmc_a2gmii2_txd3rgmii2_td3mmc2_dat1gpmc_a18pr1_mii1_txd2ehrpwm1A*gpio1_18
                          15R13GPMC_A00x840gpmc_a0gmii2_txenrgmii2_tctlrmii2_txengpmc_a16pr1_mii_mt1_clkehrpwm1_tripzone_input*gpio1_16
                          16T14GPMC_A30x84Cgpmc_a3gmii2_txd2rgmii2_td2mmc2_dat2gpmc_a19pr1_mii1_txd1ehrpwm1B*gpio1_19
                          17A16SPI0_CS00x95Cspi0_cs0mmc2_sdwpI2C1_SCLehrpwm0_syncipr1_uart0_txdpr1_edio_data_in1pr1_edio_data_out1*gpio0_5
                          18B16SPI0_D10x958spi0_d1mmc1_sdwpI2C1_SDAehrpwm0_tripzone_inputpr1_uart0_rxdpr1_edio_data_in0pr1_edio_data_out0*gpio0_4
                          19D17UART1_RTSn0x97Cuart1_rtsntimer5dcan0_rxI2C2_SCLspi1_cs1pr1_uart0_rts_npr1_edc_latch1_in*gpio0_13
                          20D18UART1_CTSn0x978uart1_ctsntimer6dcan0_txI2C2_SDAspi1_cs0pr1_uart0_cts_npr1_edc_latch0_in*gpio0_12
                          21B17SPI0_D00x954spi0_d0uart2_txdI2C2_SCLehrpwm0Bpr1_uart0_rts_npr1_edio_latch_inEMU3*gpio0_3
                          22A17SPI0_SCLK0x950spi0_sclkuart2_rxdI2C2_SDAehrpwm0Apr1_uart0_cts_npr1_edio_sofEMU2*gpio0_2
                          23V14GPMC_A10x844gpmc_a1gmii2_rxdvrgmii2_rctlmmc2_dat0gpmc_a17pr1_mii1_txd3ehrpwm0_synco*gpio1_17
                          24D15UART1_TXD0x984uart1_txdmmc2_sdwpdcan1_rxI2C1_SCL
                          pr1_uart0_txdpr1_pru0_pru_r31_16*gpio0_15
                          25A14MCASP0_AHCLKX0x9ACmcasp0_ahclkxeQEP0_strobemcasp0_axr3mcasp1_axr1EMU4pr1_pru0_pru_r30_7pr1_pru0_pru_r31_7*gpio3_21
                          26D16UART1_RXD0x980uart1_rxdmmc1_sdwpdcan1_txI2C1_SDA
                          pr1_uart0_rxdpr1_pru1_pru_r31_16*gpio0_14
                          27C13MCASP0_FSR0x9A4mcasp0_fsreQEP0B_inmcasp0_axr3mcasp1_fsxEMU2pr1_pru0_pru_r30_5pr1_pru0_pru_r31_5*gpio3_19
                          28C12MCASP0_AHCLKR0x99Cmcasp0_ahclkrehrpwm0_syncimcasp0_axr2spi1_cs0eCAP2_in_PWM2_outpr1_pru0_pru_r30_3pr1_pru0_pru_r31_3*gpio3_17
                          29B13MCASP0_FSX0x994mcasp0_fsxehrpwm0B
                          spi1_d0mmc1_sdcdpr1_pru0_pru_r30_1pr1_pru0_pru_r31_1*gpio3_15
                          30D12MCASP0_AXR00x998mcasp0_axr0ehrpwm0_tripzone_input
                          spi1_d1mmc2_sdcdpr1_pru0_pru_r30_2pr1_pru0_pru_r31_2*gpio3_16
                          31A13MCASP0_ACLKX0x990mcasp0_aclkxehrpwm0A
                          spi1_sclkmmc0_sdcdpr1_pru0_pru_r30_0pr1_pru0_pru_r31_0*gpio3_14
                          32VADC









                          33C8AIN4
                          *AIN4






                          34AGND









                          35A8AIN6
                          *AIN6






                          36B8AIN5
                          *AIN5






                          37B7AIN2
                          *AIN2






                          38A7AIN3
                          *AIN3






                          39B6AIN0
                          *AIN0






                          40C7AIN1
                          *AIN1






                          41D14XDMA_EVENT_INTR10x9B4xdma_event_intr1
                          tclkinclkout2timer7pr1_pru0_pru_r31_16EMU3*gpio0_20
                          41.1D13MCASP0_AXR10x9A8mcasp0_axr1eQEP0_index
                          mcasp1_axr0EMU3pr1_pru0_pru_r30_6pr1_pru0_pru_r31_6*gpio3_20
                          42C18ECAP0_IN_PWM0_OUT0x964eCAP0_in_PWM0_outuart3_txdspi1_cs1pr1_ecap0_ecap_capin_apwm_ospi1_sclkmmc0_sdwpxdma_event_intr2*gpio0_7
                          42.1B12MCASP0_ACLKR0x9A0mcasp0_aclkreQEP0A_inmcasp0_axr2mcasp1_aclkxmmc0_sdwppr1_pru0_pru_r30_4pr1_pru0_pru_r31_4*gpio3_18
                          43GND









                          44GND









                          45GND









                          46GND









                          • Re: Pinmux - enabling SPI
                            chli

                            I have been playing with dtbo to enable spi0 on the BeagleBone Black. You can read about it on inbedded.net. Hope that will help,

                             

                            Christophe

                              • Re: Pinmux - enabling SPI
                                morgaine

                                Hi Christophe, and welcome to Element 14's BBB community!

                                 

                                That's a  nice set of BBB articles at your site.  My discarded Nokia Communicator 9210 has been looking at me with some anxiety since I began reading your experiences interfacing the Nokia 3330's LCD.   The  9210 is a completely different beast of course, but I'll take a look on the net for info on its nice colour LCD, as it might well have an SPI or I2C interface like yours.

                                 

                                It's great to have more examples to help demystify Device Tree Overlays.  What's next on your BBB project plan?

                                 

                                Morgaine.

                                 

                                Addendum.  Scratch that for an idea, the 9210 schematics show that the display has a parallel interface driven by a bespoke chip.  Oh well, I'll find some other display to recycle, there's no shortage of old gear here.