Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
Hi, On 17 February 2016 at 04:00, Belisko Marek wrote: > Hi Simon, > > > On Thu, Jan 28, 2016 at 5:39 PM, Simon Glass wrote: >> We need a way to support more than one board per binary in U-Boot with >> device tree. Various methods have been discussed. The one that seems to make >> the most sense is to adjust SPL so that it can load a FIT which contains >> U-Boot and several device tree binaries. This is how things with with Linux: >> load a FIT and select the correct device tree to pass to Linux. > Some time ago I rise question [0] to load FIT kernel directly in SPL > using falcon mode. > I did look at your patches and I have a feeling that with small > adaptions it should be possible? > Am I right or it's impossible? (Trying to use it on am33xx boards). Many > thanks. Yes it should be possible. You will probably need to modify the device tree before booting Linux. In this case however I am not really using the full existing FIT code. It would be easier to use it and it is possible to build full FIT support in SPL. I did it for a project a few years ago but did not upstream it. It does add a bit to the size though. Regards, Simon >> >> This series: >> >> - Adjusts the build system to optionally build a u-boot.img in FIT format >> that includes the U-Boot binary and >1 device tree files >> - Adjusts SPL to support loading this >> - Adds a way for SPL to determine which device tree to select (by calling a >> board-specific function) >> - Adjusts SPL to pass this selected device tree to U-Boot when it starts >> >> It would be painful to require an .its file for each board just to support >> this feature. In any case various people have commented that it would be >> nice not to have to write this file in general. Therefore, this series >> enhances mkimage to automatically generate a FIT without a .its file. So far >> it understands how to add a main image and a number of device tree files. It >> does not support hashing or verified boot as yet. >> >> One problem with the FIT format as it stands is that all the data is inline. >> This means that the entire file must be read in order to figure out what >> device-tree files are available. It is then possible to copy the images into >> place. >> >> This is not really suitable for SPL since copying can be slow, and reading >> unnecessary data would make the FIT format less efficient than the legacy >> format. >> >> Therefore this series adds a new feature to FIT which allows the images to >> be stored immediately after the FIT itself ends. This makes the FIT very >> small. It can be read quickly and in its entirety. Then the images can be >> loaded one by one as needed. This allows SPL to support FITs containing lots >> of images very efficiently. >> >> To achieve this, mkimage is enhanced to convert between the 'normal' and >> 'external' version of a FIT file. The latter is only used for the SPL loader. >> The main difference is that viewing an 'external' FIT will not show the >> contents of each image. >> >> This series also includes a few other tidy-ups, such as moving mkimage's >> tricky argument-processing code to use getopt(). >> >> NOTE: There are a few problems remaining with the Kconfig conversion. I'm >> still fiddling with this but thought it best to send this series out for >> comment in the meantime. >> >> This series is available at u-boot-fdt/spl-working. >> > > [0] - http://lists.denx.de/pipermail/u-boot/2015-February/203938.html >> >> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
Hi Simon, On Thu, Jan 28, 2016 at 5:39 PM, Simon Glass wrote: > We need a way to support more than one board per binary in U-Boot with > device tree. Various methods have been discussed. The one that seems to make > the most sense is to adjust SPL so that it can load a FIT which contains > U-Boot and several device tree binaries. This is how things with with Linux: > load a FIT and select the correct device tree to pass to Linux. Some time ago I rise question [0] to load FIT kernel directly in SPL using falcon mode. I did look at your patches and I have a feeling that with small adaptions it should be possible? Am I right or it's impossible? (Trying to use it on am33xx boards). Many thanks. > > This series: > > - Adjusts the build system to optionally build a u-boot.img in FIT format > that includes the U-Boot binary and >1 device tree files > - Adjusts SPL to support loading this > - Adds a way for SPL to determine which device tree to select (by calling a > board-specific function) > - Adjusts SPL to pass this selected device tree to U-Boot when it starts > > It would be painful to require an .its file for each board just to support > this feature. In any case various people have commented that it would be > nice not to have to write this file in general. Therefore, this series > enhances mkimage to automatically generate a FIT without a .its file. So far > it understands how to add a main image and a number of device tree files. It > does not support hashing or verified boot as yet. > > One problem with the FIT format as it stands is that all the data is inline. > This means that the entire file must be read in order to figure out what > device-tree files are available. It is then possible to copy the images into > place. > > This is not really suitable for SPL since copying can be slow, and reading > unnecessary data would make the FIT format less efficient than the legacy > format. > > Therefore this series adds a new feature to FIT which allows the images to > be stored immediately after the FIT itself ends. This makes the FIT very > small. It can be read quickly and in its entirety. Then the images can be > loaded one by one as needed. This allows SPL to support FITs containing lots > of images very efficiently. > > To achieve this, mkimage is enhanced to convert between the 'normal' and > 'external' version of a FIT file. The latter is only used for the SPL loader. > The main difference is that viewing an 'external' FIT will not show the > contents of each image. > > This series also includes a few other tidy-ups, such as moving mkimage's > tricky argument-processing code to use getopt(). > > NOTE: There are a few problems remaining with the Kconfig conversion. I'm > still fiddling with this but thought it best to send this series out for > comment in the meantime. > > This series is available at u-boot-fdt/spl-working. > [0] - http://lists.denx.de/pipermail/u-boot/2015-February/203938.html > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
On Tue, Feb 16, 2016 at 09:30:44PM +0900, Masahiro Yamada wrote: > 2016-02-16 21:17 GMT+09:00 Tom Rini : > > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote: > >> Hi Simon, > >> > >> > >> 2016-01-29 1:39 GMT+09:00 Simon Glass : > >> > We need a way to support more than one board per binary in U-Boot with > >> > device tree. Various methods have been discussed. The one that seems to > >> > make > >> > the most sense is to adjust SPL so that it can load a FIT which contains > >> > U-Boot and several device tree binaries. This is how things with with > >> > Linux: > >> > load a FIT and select the correct device tree to pass to Linux. > >> > >> I've just skimmed over the git-logs, but I am confused. > >> > >> > >> Please makes it clearer why this is useful. > >> In your way, how SPL is handled? > >> > >> SPL is much more board-specific than U-Boot proper. > >> So, I assume SPL would remain as a per-board image > >> even after achieving one U-Boot proper for multi-boards. > >> > >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot > >> proper. > >> > >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be > >> generated by one-shot > >> and by one defconfig. > >> > >> > >> But, we would still have to do > >> > >> make board_a_defconfig && make > >> make board_b_defconfig && make > >> make board_c_defconfig && make > >> > >> to generate SPL for each of the three. > >> Is this correct? > >> > >> > >> Supposing my guess is correct, this series would not contribute > >> to decreasing the number of defconfig files. > >> > >> > >> > >> Please explain which problem you are solving with this series. > > > > It won't be just one board. We need this so that we can replicate > > existing (and very useful) functionality. Today, am335x_evm_config > > supports Beaglebone White, Beaglebone Black (could be faked enough for > > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART > > AM335x IDK EVM. Each of these is different enough that they have their > > own DT that we will need to pass up to U-Boot, and their own config > > file. With Simon's series we'll be able to move am335x_evm_config up to > > DM in SPL and possibly even remove some of the am335x_evm subconfigs we > > have today, once those specific options also move to Kconfig. > > So, this series is useful to merge some boards > that are different enough to have their own DT, > but that are similar enough to share one SPL binary, correct? Yes. It _may_ even be useful later on to support a more broad set of boards than we do today (ie it's not impossible that one binary could support the TI AM43xx EVMs as well, or all TI EVMs that have the EEPROM that identifies the model, for some narrow scope of boot devices). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
2016-02-16 21:17 GMT+09:00 Tom Rini : > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote: >> Hi Simon, >> >> >> 2016-01-29 1:39 GMT+09:00 Simon Glass : >> > We need a way to support more than one board per binary in U-Boot with >> > device tree. Various methods have been discussed. The one that seems to >> > make >> > the most sense is to adjust SPL so that it can load a FIT which contains >> > U-Boot and several device tree binaries. This is how things with with >> > Linux: >> > load a FIT and select the correct device tree to pass to Linux. >> >> I've just skimmed over the git-logs, but I am confused. >> >> >> Please makes it clearer why this is useful. >> In your way, how SPL is handled? >> >> SPL is much more board-specific than U-Boot proper. >> So, I assume SPL would remain as a per-board image >> even after achieving one U-Boot proper for multi-boards. >> >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot >> proper. >> >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be >> generated by one-shot >> and by one defconfig. >> >> >> But, we would still have to do >> >> make board_a_defconfig && make >> make board_b_defconfig && make >> make board_c_defconfig && make >> >> to generate SPL for each of the three. >> Is this correct? >> >> >> Supposing my guess is correct, this series would not contribute >> to decreasing the number of defconfig files. >> >> >> >> Please explain which problem you are solving with this series. > > It won't be just one board. We need this so that we can replicate > existing (and very useful) functionality. Today, am335x_evm_config > supports Beaglebone White, Beaglebone Black (could be faked enough for > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART > AM335x IDK EVM. Each of these is different enough that they have their > own DT that we will need to pass up to U-Boot, and their own config > file. With Simon's series we'll be able to move am335x_evm_config up to > DM in SPL and possibly even remove some of the am335x_evm subconfigs we > have today, once those specific options also move to Kconfig. So, this series is useful to merge some boards that are different enough to have their own DT, but that are similar enough to share one SPL binary, correct? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote: > Hi Simon, > > > 2016-01-29 1:39 GMT+09:00 Simon Glass : > > We need a way to support more than one board per binary in U-Boot with > > device tree. Various methods have been discussed. The one that seems to make > > the most sense is to adjust SPL so that it can load a FIT which contains > > U-Boot and several device tree binaries. This is how things with with Linux: > > load a FIT and select the correct device tree to pass to Linux. > > I've just skimmed over the git-logs, but I am confused. > > > Please makes it clearer why this is useful. > In your way, how SPL is handled? > > SPL is much more board-specific than U-Boot proper. > So, I assume SPL would remain as a per-board image > even after achieving one U-Boot proper for multi-boards. > > Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper. > > The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be > generated by one-shot > and by one defconfig. > > > But, we would still have to do > > make board_a_defconfig && make > make board_b_defconfig && make > make board_c_defconfig && make > > to generate SPL for each of the three. > Is this correct? > > > Supposing my guess is correct, this series would not contribute > to decreasing the number of defconfig files. > > > > Please explain which problem you are solving with this series. It won't be just one board. We need this so that we can replicate existing (and very useful) functionality. Today, am335x_evm_config supports Beaglebone White, Beaglebone Black (could be faked enough for U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART AM335x IDK EVM. Each of these is different enough that they have their own DT that we will need to pass up to U-Boot, and their own config file. With Simon's series we'll be able to move am335x_evm_config up to DM in SPL and possibly even remove some of the am335x_evm subconfigs we have today, once those specific options also move to Kconfig. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
Hi Simon, 2016-01-29 1:39 GMT+09:00 Simon Glass : > We need a way to support more than one board per binary in U-Boot with > device tree. Various methods have been discussed. The one that seems to make > the most sense is to adjust SPL so that it can load a FIT which contains > U-Boot and several device tree binaries. This is how things with with Linux: > load a FIT and select the correct device tree to pass to Linux. I've just skimmed over the git-logs, but I am confused. Please makes it clearer why this is useful. In your way, how SPL is handled? SPL is much more board-specific than U-Boot proper. So, I assume SPL would remain as a per-board image even after achieving one U-Boot proper for multi-boards. Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper. The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be generated by one-shot and by one defconfig. But, we would still have to do make board_a_defconfig && make make board_b_defconfig && make make board_c_defconfig && make to generate SPL for each of the three. Is this correct? Supposing my guess is correct, this series would not contribute to decreasing the number of defconfig files. Please explain which problem you are solving with this series. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot
We need a way to support more than one board per binary in U-Boot with device tree. Various methods have been discussed. The one that seems to make the most sense is to adjust SPL so that it can load a FIT which contains U-Boot and several device tree binaries. This is how things with with Linux: load a FIT and select the correct device tree to pass to Linux. This series: - Adjusts the build system to optionally build a u-boot.img in FIT format that includes the U-Boot binary and >1 device tree files - Adjusts SPL to support loading this - Adds a way for SPL to determine which device tree to select (by calling a board-specific function) - Adjusts SPL to pass this selected device tree to U-Boot when it starts It would be painful to require an .its file for each board just to support this feature. In any case various people have commented that it would be nice not to have to write this file in general. Therefore, this series enhances mkimage to automatically generate a FIT without a .its file. So far it understands how to add a main image and a number of device tree files. It does not support hashing or verified boot as yet. One problem with the FIT format as it stands is that all the data is inline. This means that the entire file must be read in order to figure out what device-tree files are available. It is then possible to copy the images into place. This is not really suitable for SPL since copying can be slow, and reading unnecessary data would make the FIT format less efficient than the legacy format. Therefore this series adds a new feature to FIT which allows the images to be stored immediately after the FIT itself ends. This makes the FIT very small. It can be read quickly and in its entirety. Then the images can be loaded one by one as needed. This allows SPL to support FITs containing lots of images very efficiently. To achieve this, mkimage is enhanced to convert between the 'normal' and 'external' version of a FIT file. The latter is only used for the SPL loader. The main difference is that viewing an 'external' FIT will not show the contents of each image. This series also includes a few other tidy-ups, such as moving mkimage's tricky argument-processing code to use getopt(). NOTE: There are a few problems remaining with the Kconfig conversion. I'm still fiddling with this but thought it best to send this series out for comment in the meantime. This series is available at u-boot-fdt/spl-working. Simon Glass (26): mkimage: Move argument processing into its own function mkimage: Convert to use getopt() mkimage: Sort the option processing code by option mkimage: Move usage() up to the top mkimage: Show an error message when usage() is called mkimage: Make 'params' static libfdt: Add a function to write a property placeholder Correct defconfig ordering Move CONFIG_OF_LIBFDT to Kconfig Kconfig: Move CONFIG_FIT and CONFIG_OF_*_SETUP to Kconfig fdt: Adjust DEFAULT_DEVICE_TREE to device on OF_CONTROL fdt: Allow libfdt to be used in SPL sunxi: Display the board model on start-up tools: Include fdt_sw.o in libfdt for mkimage mkimage: Allow a FIT to include an image of any type tools: Add a function to obtain the size of a file image: Add functions to obtain short names mkimage: Support automatic creating of a FIT without a .its mkimage: Support adding device tree files to a FIT mkimage: Support placing data outside the FIT mkimage: Bring data into the FIT before processing spl: Add a way for boards to select which device tree to load spl: Add an option to load a FIT containing U-Boot spl: Add a way to specify a list of device trees to include spl: Support loading a FIT from MMC RFC: sunxi: Enable SPL FIT support Kconfig| 11 + Makefile | 10 +- arch/arm/cpu/armv7/sunxi/board.c | 5 + cmd/disk.c | 6 +- common/Kconfig | 28 ++ common/Makefile| 6 +- common/bootm.c | 14 +- common/image-fdt.c | 8 +- common/image-fit.c | 3 +- common/image.c | 50 +- common/spl/Makefile| 1 + common/spl/spl_fit.c | 192 common/spl/spl_mmc.c | 75 ++- configs/10m50_defconfig| 1 + configs/3c120_defconfig| 1 + configs/A10-OLinuXino-Lime_defconfig | 1 + configs/A10s-OLinuXino-M_defconfig | 1 + configs/A13-OLinuXinoM_defconfig | 1 + configs/A13-OLinuXino_defconfig| 1 + configs/A20-OLinuXino-Lime2_defconfig | 1 + configs/A20-OLinuXino-Lime_defcon
