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