Kernel/device tree road-map for the BBB

GoogleGroups
1

I am contemplating moving from 3.8.x to 3.13.x kernels due to the apparent improvement in USB support. I am confused, however, as to the state of device trees/overlays and their relationship with capes.

It appears to me that 3.8.x kernels use device tree overlays managed by an internal kernel cape manager, whereas 3.13.x kernels handle capes using Robert Nelson's "Really Simple Cape Manager" to patch and recompile the base BBB device tree.

My questions are:

a) Are the above assumptions correct?
b) Will the 3.8.x cape manager be ported to 3.13.x kernel or is RCN's rscm here to stay.
c) Any other pointers?

Any help would be appreciated.

Regards,

Dave.

2

I am contemplating moving from 3.8.x to 3.13.x kernels due to the apparent
improvement in USB support. I am confused, however, as to the state of
device trees/overlays and their relationship with capes.

It appears to me that 3.8.x kernels use device tree overlays managed by an
internal kernel cape manager, whereas 3.13.x kernels handle capes using
Robert Nelson's "Really Simple Cape Manager" to patch and recompile the
base BBB device tree.

My questions are:

a) Are the above assumptions correct?
b) Will the 3.8.x cape manager be ported to 3.13.x kernel or is RCN's rscm
here to stay.

sadly, it only works for 'simple' things.

c) Any other pointers?

I might have some free time this weekend..

The path i'm going to start heading for v3.13.x/v3.14.x is just to do
separate major cape dtb's..

So in u-boot: fdtbase=am335x-bone or am335x-boneblack

cape=xzy (defined in uEnv.txt (lcd4-a1/etc))

Then it'll just load:
$fdtbase-$cape.dtb

on bootup..

Regards,

3

I vote to keep things simple. Since there is no way to add or remove capes with the power on and since the hardware configuration rarely changes, why have an auto discoverable cape solution. Simply edit the uEnv.txt to add or remove cape settings is the best solution.

Regards,
John

4

Thanks Robert. That sounds like a good plan.

Dave.

5

Any updates on this?

6

Here's, just phase one to test the idea.
https://github.com/RobertCNelson/linux-dev/commit/685b182ca956dcd8396ca69af5c678c43a102d03

I'm heading out of the office in a little bit for the rest of day.
Probably won't have free time to add lcd3/4/7 till tomorrow.

Regards,

7

Using 3.13.5-bone5.1 on my BBB I have edited my uEnv.txt to include the line: cape=cape-bone-argus and I have the file: /boot/uboot/dtbs/am335x-boneblack-cape-bone-argus.dtb The above dtb does not load regardless of $cape. However if I copy am335x-boneblack-cape-bone-argus.dtb to am335x-boneblack.dtb, all works fine. Any pointers? Regards, Dave.

8

I just fixed this last friday, the 'cape' variable was used in the
wrong spot in u-boot so it never got used..

cd /opt/scripts/
git pull
./tools/update_bootloader.sh

Regards,

9

I am confused, where is this script? I have searched netinstall and linux-dev trees?

Dave.

10

yeah, that's on my todo list, I need to add it to the netinstall by default.

sudo mkdir -p /opt/scripts/
sudo chown -R (user):(user) /opt/scripts
git clone git://github.com/RobertCNelson/boot-scripts /opt/scripts

It's a git repo where i'm stashing help beagle scripts.

Regards,

11

Thanks Robert. That worked fine! I will send you a patch file of my cape code for inclusion in 3.13 shortly.

Again, thanks for all your help

Regards,

Dave.

12

Just a suggestion. If the dtb for the cape does not exist or is corrupted, could the device tree default to the base, for example am335x-boneblack.dtb?

Dave.

13

You read my mind, there is a new file test function, i'd like to
backport to v2014.01

http://git.denx.de/?p=u-boot.git;a=commit;h=e5e897c01b1cd496187ca56a38ff5559d27f951c

Then yes, we can set it to use the default *.dtb.

Regards,

14

Hey guys, I am trying to decide whether to stay on the 3.8 kernel or move to 3.13 myself… The reason is that my usb wifi dongle does not work in 3.8 but it does in 3.12+. I am fairly new and just became familiar with getting things to work using the device tree overlays and the cape manager; therefore I am a bit hesitant to leave 3.8… How straightforward would it be to configure SPI/PWM/etc using the rscm? Looking at Robert’s am335x-boneblack-default.dts patch, it seems like UART/I2C/TTY are enabled… Would a similar dts node be created for say PWM? Where would I get a template for that stuff - maybe the existing device tree overlays from 3.8?

Just wondering if it would be easier to move forward now, or stay on 3.8 and try and figure out how to get the wifi dongle to work…

15

@Chris:
Hi Chris, what usb-wifi devices are you using? Is this the only reason to move to 3.13? I have two wifi devices(Netgear WNA1100 and Logic Supply UWN200) working very reliably with RCN’s debian 3.8.13-bone41. Kernel drivers are built into -bone41 for both. I would recommend devices with these chipsets (Atheros or Ralink/Mediatek).
Regards - Eamonn

16

Eamonn,

I have this device, which I bought from adafruit… I looked around and saw a lot of people having problems with this guy.

Bus 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
http://www.adafruit.com/products/814

Yeah if it’s cheap, it might be better just to get a new adapter and save myself the hassle.

17

Hi Chris, I was using a TP-Link TL-WN725N wifi with the Realtek RTL8188 chipset, and I had a lot of problems with it. I think some of the issue may be the fact that the very small device pushes the antenna too close to BBB where you have a lot of nearby electrical activity (usb, hdmi, SD, DDR etc). I found that the larger devices worked very well, and the Atheros and Mediatek chipsets seem to be more reliable.
Hope that helps - Eamonn

18

Robert,
     It looks like I spoke too soon. Although my device tree appears to get loaded and my driver entry point is called with correct parameters, the pinmux does not appear to get set up correctly. Where do I look in 3.13 kernel based systems to debug the pinmux settings?

Best regards,

Dave.

19

Robert,
     It appears that the GPIO label numbering scheme has been changed from the device tree overlay's "1 to n+1", to the more con-formant 0 to n; I fell into this trap :-[ . I will send you my consolidated patch directly, once I had time to check it out further.

Sorry for the confusion. Regards,

Dave.

20

I think its because of this, the Adafruit Python GPIO library broke. Is there anyway to fix this? I fixed the I2C probably by changing the python file, but unsure how for the SPI.