[U-Boot] Make display initialization more flexible

[Christian Schnell]

Hello,

I have an A13-OLinuXino with a LCD-OLinuXino-7TS (7" touch LCD) and a
LCD-OLinuXino-10 (10" LCD).

I am building my own distribution using mainline U-Boot, mainline kernel
and debian multistrap (stretch).

My goal is to create a single distribution which supports all of the
board's display types (VGA, LCD7, LCD7TS, LCD10, LCD10TS).

With a really helpful tip from someone calling himself HolgerK I managed
to get the LCDs working in the mainline kernel
(https://www.olimex.com/forum/index.php?topic=6038.0). The solution left
me with two device trees instead of one (one DTB for VGA and one for
both LCDs). He also told me how to add support for the resistive touch
panel to the LCD device tree.

But the device tree is only the linux-side of the problem, part of the
solution forced me to apply a patch to U-Boot, and I would like to hear
your opinion.

>From what I know from the linux-sunxi.org Wiki
(http://linux-sunxi.org/LCD), U-Boot requires me to declare a couple of
constants which are specific to the LCD model. In my case, this would
mean to maintain three different bootloaders in my distribution (a whole
U-Boot fleet!). In the linux-sunxi.org Wiki I stumbled upon this remark:
http://linux-sunxi.org/Display#mainline_kernel which claims there is a
way to control the value of at least CONFIG_VIDEO_LCD_MODE dynamically
through the use of uenv variable "video-mode". But when looking at the
sources I only found the static use of CONFIG_VIDEO_LCD_MODE in
sunxi_display.c (twice). Is the Wiki incorrect or not applicable in my
case or did I oversee something?

So I introduced two new uenv variables "sunxi_video_lcd_mode" and
"sunxi_video_lcd_bl_en", they correspond to CONFIG_VIDEO_LCD_MODE and
CONFIG_VIDEO_LCD_BL_EN, respectively. In my case, these are the only two
parameters that differ between VGA, LCD7" and LCD10" (when looking at
the LCD Wiki page it looks like this is a pattern similar to many
boards). I replaced the direct use of each preprocessor constant with a
helper function that returns the respective environment variable's value
if it is defined, and else falls back to the preprocessor constant.

In my uEnv.txt, I keep the FDT filename in "fdt_file" and also a
variable "fdt_enable". fdt_enble contains a list of fdt node aliases (or
paths), and in boot.cmd the status of each of these nodes is set to
"okay" using U-Boot's "fdt set <FDTNOE> status okay" when booting
(nothing uncommon, other distros do the same).

With all this, I can
- override CONFIG_VIDEO_LCD_MODE and CONFIG_VIDEO_LCD_BL_EN using
U-Boot's fw_setenv utility
- switch between the VGA and the LCD device tree by modifying "fdt_file"
in uEnv.txt
- enable/disable the resistive touch panel by modifying "fdt_enable" in
uEnv.txt

and with that I was able to write a script "a13-config", it allows me to
switch between the three (or five with touch) display types from the
console, taking effect with the next reboot. Tested and works with all
three types of displays.

I can also preseed the uenv variables "sunxi_video_lcd_mode" and
"sunxi_video_lcd_bl_en" using CONFIG_EXTRA_ENV_SETTINGS in my board's
sunxi-common.h (defining them in uEnv.txt is too late, of course, they
have to be permanently stored to be available when U-Boot initializes
the display). I do not assign anything to CONFIG_VIDEO_LCD_MODE and
CONFIG_VIDEO_LCD_BL_EN in .config any more.

Are there plans in U-Boot to make the display initialization more
flexible? Because I would have a few more ideas here.

Definitely not the right place to ask, but does anybody know whether
there is an official way to support the LCDs in mainline linux? The
current mainline device tree for my board "sun5i-a13-olinuxino.dtb"
enforces VGA and needs to be patched in order to use the LCDs, maybe the
LCDs aren't even in their scope. Can anyone shed a bit more light on the
tip I received from HolgerK?

Last, in order to be able to use fw_setenv I had to modify
CONFIG_ENV_OFFSET (default: 0x88000) to be aligned to CONFIG_ENV_SIZE
(0x20000). I chose the next closest upper bound 0xA0000, is that
recommended or should I chose a different offset? Why is
CONFIG_ENV_OFFSET not a multiple of CONFIG_ENV_SIZE when fw_setenv
requires it?

Cheers,
Christian