Hi
On Mon., 24 Sep. 2018, 5:15 pm Stefan Agner, <ste...@agner.ch> wrote:
> On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, <ste...@agner.ch> wrote:
> >
> >> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> >>> Hi
> >>>
> >>> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, <ste...@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.salvate...@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@lists.denx.de
> >>>>> https://lists.denx.de/listinfo/u-boot
> >>>> _______________________________________________
> >>>> U-Boot mailing list
> >>>> U-Boot@lists.denx.de
> >>>> https://lists.denx.de/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
