[U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com --- Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 - configs/pcm058_defconfig | 1 - configs/pfla02_defconfig | 1 - configs/platinum_picon_defconfig | 1 - configs/platinum_titanium_defconfig | 1 - configs/riotboard_spl_defconfig | 1 - configs/sksimx6_defconfig | 1 - configs/udoo_defconfig | 1 - configs/udoo_neo_defconfig | 1 - configs/wandboard_defconfig | 1 - configs/xpress_spl_defconfig | 1 - configs/zc5202_defconfig | 1 - configs/zc5601_defconfig | 1 - 21 files changed, 21 deletions(-)
diff --git a/configs/cgtqmx6eval_defconfig b/configs/cgtqmx6eval_defconfig index 0a6ff20a4d42..cf8502b370f4 100644 --- a/configs/cgtqmx6eval_defconfig +++ b/configs/cgtqmx6eval_defconfig @@ -22,7 +22,6 @@ CONFIG_MISC_INIT_R=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index f13e6885071b..31427e24ad14 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -18,7 +18,6 @@ CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y # CONFIG_CMD_FLASH is not set diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index d0f302e9d09b..303636511326 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -24,7 +24,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_FIT_IMAGE_TINY=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig index 0fda6fc3946e..c060d6f692d7 100644 --- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -23,7 +23,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_FIT_IMAGE_TINY=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_OS_BOOT=y CONFIG_SPL_USB_HOST_SUPPORT=y diff --git a/configs/mx6slevk_spl_defconfig b/configs/mx6slevk_spl_defconfig index 4841dc62bf5c..fbf0e3e774c7 100644 --- a/configs/mx6slevk_spl_defconfig +++ b/configs/mx6slevk_spl_defconfig @@ -16,7 +16,6 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/mx6sxsabresd_spl_defconfig b/configs/mx6sxsabresd_spl_defconfig index 159f07931a3b..51eb0726d658 100644 --- a/configs/mx6sxsabresd_spl_defconfig +++ b/configs/mx6sxsabresd_spl_defconfig @@ -18,7 +18,6 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/mx6ul_14x14_evk_defconfig b/configs/mx6ul_14x14_evk_defconfig index 2fc7119042a1..8735401bb71a 100644 --- a/configs/mx6ul_14x14_evk_defconfig +++ b/configs/mx6ul_14x14_evk_defconfig @@ -17,7 +17,6 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/mx6ul_9x9_evk_defconfig b/configs/mx6ul_9x9_evk_defconfig index 8816f6a4fdec..c204b49e2bc9 100644 --- a/configs/mx6ul_9x9_evk_defconfig +++ b/configs/mx6ul_9x9_evk_defconfig @@ -17,7 +17,6 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/novena_defconfig b/configs/novena_defconfig index 340e1cd91c69..a7386b6108c7 100644 --- a/configs/novena_defconfig +++ b/configs/novena_defconfig @@ -24,7 +24,6 @@ CONFIG_VERSION_VARIABLE=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_ASKENV=y diff --git a/configs/pcm058_defconfig b/configs/pcm058_defconfig index c4614593af90..ebf015246274 100644 --- a/configs/pcm058_defconfig +++ b/configs/pcm058_defconfig @@ -23,7 +23,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_DMA_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/pfla02_defconfig b/configs/pfla02_defconfig index aeab883258da..e500419d61d9 100644 --- a/configs/pfla02_defconfig +++ b/configs/pfla02_defconfig @@ -23,7 +23,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_DMA_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/platinum_picon_defconfig b/configs/platinum_picon_defconfig index 786f6a4ba4c4..07ae40a1cf73 100644 --- a/configs/platinum_picon_defconfig +++ b/configs/platinum_picon_defconfig @@ -18,7 +18,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_DMA_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/platinum_titanium_defconfig b/configs/platinum_titanium_defconfig index c45abb0356ae..c8a408116a27 100644 --- a/configs/platinum_titanium_defconfig +++ b/configs/platinum_titanium_defconfig @@ -18,7 +18,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_DMA_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/riotboard_spl_defconfig b/configs/riotboard_spl_defconfig index 1b61232d5c46..9c7f1c0a3645 100644 --- a/configs/riotboard_spl_defconfig +++ b/configs/riotboard_spl_defconfig @@ -19,7 +19,6 @@ CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_RAW_IMAGE_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_OS_BOOT=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/sksimx6_defconfig b/configs/sksimx6_defconfig index 164614decdd3..bccf3ce01693 100644 --- a/configs/sksimx6_defconfig +++ b/configs/sksimx6_defconfig @@ -24,7 +24,6 @@ CONFIG_VERSION_VARIABLE=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_GPIO=y diff --git a/configs/udoo_defconfig b/configs/udoo_defconfig index 317592b5e95e..c56dc5d9218f 100644 --- a/configs/udoo_defconfig +++ b/configs/udoo_defconfig @@ -17,7 +17,6 @@ CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_GPIO=y diff --git a/configs/udoo_neo_defconfig b/configs/udoo_neo_defconfig index e8df11db669b..e327c9728d1d 100644 --- a/configs/udoo_neo_defconfig +++ b/configs/udoo_neo_defconfig @@ -18,7 +18,6 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_ENV_SUPPORT=y -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_WATCHDOG_SUPPORT=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig index ee81e1aa1c8e..a25cc6e924ed 100644 --- a/configs/wandboard_defconfig +++ b/configs/wandboard_defconfig @@ -23,7 +23,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y # CONFIG_CMD_FLASH is not set diff --git a/configs/xpress_spl_defconfig b/configs/xpress_spl_defconfig index e79a038816d5..7c22abf7dcd2 100644 --- a/configs/xpress_spl_defconfig +++ b/configs/xpress_spl_defconfig @@ -17,7 +17,6 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y diff --git a/configs/zc5202_defconfig b/configs/zc5202_defconfig index ae3a6b32bf21..5964472d694a 100644 --- a/configs/zc5202_defconfig +++ b/configs/zc5202_defconfig @@ -20,7 +20,6 @@ CONFIG_DEFAULT_FDT_FILE="imx6q-zc5202.dtb" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/zc5601_defconfig b/configs/zc5601_defconfig index 65a19151a829..65afbc2736ef 100644 --- a/configs/zc5601_defconfig +++ b/configs/zc5601_defconfig @@ -20,7 +20,6 @@ CONFIG_DEFAULT_FDT_FILE="imx6q-zc5601.dtb" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_TEXT_BASE=0x00908000 -CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_WATCHDOG_SUPPORT=y
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
Thanks for the review, Eze
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons: 1) It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired. 2) Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not? There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote: > i.MX6 platforms boot U-Boot second-stage from unformatted space, > and should not need Ext filesystem support on SPL. > > The commit was generated with: > > git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' > > This change has a dramatic impact on SPL size: > > ./scripts/bloat-o-meter old new > add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) > [..] > Total: Before=38320, After=29646, chg -22.64% > > Cc: Otavio Salvador otavio@ossystems.com.br > Cc: Fabio Estevam fabio.estevam@nxp.com > Cc: Peng Fan peng.fan@nxp.com > Cc: Marek Vasut marex@denx.de > Cc: Stefano Babic sbabic@denx.de > Cc: Stefan Roese sr@denx.de > Cc: "Eric Bénard" eric@eukrea.com > Cc: Breno Lima breno.lima@nxp.com > Cc: Francesco Montefoschi francesco.montefoschi@udoo.org > Signed-off-by: Ezequiel Garcia ezequiel@collabora.com > --- > Tested on Wandboard only. Maintainers, please ACK or NAK! > > configs/cgtqmx6eval_defconfig | 1 - > configs/mx6cuboxi_defconfig | 1 - > configs/mx6sabreauto_defconfig | 1 - > configs/mx6sabresd_defconfig | 1 - > configs/mx6slevk_spl_defconfig | 1 - > configs/mx6sxsabresd_spl_defconfig | 1 - > configs/mx6ul_14x14_evk_defconfig | 1 - > configs/mx6ul_9x9_evk_defconfig | 1 - > configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: > On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >> i.MX6 platforms boot U-Boot second-stage from unformatted space, >> and should not need Ext filesystem support on SPL. >> >> The commit was generated with: >> >> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >> >> This change has a dramatic impact on SPL size: >> >> ./scripts/bloat-o-meter old new >> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >> [..] >> Total: Before=38320, After=29646, chg -22.64% >> >> Cc: Otavio Salvador otavio@ossystems.com.br >> Cc: Fabio Estevam fabio.estevam@nxp.com >> Cc: Peng Fan peng.fan@nxp.com >> Cc: Marek Vasut marex@denx.de >> Cc: Stefano Babic sbabic@denx.de >> Cc: Stefan Roese sr@denx.de >> Cc: "Eric Bénard" eric@eukrea.com >> Cc: Breno Lima breno.lima@nxp.com >> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >> --- >> Tested on Wandboard only. Maintainers, please ACK or NAK! >> >> configs/cgtqmx6eval_defconfig | 1 - >> configs/mx6cuboxi_defconfig | 1 - >> configs/mx6sabreauto_defconfig | 1 - >> configs/mx6sabresd_defconfig | 1 - >> configs/mx6slevk_spl_defconfig | 1 - >> configs/mx6sxsabresd_spl_defconfig | 1 - >> configs/mx6ul_14x14_evk_defconfig | 1 - >> configs/mx6ul_9x9_evk_defconfig | 1 - >> configs/novena_defconfig | 1 - > > NAK, I boot my Novena from ext4 and this just broke it. > > And also, NAK, this removes functionality from SPL which worked fine before. >
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote: > On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>> i.MX6 platforms boot U-Boot second-stage from unformatted space, >>> and should not need Ext filesystem support on SPL. >>> >>> The commit was generated with: >>> >>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>> >>> This change has a dramatic impact on SPL size: >>> >>> ./scripts/bloat-o-meter old new >>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >>> [..] >>> Total: Before=38320, After=29646, chg -22.64% >>> >>> Cc: Otavio Salvador otavio@ossystems.com.br >>> Cc: Fabio Estevam fabio.estevam@nxp.com >>> Cc: Peng Fan peng.fan@nxp.com >>> Cc: Marek Vasut marex@denx.de >>> Cc: Stefano Babic sbabic@denx.de >>> Cc: Stefan Roese sr@denx.de >>> Cc: "Eric Bénard" eric@eukrea.com >>> Cc: Breno Lima breno.lima@nxp.com >>> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >>> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >>> --- >>> Tested on Wandboard only. Maintainers, please ACK or NAK! >>> >>> configs/cgtqmx6eval_defconfig | 1 - >>> configs/mx6cuboxi_defconfig | 1 - >>> configs/mx6sabreauto_defconfig | 1 - >>> configs/mx6sabresd_defconfig | 1 - >>> configs/mx6slevk_spl_defconfig | 1 - >>> configs/mx6sxsabresd_spl_defconfig | 1 - >>> configs/mx6ul_14x14_evk_defconfig | 1 - >>> configs/mx6ul_9x9_evk_defconfig | 1 - >>> configs/novena_defconfig | 1 - >> >> NAK, I boot my Novena from ext4 and this just broke it. >> >> And also, NAK, this removes functionality from SPL which worked fine before. >> > > I'll drop from Novena, but I think the patch still makes some sense, > why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
On Sun, May 26, 2019 at 01:30:01AM +0200, Marek Vasut wrote:
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: > On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>> i.MX6 platforms boot U-Boot second-stage from unformatted space, >>>> and should not need Ext filesystem support on SPL. >>>> >>>> The commit was generated with: >>>> >>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>> >>>> This change has a dramatic impact on SPL size: >>>> >>>> ./scripts/bloat-o-meter old new >>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >>>> [..] >>>> Total: Before=38320, After=29646, chg -22.64% >>>> >>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>> Cc: Peng Fan peng.fan@nxp.com >>>> Cc: Marek Vasut marex@denx.de >>>> Cc: Stefano Babic sbabic@denx.de >>>> Cc: Stefan Roese sr@denx.de >>>> Cc: "Eric Bénard" eric@eukrea.com >>>> Cc: Breno Lima breno.lima@nxp.com >>>> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >>>> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >>>> --- >>>> Tested on Wandboard only. Maintainers, please ACK or NAK! >>>> >>>> configs/cgtqmx6eval_defconfig | 1 - >>>> configs/mx6cuboxi_defconfig | 1 - >>>> configs/mx6sabreauto_defconfig | 1 - >>>> configs/mx6sabresd_defconfig | 1 - >>>> configs/mx6slevk_spl_defconfig | 1 - >>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>> configs/novena_defconfig | 1 - >>> >>> NAK, I boot my Novena from ext4 and this just broke it. >>> >>> And also, NAK, this removes functionality from SPL which worked fine before. >>> >> >> I'll drop from Novena, but I think the patch still makes some sense, >> why do you want Ext4 on SPL? > > What other filesystem is available in SPL and doesn't have patent problems ? >
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
No, it's what the board maintainer says, for wandboard.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
By that logic you should be enabling every possible filesystem in SPL and a bunch of other features too just in case. No, if no one is _using_ a feature on a board, removing useless features is a goal onto itself.
On 5/26/19 2:33 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:30:01AM +0200, Marek Vasut wrote:
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote: > On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: >> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>> i.MX6 platforms boot U-Boot second-stage from unformatted space, >>>>> and should not need Ext filesystem support on SPL. >>>>> >>>>> The commit was generated with: >>>>> >>>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>>> >>>>> This change has a dramatic impact on SPL size: >>>>> >>>>> ./scripts/bloat-o-meter old new >>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >>>>> [..] >>>>> Total: Before=38320, After=29646, chg -22.64% >>>>> >>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>> Cc: Peng Fan peng.fan@nxp.com >>>>> Cc: Marek Vasut marex@denx.de >>>>> Cc: Stefano Babic sbabic@denx.de >>>>> Cc: Stefan Roese sr@denx.de >>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>> Cc: Breno Lima breno.lima@nxp.com >>>>> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >>>>> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >>>>> --- >>>>> Tested on Wandboard only. Maintainers, please ACK or NAK! >>>>> >>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>> configs/mx6cuboxi_defconfig | 1 - >>>>> configs/mx6sabreauto_defconfig | 1 - >>>>> configs/mx6sabresd_defconfig | 1 - >>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>> configs/novena_defconfig | 1 - >>>> >>>> NAK, I boot my Novena from ext4 and this just broke it. >>>> >>>> And also, NAK, this removes functionality from SPL which worked fine before. >>>> >>> >>> I'll drop from Novena, but I think the patch still makes some sense, >>> why do you want Ext4 on SPL? >> >> What other filesystem is available in SPL and doesn't have patent problems ? >> > > Sorry for not being clear. I am asking why turn on a feature that is so heavy, > on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
No, it's what the board maintainer says, for wandboard.
I would like to avoid carrying downstream patch.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
By that logic you should be enabling every possible filesystem in SPL and a bunch of other features too just in case.
I never implied this. All I said is that I am strongly opposed to removing useful functionality to accommodate useless bloat. It is the bloat that should be fixed and the functionality should be retained.
No, if no one is _using_ a feature on a board, removing useless features is a goal onto itself.
I just said I am using ext4 on at least novena and wandboard.
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: > On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>> i.MX6 platforms boot U-Boot second-stage from unformatted >>>> space, and should not need Ext filesystem support on SPL. >>>> >>>> The commit was generated with: >>>> >>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | >>>> xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>> >>>> This change has a dramatic impact on SPL size: >>>> >>>> ./scripts/bloat-o-meter old new >>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >>>> [..] >>>> Total: Before=38320, After=29646, chg -22.64% >>>> >>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>> Cc: Peng Fan peng.fan@nxp.com >>>> Cc: Marek Vasut marex@denx.de >>>> Cc: Stefano Babic sbabic@denx.de >>>> Cc: Stefan Roese sr@denx.de >>>> Cc: "Eric Bénard" eric@eukrea.com >>>> Cc: Breno Lima breno.lima@nxp.com >>>> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >>>> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >>>> --- >>>> Tested on Wandboard only. Maintainers, please ACK or NAK! >>>> >>>> configs/cgtqmx6eval_defconfig | 1 - >>>> configs/mx6cuboxi_defconfig | 1 - >>>> configs/mx6sabreauto_defconfig | 1 - >>>> configs/mx6sabresd_defconfig | 1 - >>>> configs/mx6slevk_spl_defconfig | 1 - >>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>> configs/novena_defconfig | 1 - >>> >>> NAK, I boot my Novena from ext4 and this just broke it. >>> >>> And also, NAK, this removes functionality from SPL which >>> worked fine before. >> >> I'll drop from Novena, but I think the patch still makes some >> sense, why do you want Ext4 on SPL? > > What other filesystem is available in SPL and doesn't have > patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for
no good reason (oops, bloat, is not a good reason), and that is not desired. 2) Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C): ------------------------------------------------ Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper: ---------------------------- Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
1. We replace small, robust SPL (I speak only for i.MX) with something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here.
2. To make it usable (with the size comparable to what we do have now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote: > On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: >> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>> i.MX6 platforms boot U-Boot second-stage from unformatted >>>>> space, and should not need Ext filesystem support on SPL. >>>>> >>>>> The commit was generated with: >>>>> >>>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | >>>>> xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>>> >>>>> This change has a dramatic impact on SPL size: >>>>> >>>>> ./scripts/bloat-o-meter old new >>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) >>>>> [..] >>>>> Total: Before=38320, After=29646, chg -22.64% >>>>> >>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>> Cc: Peng Fan peng.fan@nxp.com >>>>> Cc: Marek Vasut marex@denx.de >>>>> Cc: Stefano Babic sbabic@denx.de >>>>> Cc: Stefan Roese sr@denx.de >>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>> Cc: Breno Lima breno.lima@nxp.com >>>>> Cc: Francesco Montefoschi francesco.montefoschi@udoo.org >>>>> Signed-off-by: Ezequiel Garcia ezequiel@collabora.com >>>>> --- >>>>> Tested on Wandboard only. Maintainers, please ACK or NAK! >>>>> >>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>> configs/mx6cuboxi_defconfig | 1 - >>>>> configs/mx6sabreauto_defconfig | 1 - >>>>> configs/mx6sabresd_defconfig | 1 - >>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>> configs/novena_defconfig | 1 - >>>> >>>> NAK, I boot my Novena from ext4 and this just broke it. >>>> >>>> And also, NAK, this removes functionality from SPL which >>>> worked fine before. >>> >>> I'll drop from Novena, but I think the patch still makes some >>> sense, why do you want Ext4 on SPL? >> >> What other filesystem is available in SPL and doesn't have >> patent problems ? > > Sorry for not being clear. I am asking why turn on a feature > that is so heavy, on a system that won't need it (such as > Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for
no good reason (oops, bloat, is not a good reason), and that is not desired. 2) Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with something
which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here.
- To make it usable (with the size comparable to what we do have now)
we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago, when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut wrote: > On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: >>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>> unformatted space, and should not need Ext filesystem >>>>>> support on SPL. >>>>>> >>>>>> The commit was generated with: >>>>>> >>>>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 >>>>>> | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>>>> >>>>>> This change has a dramatic impact on SPL size: >>>>>> >>>>>> ./scripts/bloat-o-meter old new >>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>> (-8674) [..] >>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>> >>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>> Cc: Marek Vasut marex@denx.de >>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>> Cc: Stefan Roese sr@denx.de >>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>> Cc: Francesco Montefoschi >>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>> NAK! >>>>>> >>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>> configs/novena_defconfig | 1 - >>>>> >>>>> NAK, I boot my Novena from ext4 and this just broke it. >>>>> >>>>> And also, NAK, this removes functionality from SPL which >>>>> worked fine before. >>>> >>>> I'll drop from Novena, but I think the patch still makes >>>> some sense, why do you want Ext4 on SPL? >>> >>> What other filesystem is available in SPL and doesn't have >>> patent problems ? >> >> Sorry for not being clear. I am asking why turn on a feature >> that is so heavy, on a system that won't need it (such as >> Sabre* boards, Wandboard and similar)? > > Two reasons: > 1) It was enabled, disabling it means removing functionality > for no good reason (oops, bloat, is not a good reason), and > that is not desired. 2) Booting from block device implies > booting from a filesystem, otherwise you might overwrite > various things on the block device when updating the file > (u-boot image).
So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
There are setups where people have configured the system such that SPL loads something from ext4 and that's why we have it available. Is anyone doing that on Novena? Or any iMX system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with
something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here.
- To make it usable (with the size comparable to what we do have
now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On 5/26/19 1:46 PM, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote: > On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut > wrote: >> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: >>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>> unformatted space, and should not need Ext filesystem >>>>>>> support on SPL. >>>>>>> >>>>>>> The commit was generated with: >>>>>>> >>>>>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 >>>>>>> | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>> >>>>>>> This change has a dramatic impact on SPL size: >>>>>>> >>>>>>> ./scripts/bloat-o-meter old new >>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>> (-8674) [..] >>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>> >>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>> Cc: Francesco Montefoschi >>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>> NAK! >>>>>>> >>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>> configs/novena_defconfig | 1 - >>>>>> >>>>>> NAK, I boot my Novena from ext4 and this just broke it. >>>>>> >>>>>> And also, NAK, this removes functionality from SPL which >>>>>> worked fine before. >>>>> >>>>> I'll drop from Novena, but I think the patch still makes >>>>> some sense, why do you want Ext4 on SPL? >>>> >>>> What other filesystem is available in SPL and doesn't have >>>> patent problems ? >>> >>> Sorry for not being clear. I am asking why turn on a feature >>> that is so heavy, on a system that won't need it (such as >>> Sabre* boards, Wandboard and similar)? >> >> Two reasons: >> 1) It was enabled, disabling it means removing functionality >> for no good reason (oops, bloat, is not a good reason), and >> that is not desired. 2) Booting from block device implies >> booting from a filesystem, otherwise you might overwrite >> various things on the block device when updating the file >> (u-boot image). > > So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
> There are > setups where people have configured the system such that SPL > loads something from ext4 and that's why we have it > available. Is anyone doing that on Novena? Or any iMX > system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
Better yet, the ability to short-circuit the whole DM functionality for systems which only have one driver per subsystem in the SPL, and optimize the entire DM machinery out in such a case, since it's all not required only to track one driver instance.
[...]
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
VFAT is a patent minefield, which is why people use ext4 in the first place. Migrating from ext4 -> VFAT is like moving from a good thing to bad thing.
On Sun, May 26, 2019 at 01:46:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote:
On 5/26/19 1:08 AM, Tom Rini wrote: > On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut > wrote: >> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote: >>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote: >>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>> unformatted space, and should not need Ext filesystem >>>>>>> support on SPL. >>>>>>> >>>>>>> The commit was generated with: >>>>>>> >>>>>>> git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 >>>>>>> | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>> >>>>>>> This change has a dramatic impact on SPL size: >>>>>>> >>>>>>> ./scripts/bloat-o-meter old new >>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>> (-8674) [..] >>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>> >>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>> Cc: Francesco Montefoschi >>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>> NAK! >>>>>>> >>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>> configs/novena_defconfig | 1 - >>>>>> >>>>>> NAK, I boot my Novena from ext4 and this just broke it. >>>>>> >>>>>> And also, NAK, this removes functionality from SPL which >>>>>> worked fine before. >>>>> >>>>> I'll drop from Novena, but I think the patch still makes >>>>> some sense, why do you want Ext4 on SPL? >>>> >>>> What other filesystem is available in SPL and doesn't have >>>> patent problems ? >>> >>> Sorry for not being clear. I am asking why turn on a feature >>> that is so heavy, on a system that won't need it (such as >>> Sabre* boards, Wandboard and similar)? >> >> Two reasons: >> 1) It was enabled, disabling it means removing functionality >> for no good reason (oops, bloat, is not a good reason), and >> that is not desired. 2) Booting from block device implies >> booting from a filesystem, otherwise you might overwrite >> various things on the block device when updating the file >> (u-boot image). > > So, are you using SPL to load something from ext4 or not?
Yes, I think that's what I said.
> There are > setups where people have configured the system such that SPL > loads something from ext4 and that's why we have it > available. Is anyone doing that on Novena? Or any iMX > system?
Quoting my first response in this thread: " NAK, I boot my Novena from ext4 and this just broke it. "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with
something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here.
- To make it usable (with the size comparable to what we do have
now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
DM/DT has been around for over 7 years now, so it too is "legacy code". So it's not "immediately", it's been several years now of trying to get people to migrate and introducing more firm deadlines about it.
And I'm _still_ not removing code that's close to a full year past the published "We're going to remove this now" date.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
Yes, it's been hard to get some drivers converted because just not doing it had no consequences. And yes, I'm sure drivers you need will need OF_PLATDATA hooks added.
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Exactly. If people are using EXT4 on iMX6 then it should stay. We dropped it from am335x_evm over a year ago because it wasn't used.
Hi Tom,
On Sun, May 26, 2019 at 01:46:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote:
On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut wrote: > On 5/26/19 1:08 AM, Tom Rini wrote: >> On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut >> wrote: >>> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut >>>> wrote: >>>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut >>>>>> wrote: >>>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>>> unformatted space, and should not need Ext >>>>>>>> filesystem support on SPL. >>>>>>>> >>>>>>>> The commit was generated with: >>>>>>>> >>>>>>>> git grep -l MX6 -- configs/ | xargs grep -l >>>>>>>> SPL_FS_EXT4 | xargs sed -i -e >>>>>>>> '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>>> >>>>>>>> This change has a dramatic impact on SPL size: >>>>>>>> >>>>>>>> ./scripts/bloat-o-meter old new >>>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>>> (-8674) [..] >>>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>>> >>>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>>> Cc: Francesco Montefoschi >>>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>>> NAK! >>>>>>>> >>>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>>> configs/novena_defconfig | 1 - >>>>>>> >>>>>>> NAK, I boot my Novena from ext4 and this just broke >>>>>>> it. >>>>>>> >>>>>>> And also, NAK, this removes functionality from SPL >>>>>>> which worked fine before. >>>>>> >>>>>> I'll drop from Novena, but I think the patch still >>>>>> makes some sense, why do you want Ext4 on SPL? >>>>> >>>>> What other filesystem is available in SPL and doesn't >>>>> have patent problems ? >>>> >>>> Sorry for not being clear. I am asking why turn on a >>>> feature that is so heavy, on a system that won't need >>>> it (such as Sabre* boards, Wandboard and similar)? >>> >>> Two reasons: >>> 1) It was enabled, disabling it means removing >>> functionality for no good reason (oops, bloat, is not a >>> good reason), and that is not desired. 2) Booting from >>> block device implies booting from a filesystem, >>> otherwise you might overwrite various things on the >>> block device when updating the file (u-boot image). >> >> So, are you using SPL to load something from ext4 or >> not? > > Yes, I think that's what I said. > >> There are >> setups where people have configured the system such that >> SPL loads something from ext4 and that's why we have it >> available. Is anyone doing that on Novena? Or any iMX >> system? > > Quoting my first response in this thread: > " > NAK, I boot my Novena from ext4 and this just broke it. > "
Actually, I wasn't sure from your first response if you're using SPL to load u-boot from EXT4 or not. So, Novena is a no and we should wait for more board maintainers to speak up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with
something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here. fdtdec_get_chosen_node 2. To make it usable (with the size comparable to what we do have now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
DM/DT has been around for over 7 years now, so it too is "legacy code". So it's not "immediately", it's been several years now of trying to get people to migrate and introducing more firm deadlines about it.
I'm not talking about generic DM/DTS adoption - this goes pretty well.
I'm specific about OF_PLATDATA in SPL, which is lagging behind in the whole U-Boot. To efficiently convert SPL on i.MX we do need it.
And I'm _still_ not removing code that's close to a full year past the published "We're going to remove this now" date.
And this is a good approach. This code is a legacy one, but still working and sometimes used.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
Yes, it's been hard to get some drivers converted because just not doing it had no consequences. And yes, I'm sure drivers you need will need OF_PLATDATA hooks added.
Yes, certainly.
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Exactly. If people are using EXT4 on iMX6 then it should stay. We dropped it from am335x_evm over a year ago because it wasn't used.
Yes. I also do agree.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Sun, 26 May 2019 at 12:05, Lukasz Majewski lukma@denx.de wrote:
Hi Tom,
On Sun, May 26, 2019 at 01:46:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
On 5/26/19 1:23 AM, Tom Rini wrote: > On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut > wrote: >> On 5/26/19 1:08 AM, Tom Rini wrote: >>> On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut >>> wrote: >>>> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>>>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut >>>>> wrote: >>>>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut >>>>>>> wrote: >>>>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>>>> unformatted space, and should not need Ext >>>>>>>>> filesystem support on SPL. >>>>>>>>> >>>>>>>>> The commit was generated with: >>>>>>>>> >>>>>>>>> git grep -l MX6 -- configs/ | xargs grep -l >>>>>>>>> SPL_FS_EXT4 | xargs sed -i -e >>>>>>>>> '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>>>> >>>>>>>>> This change has a dramatic impact on SPL size: >>>>>>>>> >>>>>>>>> ./scripts/bloat-o-meter old new >>>>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>>>> (-8674) [..] >>>>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>>>> >>>>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>>>> Cc: Francesco Montefoschi >>>>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>>>> NAK! >>>>>>>>> >>>>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>>>> configs/novena_defconfig | 1 - >>>>>>>> >>>>>>>> NAK, I boot my Novena from ext4 and this just broke >>>>>>>> it. >>>>>>>> >>>>>>>> And also, NAK, this removes functionality from SPL >>>>>>>> which worked fine before. >>>>>>> >>>>>>> I'll drop from Novena, but I think the patch still >>>>>>> makes some sense, why do you want Ext4 on SPL? >>>>>> >>>>>> What other filesystem is available in SPL and doesn't >>>>>> have patent problems ? >>>>> >>>>> Sorry for not being clear. I am asking why turn on a >>>>> feature that is so heavy, on a system that won't need >>>>> it (such as Sabre* boards, Wandboard and similar)? >>>> >>>> Two reasons: >>>> 1) It was enabled, disabling it means removing >>>> functionality for no good reason (oops, bloat, is not a >>>> good reason), and that is not desired. 2) Booting from >>>> block device implies booting from a filesystem, >>>> otherwise you might overwrite various things on the >>>> block device when updating the file (u-boot image). >>> >>> So, are you using SPL to load something from ext4 or >>> not? >> >> Yes, I think that's what I said. >> >>> There are >>> setups where people have configured the system such that >>> SPL loads something from ext4 and that's why we have it >>> available. Is anyone doing that on Novena? Or any iMX >>> system? >> >> Quoting my first response in this thread: >> " >> NAK, I boot my Novena from ext4 and this just broke it. >> " > > Actually, I wasn't sure from your first response if you're > using SPL to load u-boot from EXT4 or not. So, Novena is a > no and we should wait for more board maintainers to speak > up to see if they use it or not, thanks!
Novena is certainly a no. Since I use a couple of wandboards, those are no as well.
But I do not want to see useful functionality removed from SPL only to make space for useless DM/DT bloat. Temporarily band-aiding this real problem by removing functionality is a no-go, no matter how you slice it. The real fix is to fix the DM/DT and figure out a way to reduce it's size and _retain_ _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with
something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here. fdtdec_get_chosen_node 2. To make it usable (with the size comparable to what we do have now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
DM/DT has been around for over 7 years now, so it too is "legacy code". So it's not "immediately", it's been several years now of trying to get people to migrate and introducing more firm deadlines about it.
I'm not talking about generic DM/DTS adoption - this goes pretty well.
I'm specific about OF_PLATDATA in SPL, which is lagging behind in the whole U-Boot. To efficiently convert SPL on i.MX we do need it.
And I'm _still_ not removing code that's close to a full year past the published "We're going to remove this now" date.
And this is a good approach. This code is a legacy one, but still working and sometimes used.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
Yes, it's been hard to get some drivers converted because just not doing it had no consequences. And yes, I'm sure drivers you need will need OF_PLATDATA hooks added.
Yes, certainly.
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Exactly. If people are using EXT4 on iMX6 then it should stay. We dropped it from am335x_evm over a year ago because it wasn't used.
Yes. I also do agree.
I don't want to get into the DM discussion, the intention of this patch was to reduce SPL size, not make room for a future increase.
That said, I am surprised it is so controversial to slim down a Defconfig, which (at least in my mind) is just the "Maintainer Recommended Starting Point". By removing Ext4 we stating that it's no needed for the board "typical" use.
Of course, anyone can still turn Ext4 -and many other features- on.
Once again, this is only possible if we maintain SPL "starting point" size as small as possible, which probably excludes DM or any other form of bloat.
In fact, if I can keep removing features and still boot the board with the typical setup, I'll be happy to keep suggesting such patches.
Thanks! Eze
On 5/26/19 6:18 PM, Ezequiel Garcia wrote:
On Sun, 26 May 2019 at 12:05, Lukasz Majewski lukma@denx.de wrote:
Hi Tom,
On Sun, May 26, 2019 at 01:46:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote:
Dear Marek, Tom,
> On 5/26/19 1:23 AM, Tom Rini wrote: >> On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut >> wrote: >>> On 5/26/19 1:08 AM, Tom Rini wrote: >>>> On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut >>>> wrote: >>>>> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>>>>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut >>>>>> wrote: >>>>>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut >>>>>>>> wrote: >>>>>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>>>>> unformatted space, and should not need Ext >>>>>>>>>> filesystem support on SPL. >>>>>>>>>> >>>>>>>>>> The commit was generated with: >>>>>>>>>> >>>>>>>>>> git grep -l MX6 -- configs/ | xargs grep -l >>>>>>>>>> SPL_FS_EXT4 | xargs sed -i -e >>>>>>>>>> '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>>>>> >>>>>>>>>> This change has a dramatic impact on SPL size: >>>>>>>>>> >>>>>>>>>> ./scripts/bloat-o-meter old new >>>>>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>>>>> (-8674) [..] >>>>>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>>>>> >>>>>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>>>>> Cc: Francesco Montefoschi >>>>>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>>>>> NAK! >>>>>>>>>> >>>>>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>>>>> configs/novena_defconfig | 1 - >>>>>>>>> >>>>>>>>> NAK, I boot my Novena from ext4 and this just broke >>>>>>>>> it. >>>>>>>>> >>>>>>>>> And also, NAK, this removes functionality from SPL >>>>>>>>> which worked fine before. >>>>>>>> >>>>>>>> I'll drop from Novena, but I think the patch still >>>>>>>> makes some sense, why do you want Ext4 on SPL? >>>>>>> >>>>>>> What other filesystem is available in SPL and doesn't >>>>>>> have patent problems ? >>>>>> >>>>>> Sorry for not being clear. I am asking why turn on a >>>>>> feature that is so heavy, on a system that won't need >>>>>> it (such as Sabre* boards, Wandboard and similar)? >>>>> >>>>> Two reasons: >>>>> 1) It was enabled, disabling it means removing >>>>> functionality for no good reason (oops, bloat, is not a >>>>> good reason), and that is not desired. 2) Booting from >>>>> block device implies booting from a filesystem, >>>>> otherwise you might overwrite various things on the >>>>> block device when updating the file (u-boot image). >>>> >>>> So, are you using SPL to load something from ext4 or >>>> not? >>> >>> Yes, I think that's what I said. >>> >>>> There are >>>> setups where people have configured the system such that >>>> SPL loads something from ext4 and that's why we have it >>>> available. Is anyone doing that on Novena? Or any iMX >>>> system? >>> >>> Quoting my first response in this thread: >>> " >>> NAK, I boot my Novena from ext4 and this just broke it. >>> " >> >> Actually, I wasn't sure from your first response if you're >> using SPL to load u-boot from EXT4 or not. So, Novena is a >> no and we should wait for more board maintainers to speak >> up to see if they use it or not, thanks! > > Novena is certainly a no. Since I use a couple of wandboards, > those are no as well. > > But I do not want to see useful functionality removed from SPL > only to make space for useless DM/DT bloat. Temporarily > band-aiding this real problem by removing functionality is a > no-go, no matter how you slice it. The real fix is to fix the > DM/DT and figure out a way to reduce it's size and _retain_ > _all_ the functionality.
I fully agree with Marek here - the DM/DT SPL support (in the form as it is now) is a bloat. The SPL size increases considerably.
The _real_ issue is the lack of OF_PLATDATA support for DM/DTS drivers, which are used when we convert u-boot to DM/DTS.
For boards, which have enough internal on-chip RAM (OCRAM in case of imx6q) it is doable to convert them to DM/DTS in SPL.
However, nobody wants to say it loud, but the footprint considerably increases in SPL - for example:
SPL (and I only use eMMC there - no SPI, no I2C):
Before conversion: 35 KiB DM conversion: 47 KiB (around ~25% increase)
For u-boot proper:
Footprint changes (u-boot.imx):
Before conversion: 345 KiB DM conversion: 415 KiB (around + 17% increase)
This has several implications:
- We replace small, robust SPL (I speak only for i.MX) with
something which is XX% larger and hence boot time increases. In short - customers are/will not be happy. We do introduce regression here. fdtdec_get_chosen_node 2. To make it usable (with the size comparable to what we do have now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, etc. drivers. Test them and validate.
That is why we now "just" convert only U-Boot proper to DM/DTS.
As a follow up - it seems pragmatic to not touch SPL for now, and start the conversion ONLY when necessary drivers gain support for OF_PLATDATA (so we don't need DTS support in SPL).
Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
DM/DT has been around for over 7 years now, so it too is "legacy code". So it's not "immediately", it's been several years now of trying to get people to migrate and introducing more firm deadlines about it.
I'm not talking about generic DM/DTS adoption - this goes pretty well.
I'm specific about OF_PLATDATA in SPL, which is lagging behind in the whole U-Boot. To efficiently convert SPL on i.MX we do need it.
And I'm _still_ not removing code that's close to a full year past the published "We're going to remove this now" date.
And this is a good approach. This code is a legacy one, but still working and sometimes used.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
Yes, it's been hard to get some drivers converted because just not doing it had no consequences. And yes, I'm sure drivers you need will need OF_PLATDATA hooks added.
Yes, certainly.
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Exactly. If people are using EXT4 on iMX6 then it should stay. We dropped it from am335x_evm over a year ago because it wasn't used.
Yes. I also do agree.
I don't want to get into the DM discussion, the intention of this patch was to reduce SPL size, not make room for a future increase.
SPL size should not be reduced at the expense of useful functionality though.
That said, I am surprised it is so controversial to slim down a Defconfig, which (at least in my mind) is just the "Maintainer Recommended Starting Point". By removing Ext4 we stating that it's no needed for the board "typical" use.
Maybe you can remove VFAT first, why ext4 in the first place ?
Of course, anyone can still turn Ext4 -and many other features- on.
I was under the impression that mainline should be as useful as possible. Maybe I'm mistaken and carrying random downstream patches is now the suggested approach ?
Once again, this is only possible if we maintain SPL "starting point" size as small as possible, which probably excludes DM or any other form of bloat.
In fact, if I can keep removing features and still boot the board with the typical setup, I'll be happy to keep suggesting such patches.
That's fine, unless it breaks other peoples' existing setups .
On Sun, 26 May 2019 at 14:30, Marek Vasut marex@denx.de wrote:
On 5/26/19 6:18 PM, Ezequiel Garcia wrote:
On Sun, 26 May 2019 at 12:05, Lukasz Majewski lukma@denx.de wrote:
Hi Tom,
On Sun, May 26, 2019 at 01:46:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sun, May 26, 2019 at 10:22:00AM +0200, Lukasz Majewski wrote: > Dear Marek, Tom, > >> On 5/26/19 1:23 AM, Tom Rini wrote: >>> On Sun, May 26, 2019 at 01:20:34AM +0200, Marek Vasut >>> wrote: >>>> On 5/26/19 1:08 AM, Tom Rini wrote: >>>>> On Sun, May 26, 2019 at 12:57:08AM +0200, Marek Vasut >>>>> wrote: >>>>>> On 5/26/19 12:45 AM, Ezequiel Garcia wrote: >>>>>>> On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut >>>>>>> wrote: >>>>>>>> On 5/25/19 11:47 PM, Ezequiel Garcia wrote: >>>>>>>>> On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut >>>>>>>>> wrote: >>>>>>>>>> On 5/25/19 6:49 PM, Ezequiel Garcia wrote: >>>>>>>>>>> i.MX6 platforms boot U-Boot second-stage from >>>>>>>>>>> unformatted space, and should not need Ext >>>>>>>>>>> filesystem support on SPL. >>>>>>>>>>> >>>>>>>>>>> The commit was generated with: >>>>>>>>>>> >>>>>>>>>>> git grep -l MX6 -- configs/ | xargs grep -l >>>>>>>>>>> SPL_FS_EXT4 | xargs sed -i -e >>>>>>>>>>> '/CONFIG_SPL_FS_EXT4=y/d' >>>>>>>>>>> >>>>>>>>>>> This change has a dramatic impact on SPL size: >>>>>>>>>>> >>>>>>>>>>> ./scripts/bloat-o-meter old new >>>>>>>>>>> add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 >>>>>>>>>>> (-8674) [..] >>>>>>>>>>> Total: Before=38320, After=29646, chg -22.64% >>>>>>>>>>> >>>>>>>>>>> Cc: Otavio Salvador otavio@ossystems.com.br >>>>>>>>>>> Cc: Fabio Estevam fabio.estevam@nxp.com >>>>>>>>>>> Cc: Peng Fan peng.fan@nxp.com >>>>>>>>>>> Cc: Marek Vasut marex@denx.de >>>>>>>>>>> Cc: Stefano Babic sbabic@denx.de >>>>>>>>>>> Cc: Stefan Roese sr@denx.de >>>>>>>>>>> Cc: "Eric Bénard" eric@eukrea.com >>>>>>>>>>> Cc: Breno Lima breno.lima@nxp.com >>>>>>>>>>> Cc: Francesco Montefoschi >>>>>>>>>>> francesco.montefoschi@udoo.org Signed-off-by: >>>>>>>>>>> Ezequiel Garcia ezequiel@collabora.com --- >>>>>>>>>>> Tested on Wandboard only. Maintainers, please ACK or >>>>>>>>>>> NAK! >>>>>>>>>>> >>>>>>>>>>> configs/cgtqmx6eval_defconfig | 1 - >>>>>>>>>>> configs/mx6cuboxi_defconfig | 1 - >>>>>>>>>>> configs/mx6sabreauto_defconfig | 1 - >>>>>>>>>>> configs/mx6sabresd_defconfig | 1 - >>>>>>>>>>> configs/mx6slevk_spl_defconfig | 1 - >>>>>>>>>>> configs/mx6sxsabresd_spl_defconfig | 1 - >>>>>>>>>>> configs/mx6ul_14x14_evk_defconfig | 1 - >>>>>>>>>>> configs/mx6ul_9x9_evk_defconfig | 1 - >>>>>>>>>>> configs/novena_defconfig | 1 - >>>>>>>>>> >>>>>>>>>> NAK, I boot my Novena from ext4 and this just broke >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> And also, NAK, this removes functionality from SPL >>>>>>>>>> which worked fine before. >>>>>>>>> >>>>>>>>> I'll drop from Novena, but I think the patch still >>>>>>>>> makes some sense, why do you want Ext4 on SPL? >>>>>>>> >>>>>>>> What other filesystem is available in SPL and doesn't >>>>>>>> have patent problems ? >>>>>>> >>>>>>> Sorry for not being clear. I am asking why turn on a >>>>>>> feature that is so heavy, on a system that won't need >>>>>>> it (such as Sabre* boards, Wandboard and similar)? >>>>>> >>>>>> Two reasons: >>>>>> 1) It was enabled, disabling it means removing >>>>>> functionality for no good reason (oops, bloat, is not a >>>>>> good reason), and that is not desired. 2) Booting from >>>>>> block device implies booting from a filesystem, >>>>>> otherwise you might overwrite various things on the >>>>>> block device when updating the file (u-boot image). >>>>> >>>>> So, are you using SPL to load something from ext4 or >>>>> not? >>>> >>>> Yes, I think that's what I said. >>>> >>>>> There are >>>>> setups where people have configured the system such that >>>>> SPL loads something from ext4 and that's why we have it >>>>> available. Is anyone doing that on Novena? Or any iMX >>>>> system? >>>> >>>> Quoting my first response in this thread: >>>> " >>>> NAK, I boot my Novena from ext4 and this just broke it. >>>> " >>> >>> Actually, I wasn't sure from your first response if you're >>> using SPL to load u-boot from EXT4 or not. So, Novena is a >>> no and we should wait for more board maintainers to speak >>> up to see if they use it or not, thanks! >> >> Novena is certainly a no. Since I use a couple of wandboards, >> those are no as well. >> >> But I do not want to see useful functionality removed from SPL >> only to make space for useless DM/DT bloat. Temporarily >> band-aiding this real problem by removing functionality is a >> no-go, no matter how you slice it. The real fix is to fix the >> DM/DT and figure out a way to reduce it's size and _retain_ >> _all_ the functionality. > > I fully agree with Marek here - the DM/DT SPL support (in the > form as it is now) is a bloat. The SPL size increases > considerably. > > The _real_ issue is the lack of OF_PLATDATA support for DM/DTS > drivers, which are used when we convert u-boot to DM/DTS. > > For boards, which have enough internal on-chip RAM (OCRAM in > case of imx6q) it is doable to convert them to DM/DTS in SPL. > > However, nobody wants to say it loud, but the footprint > considerably increases in SPL - for example: > > SPL (and I only use eMMC there - no SPI, no I2C): > ------------------------------------------------ > Before conversion: 35 KiB > DM conversion: 47 KiB > (around ~25% increase) > > > For u-boot proper: > ---------------------------- > Footprint changes (u-boot.imx): > > Before conversion: 345 KiB > DM conversion: 415 KiB > (around + 17% increase) > > > This has several implications: > > 1. We replace small, robust SPL (I speak only for i.MX) with > something which is XX% larger and hence boot time increases. In > short - customers are/will not be happy. We do introduce > regression here. > fdtdec_get_chosen_node > 2. To make it usable (with the size comparable to what we do > have now) we need to add OF_PLATDATA support to eMMC, SPI, I2C, > etc. drivers. Test them and validate. > > That is why we now "just" convert only U-Boot proper to DM/DTS. > > As a follow up - it seems pragmatic to not touch SPL for now, > and start the conversion ONLY when necessary drivers gain > support for OF_PLATDATA (so we don't need DTS support in SPL). > > Unfortunately, it would take some time.
Right, and again, DM support in SPL is not required as we haven't sorted out some of the issues such as making sure it is still small enough.
Ok, so we do have agreement here. Good.
Which is why I'm quite frustrated at the moment about "just now" starting to convert these things for i.MX rather than several years ago,
Frankly speaking - I do prefer to use older, well tested and stable SW.
And such situation we had with i.MX port. It was (and still is) working, being there before the whole DM/DTS stuff.
I can understand that we advised new ports/archs to use DM/DTS. But i.MX has a lot of legacy code, which is already deployed. Changing it because "we move to DM/DTS" immediately is not practical as we loose the code base developed, tested and validated for years.
DM/DT has been around for over 7 years now, so it too is "legacy code". So it's not "immediately", it's been several years now of trying to get people to migrate and introducing more firm deadlines about it.
I'm not talking about generic DM/DTS adoption - this goes pretty well.
I'm specific about OF_PLATDATA in SPL, which is lagging behind in the whole U-Boot. To efficiently convert SPL on i.MX we do need it.
And I'm _still_ not removing code that's close to a full year past the published "We're going to remove this now" date.
And this is a good approach. This code is a legacy one, but still working and sometimes used.
when the first "hey, this might be too big for some platforms" conversations started and we changed from "OF_PLATDATA is a stop-gap" to "OF_PLATDATA is a required feature or we'll never be small enough".
Please consider that we even now have issues with some non-converted drivers. Some drivers were "under conversion" for years (spi framework, sf command). Please also note how many drivers actually support OF_PLATDATA?
Yes, it's been hard to get some drivers converted because just not doing it had no consequences. And yes, I'm sure drivers you need will need OF_PLATDATA hooks added.
Yes, certainly.
And it's still unrelated to removing unused features from a build, which this thread is about. If platforms aren't loading U-Boot from EXT4, that's just unused bloat.
I do agree with the above sentence. If the feature is not used - it shall be removed. However, if somebody deployed it already - then - well it must be supported or other, acceptable solution needs to be used (e.g. EXT4 -> VFAT conversion).
Exactly. If people are using EXT4 on iMX6 then it should stay. We dropped it from am335x_evm over a year ago because it wasn't used.
Yes. I also do agree.
I don't want to get into the DM discussion, the intention of this patch was to reduce SPL size, not make room for a future increase.
SPL size should not be reduced at the expense of useful functionality though.
That said, I am surprised it is so controversial to slim down a Defconfig, which (at least in my mind) is just the "Maintainer Recommended Starting Point". By removing Ext4 we stating that it's no needed for the board "typical" use.
Maybe you can remove VFAT first, why ext4 in the first place ?
I guess we shouldn't remove VFAT either (or anything!) since it might break someone setup as well.
Of course, anyone can still turn Ext4 -and many other features- on.
I was under the impression that mainline should be as useful as possible. Maybe I'm mistaken and carrying random downstream patches is now the suggested approach ?
Once again, this is only possible if we maintain SPL "starting point" size as small as possible, which probably excludes DM or any other form of bloat.
In fact, if I can keep removing features and still boot the board with the typical setup, I'll be happy to keep suggesting such patches.
That's fine, unless it breaks other peoples' existing setups .
I don't want to break anyone's setup (much less yours).
I never thought we considered defconfig as something people use, for anything except starting point.
I'm happy to drop this patch (partially or fully).
Thanks, Eze
On 5/27/19 4:59 AM, Ezequiel Garcia wrote: [...]
I don't want to get into the DM discussion, the intention of this patch was to reduce SPL size, not make room for a future increase.
SPL size should not be reduced at the expense of useful functionality though.
That said, I am surprised it is so controversial to slim down a Defconfig, which (at least in my mind) is just the "Maintainer Recommended Starting Point". By removing Ext4 we stating that it's no needed for the board "typical" use.
Maybe you can remove VFAT first, why ext4 in the first place ?
I guess we shouldn't remove VFAT either (or anything!) since it might break someone setup as well.
Correct.
Note that VFAT has quite a footprint, see FS_FAT_MAX_CLUSTSIZE , which ends up preallocating large static buffers.
Of course, anyone can still turn Ext4 -and many other features- on.
I was under the impression that mainline should be as useful as possible. Maybe I'm mistaken and carrying random downstream patches is now the suggested approach ?
Once again, this is only possible if we maintain SPL "starting point" size as small as possible, which probably excludes DM or any other form of bloat.
In fact, if I can keep removing features and still boot the board with the typical setup, I'll be happy to keep suggesting such patches.
That's fine, unless it breaks other peoples' existing setups .
I don't want to break anyone's setup (much less yours).
I hope we don't have some weird personality cult going on here. Just to make this perfectly clear, breaking anyones' setup is bad.
I never thought we considered defconfig as something people use, for anything except starting point.
I think this is where we disconnected. My take is that defconfig is something I build, install the result and can just use the device without fighting any weird problems (like missing support for some obvious boot device).
I'm happy to drop this patch (partially or fully).
Thanks, Eze
Hi Ezequiel,
On 26/05/19 00:57, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote:
i.MX6 platforms boot U-Boot second-stage from unformatted space, and should not need Ext filesystem support on SPL.
The commit was generated with:
git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d'
This change has a dramatic impact on SPL size:
./scripts/bloat-o-meter old new add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) [..] Total: Before=38320, After=29646, chg -22.64%
Cc: Otavio Salvador otavio@ossystems.com.br Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Cc: "Eric Bénard" eric@eukrea.com Cc: Breno Lima breno.lima@nxp.com Cc: Francesco Montefoschi francesco.montefoschi@udoo.org Signed-off-by: Ezequiel Garcia ezequiel@collabora.com
Tested on Wandboard only. Maintainers, please ACK or NAK!
configs/cgtqmx6eval_defconfig | 1 - configs/mx6cuboxi_defconfig | 1 - configs/mx6sabreauto_defconfig | 1 - configs/mx6sabresd_defconfig | 1 - configs/mx6slevk_spl_defconfig | 1 - configs/mx6sxsabresd_spl_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
They *could* be good reasons, but it depends on the use case. In case of Novena as Marek stated, it boots from filesystem and dropping this feature breaks definetly the board.
My position is that each board maintainer can take the decision what is necessary for the board he maintained. I think this should be done per each board, so just send single patches (not a compund as this one) just for the boards you want to drop ext4 (I guess just sabre and Wandboard). If the board maintainers agree (Fabio and Otavio), patches can be merged.
Thanks, Stefano
Hi Stefano,
On Fri, May 31, 2019 at 7:39 AM Stefano Babic sbabic@denx.de wrote:
They *could* be good reasons, but it depends on the use case. In case of Novena as Marek stated, it boots from filesystem and dropping this feature breaks definetly the board.
My position is that each board maintainer can take the decision what is necessary for the board he maintained. I think this should be done per each board, so just send single patches (not a compund as this one) just for the boards you want to drop ext4 (I guess just sabre and Wandboard). If the board maintainers agree (Fabio and Otavio), patches can be merged.
I agree that we should remove CONFIG_SPL_FS_EXT4 on a case by case basis.
Thanks
On 5/31/19 12:42 PM, Fabio Estevam wrote:
Hi Stefano,
On Fri, May 31, 2019 at 7:39 AM Stefano Babic sbabic@denx.de wrote:
They *could* be good reasons, but it depends on the use case. In case of Novena as Marek stated, it boots from filesystem and dropping this feature breaks definetly the board.
My position is that each board maintainer can take the decision what is necessary for the board he maintained. I think this should be done per each board, so just send single patches (not a compund as this one) just for the boards you want to drop ext4 (I guess just sabre and Wandboard). If the board maintainers agree (Fabio and Otavio), patches can be merged.
I agree that we should remove CONFIG_SPL_FS_EXT4 on a case by case basis.
So I will have to track a downstream patch for wandboard now ?
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
I do want to remove it from mx6sabresd for sure.
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
On 5/31/19 2:51 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
I would say this is the recommended approach over just writing U-Boot binary to random offset on the card at hoping that your data will be safe the next time you update it ?
On Fri, May 31, 2019 at 02:57:08PM +0200, Marek Vasut wrote:
On 5/31/19 2:51 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote:
> So I will have to track a downstream patch for wandboard now ?
I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
I would say this is the recommended approach over just writing U-Boot binary to random offset on the card at hoping that your data will be safe the next time you update it ?
No, it's generally not.
On 5/31/19 3:08 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:57:08PM +0200, Marek Vasut wrote:
On 5/31/19 2:51 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote:
On 5/31/19 2:18 PM, Fabio Estevam wrote: > On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote: > >> So I will have to track a downstream patch for wandboard now ? > > I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard.
Ah OK, good, thanks.
> I do want to remove it from mx6sabresd for sure.
How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
I would say this is the recommended approach over just writing U-Boot binary to random offset on the card at hoping that your data will be safe the next time you update it ?
No, it's generally not.
That's not the point, the point is that writing data to random offset is likely to end up with silent FS corruption eventually.
On Fri, May 31, 2019 at 03:22:05PM +0200, Marek Vasut wrote:
On 5/31/19 3:08 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:57:08PM +0200, Marek Vasut wrote:
On 5/31/19 2:51 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote: > On 5/31/19 2:18 PM, Fabio Estevam wrote: >> On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote: >> >>> So I will have to track a downstream patch for wandboard now ? >> >> I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard. > > Ah OK, good, thanks. > >> I do want to remove it from mx6sabresd for sure. > > How does the sabresd boot ?
How does your wandboard/novena boot? I'd have sworn most distros do VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
I would say this is the recommended approach over just writing U-Boot binary to random offset on the card at hoping that your data will be safe the next time you update it ?
No, it's generally not.
That's not the point, the point is that writing data to random offset is likely to end up with silent FS corruption eventually.
No, it's generally not.
On 5/31/19 3:31 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 03:22:05PM +0200, Marek Vasut wrote:
On 5/31/19 3:08 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:57:08PM +0200, Marek Vasut wrote:
On 5/31/19 2:51 PM, Tom Rini wrote:
On Fri, May 31, 2019 at 02:46:45PM +0200, Marek Vasut wrote:
On 5/31/19 2:42 PM, Tom Rini wrote: > On Fri, May 31, 2019 at 02:20:15PM +0200, Marek Vasut wrote: >> On 5/31/19 2:18 PM, Fabio Estevam wrote: >>> On Fri, May 31, 2019 at 9:17 AM Marek Vasut marex@denx.de wrote: >>> >>>> So I will have to track a downstream patch for wandboard now ? >>> >>> I didn't mention we want to remove CONFIG_SPL_FS_EXT4 from Wandboard. >> >> Ah OK, good, thanks. >> >>> I do want to remove it from mx6sabresd for sure. >> >> How does the sabresd boot ? > > How does your wandboard/novena boot? I'd have sworn most distros do > VFAT /boot not ext4 /boot. Of course I'm still surprised anyone is > loading u-boot from fs on iMX since I always see that as raw offsets.
Novena is ext4 for sure, for two reasons -- VFAT has patent problems and putting it at raw offset is just an accident waiting to happen (silent FT corruption if the image gets too large)
So you've setup your own one-off. That's fine and something to support. But it's irregular and uncommon.
I would say this is the recommended approach over just writing U-Boot binary to random offset on the card at hoping that your data will be safe the next time you update it ?
No, it's generally not.
That's not the point, the point is that writing data to random offset is likely to end up with silent FS corruption eventually.
No, it's generally not.
You do agree that putting as much as possible into a filesystem is better and safer than putting it at random offset in raw block device , yes ?
On Fri, May 31, 2019 at 9:20 AM Marek Vasut marex@denx.de wrote:
How does the sabresd boot ?
It boots from SD card with SPL at 1kB and u-boot-dtb.img at 69kB.
We don't need EXT4 in SPL at all.
On 5/31/19 2:43 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:20 AM Marek Vasut marex@denx.de wrote:
How does the sabresd boot ?
It boots from SD card with SPL at 1kB and u-boot-dtb.img at 69kB.
We don't need EXT4 in SPL at all.
It's an accident just waiting to happen -- only a matter of time until someone writes too large u-boot-dtb.img and silently corrupts the file system right behind it ;-)
On Fri, May 31, 2019 at 9:45 AM Marek Vasut marex@denx.de wrote:
It's an accident just waiting to happen -- only a matter of time until someone writes too large u-boot-dtb.img and silently corrupts the file system right behind it ;-)
If u-boot-dtb.img grows it will corrupt the env region.
We can detect this situation in build time using CONFIG_BOARD_SIZE_LIMIT.
On 5/31/19 2:51 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:45 AM Marek Vasut marex@denx.de wrote:
It's an accident just waiting to happen -- only a matter of time until someone writes too large u-boot-dtb.img and silently corrupts the file system right behind it ;-)
If u-boot-dtb.img grows it will corrupt the env region.
We can detect this situation in build time using CONFIG_BOARD_SIZE_LIMIT.
With filesystem, you can grow until you exhaust the boot partition capacity.
On Fri, May 31, 2019 at 02:58:47PM +0200, Marek Vasut wrote:
On 5/31/19 2:51 PM, Fabio Estevam wrote:
On Fri, May 31, 2019 at 9:45 AM Marek Vasut marex@denx.de wrote:
It's an accident just waiting to happen -- only a matter of time until someone writes too large u-boot-dtb.img and silently corrupts the file system right behind it ;-)
If u-boot-dtb.img grows it will corrupt the env region.
We can detect this situation in build time using CONFIG_BOARD_SIZE_LIMIT.
With filesystem, you can grow until you exhaust the boot partition capacity.
Unrestricted growth isn't a good thing :)
On Fri, 2019-05-31 at 12:39 +0200, Stefano Babic wrote:
Hi Ezequiel,
On 26/05/19 00:57, Marek Vasut wrote:
On 5/26/19 12:45 AM, Ezequiel Garcia wrote:
On Sun, 2019-05-26 at 00:24 +0200, Marek Vasut wrote:
On 5/25/19 11:47 PM, Ezequiel Garcia wrote:
On Sat, 2019-05-25 at 22:15 +0200, Marek Vasut wrote:
On 5/25/19 6:49 PM, Ezequiel Garcia wrote: > i.MX6 platforms boot U-Boot second-stage from unformatted space, > and should not need Ext filesystem support on SPL. > > The commit was generated with: > > git grep -l MX6 -- configs/ | xargs grep -l SPL_FS_EXT4 | xargs sed -i -e '/CONFIG_SPL_FS_EXT4=y/d' > > This change has a dramatic impact on SPL size: > > ./scripts/bloat-o-meter old new > add/remove: 0/59 grow/shrink: 0/3 up/down: 0/-8674 (-8674) > [..] > Total: Before=38320, After=29646, chg -22.64% > > Cc: Otavio Salvador otavio@ossystems.com.br > Cc: Fabio Estevam fabio.estevam@nxp.com > Cc: Peng Fan peng.fan@nxp.com > Cc: Marek Vasut marex@denx.de > Cc: Stefano Babic sbabic@denx.de > Cc: Stefan Roese sr@denx.de > Cc: "Eric Bénard" eric@eukrea.com > Cc: Breno Lima breno.lima@nxp.com > Cc: Francesco Montefoschi francesco.montefoschi@udoo.org > Signed-off-by: Ezequiel Garcia ezequiel@collabora.com > --- > Tested on Wandboard only. Maintainers, please ACK or NAK! > > configs/cgtqmx6eval_defconfig | 1 - > configs/mx6cuboxi_defconfig | 1 - > configs/mx6sabreauto_defconfig | 1 - > configs/mx6sabresd_defconfig | 1 - > configs/mx6slevk_spl_defconfig | 1 - > configs/mx6sxsabresd_spl_defconfig | 1 - > configs/mx6ul_14x14_evk_defconfig | 1 - > configs/mx6ul_9x9_evk_defconfig | 1 - > configs/novena_defconfig | 1 -
NAK, I boot my Novena from ext4 and this just broke it.
And also, NAK, this removes functionality from SPL which worked fine before.
I'll drop from Novena, but I think the patch still makes some sense, why do you want Ext4 on SPL?
What other filesystem is available in SPL and doesn't have patent problems ?
Sorry for not being clear. I am asking why turn on a feature that is so heavy, on a system that won't need it (such as Sabre* boards, Wandboard and similar)?
Two reasons:
- It was enabled, disabling it means removing functionality for no good reason (oops, bloat, is not a good reason), and that is not desired.
- Booting from block device implies booting from a filesystem, otherwise you might overwrite various things on the block device when updating the file (u-boot image).
They *could* be good reasons, but it depends on the use case. In case of Novena as Marek stated, it boots from filesystem and dropping this feature breaks definetly the board.
My position is that each board maintainer can take the decision what is necessary for the board he maintained. I think this should be done per each board, so just send single patches (not a compund as this one) just for the boards you want to drop ext4 (I guess just sabre and Wandboard). If the board maintainers agree (Fabio and Otavio), patches can be merged.
I am dropping these changes. If board maintainers want to pursue this path, it's up to them, as this clearly has heavier implications than I originally thought.
Thanks, Ezequiel
participants (7)
-
Ezequiel Garcia -
Ezequiel Garcia -
Fabio Estevam -
Lukasz Majewski -
Marek Vasut -
Stefano Babic -
Tom Rini