* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
@ 2019-05-25 16:49 Ezequiel Garcia
2019-05-25 20:15 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-25 16:49 UTC (permalink / raw)
To: u-boot
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
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 16:49 [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms Ezequiel Garcia
@ 2019-05-25 20:15 ` Marek Vasut
2019-05-25 21:47 ` Ezequiel Garcia
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-25 20:15 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 20:15 ` Marek Vasut
@ 2019-05-25 21:47 ` Ezequiel Garcia
2019-05-25 22:24 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-25 21:47 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 21:47 ` Ezequiel Garcia
@ 2019-05-25 22:24 ` Marek Vasut
2019-05-25 22:45 ` Ezequiel Garcia
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-25 22:24 UTC (permalink / raw)
To: u-boot
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 22:24 ` Marek Vasut
@ 2019-05-25 22:45 ` Ezequiel Garcia
2019-05-25 22:57 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-25 22:45 UTC (permalink / raw)
To: u-boot
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)?
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 22:45 ` Ezequiel Garcia
@ 2019-05-25 22:57 ` Marek Vasut
2019-05-25 23:08 ` Tom Rini
2019-05-31 10:39 ` Stefano Babic
0 siblings, 2 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-25 22:57 UTC (permalink / raw)
To: u-boot
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).
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 22:57 ` Marek Vasut
@ 2019-05-25 23:08 ` Tom Rini
2019-05-25 23:20 ` Marek Vasut
2019-05-31 10:39 ` Stefano Babic
1 sibling, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-25 23:08 UTC (permalink / raw)
To: u-boot
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? 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?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190525/12e291cf/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 23:08 ` Tom Rini
@ 2019-05-25 23:20 ` Marek Vasut
2019-05-25 23:23 ` Tom Rini
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-25 23:20 UTC (permalink / raw)
To: u-boot
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.
"
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 23:20 ` Marek Vasut
@ 2019-05-25 23:23 ` Tom Rini
2019-05-25 23:30 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-25 23:23 UTC (permalink / raw)
To: u-boot
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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190525/38f68258/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 23:23 ` Tom Rini
@ 2019-05-25 23:30 ` Marek Vasut
2019-05-26 0:33 ` Tom Rini
2019-05-26 8:22 ` Lukasz Majewski
0 siblings, 2 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-25 23:30 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 23:30 ` Marek Vasut
@ 2019-05-26 0:33 ` Tom Rini
2019-05-26 2:58 ` Marek Vasut
2019-05-26 8:22 ` Lukasz Majewski
1 sibling, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-26 0:33 UTC (permalink / raw)
To: u-boot
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:
> >>>> 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.
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190525/c2dc646e/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 0:33 ` Tom Rini
@ 2019-05-26 2:58 ` Marek Vasut
0 siblings, 0 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-26 2:58 UTC (permalink / raw)
To: u-boot
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:
>>>>>> 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.
>
> 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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 23:30 ` Marek Vasut
2019-05-26 0:33 ` Tom Rini
@ 2019-05-26 8:22 ` Lukasz Majewski
2019-05-26 10:45 ` Tom Rini
1 sibling, 1 reply; 41+ messages in thread
From: Lukasz Majewski @ 2019-05-26 8:22 UTC (permalink / raw)
To: u-boot
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.
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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190526/1b2f8768/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 8:22 ` Lukasz Majewski
@ 2019-05-26 10:45 ` Tom Rini
2019-05-26 11:46 ` Lukasz Majewski
0 siblings, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-26 10:45 UTC (permalink / raw)
To: u-boot
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.
>
> 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.
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190526/046fbeed/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 10:45 ` Tom Rini
@ 2019-05-26 11:46 ` Lukasz Majewski
2019-05-26 11:52 ` Marek Vasut
2019-05-26 12:30 ` Tom Rini
0 siblings, 2 replies; 41+ messages in thread
From: Lukasz Majewski @ 2019-05-26 11:46 UTC (permalink / raw)
To: u-boot
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.
> >
> > 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.
> 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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190526/1c83a528/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 11:46 ` Lukasz Majewski
@ 2019-05-26 11:52 ` Marek Vasut
2019-05-26 12:30 ` Tom Rini
1 sibling, 0 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-26 11:52 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 11:46 ` Lukasz Majewski
2019-05-26 11:52 ` Marek Vasut
@ 2019-05-26 12:30 ` Tom Rini
2019-05-26 15:04 ` Lukasz Majewski
1 sibling, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-26 12:30 UTC (permalink / raw)
To: u-boot
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.
> > >
> > > 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.
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190526/e4b8a173/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 12:30 ` Tom Rini
@ 2019-05-26 15:04 ` Lukasz Majewski
2019-05-26 16:18 ` Ezequiel Garcia
0 siblings, 1 reply; 41+ messages in thread
From: Lukasz Majewski @ 2019-05-26 15:04 UTC (permalink / raw)
To: u-boot
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.
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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190526/3b6f384d/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 15:04 ` Lukasz Majewski
@ 2019-05-26 16:18 ` Ezequiel Garcia
2019-05-26 17:30 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-26 16:18 UTC (permalink / raw)
To: u-boot
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.
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 16:18 ` Ezequiel Garcia
@ 2019-05-26 17:30 ` Marek Vasut
2019-05-27 2:59 ` Ezequiel Garcia
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-26 17:30 UTC (permalink / raw)
To: u-boot
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 ?
> 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 .
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-26 17:30 ` Marek Vasut
@ 2019-05-27 2:59 ` Ezequiel Garcia
2019-05-27 3:33 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-27 2:59 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-27 2:59 ` Ezequiel Garcia
@ 2019-05-27 3:33 ` Marek Vasut
0 siblings, 0 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-27 3:33 UTC (permalink / raw)
To: u-boot
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
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-25 22:57 ` Marek Vasut
2019-05-25 23:08 ` Tom Rini
@ 2019-05-31 10:39 ` Stefano Babic
2019-05-31 10:42 ` Fabio Estevam
2019-05-31 12:24 ` Ezequiel Garcia
1 sibling, 2 replies; 41+ messages in thread
From: Stefano Babic @ 2019-05-31 10:39 UTC (permalink / raw)
To: u-boot
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:
> 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).
>
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
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 10:39 ` Stefano Babic
@ 2019-05-31 10:42 ` Fabio Estevam
2019-05-31 12:17 ` Marek Vasut
2019-05-31 12:24 ` Ezequiel Garcia
1 sibling, 1 reply; 41+ messages in thread
From: Fabio Estevam @ 2019-05-31 10:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 10:42 ` Fabio Estevam
@ 2019-05-31 12:17 ` Marek Vasut
2019-05-31 12:18 ` Fabio Estevam
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:17 UTC (permalink / raw)
To: u-boot
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:17 ` Marek Vasut
@ 2019-05-31 12:18 ` Fabio Estevam
2019-05-31 12:20 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Fabio Estevam @ 2019-05-31 12:18 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:18 ` Fabio Estevam
@ 2019-05-31 12:20 ` Marek Vasut
2019-05-31 12:42 ` Tom Rini
2019-05-31 12:43 ` Fabio Estevam
0 siblings, 2 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:20 UTC (permalink / raw)
To: u-boot
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 10:39 ` Stefano Babic
2019-05-31 10:42 ` Fabio Estevam
@ 2019-05-31 12:24 ` Ezequiel Garcia
1 sibling, 0 replies; 41+ messages in thread
From: Ezequiel Garcia @ 2019-05-31 12:24 UTC (permalink / raw)
To: u-boot
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:
> > 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).
> >
>
> 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:20 ` Marek Vasut
@ 2019-05-31 12:42 ` Tom Rini
2019-05-31 12:46 ` Marek Vasut
2019-05-31 12:43 ` Fabio Estevam
1 sibling, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-31 12:42 UTC (permalink / raw)
To: u-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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190531/f64368db/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:20 ` Marek Vasut
2019-05-31 12:42 ` Tom Rini
@ 2019-05-31 12:43 ` Fabio Estevam
2019-05-31 12:45 ` Marek Vasut
1 sibling, 1 reply; 41+ messages in thread
From: Fabio Estevam @ 2019-05-31 12:43 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:43 ` Fabio Estevam
@ 2019-05-31 12:45 ` Marek Vasut
2019-05-31 12:51 ` Fabio Estevam
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:45 UTC (permalink / raw)
To: u-boot
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 ;-)
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:42 ` Tom Rini
@ 2019-05-31 12:46 ` Marek Vasut
2019-05-31 12:51 ` Tom Rini
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:46 UTC (permalink / raw)
To: u-boot
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)
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:45 ` Marek Vasut
@ 2019-05-31 12:51 ` Fabio Estevam
2019-05-31 12:58 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Fabio Estevam @ 2019-05-31 12:51 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:46 ` Marek Vasut
@ 2019-05-31 12:51 ` Tom Rini
2019-05-31 12:57 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-31 12:51 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190531/b6e712ba/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:51 ` Tom Rini
@ 2019-05-31 12:57 ` Marek Vasut
2019-05-31 13:08 ` Tom Rini
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:57 UTC (permalink / raw)
To: u-boot
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:51 ` Fabio Estevam
@ 2019-05-31 12:58 ` Marek Vasut
2019-05-31 13:08 ` Tom Rini
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 12:58 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:57 ` Marek Vasut
@ 2019-05-31 13:08 ` Tom Rini
2019-05-31 13:22 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-31 13:08 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190531/7fa7717b/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 12:58 ` Marek Vasut
@ 2019-05-31 13:08 ` Tom Rini
0 siblings, 0 replies; 41+ messages in thread
From: Tom Rini @ 2019-05-31 13:08 UTC (permalink / raw)
To: u-boot
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 :)
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190531/c1decf0a/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 13:08 ` Tom Rini
@ 2019-05-31 13:22 ` Marek Vasut
2019-05-31 13:31 ` Tom Rini
0 siblings, 1 reply; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 13:22 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 13:22 ` Marek Vasut
@ 2019-05-31 13:31 ` Tom Rini
2019-05-31 13:40 ` Marek Vasut
0 siblings, 1 reply; 41+ messages in thread
From: Tom Rini @ 2019-05-31 13:31 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190531/ec2ceb40/attachment.sig>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms
2019-05-31 13:31 ` Tom Rini
@ 2019-05-31 13:40 ` Marek Vasut
0 siblings, 0 replies; 41+ messages in thread
From: Marek Vasut @ 2019-05-31 13:40 UTC (permalink / raw)
To: u-boot
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2019-05-31 13:40 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-25 16:49 [U-Boot] [PATCH] configs: Remove CONFIG_SPL_FS_EXT4 for all MX6 platforms Ezequiel Garcia
2019-05-25 20:15 ` Marek Vasut
2019-05-25 21:47 ` Ezequiel Garcia
2019-05-25 22:24 ` Marek Vasut
2019-05-25 22:45 ` Ezequiel Garcia
2019-05-25 22:57 ` Marek Vasut
2019-05-25 23:08 ` Tom Rini
2019-05-25 23:20 ` Marek Vasut
2019-05-25 23:23 ` Tom Rini
2019-05-25 23:30 ` Marek Vasut
2019-05-26 0:33 ` Tom Rini
2019-05-26 2:58 ` Marek Vasut
2019-05-26 8:22 ` Lukasz Majewski
2019-05-26 10:45 ` Tom Rini
2019-05-26 11:46 ` Lukasz Majewski
2019-05-26 11:52 ` Marek Vasut
2019-05-26 12:30 ` Tom Rini
2019-05-26 15:04 ` Lukasz Majewski
2019-05-26 16:18 ` Ezequiel Garcia
2019-05-26 17:30 ` Marek Vasut
2019-05-27 2:59 ` Ezequiel Garcia
2019-05-27 3:33 ` Marek Vasut
2019-05-31 10:39 ` Stefano Babic
2019-05-31 10:42 ` Fabio Estevam
2019-05-31 12:17 ` Marek Vasut
2019-05-31 12:18 ` Fabio Estevam
2019-05-31 12:20 ` Marek Vasut
2019-05-31 12:42 ` Tom Rini
2019-05-31 12:46 ` Marek Vasut
2019-05-31 12:51 ` Tom Rini
2019-05-31 12:57 ` Marek Vasut
2019-05-31 13:08 ` Tom Rini
2019-05-31 13:22 ` Marek Vasut
2019-05-31 13:31 ` Tom Rini
2019-05-31 13:40 ` Marek Vasut
2019-05-31 12:43 ` Fabio Estevam
2019-05-31 12:45 ` Marek Vasut
2019-05-31 12:51 ` Fabio Estevam
2019-05-31 12:58 ` Marek Vasut
2019-05-31 13:08 ` Tom Rini
2019-05-31 12:24 ` Ezequiel Garcia
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.