mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* One barebox image for multiple boards
@ 2022-05-13  8:55 Matthias Fend
  2022-05-13 10:30 ` Sam Ravnborg
  2022-05-13 11:00 ` Sascha Hauer
  0 siblings, 2 replies; 10+ messages in thread
From: Matthias Fend @ 2022-05-13  8:55 UTC (permalink / raw)
  To: barebox

Hi,

I'm looking for a solution to support multiple boards with just one 
barebox image. The few core components that are relevant for barebox are 
the same on all boards, so that the same barebox image runs on all 
boards. It is possible to dynamically detect the board type inside 
barebox, but as this requires some infrastructure it is not possible 
during lowlevel init. So basically Barebox should boot with a minimal 
core device tree, detect the board type and then use the corresponding 
device tree of the detected board. Something similar to 
arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at low level.
Maybe I missed something, but I couldn't find such a scenario in the 
existing board code yet.

Is there a suggestion on how to best implement such a system, or is 
there perhaps a board that uses something like this?

Thanks
  ~Matthias

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13  8:55 One barebox image for multiple boards Matthias Fend
@ 2022-05-13 10:30 ` Sam Ravnborg
  2022-05-13 12:08   ` Matthias Fend
  2022-05-13 11:00 ` Sascha Hauer
  1 sibling, 1 reply; 10+ messages in thread
From: Sam Ravnborg @ 2022-05-13 10:30 UTC (permalink / raw)
  To: Matthias Fend; +Cc: barebox

Hi Matthias

On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
> Hi,
> 
> I'm looking for a solution to support multiple boards with just one barebox
> image. The few core components that are relevant for barebox are the same on
> all boards, so that the same barebox image runs on all boards. It is
> possible to dynamically detect the board type inside barebox, but as this
> requires some infrastructure it is not possible during lowlevel init.

The skov-imx6 boards was in a similar situation - here the solution was
to add enough infrastructure to lowlevel to be able to determine the
board variant.

Not what you asked for but maybe duplicating the minimal set of
infrastructure allows you to determine the board type anyway in lowlevel?

	Sam

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13  8:55 One barebox image for multiple boards Matthias Fend
  2022-05-13 10:30 ` Sam Ravnborg
@ 2022-05-13 11:00 ` Sascha Hauer
  2022-05-13 12:10   ` Matthias Fend
  1 sibling, 1 reply; 10+ messages in thread
From: Sascha Hauer @ 2022-05-13 11:00 UTC (permalink / raw)
  To: Matthias Fend; +Cc: barebox

Hi Matthias,

On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
> Hi,
> 
> I'm looking for a solution to support multiple boards with just one barebox
> image. The few core components that are relevant for barebox are the same on
> all boards, so that the same barebox image runs on all boards. It is
> possible to dynamically detect the board type inside barebox, but as this
> requires some infrastructure it is not possible during lowlevel init. So
> basically Barebox should boot with a minimal core device tree, detect the
> board type and then use the corresponding device tree of the detected board.
> Something similar to arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at
> low level.

Do you even need the full device tree in barebox? The minimal core
device tree might be enough for barebox and only the kernel is then
booted with the full device tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 10:30 ` Sam Ravnborg
@ 2022-05-13 12:08   ` Matthias Fend
  2022-05-13 12:20     ` Ahmad Fatoum
  2022-05-13 12:23     ` Sascha Hauer
  0 siblings, 2 replies; 10+ messages in thread
From: Matthias Fend @ 2022-05-13 12:08 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: barebox

Hello Sam,

Am 13.05.2022 um 12:30 schrieb Sam Ravnborg:
> Hi Matthias
> 
> On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
>> Hi,
>>
>> I'm looking for a solution to support multiple boards with just one barebox
>> image. The few core components that are relevant for barebox are the same on
>> all boards, so that the same barebox image runs on all boards. It is
>> possible to dynamically detect the board type inside barebox, but as this
>> requires some infrastructure it is not possible during lowlevel init.
> 
> The skov-imx6 boards was in a similar situation - here the solution was
> to add enough infrastructure to lowlevel to be able to determine the
> board variant.
> 
> Not what you asked for but maybe duplicating the minimal set of
> infrastructure allows you to determine the board type anyway in lowlevel?

Thank you for pointing out this interesting example.
Since in this case things like I2C devices are needed for board 
detection, I think putting them in lowlevel init is not a good idea.

Thanks
  ~Matthias

> 
> 	Sam

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 11:00 ` Sascha Hauer
@ 2022-05-13 12:10   ` Matthias Fend
  2022-05-16  8:07     ` Sascha Hauer
  0 siblings, 1 reply; 10+ messages in thread
From: Matthias Fend @ 2022-05-13 12:10 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

Hi Sascha,

Am 13.05.2022 um 13:00 schrieb Sascha Hauer:
> Hi Matthias,
> 
> On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
>> Hi,
>>
>> I'm looking for a solution to support multiple boards with just one barebox
>> image. The few core components that are relevant for barebox are the same on
>> all boards, so that the same barebox image runs on all boards. It is
>> possible to dynamically detect the board type inside barebox, but as this
>> requires some infrastructure it is not possible during lowlevel init. So
>> basically Barebox should boot with a minimal core device tree, detect the
>> board type and then use the corresponding device tree of the detected board.
>> Something similar to arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at
>> low level.
> 
> Do you even need the full device tree in barebox? The minimal core
> device tree might be enough for barebox and only the kernel is then
> booted with the full device tree.

If there is no trick to changing the used device tree at boardlevel 
init, then this might be a possibility.
The core device tree might not be as minimal then and in exceptional 
cases minor fixups in the board code will be needed, but I think it 
could work.

In such a case, how should one ensure that the appropriate blspec entry 
is booted? Maybe by simply replacing/updating the compatible string in 
the live device tree after the board was detected?

Thanks
  ~Matthias

> 
> Sascha
> 

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 12:08   ` Matthias Fend
@ 2022-05-13 12:20     ` Ahmad Fatoum
  2022-05-13 18:02       ` Trent Piepho
  2022-05-13 12:23     ` Sascha Hauer
  1 sibling, 1 reply; 10+ messages in thread
From: Ahmad Fatoum @ 2022-05-13 12:20 UTC (permalink / raw)
  To: Matthias Fend, Sam Ravnborg; +Cc: barebox

Hello Matthias,

On 13.05.22 14:08, Matthias Fend wrote:
> Hello Sam,
> 
> Am 13.05.2022 um 12:30 schrieb Sam Ravnborg:
>> Hi Matthias
>>
>> On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
>>> Hi,
>>>
>>> I'm looking for a solution to support multiple boards with just one barebox
>>> image. The few core components that are relevant for barebox are the same on
>>> all boards, so that the same barebox image runs on all boards. It is
>>> possible to dynamically detect the board type inside barebox, but as this
>>> requires some infrastructure it is not possible during lowlevel init.
>>
>> The skov-imx6 boards was in a similar situation - here the solution was
>> to add enough infrastructure to lowlevel to be able to determine the
>> board variant.
>>
>> Not what you asked for but maybe duplicating the minimal set of
>> infrastructure allows you to determine the board type anyway in lowlevel?
> 
> Thank you for pointing out this interesting example.
> Since in this case things like I2C devices are needed for board detection, I think putting them in lowlevel init is not a good idea.

The i.MX8MN-EVK uses i2c to differentiate between two variants,
look for power_init_board_pca9450 and power_init_board_bd71837.

We don't pass different device trees there, but this can easily
be retrofitted once it's useful (i.e. once we have PMIC drivers
for one of these chips).

Cheers,
Ahmad

> 
> Thanks
>  ~Matthias
> 
>>
>>     Sam
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 12:08   ` Matthias Fend
  2022-05-13 12:20     ` Ahmad Fatoum
@ 2022-05-13 12:23     ` Sascha Hauer
  1 sibling, 0 replies; 10+ messages in thread
