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

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

[Gerard Salvatella]

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.

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] [PATCH] common: add board specific hook for os preboot config

[Stefan Agner]

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.

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] [PATCH] common: add board specific hook for os preboot config

[Christian Gmeiner]

HI all

Am Mo., 13. Aug. 2018 um 13:12 Uhr schrieb Gerard Salvatella
<gerard.salvatella@toradex.com>:
>
> 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.
>

I really like this idea (as I also need to do some pre-os-boot stuff
for a legacy operating system).

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

> 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



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

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

[Stefan Agner]

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.
> 
> Signed-off-by: Gerard Salvatella <gerard.salvatella@toradex.com>

Tom, any thoughts on this? I guess it would get merged directly by you?

FWIW, I suggested this approach, and Gerards implementation looks good
to me, so:
Reviewed-by: Stefan Agner <stefan.agner@toradex.com>

--
Stefan

> ---
>  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] [PATCH] common: add board specific hook for os preboot config

[Michael Nazzareno Trimarchi]

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)

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
>

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

[Stefan Agner]

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

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

[Michael Nazzareno Trimarchi]

Hi



On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, <stefan@agner.ch> wrote:

> 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.
>

Yes but there are a lot of reason to have when you deal multi-image update
and so on.


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

No that is wrong. imx6ull need a small patches right now I have applied in
kernel in legacy driver and not in drm one.

sunxi already implement everything in their side


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

gpio clear gpio-6 ; bootm ?

Michael

>
> --
> 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
>

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

[Stefan Agner]

On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, <stefan@agner.ch> wrote:
> 
>> 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.
> 
> Yes but there are a lot of reason to have when you deal multi-image
> update and so on.
> 
>> But as far as I know it also needs proper (driver specific) Linux
>> support, is that correct?
> 
> No that is wrong. imx6ull need a small patches right now I have
> applied in kernel in legacy driver and not in drm one. 
> 

In what way is that different to what I wrote above?

In the end, the OS needs support for this.

> sunxi already implement everything in their side
> 
>> So, I think its anyway worth having an option to properly disable
>> the
>> display and backlight for older kernels/non-Linux OS.
> 
> gpio clear gpio-6 ; bootm ?

That is very board specific scripting required. We enable the backlight
in code, so we should disable it, especially if we disable the
controller (which we do currently).

--
Stefan

> 
> Michael
> 
>> --
>> 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

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

[Michael Nazzareno Trimarchi]

Hi


On Mon., 24 Sep. 2018, 5:15 pm Stefan Agner, <stefan@agner.ch> wrote:

> On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, <stefan@agner.ch> wrote:
> >
> >> 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.
> >
> > Yes but there are a lot of reason to have when you deal multi-image
> > update and so on.
> >
> >> But as far as I know it also needs proper (driver specific) Linux
> >> support, is that correct?
> >
> > No that is wrong. imx6ull need a small patches right now I have
> > applied in kernel in legacy driver and not in drm one.
> >
>
> In what way is that different to what I wrote above?
>
> In the end, the OS needs support for this.
>

I said that Linux support but not all the specic SoC. I don't against the
proposal but on my side I think that create some label and some way to
register them and go through a list instead of continue create weak make
more sense



> > sunxi already implement everything in their side
> >
> >> So, I think its anyway worth having an option to properly disable
> >> the
> >> display and backlight for older kernels/non-Linux OS.
> >
> > gpio clear gpio-6 ; bootm ?
>
> That is very board specific scripting required. We enable the backlight
> in code, so we should disable it, especially if we disable the
> controller (which we do currently).
>

Your function is board specific anyway but ok I understand the asymmetric
situation. I suggest it before migrate to the latest solution

Michael

>
> --
> Stefan
>
> >
> > Michael
> >
> >> --
> >> 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
>

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

[Marcel Ziswiler]

I see this got superseded by fd3d1212a2cb ("bootm: Add board specific
OS preboot hook") which does the exact same thing. Thanks!

On Mon, 2018-08-13 at 09:30 +0200, 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.
> 
> 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-mo
> dule-partner> | Products<https://www.toradex.com/products> |
> Developer Center<http://developer.toradex.com/> | Community<https://w
> ww.toradex.com/community> | Careers<https://careers.toradex.com/>
> Meet our engineers at<https://www.toradex.com/events>:<https://www.to
> radex.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