Enable can0, can1, adc and spi0 with dtb-rebuilder (Debian Jessy 8.4, 4.4.9-ti-r25)

Hello,

I’ve problems to change the device tree on debian jessie on my beaglebone black.

After boot, I need the following interfaces working:

  • can0
  • can1
  • spi0
  • adc
  • i2c2 disabled (to use both can interfaces, I need no cape eeprom support)

I’ve installed this image (and executed apt-get update && apt-get upgrade): bone-debian-8.4-iot-armhf-2016-05-13-4gb.img

Distributor ID: Debian
Description: Debian GNU/Linux 8.4 (jessie)
Release: 8.4
Codename: jessie

The Kernel Version is:

uname -a
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux

Previously I used a debian “wheezy” image with 3.8.13 kernel. But since that the device tree seems to changed a lot and now I’m stuck :frowning:

On wheezy I changed the am335x-bone-common.dtsi (get the source from https://github.com/derekmolloy/boneDeviceTree.git), for disabling i2c2 and enabling can0/can1/spi/adc. Then I rebuilded the am335x-boneblack.dtb and copied it in the /boot/dtbs/3.8.13-bone71 folder. To use the can-bus, I had to add the interfaces to /etc/network/interfaces:

`
auto can0
iface can0 can static
bitrate 500000

auto can1
iface can1 can static
bitrate 500000
`

After a reboot everything works fine. This was the result of many different tutorials about enabling periphery on beaglebone black. Propably it was not the right way, but I was glad that it finally worked :slight_smile:

For jessie I found the dtb-rebuilder, but everything I tried to change did not work. New debian, no function - it’s very frustrating…

Can someone explain me, how to work with the dtb-rebuilder, so I can enable at least both can interfaces?

Thank your very much!

https://github.com/RobertCNelson/dtb-rebuilder/commit/d664d9d5411d2242355cd777b0211a2a3268cfbe

Just un-comment what you want:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-custom.dts#L47-L65

Regards,

Robert,

Is that overlay included by default ?

Not yet..

is that a standard config for users?

can0, can1, spi0, adc ?

right now it's called am335x-boneblack-custom.dts what would be a good
name for it?

Regards,

Not yet…

is that a standard config for users?

can0, can1, spi0, adc ?

right now it’s called am335x-boneblack-custom.dts what would be a good name for it?

My guess is no, that is probably not a std config for most users. But I think the name is probably fine. I just had no noticed that file before, and it’s probably because you just committed it a couple hours ago.

However, what I was thinking since you said un-comment whatever you want working. Was that perhaps the file was already included, and people could just un-comment what they wanted to work. That I think might not be a bad idea. It would / could possibly help mitigate support needed to get some hardware peripherals working.

The includes for can0, can1 where in the repo prior, i just added back
spi0, and the adc details..

and there wasn't a real good non-overlay example,
"am335x-boneblack-custom.dts" that users can enable what they want till
today..

Regards,

The includes for can0, can1 where in the repo prior, i just added back spi0, and the adc details…

and there wasn’t a real good non-overlay example, “am335x-boneblack-custom.dts” that users can enable what they want till today…

Ah, ok cool.

I was just wondering if some sort of GUI tool would be useful or not. And then if so, what level of device tree manipulation would be required for said tool to be of real use.

https://github.com/strahlex/BBIOConfig

^ good starting point, built for 3.8/cape-universal

Regards,

but it would be cooler to build the functionality into bone101, then user
can edit it live thru nodejs and have it reboot with those changes.. :wink:

Regards,

but it would be cooler to build the functionality into bone101, then user can edit it live thru nodejs and have it reboot with those changes… :wink:

You know you’re certifiable right ? hehe, but you’re also right, and I just happen to know it is possible. So what exactly is bone101 ? Just the web stuff, or does it include bonescript ?

I ask because I do not personally use bonescript, but am instead writing my own code that does what bonescript does( maybe more ). But is also much simpler in nature. Currently, I’m also try to attempt to do all this without including a bunch of NPM packages to reduce code bloat, and to help keep things understandable. So others can read through the code and instantly understand what is happening. As a bonus side effect, I’m hoping this means that in order to enable one thing, like say GPIO, or ADC, that the developer just need drop in a single file such as gpio.js, or adc.js, then just require that file.

Like you, I really dislike npm, but I suspect for maybe different reasons . . . code bloat, and application function clarity are two of my own main concerns.

*but it would be cooler to build the functionality into bone101, then user

can edit it live thru nodejs and have it reboot with those changes.. ;)*