From: Sascha Hauer @ 2022-05-13 12:23 UTC (permalink / raw)
  To: Matthias Fend; +Cc: Sam Ravnborg, barebox

On Fri, May 13, 2022 at 02:08:06PM +0200, Matthias Fend wrote:
> Hello Sam,
> 
> Am 13.05.2022 um 12:30 schrieb Sam Ravnborg:
> > Hi Matthias
> > 
> > On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
> > > Hi,
> > > 
> > > I'm looking for a solution to support multiple boards with just one barebox
> > > image. The few core components that are relevant for barebox are the same on
> > > all boards, so that the same barebox image runs on all boards. It is
> > > possible to dynamically detect the board type inside barebox, but as this
> > > requires some infrastructure it is not possible during lowlevel init.
> > 
> > The skov-imx6 boards was in a similar situation - here the solution was
> > to add enough infrastructure to lowlevel to be able to determine the
> > board variant.
> > 
> > Not what you asked for but maybe duplicating the minimal set of
> > infrastructure allows you to determine the board type anyway in lowlevel?
> 
> Thank you for pointing out this interesting example.
> Since in this case things like I2C devices are needed for board detection, I
> think putting them in lowlevel init is not a good idea.

It wouldn't be the first board doing I2C in lowlevel init, see
drivers/i2c/busses/i2c-imx-early.c.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 12:20     ` Ahmad Fatoum
@ 2022-05-13 18:02       ` Trent Piepho
  0 siblings, 0 replies; 10+ messages in thread
From: Trent Piepho @ 2022-05-13 18:02 UTC (permalink / raw)
  To: Ahmad Fatoum; +Cc: Matthias Fend, Sam Ravnborg, barebox

On Fri, May 13, 2022 at 5:21 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

> >>
> >> Not what you asked for but maybe duplicating the minimal set of
> >> infrastructure allows you to determine the board type anyway in lowlevel?
> >
> > Thank you for pointing out this interesting example.
> > Since in this case things like I2C devices are needed for board detection, I think putting them in lowlevel init is not a good idea.
>
> The i.MX8MN-EVK uses i2c to differentiate between two variants,
> look for power_init_board_pca9450 and power_init_board_bd71837.
>
> We don't pass different device trees there, but this can easily
> be retrofitted once it's useful (i.e. once we have PMIC drivers
> for one of these chips).

Something I've done is to modify the unflattened device tree
programmatically based on board type.  For instance, set one device to
status = "okay" and another to status = "disabled" based on board
type.

One needs to do this before the driver(s) for those devices are
initialized.  But other drivers can be initialized first.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-13 12:10   ` Matthias Fend
@ 2022-05-16  8:07     ` Sascha Hauer
  2022-05-19  9:25       ` Matthias Fend
  0 siblings, 1 reply; 10+ messages in thread
From: Sascha Hauer @ 2022-05-16  8:07 UTC (permalink / raw)
  To: Matthias Fend; +Cc: barebox

On Fri, May 13, 2022 at 02:10:32PM +0200, Matthias Fend wrote:
> Hi Sascha,
> 
> Am 13.05.2022 um 13:00 schrieb Sascha Hauer:
> > Hi Matthias,
> > 
> > On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
> > > Hi,
> > > 
> > > I'm looking for a solution to support multiple boards with just one barebox
> > > image. The few core components that are relevant for barebox are the same on
> > > all boards, so that the same barebox image runs on all boards. It is
> > > possible to dynamically detect the board type inside barebox, but as this
> > > requires some infrastructure it is not possible during lowlevel init. So
> > > basically Barebox should boot with a minimal core device tree, detect the
> > > board type and then use the corresponding device tree of the detected board.
> > > Something similar to arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at
> > > low level.
> > 
> > Do you even need the full device tree in barebox? The minimal core
> > device tree might be enough for barebox and only the kernel is then
> > booted with the full device tree.
> 
> If there is no trick to changing the used device tree at boardlevel init,
> then this might be a possibility.

Replacing the live tree after it has been partly probed already is
dangerous and barebox is not really prepared for that.

> The core device tree might not be as minimal then and in exceptional cases
> minor fixups in the board code will be needed, but I think it could work.
> 
> In such a case, how should one ensure that the appropriate blspec entry is
> booted? Maybe by simply replacing/updating the compatible string in the live
> device tree after the board was detected?

As it happens Oleksij has just introduced of_prepend_machine_compatible()
exactly for this usecase. You can find it in current next branch.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: One barebox image for multiple boards
  2022-05-16  8:07     ` Sascha Hauer
