[How-to] BB-View on latest Debian

Regarding Patching the Kernel:

My "touchscreen" is in your linux-dev repository, but not in the angstrom source.  Should we do the cp FROM your linux-dev repository TO the ANGSTROM source?

I pulled the source directly from the Element 14 site, and the file (unzipped) was:  bb-black-kernel-3.8.13-bb-view.tar.bz2.  It doesn't seem to have these files.  If your source already has them, why are we rebuilding the Kernel?

Also, with the addition of the LCD line to the Makefile, can you id where it needs to go (functionally), rather than just mentioning a line numbers, so I know I have this right?

Thanks.

> unzip angstrom-source.zip

> tar -zxf bb-black-kernel-3.8.13-bb-view.tar.bz2

> cp ./kernel/kernel/drivers/input/touchscreen/ti_am335x_tsc.c  ~/bb-view/linux-dev/KERNEL/drivers/input/touchscreen/

> cp ./kernel/kernel/firmware/capes/BB-VIEW-LCD7-01-00A0.dts  ~/bb-view/linux-dev/KERNEL/firmware/capes/

@Matthew Trippy

Is the rest of the Angstrom source visible? Are the other source folders present and populated?

The reason for copying the angstrom tsc file to the linux-dev was to get most of the changes copied over to the Debian build under linux-dev. You are not building Angstrom, so you don't need to copy from the linux-dev folder back to the Angstrom folder.

The reason for compiling the kernel is to enable touchscreen support. If you don't need the touch screen controller, you don't have to recompile. The LCD7 uses a non-standard connection method, so the analog pins have to be read in a different order, by the tsc driver.

The makefile line placement is not critical. I just included it close to where the other dts files where getting added, so I could find it again if I needed to change anything.

Louis

Yep, Robert has put some work into building static devicetree files for the 3.13+ stuff he's been working on.

Taking a step back and looking at other similar SBCs like the OLinuXino or Sabre-Lite or Wandboard, none of them use capemgr. They all go with the same static devicetree method.  I wouldn't class it as a pain, it's just different. Thing is that it just works, and unless you're hot-plugging capes the inconvenience is small.

I don't know what the problem was, but hot-plugging usb devices on the 3.8.x kernels required having a usb hub connected to the BBB. Anything plugged in directly would only be detected at boot. That one is a known problem and had been there since the BBB was released.  Given nobody has managed to fix it in the last year probably means it's not going to get fixed - at least for 3.8.x

So what does capemgr do? It basically maintains a list of what capes are available based on EEPROM signatures. It probably does too much, which is likely why kernel maintainers won't include it in the 3.14/15 codebase (if my reading of 20+ kernel dev history is accurate.) In the short term, however, it looks like I'll have to stick with the 3.8.13 variant (<sigh!>)

I haven't seen any activity related to BBW/BBB/BBxm cape activity in the newer kernels, but here's what I'd likely propose so that the cape device management fits into the overall static device tree strategy:

(a) Refactor capemgr into a library for probing device signatures.

(b) Add the necessary driver code for the BB View LCDs, along with their device trees (BTW: the format has really changed for DTS structure.)

The upside of this approach is that the end user can choose which capes are compiled into the kernel or shipped as modules. Another upside of the module approach is that modules can be selectively disabled, which eliminates the magic enable_cape and disable_cape kernel cmdline strings.

One thing I did notice in the current set of device tree files is that the HDMI framebuffer is integral to the BBB device tree. I'm not sure if there's any harm in having two frame buffer devices in the kernel, but would lead to obvious confusion in the end user's X11 configuration. It doesn't look like the HDMI device is actually disabled; it's just not part of the device tree interrogated by X11, so it's never found.

But I'd hate to duplicate effort, so if there is an existing effort/project, I'd really like to get in touch with them. Robert isn't particularly responsive, for obvious reasons.

To be more specific:

• Refactor capemgr into an EEPROM probing-only library. Could cache results, if desired.
• Driver for BB View 7", 4.3" LCDs, using libcapemgr probes for its EEPROM signature. If found, continue to populate the appropriate device tree, otherwise, abort module/driver loading.

Basically splits the driver loading into two conceptually distinct phases, which capemgr currently does in one step. I suspect that other cape device drivers would have similar code, which is probably what capemgr was attempting to avoid in the first place. However, it's not generally in line with Linux kernel evolution -- there's a preference for a module-driven elegance that Robert, et. al., look like they're moving toward, even if it results in templated code (but configurable via *config.)

panto is the original developer, and it looks like he's trying again here

http://thread.gmane.org/gmane.linux.drivers.devicetree/68674

That was three weeks ago and not a single reply. Usually he gets some interest from at least FPGA people who also like the idea.  You can search the archives, he's proposed variations on the idea several times, usually about a year inbetween tries and the discussion seems to die off quickly even when not outright rejected.

Last time I looked (before the attempt in the above link) he was proposing a very simple thing that just allowed loading the overlay, much like loading modules today, and letting userspace do the hard work of identifying what to load, resolving conflicts etc.

It's worth reading through the discussions on his previous attempts if you're at all interested in this stuff, there are some good reasons why it's never been accepted.  Yet it's still unclear to me why the idea always seems to get dropped instead of working through the concerns.

The problem you have with things like the BB-View is that they have no eeprom, so your libcapemgr idea can't probe for it.  Unfortunately it's an inherent weakness in the the design - there's no absolute requirement to have an eeprom, unlike something like pci or usb where you have to follow the spec.

Displays are also problematic as you probably want them initialised early, a slow boot with a blank screen because you have to wait for userspace to configure the display won't be acceptable for many.

Scott Michel wrote:

 

One thing I did notice in the current set of device tree files is that the HDMI framebuffer is integral to the BBB device tree. I'm not sure if there's any harm in having two frame buffer devices in the kernel, but would lead to obvious confusion in the end user's X11 configuration. It doesn't look like the HDMI device is actually disabled; it's just not part of the device tree interrogated by X11, so it's never found.

I didn't look in detail, but I assume that what happens is the status property for the node is changed from 'okay' to 'disabled'. When that's done the whole section in the tree should be ignored.

There's no generic problem in having more than one display device enabled. The problem for the BBB is that both the HDMI framer and LCD capes use the same set of pins on the SoC which makes it impossible to use both HDMI and LCD at the same time.  Other boards don't have that particular limitation.

Isn't gpmc_a4 the same as gpio2_10 in mode 1? I'm looking at page 83 of the BBB-SRM.pdf manual.

Isn't gpmc_a4 the same as gpio2_10 in mode 1? I'm looking at page 83 of the BBB-SRM.pdf manual.

No, you're mistaking the logical function with the physical pin. The physical pin name for P8.41 is LCD_DATA4

The tables in the SRM are mostly useless as they omit the important information.

You're looking at this line from the BBB_SRM

<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>

The important part is the T1 in the second column which refers the the physical ball on the BGA package

Look in the AM3359 datasheet and you'll see this on page 31

<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>

Then in AM335x Technical reference manual on page 759 you'll find

The 8B0h refers to the offset from the base address of the control module which you'll find on p158

Which gives you a pinmux address of 44e108b0,

You pasted the boot log where it says

[   11.352494] pinctrl-single 44e10800.pinmux: pin 44e10850 already requested by rstctl.4; cannot claim for panel.14

so, different address means different physical pins.

Your 44e10850 is

on p758 of the TRM.  Go back to the datasheet and look for the 'Pin Name' GPMC_A4

Note the ball number of R14 this time

In the BBB_SCH.pdf, you'll find it on page 3

<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>

It's the one connected to that inverter which then goes to eMMC_RSTn,  follow it through the schematic and you'll find that's the only thing it's connected to.

So, going back to the message from your log

[   11.352494] pinctrl-single 44e10800.pinmux: pin 44e10850 already requested by rstctl.4; cannot claim for panel.14

So we have a pin that's used to reset the emmc being claimed by the rstctl (or reset control) driver.  That seems to make a lot of sense.

As the pin doesn't connect to the expansion headers at all, it makes no sense whatsoever that it would conflict with a cape overlay that can't physically connect to the pin.  So that leads to the thought that there's either something wrong with the overlay you're using, or there's something wrong with how capemgr is attempting to merge the overlay into the base devicetree.

Ok, hope that explains how I got from A to B...  If you're head's spinning trying to follow it, I absolutely understand.. The information being split across three documents makes finding exactly what's going on difficult at best.

I should probably have mentioned.  The BBB_SRM falls into a common trap of giving P8.41 a 'vanity name' of gpio2_10 when the SoC datasheet and schematics refer to the actual physical pin differently.

The Raspberry Pi did it too and caused a pile of confusion by naming GPIO10 on the SoC GPIO8 on the expansion connector (I forget the actual mapping).

There's no point to doing this, as we've seen you can configure the pin in software to be many different things, so it's better to just use the correct names from the SoC datasheet. That's what Linux will use since the same SoC could be in multiple different boards  where the pin gets used differently.

So my advice is to ignore the SRM, use the schematics and the SoC datasheet and TRM directly.

I finally got the 7" LCD to work on 3.8.13-bone47, without the LEDs or the buttons enabled in the device tree. Still working on debugging those. How's the best way to send updated instructions and patches to files under KERNEL?

Upside: More patches from Robert Nelson that enables better networking, USB.

Downside: Cape LEDs and buttons are temporarily disabled, must reinstall the kernel modules.

And I've made further progress: Keys work and LED 1 works. LED 2 still has a conflict with i2c:

But that looks like it's possibly a conflict in device tree source.

What appears to have been missing in the BB-VIEW-LCD7-01-00A1.dts source:

@@ -6,7 +6,7 @@

  * published by the Free Software Foundation.

  */

/dts-v1/;

-/* /plugin/; */

+/plugin/;

/ {

@@ -273,6 +273,7 @@

                                interrupt-parent = <&intc>;

                                interrupts = <36>;

                                ti,hwmods = "lcdc";

+                               ti,power-gpio = <&gpio1 2 0x0>;

                        };

                };

Not sure why the /plugin/ is significant, but without it, no joy. The "ti,power-gpio" is also necessary. Also, blue/red swap still happens and you can't use the default depth hack to xorg.conf.

And I've made further progress: Keys work and LED 1 works. LED 2 still has a conflict with i2c:

But that looks like it's possibly a conflict in device tree source.

What appears to have been missing in the BB-VIEW-LCD7-01-00A1.dts source:

@@ -6,7 +6,7 @@

  * published by the Free Software Foundation.

  */

/dts-v1/;

-/* /plugin/; */

+/plugin/;

/ {

@@ -273,6 +273,7 @@

                                interrupt-parent = <&intc>;

                                interrupts = <36>;

                                ti,hwmods = "lcdc";

+                               ti,power-gpio = <&gpio1 2 0x0>;

                        };

                };

Not sure why the /plugin/ is significant, but without it, no joy. The "ti,power-gpio" is also necessary. Also, blue/red swap still happens and you can't use the default depth hack to xorg.conf.