[How-to] BB-View on latest Debian

It seems like latest debian image (2014-05-14) doesn't supports "DefaultDepth 24".

Is there a work-around ?

Luca:

The framebuffer is statically set to 16bpp in the TI LCD driver (tilcdc_drv.c, if you want to track it down). I sent patches to RNelson, which should generally fix the various problems and issues (like statically nailing the framebuffer depth to 16bpp.) I don't have a date for when the next debian binary will appear.

-scooter

Luca:

I can re-generate the patches for you if you're willing to recompile and reinstall your own kernel, using RNelson's linux-dev tree.

-scooter

Hi Scott, thanks for your answer and for your help.

I don't understand very well the problem. In the original post (the compeoree's post) he describe how to fix the color problem by putting "DefaultDepth 24" in xorg configuration. why doesn't it works for me?

The patch that you can re-generate for me what part of the problem does it solve?

Thanks

Luca:

There are various "depths" by which color is represented. Common values are 8, 16, 24, and 32 bits per pixel (bpp). This is a difference in semantics -- there is bits per pixel how the hardware steps through memory and reads pixels and there is color depth how pixels are represented. So, you can have 32 bits per pixel, where the hardware steps through 32 bit strides in memory when displaying a pixel, but only use 16 bpp color depth, where only 16 bits are used to represent color (most common is 5/6/5 R/G/B bits).

The TI LCD kernel driver statically initializes the framebuffer's color depth to 16 bits per pixel. You can't change it easily. Presumably, you might be able to change it using the 'fbset' command or by recompiling the kernel. There may have been a time when the Xorg configuration "DefaultDepth 24" might have worked, but a 16bpp framebuffer will not allow you to increase the color depth to 24bpp.

The reason why red and black are still swapped is that the element14 cape physically swaps red and black signals in the LCD cape. If you read through the TI AM335X silicon errata, you'll find that red and black are swapped in the 24 bpp color depth -- so, to fix it, element14 swapped the signals and assumed that the kernel's LCD driver initialized the framebuffer to 24 or 32 bpp by default. Except that the driver doesn't initialize to the higher color depth, so you're stuck in the 16bpp color depth looking at physically swapped red/blue with few options to fix the problem.

Confused yet? For the "tl;dr" crowd: element14 probably did the right thing by swapping signals in the device, the TI LCD kernel driver doesn't do the right thing yet.

What I did: I hacked for a couple of days to improve the TI LCD kernel driver. I added the element14 capes to the cape firmware sources. The TI LCD driver understands two flags that will cause the kernel to swap red and black in the color representation (to fix the 16bpp and 24bpp swaps). The TI LCD driver queries the device tree to pick up the requested color depth, which gives you 24bpp color depth for the element14 cape by default via my patches.

Once the kernel with my patches is built and distributed, none of the instructions on this wiki page will be necessary. RNelson accepted them, but I don't know when the new kernel will be distributed.

Things will just work. Batteries included. :-)

-scooter

Would be really nice if you could submit those patches to the mainline kernel. Not everyone uses, or wants to use, Roberts stuff.

Reading between the lines, I don't see them moving the default kernel on until they come up with a solution for capemgr in newer kernels. While there's been some progress in that area it still seems to be some way off getting into mainline.

People are still able to build from Roberts newer stuff - with your patch included - assuming they know it exists and can deal with the issues of no capemgr in an ecosystem that blindly assumes it's presence.

Meanwhile, Louis original instructions here, are now some six months old and the repo he cloned from no longer includes the branch he used.  Things have moved on, the instructions are out of date and really don't work anymore..   With your patch, or a version of it, in mainline these sorts of issues largely disappear and instructions can be provided here that are relatively stable, or at least don't bitrot quite as badly.

Scott, you were very clear! Thanks for the explanation.

Now it's more clear. I was confused by the fact that "DefaultDepth 24" didn't work for me with the latest Debian image (as the post's title says)...

Is your patches available for me to use and rebuild kernel? Where can I find it?

Thanks.

Is your patches available for me to use and rebuild kernel? Where can I find it?

Try https://github.com/beagleboard/linux/commit/2cb33ad1b767087899860f8de75c3af901748d99

selsinork:

You're absolutely correct: no capemgr in the 3.15.x branch right now, so the BBB community is "stuck" with 3.8.x. The alternative is to create a customized device tree file that conditionally enables a user's capes. Not optimal, not dynamic, but it would work. It's something I've considered hacking, in between other activities of mine (like managing a research department, having fun with Elvis the Labradoodle and other parts of living life... :-)

Even if capemgr magically showed up in 3.15, there are still parts of the TI board support package (BSP) that would have to migrate, notably all of the 3D accelerator code. Note that the 3D accelerator is a high priority GNU reverse engineering effort that seems to have stalled. Consequently, being "stuck" with 3.8.x is not necessarily as bad as it might seem.

-scooter

being stuck on 3.8.x will just become a bigger problem as time goes on. Robert already maintains a huge set of patches which is only going to grow.  I'm sure he has a life away from BBB too, so should he ever decide to give up maintaining things....

I'm fairly sure the SGX gpu code is never going to get into mainline for all sorts of reasons, but it's been my experience that everything else mostly just works as the TI guys have been working away in the background to make that a reality.  The unfortunate part is that BBB has diverged from TIs work enough that moving onwards has become difficult.  You can no longer easily take an overlay from 3.8 and apply it directly to 3.15, too much has changed.

Capes may or may not be a good thing, taking a concept like shields/capes from Arduino and trying to apply it to a much more complex linux/devicetree combination is certainly a much more difficult task.  Betting the farm on capemgr seems likely (hindsight being 20-20) to be the achilles heel of the whole thing - should something useable eventually get into mainline it's never going to be capemgr and whatever differences there are will end up being painful for both users and cape manufacturers alike.

What I find interesting is that there are many SBC's currently available, RPi, BBB, Cubieboard, OLinuXino, ODroid, Wandboard, Sabre-Lite, RIoTboard and the list goes on. Apart from BBB they all seem to manage just fine without capemgr or any sort of similar thing. So the capemgr concept stands out - by being the focal point for a lot of the pain.

being stuck on 3.8.x will just become a bigger problem as time goes on. Robert already maintains a huge set of patches which is only going to grow.  I'm sure he has a life away from BBB too, so should he ever decide to give up maintaining things....

I'm fairly sure the SGX gpu code is never going to get into mainline for all sorts of reasons, but it's been my experience that everything else mostly just works as the TI guys have been working away in the background to make that a reality.  The unfortunate part is that BBB has diverged from TIs work enough that moving onwards has become difficult.  You can no longer easily take an overlay from 3.8 and apply it directly to 3.15, too much has changed.

Capes may or may not be a good thing, taking a concept like shields/capes from Arduino and trying to apply it to a much more complex linux/devicetree combination is certainly a much more difficult task.  Betting the farm on capemgr seems likely (hindsight being 20-20) to be the achilles heel of the whole thing - should something useable eventually get into mainline it's never going to be capemgr and whatever differences there are will end up being painful for both users and cape manufacturers alike.

What I find interesting is that there are many SBC's currently available, RPi, BBB, Cubieboard, OLinuXino, ODroid, Wandboard, Sabre-Lite, RIoTboard and the list goes on. Apart from BBB they all seem to manage just fine without capemgr or any sort of similar thing. So the capemgr concept stands out - by being the focal point for a lot of the pain.