| Message ID | 20180813073014.28564-1-gerard.salvatella@toradex.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot] common: add board specific hook for os preboot config | expand |
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@lists.denx.de > https://lists.denx.de/listinfo/u-boot
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 at 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@lists.denx.de > https://lists.denx.de/listinfo/u-boot
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@lists.denx.de > https://lists.denx.de/listinfo/u-boot
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@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 >
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@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
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@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 >
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@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
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@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 >
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@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
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);
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(+) -- 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