element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Achievement Levels
    • Benefits of Membership
    • Feedback and Support
    • Members Area
    • Personal Blogs
    • What's New on element14
  • Learn
    Learn
    • eBooks
    • Learning Center
    • Learning Groups
    • STEM Academy
    • Webinars, Training and Events
  • Technologies
    Technologies
    • 3D Printing
    • Experts & Guidance
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Arduino Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Project Groups
    • Raspberry Pi Projects
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Or choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Single-Board Computers
  • Products
  • Dev Tools
  • Single-Board Computers
  • More
  • Cancel
Single-Board Computers
Forum Pinmux - enabling SPI
  • Blog
  • Forum
  • Documents
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Single-Board Computers requires membership for participation - click to join
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 26 replies
  • Subscribers 39 subscribers
  • Views 2891 views
  • Users 0 members are here
  • beagle
  • bbb
  • BeagleBone
  • bb_black
  • beagle_bone_black
Related

Pinmux - enabling SPI

Former Member
Former Member over 10 years ago

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 ?

  • Sign in to reply
  • Cancel

Top Replies

  • Former Member
    Former Member over 10 years ago +1
    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
  • morgaine
    morgaine over 10 years ago in reply to Former Member +1
    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…
Parents
  • shabaz
    shabaz over 10 years ago

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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 10 years ago in reply to shabaz

    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 image

     

    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.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • shabaz
    shabaz over 10 years ago in reply to Former Member

    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.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 10 years ago in reply to shabaz

    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 image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • Former Member
    Former Member over 10 years ago in reply to shabaz

    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 image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube