Skip to contentSkip to conversation

common: add board specific hook for os preboot config

PATCH New Gerard Salvatella 5 participants 10 messages Aug 13, 2018 – Nov 14, 2018

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

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.

---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -0
index f4bd905909..1e7af56b64 100644
@@ -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

#1 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Quoted 5 lines · 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.

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

Quoted 52 lines
---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

#2 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Hi

Quoted 11 lines · Stefan Agner,
Quoted 5 lines · 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.

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

Quoted 81 lines

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

Quoted 31 lines
---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

Quoted 5 lines

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

Quoted 12 lines
| 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

Quoted 4 lines

_______________________________________________
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

#3 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Quoted 20 lines · Michael Nazzareno Trimarchi

Hi

Quoted 5 lines · Stefan Agner,
Quoted 1 line · Gerard Salvatella

Some boards require specific configuration prior to booting the

kernel.

Quoted 1 line

For instance, our boards require shutting down the display to

avoid

Quoted 8 lines
Quoted 1 line

fading transitions before the drivers are reloaded by the kernel.

This

Quoted 2 lines

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.

Quoted 8 lines

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

Quoted 89 lines

You can still scripting it using cmd interface

Michael

Quoted 56 lines

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

Quoted 31 lines

---
common/bootm_os.c | 7 +++++++

1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

Quoted 6 lines
Quoted 5 lines

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

Quoted 21 lines
Quoted 6 lines
| 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>

Quoted 10 lines

- 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

#4 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Hi

Quoted 25 lines · Stefan Agner,
Quoted 24 lines · Michael Nazzareno Trimarchi

Hi

Quoted 5 lines · Stefan Agner,
Quoted 1 line · Gerard Salvatella

Some boards require specific configuration prior to booting the

kernel.

Quoted 1 line

For instance, our boards require shutting down the display to

avoid

Quoted 8 lines
Quoted 1 line

fading transitions before the drivers are reloaded by the kernel.

This

Quoted 2 lines

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

Quoted 8 lines
Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 3 lines

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

Quoted 95 lines

--
Stefan

Quoted 61 lines

You can still scripting it using cmd interface

Michael

Quoted 56 lines

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

Quoted 31 lines

---
common/bootm_os.c | 7 +++++++

1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

Quoted 7 lines
Quoted 6 lines
Quoted 5 lines

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

Quoted 21 lines
Quoted 21 lines
Quoted 6 lines
| 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>

Quoted 10 lines

- 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

#5 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Quoted 42 lines · Michael Nazzareno Trimarchi

Hi

Quoted 29 lines · Stefan Agner,
Quoted 3 lines · Michael Nazzareno Trimarchi

Hi

On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, <[email protected]>

Quoted 7 lines · wrote:
Quoted 7 lines · Gerard Salvatella
Quoted 1 line

Some boards require specific configuration prior to booting the

kernel.

Quoted 1 line

For instance, our boards require shutting down the display to

avoid

Quoted 1 line

fading transitions before the drivers are reloaded by the

kernel.

Quoted 2 lines
Quoted 2 lines

This

Quoted 1 line

could be facilitated by adding an extra hook during the os

booting

Quoted 10 lines
Quoted 5 lines
Quoted 1 line

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

Quoted 2 lines

during probing

Quoted 8 lines
Quoted 4 lines

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.

Quoted 9 lines

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

Quoted 2 lines

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.

Quoted 7 lines

sunxi already implement everything in their side

Quoted 3 lines

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

Quoted 99 lines

Michael

Quoted 18 lines

--
Stefan

Quoted 15 lines

You can still scripting it using cmd interface

Michael

Quoted 10 lines

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.

Quoted 55 lines
Quoted 3 lines
Quoted 3 lines

So we would like to disable the backlight in board code.

In a first version we used a weak display_shutdown() function,

but

Quoted 50 lines
Quoted 49 lines

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

Quoted 36 lines

---
common/bootm_os.c | 7 +++++++

1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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>

Quoted 22 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
| 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>

Quoted 14 lines
Quoted 14 lines
Quoted 10 lines

- 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

#6 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

Hi

Quoted 49 lines · Stefan Agner,
Quoted 48 lines · Michael Nazzareno Trimarchi

Hi

Quoted 29 lines · Stefan Agner,
Quoted 3 lines · Michael Nazzareno Trimarchi

Hi

On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, <[email protected]>

Quoted 7 lines · wrote:
Quoted 7 lines · Gerard Salvatella
Quoted 1 line

Some boards require specific configuration prior to booting the

kernel.

Quoted 1 line

For instance, our boards require shutting down the display to

avoid

Quoted 1 line

fading transitions before the drivers are reloaded by the

kernel.

Quoted 2 lines
Quoted 2 lines

This

Quoted 1 line

could be facilitated by adding an extra hook during the os

booting

Quoted 10 lines
Quoted 5 lines
Quoted 1 line

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

Quoted 2 lines

during probing

Quoted 8 lines
Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 8 lines
Quoted 3 lines

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

Quoted 6 lines
Quoted 6 lines

sunxi already implement everything in their side

Quoted 3 lines

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

Quoted 6 lines
Quoted 1 line

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

Quoted 105 lines

--
Stefan

Quoted 71 lines

Michael

Quoted 68 lines

--
Stefan

Quoted 18 lines

You can still scripting it using cmd interface

Michael

Quoted 13 lines

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

Quoted 46 lines
Quoted 46 lines

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

Quoted 34 lines

---
common/bootm_os.c | 7 +++++++

1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

Quoted 6 lines
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines

Choose

Us<

https://www.toradex.com/how-to-choose-system-computer-on-module-partner>

Quoted 22 lines
Quoted 22 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
| 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>

Quoted 14 lines
Quoted 14 lines
Quoted 10 lines

- 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

#7 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

In reply to Gerard Salvatella

HI all

Am Mo., 13. Aug. 2018 um 13:12 Uhr schrieb Gerard Salvatella <[email protected]>:

Quoted 7 lines

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

Quoted 44 lines
---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

Signature · 5 lines
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
#8 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

In reply to Gerard Salvatella
Quoted 7 lines · 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.

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:

--
Stefan

Quoted 50 lines
---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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

#9 lore raw

PATCH 1/1 common: add board specific hook for os preboot config

In reply to Gerard Salvatella

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

Quoted 56 lines · 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.

---
 common/bootm_os.c | 7 +++++++
 1 file changed, 7 insertions(+)
common/bootm_os.c +7 -1
index f4bd905909..1e7af56b64 100644
@@ -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