You know you're certifiable right ? hehe, but you're also right, and I
just happen to know it is possible. So what exactly *is* bone101 ? Just the
web stuff, or does it include bonescript ?

so bone101 is the default web page..

repo:

live testing:

https://beagleboard.github.io/bone101/Support/bone101/

I ask because I do not personally use bonescript, but am instead writing
my own code that does what bonescript does( maybe more ). But is also much
simpler in nature. Currently, I'm also try to attempt to do all this
without including a bunch of NPM packages to reduce code bloat, and to help
keep things understandable. So others can read through the code and
instantly understand what is happening. As a bonus side effect, I'm hoping
this means that in order to enable one thing, like say GPIO, or ADC, that
the developer just need drop in a single file such as gpio.js, or adc.js,
then just require that file.

Like you, I really dislike npm, but I suspect for maybe different reasons
. . . code bloat, and application function clarity are two of my own main
concerns.

npm and i get along now. :wink:

I've given up on "npm install xyz" in a deb package and now just pre-build
them:

it's an extra step before updating the *.deb package, requires a dedicated
bbg for pre-building the *.tar.xz, but my sanity has never been better! :wink:

Regards,

it’s an extra step before updating the *.deb package, requires a dedicated bbg for pre-building the *.tar.xz, but my sanity has never been better! :wink:

So, I can tell you have not recently done anything like sudo npm install -g phantomjs . . . where phantomjs only has x86 / x86-64( maybe amd64 ) binaries. I have, and then spent 3 days trial and error compiling phantomjs on my rpi3 ( more memory, and more cores . . .), when i finally got it compiled, and installed locally. . . the flipping package that needed phantomjs still barfed on installation . . . as the other crap needed arm binaries too, and no way in hell I was going ot step into that huge pit.

It turns out that I only needed that package anyhow for a development dependency for some stupid other package that I do not need when deployed. . . . So I can write the code on an x86 machine, and just rip the needed source out for deployment onto the BBB . . .

So your sanity is different form mine in that you seem to have learned to just bypass the whole npm situation, where as a Nodejs developer - I can’t. Trust me though, I really wish I could, and it is partly why I’m writing my own Javascript wrapper for the BBB’s sysfs access to the peripherals.

So, if you ever looked at my G+ page, where it states “list bragging rights” and for my bragging rights I wrote " Having learned a good bit about javascript without losing my mind . . ."

The above, and situations like it are part of that meaning :wink:

it's an extra step before updating the *.deb package, requires a dedicated

bbg for pre-building the *.tar.xz, but my sanity has never been better! :wink:

So, I can tell you have not recently done anything like sudo npm install
-g phantomjs . . . where phantomjs only has x86 / x86-64( maybe amd64 )
binaries. I have, and then spent 3 days trial and error compiling phantomjs
on my rpi3 ( more memory, and more cores . . .), when i finally got it
compiled, and installed locally. . . the flipping package that needed
phantomjs *still* barfed on installation . . . as the other crap needed arm
binaries too, and no way in hell I was going ot step into that huge pit.

Yeah, that still happens for me too..

It turns out that I only needed that package anyhow for a development
dependency for some stupid other package that I do not need when deployed.
. . . So I can write the code on an x86 machine, and just rip the needed
source out for deployment onto the BBB . . .

So your sanity is different form mine in that you seem to have learned to
just bypass the whole npm situation, where as a Nodejs developer - I can't.
Trust me though, I really wish I could, and it is partly why I'm writing my
own Javascript wrapper for the BBB's sysfs access to the peripherals.

Yeah, my sanity is a little different..

Initially i was trying to have the deb package run "npm -g install xyz" and
update it on the user platform based on the version of nodejs..

I've changed that too:

I'm going to pre-build the package on jessie with nodejs v0.12.x and ship
it to the jessie users as is. :wink: (well the deb package has a hard
requirement of nodejs (>= 0.12.13))

Regards,

I’m going to pre-build the package on jessie with nodejs v0.12.x and ship it to the jessie users as is. :wink: (well the deb package has a hard requirement of nodejs (>= 0.12.13))

Yeah . . . I’m using node -v: v4.2.6 npm -v: 3.9.0

Part of my own problem is that I am following a few different guides on technologies I do not know all that well. So I’m forced to use the packages these people are using until I understand things better. The problem being, many of these guides in using, the packages they mention require current versions of node. I tried using v0.12 / v0.10 version of node, and for the purpose of the guides I’m following - They failed( broken dependencies ).

I’m also still learning how things work package wise as for what exactly is really needed when you finish a project. It’s currently what I’m calling “dependency hell”. As in there is so much bloat / garbage, it’s hard to figure out what truly is needed in order for the application to work properly.

Hello Robert,

thank you for your response!

Unfortunately I don’t get it work :frowning:

What I did:

  1. Downloaded the new changed dtb-rebuilder with the new files to the beaglebone
  2. Un-commented everything (can0/1, spi and adc) in am335x-boneblack-custom.dts
  3. Went to the dtb-builder directory (cd dtb-rebuilder-4.4-ti/)
  4. ./dtc-overlay.sh
  5. make
  6. make install
  7. Downloaded and installed canutils (git clone https://github.com/linux-can/can-utils.git)
  8. shutdown -r now

After the reboot, i tried to send a can message to my can test laptop:
cansend can0 100#deadbeef

But BBB told me: “write: Network is down”

So I started:

ip link set can0 up type can bitrate 500000
cansend can0 100#deadbeef

But nothing happens. I checked all can-pins with the scope, there was no output signal. dmesg output looks good for me:
root@beaglebone:/sfb/devicetree# dmesg | grep can
[ 32.566162] c_can_platform 481cc000.can: c_can_platform device registered (regs=fa1cc000, irq=208)
[ 32.623212] c_can_platform 481d0000.can: c_can_platform device registered (regs=fa1d0000, irq=209)
[ 60.805589] can: controller area network core (rev 20120528 abi 9)
[ 60.819806] can: raw protocol (rev 20120528)
[ 194.863977] c_can_platform 481cc000.can can0: setting BTR=1c02 BRPE=0000
[ 194.864175] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

After that I tried the adc, but the expected folder /sys/bus/iio/devices/iio:device0 wasn’t there, so I think the adc doesn’t work too.

Can you tell me, what I did wrong?

Regards,
Andre

CAN is running now :slight_smile:

There were two errors:

  1. I didn’t know that I have to add

dtb=am335x-boneblack-custom.dtb

to the /boot/uEnv.txt

  1. In line 43 of

src/arm/am335x-bone-pinmux-spi0.dtsi

stands “&dcan0 {” instead of “&spi0 {”

CAN and ADC are fine now. I’ve a little trouble with SPI, but this could be my software.

Hey Andre,

I also need to active CAN0, CAN1, SPI and ADC.

I got CAN0 working without a dtb file. But what i read so far, is that there will be conflicts with i2c when i try to enable CAN0 without pinmuxing it right…

If i take a look to the dts (am335x-boneblack-custom.dts) for beaglebone black (#include “am335x-bone-common-no-capemgr.dtsi”) and dts (am335x-bonegreen-wireless.dts) for beaglebone green (#include “am335x-bone-common.dtsi”) there is a big difference with the capemgr.

Is the am335x-boneblack-custom.dts compatible to beaglebone green?

Regards,
Jan

Andre,

I’m using the same BeagleBone image, but I’ve been unable to get the BeagleBone to boot after I followed your step-by-step instructions. Do you know if anything has changed in the dtb-rebuilder since you were successful in enabling can0?

Thanks,
Jay

Dear Andre and Robert,

Thank you for the information published. It has been great help!!!
Tested with => Debian 8.7 2017-03-19 4GB SD IoT image

Let me update the steps:

  1. git clone https://github.com/RobertCNelson/dtb-rebuilder
  2. Un-commented (can0/1) in am335x-boneblack-custom.dts
    (After line 47)
  3. cd dtb-rebuilder/
  4. /dtc-overlay.sh
  5. make
  6. make install
  7. sudo modprobe can
  8. sudo modprobe can-dev
  9. sudo modprobe can-raw
  10. git clone https://github.com/linux-can/can-utils.git
  11. cd can-utils/
  12. ./autogen.sh
  13. ./configure
  14. make
  15. shutdown -r now