[U-Boot] [PATCH] common: add board specific hook for os preboot config

[Stefan Agner <stefan@agner.ch>]

On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, <stefan@agner.ch> wrote:
> 
>> On 13.08.2018 09:30, Gerard Salvatella wrote:
>>> Some boards require specific configuration prior to booting the
>> kernel.
>>> For instance, our boards require shutting down the display to
>> avoid
>>> fading transitions before the drivers are reloaded by the kernel.
>> This
>>> could be facilitated by adding an extra hook during the os booting
>>> process.
>>
>> Maybe I can extend on what we are trying to achieve here:
>>
>> We enable display backlight using board code.
> 
> You can make it works almost easily. 
> 
> I enable simple fb, inject allocated display parameters in dts to
> reserve area, pass the area to the graphics controller and dismiss it
> during probing
> 
> This is mainline in linux support.
> 
> I have couple of patches need to clean up for imx architecture
> (imx6ull and imx25)

Definitely interested in those patches! Of course using this approach
leads to the most seamless booting experience.

But as far as I know it also needs proper (driver specific) Linux
support, is that correct?

So, I think its anyway worth having an option to properly disable the
display and backlight for older kernels/non-Linux OS.

--
Stefan

> 
> You can still scripting it using cmd interface
> 
> Michael
> 
>> The architecture code then shuts down the display controller just
>> before
>> booting Linux (e.g. on i.MX, by calling
>> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>>
>> This leads to a display which has backlight enabled, but no data
>> driven... Depending on display this leads to noisy/fading
>> transitions
>> between U-Boot and Linux.
>>
>> So we would like to disable the backlight in board code.
>>
>> In a first version we used a weak display_shutdown() function, but
>> with
>> that we would have to add it to every architecture.
>>
>> This approach uses a generic board specific preeboot_os callback
>> which
>> can be used for different purpose too.
>>
>> Does this sound like an approach which is acceptable upstream?
>>
>> --
>> Stefan
>>
>>>
>>> Signed-off-by: Gerard Salvatella <gerard.salvatella@toradex.com>
>>> ---
>>> common/bootm_os.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/common/bootm_os.c b/common/bootm_os.c
>>> index f4bd905909..1e7af56b64 100644
>>> --- a/common/bootm_os.c
>>> +++ b/common/bootm_os.c
>>> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
>>> /* please define platform specific arch_preboot_os() */
>>> }
>>>
>>> +/* Allow for board specific config before we boot */
>>> +__weak void board_preboot_os(void)
>>> +{
>>> +       /* please define board specific board_preboot_os() */
>>> +}
>>> +
>>> int boot_selected_os(int argc, char * const argv[], int state,
>>> bootm_headers_t *images, boot_os_fn *boot_fn)
>>> {
>>> +       board_preboot_os();
>>> arch_preboot_os();
>>> boot_fn(state, argc, argv, images);
>>>
>>> --
>>> 2.18.0
>>>
>>>
>>> [Toradex Logo]<http://toradex.com>      Global Leader in Arm®
>>> Embedded Computer Modules
>>>
>>> Choose
>>>
>>
> Us<https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
>>> | Products<https://www.toradex.com/products> | Developer
>>> Center<http://developer.toradex.com/> |
>>> Community<https://www.toradex.com/community> |
>>> Careers<https://careers.toradex.com/>
>>> Meet our engineers
>>>
>> at<https://www.toradex.com/events>:<https://www.toradex.com/events>
>>> - Linux Developer Conference, Brazil, Aug 25-26, 2018
>>> - NXP Technology Days 2018, United States, Aug 28, 2018
>>> - IoT Latin America, Brazil, Aug 29-30, 2018
>>>
>>>
>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot