Solved How to use LCD with BeagleBone?

This is not about X. In general. For example, how to get console on LCD?

When running the official FreeBSD 12.0 for BeagleBone I see:
Code:
% grep fb0 /var/run/dmesg.boot
fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0
But there is no such device node. Am I missing something?
 
Thanks, Phishfry, I've seen that. But...
The patch is in the head already. Many things are related to HDMI, which I don't need.
Also, the CPU doesn't distinguish between regular LCD and HDMI, the output is the same.
The device per se is detected – as you can see, but there is no corresponding device node, why? A driver is missing?
The device tree just tells how to configure the IO pins, but that's another step (I may not see any image on the screen).
I added the corresponding device tree fragments, don't see any difference, maybe still missing something.
 
Hi aragats

In FreeBSD a phisical device is not necessarily mapped immediately to /dev. For example when i boot my computer i don't see /dev/dsp , but as soon as i run a video in youtube /dev/dsp0.0 will appear.

Another important thing is that not always you need a device to be mapped into /dev. For example, for the PWM you use the tunables. As far as i know there is not a /dev interface.

In my BeagleBone (FBS 12) i see "fb" in dmesg as well as in the tunables. But i have not a LCD hardware connected. So, it could be that once you connect a proper hardware device a node in /dev will appear. I never tried to use and LCD, i still have issues with simpler stuff to resolve.

bye
Nicola
 
I don't know if there will be any output at all without a driver, I've never tried an LCD on a BBB (or HDMI for that matter).
Nonetheless, the most important thing to verify is that there's actual the right voltage on the backlight. I'd recommend measuring that with a volt meter (in AC mode!).
If it's not there, find out how to enable it (the link given by Phishfry seems to have info regarding that).
Once it's there, if anything is sent to the LCD driver by default, you should see something. It might be necessary to write a small program to fill the screenbuffer with a pattern or something.
I'm not sure that any of the console output will be sent to the LCD by default.

Note that if the LCD isn't on a cape produced for the BBB, it's best to verify all lines going into the LCD with the schematics. An issue with the sync lines will result in no output as well.
 
it could be that once you connect a proper hardware device a node in /dev will appear
That's not the case. It may be true for an HDMI display, since it can send events, although the BBB doesn't support hot-plugging.
Most LCDs are connected to regular GPIO pins configured as outputs, thus there is no way to send any signal back to the BBB.
Note that if the LCD isn't on a cape produced for the BBB, it's best to verify all lines going into the LCD with the schematics.
It's a Newhaven 7" Cape for BBB, it perfectly works with Linux.
 
Are you using this on FreeBSD?
Yes, it works file in Linux, and I copied it to the main DTS (am335x-boneblack.dts).
it could be that once you connect a proper hardware device a node in /dev will appear
This gives me a clue. The HDMI chip is detected:
Code:
....
tda0 at addr 0xe0 on iicbus0
tda0: TDA19988
tda0: failed to read EDID
and obviously cannot get any info. Maybe that's why fb0 doesn't appear, although in my case it has nothing to do with HDMI.
From the CPU perspective there is no difference between HDMI and 24/16 GPIO interface, I may need to disable tda0 detection either by altering the DTS or blocking its driver. However, maybe the current FreeBSD mechanism assumes the video has to be through HDMI in the BBB.
 
However, maybe the current FreeBSD mechanism assumes the video has to be through HDMI in the BBB.
I think, I'm right, unless the comment in the LCD driver's code in /usr/src/sys/arm/ti/am335x/am335x_lcd.c is outdated:
* We assume that the only endpoint in LCDC node
* is HDMI framer.
If this is true, it significantly limits BBB+FreeBSD real life applications, since it's not practical to use HDMI in real embedded systems.
 
There is some progress!
Are you using this on FreeBSD?
It didn't work when I copied the content in the main DTS (am335x-boneblack.dts). Actually I have my own (based on that one ), slightly modified – I'm using it in Linux as overlay, but FreeBSD won't load it as overlay, I had to make a few changes and it worked! I remember reading that certain BBB functionality works only when configuration is applied as overlay. Also, /dev/fb0 has appeared, the driver didn't like some implicit LCD parameters in earlier experiments.
fb0.jpg
There are still some issues related to u-boot, I'll post my adjustments after final tests.
 
Here attached are the source and compiled overlay with minimal working configuration for Newhaven 7" LCD capes (N, V, L).
It's based on Robert Nelson's project, thus has to be compiled within its tree with gmake since using macros etc.
My changes:
Code:
- "compatible" statement is removed
- PWM mode for backlight didn't work, I changed to regular output for now (mode 7 vs 6):
BONE_P9_14 (PIN_OUTPUT_PULLUP | MUX_MODE7)
- added parameter:
pixelclk-active =<1>;
- hardware bug fix (red and blue lines get swapped depending on color depth):
blue-and-red-wiring = "crossed";
I haven't tried the touch panel yet, it needs a separate driver (works via i2c), but I left its pins configuration is in the DTS.
Here is the coresponding fragment of /boot/loader.conf:
Code:
boot_multicons="YES"
console="vidconsole,comconsole"
fdt_overlays="nh7-freebsd.dtbo"
The overlay itself should be copied to /boot/dtb/nh7-freebsd.dtbo.
 

Attachments

Back
Top