One barebox image for multiple boards

One barebox image for multiple boards

[Matthias Fend]

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

Re: One barebox image for multiple boards

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

	Sam

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

Re: One barebox image for multiple boards

[Matthias Fend]

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

Re: One barebox image for multiple boards

[Ahmad Fatoum]

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

Re: One barebox image for multiple boards

[Trent Piepho]

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

Re: One barebox image for multiple boards

[Sascha Hauer]

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

Re: One barebox image for multiple boards

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

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

Re: One barebox image for multiple boards

[Matthias Fend]

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

Re: One barebox image for multiple boards

[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

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

Re: One barebox image for multiple boards

[Matthias Fend]

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