@ 2022-05-19  9:25       ` Matthias Fend
  0 siblings, 0 replies; 10+ messages in thread
From: Matthias Fend @ 2022-05-19  9:25 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

Hi,

I was pleasantly surprised to get so many comments on this topic.
Thank you everyone for your input!

Since I want to avoid duplicating the i2c bus driver in a PBL capable 
version, I decided to have a common barebox device tree for all boards.
This means that the detection takes place in the board init code and 
then prepends the compatible with the matching board-specific entry.

If at some point the hardware no longer allows this approach, I still 
can switch to the i2c-early solution.

Thanks
  ~Matthias

Am 16.05.2022 um 10:07 schrieb Sascha Hauer:
> On Fri, May 13, 2022 at 02:10:32PM +0200, Matthias Fend wrote:
>> Hi Sascha,
>>
>> Am 13.05.2022 um 13:00 schrieb Sascha Hauer:
>>> Hi Matthias,
>>>
>>> On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote:
>>>> Hi,
>>>>
>>>> I'm looking for a solution to support multiple boards with just one barebox
>>>> image. The few core components that are relevant for barebox are the same on
>>>> all boards, so that the same barebox image runs on all boards. It is
>>>> possible to dynamically detect the board type inside barebox, but as this
>>>> requires some infrastructure it is not possible during lowlevel init. So
>>>> basically Barebox should boot with a minimal core device tree, detect the
>>>> board type and then use the corresponding device tree of the detected board.
>>>> Something similar to arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at
>>>> low level.
>>>
>>> Do you even need the full device tree in barebox? The minimal core
>>> device tree might be enough for barebox and only the kernel is then
>>> booted with the full device tree.
>>
>> If there is no trick to changing the used device tree at boardlevel init,
>> then this might be a possibility.
> 
> Replacing the live tree after it has been partly probed already is
> dangerous and barebox is not really prepared for that.
> 
>> The core device tree might not be as minimal then and in exceptional cases
>> minor fixups in the board code will be needed, but I think it could work.
>>
>> In such a case, how should one ensure that the appropriate blspec entry is
>> booted? Maybe by simply replacing/updating the compatible string in the live
>> device tree after the board was detected?
> 
> As it happens Oleksij has just introduced of_prepend_machine_compatible()
> exactly for this usecase. You can find it in current next branch.
> 
> Sascha
> 

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-05-19  9:27 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-13  8:55 One barebox image for multiple boards Matthias Fend
2022-05-13 10:30 ` Sam Ravnborg
2022-05-13 12:08   ` Matthias Fend
2022-05-13 12:20     ` Ahmad Fatoum
2022-05-13 18:02       ` Trent Piepho
2022-05-13 12:23     ` Sascha Hauer
2022-05-13 11:00 ` Sascha Hauer
2022-05-13 12:10   ` Matthias Fend
2022-05-16  8:07     ` Sascha Hauer
2022-05-19  9:25       ` Matthias Fend

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox