Re: One barebox image for multiple boards
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
Re: One barebox image for multiple boards
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- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: One barebox image for multiple boards
On Fri, May 13, 2022 at 5:21 AM Ahmad Fatoum 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
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- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: One barebox image for multiple boards
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- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: One barebox image for multiple boards
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
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
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- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: One barebox image for multiple boards
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
One barebox image for multiple boards
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
