[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

Here's the board.  So I'm on a wild goose chase I think.  The J1 connected ribbon cable should probably have been taken out.

I'm reflashing my Debian ARM image.  I'm thinking I corrupted the image when I didn't wait until the 4 lights came on.  It seemed like

a long time (>45 min), and the 4 lights never came on.  But when I restarted on my HDMI, I saw the penguin, so at least part of

the image was flashed.  It never let me logon though, and the screen went blank, so the disable HDMI is working, but it's not starting up the LCD. I need to be

able to SSH into the BBB, or otherwise start over I guess.

> 45mins was common with the Angstrom images, but from what I've read it should be approx 15mins with debian.

if the HDMI disable has worked properly, then in theory you shouldn't see anything on the HDMI output as that driver won't load.  However as the LCD and HDMI framer share the same set of pins I suppose it's possible to have output on both if the timings work out and the monitor, by some miracle, supports the same timings.

To be sure you properly boot from the uSD to flash, be sure to remove power, hold the boot button, then apply power. The state of the button is only sampled at power-on, not reset, and the sampled state survives a reset, so you keep booting from uSD until you power cycle again.

OK.  New power supply.  I was using one that was older, though the specs were 5A, it seemed the lights were dimmer than using USB power.  This one is w/ the DC connector, and 3.5A 5VDC.  Lights seem brighter now.  Not getting anything on the display, not even a backlight.  Blue lights are blinking, Blue power light is on and bright.  On the cape, I noticed that the Green light is solid, but the red light (LED0) is off now.

Interesting.  I seem to remember that one of the LEDs on the cape was configured as heartbeat.  Perhaps that was the TI-SDK image then as looking at the overlay files I see:

gpio-leds-cape-lcd {

  compatible = "gpio-leds";

  pinctrl-names = "default";

  pinctrl-0 = <&bb_view_lcd_cape_led_pins>;

  bb_view_led0 {

    label = "bb-view:led0";

    gpios = <&gpio2 28 0>;

    linux,default-trigger = "none";

    default-state = "off";

  };

  bb_view_led1 {

    label = "bb-view:led1";

    gpios = <&gpio1 12 0>;

    linux,default-trigger = "none";

    default-state = "off";

  };

};

which implies they should both be off.

Are you able to ssh into the board, or to use a console cable?

If you are, you can look see if /sys/class/leds has bb-view:led1 & bb-view:led2 if those dirs exist, you can go into one of them and type "echo heartbeat > trigger" which should result in that led flashing a heartbeat pattern. Should that work the overlay would appear to be loaded ok.

Matthew Trippy wrote:

 

OK.  New power supply.  I was using one that was older, though the specs were 5A, it seemed the lights were dimmer than using USB power.  This one is w/ the DC connector, and 3.5A 5VDC.

As an aside, if your power supply is of the 'USB Charger' type, I'd refer you to the experiences of the Raspberry Pi people who found that the specs on the label on most of them simply can't be trusted...

A decent PSU is likely to be necessary with the LCD connected as you have and additional thing to power.

I've dug a little further -- the "No power control GPIO" message is preceded by other issues in the tilcdc driver initialization:

[   11.352494] pinctrl-single 44e10800.pinmux: pin 44e10850 already requested by rstctl.4; cannot claim for panel.14
[   11.363316] pinctrl-single 44e10800.pinmux: pin-20 (panel.14) status -22
[   11.370332] pinctrl-single 44e10800.pinmux: could not request pin 20 on device pinctrl-single
[   11.379250] panel panel.14: Failed to select default state
[   11.385039] panel: probe of panel.14 failed with error -22
[   11.391763] of_get_named_gpio_flags: can't parse gpios property
[   11.398041] tilcdc 4830e000.fb: No power control GPIO
[   11.403505] tilcdc 4830e000.fb: no encoders/connectors found
[   11.409480] tilcdc 4830e000.fb: failed to initialize mode setting

It looks like the tilcdc driver initialization bails because something else has control of the gpio_b1en pin (pin 20, J8) [I think... I could be wrong, but it seems reasonable.] LED0 on the cape doesn't get illuminated, which seems to be another indication that LCD7 doesn't initialize properly.

My device tree does show that the overlay loaded properly:

0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-VIEW-LCD7-01

Additional clue?

FOUND IT! Comment out "gpio1_28" in BB-VIEW-LCD7-01-00A0.dts, similar to this patch:

*** bb-view-kernel/kernel/firmware/capes/BB-VIEW-LCD7-01-00A0.dts       2014-04-18 11:49:33.949312435 -0700
--- KERNEL/firmware/capes/BB-VIEW-LCD7-01-00A0.dts      2014-04-18 17:34:43.232369345 -0700
***************
*** 47,53 ****
                "P9.21",        /* keys: gpio0_3 */
                /* the hardware IP uses */
                "gpio3_19",
!               "gpio1_28",
                "gpio1_16",
                "gpio1_17",
                "gpio1_19",
--- 47,53 ----
                "P9.21",        /* keys: gpio0_3 */
                /* the hardware IP uses */
                "gpio3_19",
!               /* "gpio1_28", */
                "gpio1_16",
                "gpio1_17",
                "gpio1_19",

Scott, that doesn't make a lot of sense. Unless you have a typo somewhere.

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

44e10850 is the thing that's stopping the overlay from loading, this corresponds to gpmc_a4 or gpio1_20. this is used for the emmc reset line, but isn't available on any of the expansion headers, so shouldn't conflict with the cape.

the gpio1_28 you've commented out would be 44e10878 which is P9 pin 12 and isn't used for anything on the BBB.

Ok, just a thought...  are you using a BB-Black, or the original White one ? 

I'm using the BeagleBone Black. Oddly enough, commenting out gpio1_28 got the LCD7 to operate on the 3.8.13-bone47 kernel branch. The board is at work, so any further answers will have to wait until Monday.

Right, and I'm not saying you're wrong.. just trying to fathom why commenting out gpio1_28 would make it work.  Others don't appear to have had to do that, so what's different about your setup?

Right, and I'm not saying you're wrong.. just trying to fathom why commenting out gpio1_28 would make it work.  Others don't appear to have had to do that, so what's different about your setup?

I'd have to look at my notes at work. IIRC, I had traced the pin 20 gpio in question to J8, but I'm happy to be proven incorrect. Might also want to look at why this cape needs exclusive access to a gpio that's not even accessible to the board and kernel source that manages exclusive gpio access. My PhD Spidey sense tells me something changed in the kernel with respect to exclusive access tie breaking. Also, the overlay loads just fine; it's the tilcdc driver that fails to initialize because omap gpio parsing fails.

A kernel change is always possible..  I gave up with the 'official' kernels that contain capemgr, there's just too many problems with it, and the original developer doesn't seem very interested in getting it accepted into the kernel proper which would likely lead to any issues getting resolved.

The tilcdc driver is indirectly tied to the pin configuration, so if there's a conflict  then that failure will propagate back up the tree and prevent the driver from loading.  You'll see something like this in the devicetree file:

panel {

     compatible = "ti,tilcdc,panel";

     pinctrl-names = "default";

     pinctrl-0 = <&bb_view_lcd_cape_pins>;

so if something in that pinctrl section conflicts then the whole panel section and the tilcdc driver will fail to bind

The tie-breaking used to work in a 'first to claim the pin wins' way. I think it'd be hard to do anything else.

A change to pinctrl is just a guess at this point, but not unreasonable. I'd have to stare at the kernel source for a bit to figure out what changed between 3.8.13 and 3.8.14. If there was a change from "first to claim" to "fix your code, exclusive means exclusive!", it's actually pretty reasonable -- only one driver should claim a pin exclusively (and a good way to get rid of persistent bugs that rely on execution order.)

The 3.14 kernel reorganized the location of firmware, otherwise, I'd likely go off and hack on that.

I'll create a diff between the two kernel dmesg's later this afternoon.

Digging around the 3.14 and 3.15 sources, capemgr is definitely gone and the various cape device trees migrated over to kernel/arch/arm/boot/dts. And... (wait for it)... each cape requires its own device driver. It's a pain, but probably better than trying to figure out why USB devices don't show up on the 3.8.13-boneXX kernel.

I will say that Debian + 3.14 feels more stable. Not looking forward to the hack-remote install-reboot software development sequence.

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.