Hi all-
Recently I purchased an Element14 Beaglebone Black Rev C, with Debian Wheezy pre-installed. I was successful with Wheezy, but I had a requirement to upgrade the OS.
I installed Ubuntu Trusty (14.04) following the instructions at http://elinux.org/BeagleBoardUbuntu#Flasher.
However, my pins no longer seem to be working. I suspect I do not have something configured correctly, but I do not know where to look.
For example, I had something succesfully powered from P9_02 (Ground) and P9_06. I have tried all of the 5v Pins, but I do not seem to be getting power.
Could I have something misconfigured? Any help is greatly appreciated.
Thanks!
Matt
What output do you get from . .
$ uname -a
??
3.14.x kernels do not have capemgr, and the element14 beaglebone blacks come stock with 3.8.13-bone47 ( at least the 3 we ordered did ).
So, you will either have to downgrade your kernel to 3.8.x or use https://github.com/cdsteinkuehler/beaglebone-universal-io to set the pin config. I have not done this personally so could not say for sure exactly how . . .
Hey William, thanks for the reply.
The output of uname -a (and lsb_release) is:
matt@arm:~$ uname -a && lsb_release -a
Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Sat Oct 25 01:30:27 UTC 2014 armv7l armv7l armv7l GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
I would hate to downgrade the kernel back to 3.8, just to get the capes to work. I’ll give those overlays a try.
I’m surprised that all of these OS’s will work with the BBB, but do not have kernel support yet. I’m exceptionally new to the community, is there an OSS project working on this support somewhere?
Thanks again!
Matt
Hey William, thanks for the reply.
The output of uname -a (and lsb_release) is:
matt@arm:~$ uname -a && lsb_release -a
Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Sat Oct 25 01:30:27 UTC 2014 armv7l
armv7l armv7l GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
I would hate to downgrade the kernel back to 3.8, just to get the capes to
work. I’ll give those overlays a try.
If you need capes, you downgrade to 3.8:
sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone68
sudo reboot
I’m surprised that all of these OS’s will work with the BBB, but do not have
kernel support yet. I’m exceptionally new to the community, is there an OSS
project working on this support somewhere?
Umm... If we did 'not' have kernel support it would not boot.
Regards,
Hi Robert,
There is a lot of confusion about how to make external hardware / custom capes to work with the latest kernel.
For people, who do not want to downgrade or will need to update the kernel sooner or later (like myself)
can you kindly point to a tutorial/reading/explanation how to do it?
That will save a lot of frequent questions and doubts about the issue.
Trying to search for related documentation didn’t bring me anything.
Regards
Jan
Take a look at:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb
There is a dozen examples in that repo:
spi/usart/adc:
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-basic-proto-cape.dtsi
gpio/rtc/i2c:
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-rtc-01-00a1.dtsi
The default: "am335x-boneblack.dtb" also supports most pins with
Charle's config-pin:
https://github.com/cdsteinkuehler/beaglebone-universal-io
(you can ignore the initial overlay note, as it's loaded by default.)
I'm not really planning to document v3.14.x further, as something
special is planned to be merged for v3.19-rc1. (if your following the
device-tree mainline list)
Regards,
OK,
Thanks Robert.
And thanks for your hard work contributing to the community.
I will have a detailed study later as my first look here https://github.com/cdsteinkuehler/beaglebone-universal-io
(your last link) got me worried. It says:
"
Usage
Load the overlay as usual
echo cape-universaln > /sys/devices/bone_capemgr.*/slots"
… but there is no specified above directory.
Anyhow, don’t worry. I will leave it till later.
Cheers,
Jan
That's the part where i mentioned: "(you can ignore the initial
overlay note, as it's loaded by default.)" it's built-in to the
v3.14.x base dtb file..
Regards,
Hi,
If you want, I made a use case of dtb-rebuilter for kernel 3.14
https://github.com/khancyr/dtb-rebuilder/wiki
What is the reason the newer kernels do not have camepanager-support? Was it dropped out of current kernels for some strange reason or wasn’t it never part of a “official” kernel release?
I do not remember why. There was an explanation some months ago as to why, but the important question would be: “Will capemgr ever be in 3.14.x?” Then, I’m pretty sure the answer would be “NO!”
Charles’ universal io is enabled in the latest TI 3.14.x with pin configuration available via sysfs. So there is an alternative. At least I think, as I use 3.8.x in my own “production” images, but I have been exploring the latest TI 3.14.x kernel available via APT. I can tell universal io is there. config-pin is not( at least as far as I can tell - sudo which config-pin returns nothing ).
Anyway, I have a bit more to explore yet, but if what I am reading will work. Something like:
# echo <some_value> > <some_file> should configure the pins fine. So long as they’re available to use. Personally, I think this is great, Make it really easy to configure pins on an app by app basis.
Anyway, get back to me in a few days, I’ll possibly have a blog write-up on it next month. After new years of course . . .
Hi Robert,
I did this:
sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone68
sudo reboot
as you suggested, and my beaglebone never rebooted, it switched off and the user LED’s never came on again. I tried booting Ubuntu from my SD card again, the 4 USRx LEDs all light up after it appeared to be writing to the eMMC. After I restart, I get no LED action other than the PWR LED. How do I get it back up and running again?
Kind regards,
Lesiba Mahapa
@Matt -
Well, if you REALLY don’t want to go back, another thing you can try is to memory map the chip address space and directly control the pin registers.
Search for the android devmem.c utility. It’s a small C program that memory maps physical address space into user space. Compile and run it on the BBB. See the TI AM335x TRM (http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf) for physical memory locations for EVERYTHING on the chip. You need to understand the architecture a little because the ARM core accesses most SoC peripherals using the L3 or L4 buses (L1 and L2 are inside the ARM core.)
For example, to read the GPIO_DATAOUT register in the GPIO1 register set and then set the USR1 LED (bit 22):
sudo devmem2 0x4804c13c w
sudo devmem2 0x4804c13c w 0x400000
To confirm the device, read the device_id reg in the CONTROL_MODULE register set. This should always return something containing B944h and 17h - the unique JTAG id for the TI AM3358 chip.
sudo devmem2 0x44e10600 w
According to the BBB SRM you want to look in section 9.2.2 of the TRM for your pins.
Heh. I went back 
And this thread gave me a much better idea of the state.
Thank you to everyone who weighed in on this thread and I appreciate the hard work everyone puts into make this hardware and software available.
Cheers!
What's showing up in your usb-serial interface?
Regards,
Hi Robert,
I finally managed to get it back up again, I think that the devices I had connected to the GPIOs were interfering with. I am having trouble finding a way to enable my PWMs and UART with the 3.14 Kernel though. I am very VERY new at the beaglebone black, and the tutorials I am finding seem to be for the previous kernel. Please advise me (as simply as you can please ) on how to get them working.
Kind regards,
Lesiba Mahapa
Can you kindly point me to any info about what 3.19 is going to bring? Thanks!
Where's the fun in that! 
It's what "everyone" has been bugging me
about personally and on this list for over a year. if you can't
find it on the device-tree mailing list, you "didn't" want it bad
enough!!!
(Sarcasm!!! ;))
Regards,
A late holiday present, since RCN seems to be camped out a bit too close
to the eggnog!
It's device-tree changesets. This is basically what cape manager was
trying to do, but with the full support of the kernel developers behind
it which will hopefully result in fewer kernel crashes!
...some links to get you started:
http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/
http://lxr.free-electrons.com/source/Documentation/devicetree/changesets.txt