| Message ID | 20181128172607.10179-5-vigneshr@ti.com |
|---|---|
| State | RFC |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
| Series | SF: Migrate to Linux SPI NOR framework | expand |
On 11/28/2018 06:26 PM, Vignesh R wrote: > Enable tiny printf to reduce SPL foot print This should be enabled already on Gen2, no ? Anyway, what's the size growth on Gen2 with the new Linux SF framework ? > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > configs/porter_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/porter_defconfig b/configs/porter_defconfig > index d51db3d5cb28..14af0f69a278 100644 > --- a/configs/porter_defconfig > +++ b/configs/porter_defconfig > @@ -87,3 +87,4 @@ CONFIG_DM_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_PCI=y > CONFIG_USB_STORAGE=y > +CONFIG_USE_TINY_PRINTF=y >
On 28.11.2018 18:52, Marek Vasut wrote: > On 11/28/2018 06:26 PM, Vignesh R wrote: >> Enable tiny printf to reduce SPL foot print > This should be enabled already on Gen2, no ? > Anyway, what's the size growth on Gen2 with the new Linux SF framework ? After downloading the missing patch 1/6 from github and testing it on socfpga gen5, my SPL got ~2500 byte larger. While I think porting this from Linux is the right thing to do, I can't say I'm happy with losing yet another 2.5 kB for SPL when it is already too stuffed to add secure boot via FIT signatures. Regards, Simon > >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> configs/porter_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configs/porter_defconfig b/configs/porter_defconfig >> index d51db3d5cb28..14af0f69a278 100644 >> --- a/configs/porter_defconfig >> +++ b/configs/porter_defconfig >> @@ -87,3 +87,4 @@ CONFIG_DM_USB=y >> CONFIG_USB_EHCI_HCD=y >> CONFIG_USB_EHCI_PCI=y >> CONFIG_USB_STORAGE=y >> +CONFIG_USE_TINY_PRINTF=y >> >
On 11/28/2018 09:34 PM, Simon Goldschmidt wrote: > On 28.11.2018 18:52, Marek Vasut wrote: >> On 11/28/2018 06:26 PM, Vignesh R wrote: >>> Enable tiny printf to reduce SPL foot print >> This should be enabled already on Gen2, no ? >> Anyway, what's the size growth on Gen2 with the new Linux SF framework ? > > After downloading the missing patch 1/6 from github and testing it on > socfpga gen5, my SPL got ~2500 byte larger. > > While I think porting this from Linux is the right thing to do, I can't > say I'm happy with losing yet another 2.5 kB for SPL when it is already > too stuffed to add secure boot via FIT signatures. Indeed. Can we somehow trim things down a bit for SPL ?
Hi Marek, Simon On 29/11/18 3:20 AM, Marek Vasut wrote: > On 11/28/2018 09:34 PM, Simon Goldschmidt wrote: >> On 28.11.2018 18:52, Marek Vasut wrote: >>> On 11/28/2018 06:26 PM, Vignesh R wrote: >>>> Enable tiny printf to reduce SPL foot print >>> This should be enabled already on Gen2, no ? Right, its already enabled, please ignore this particular patch. I saw sram overflow with this config when running buildman and therefore though this change might help. >>> Anyway, what's the size growth on Gen2 with the new Linux SF framework ? >> >> After downloading the missing patch 1/6 from github and testing it on >> socfpga gen5, my SPL got ~2500 byte larger. >> I guess patch 1/6 took a bit more time to get across. I can see it in patchworks: https://patchwork.ozlabs.org/patch/1004836/ >> While I think porting this from Linux is the right thing to do, I can't >> say I'm happy with losing yet another 2.5 kB for SPL when it is already >> too stuffed to add secure boot via FIT signatures. > > Indeed. Can we somehow trim things down a bit for SPL ? > I am able to trim overall size delta to within 1KB for porter_defconfig. Pushed new set of patches to github[1] With new this new SF framework and porter_defconfig: size spl/u-boot-spl text data bss dec hex filename 15749 184 1100 17033 4289 spl/u-boot-spl Current mainline: size spl/u-boot-spl text data bss dec hex filename 14881 184 1100 16165 3f25 spl/u-boot-spl Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different platforms depending on flash devices supports enabled. I am not sure if its possible to trim this down further, as there is addition of new code to handle 4 Byte addressing feature and moving to spi-mem framework to support direct mapping capable SPI controllers. These features will add to code size and I hope that's an acceptable tradeoff. I believe, once SPI NOR is completely integrated with MTD framework, there will be some size reduction(such as due to getting rid of sf_mtd.c and spi_flash_* APIs completely. Also, loading of U-Boot images across NAND/SPI NOR can be consolidated). I will post revised patches to mailing list after travis ci report. [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-v2
Hi Vignesh, > >> While I think porting this from Linux is the right thing to do, I can't > >> say I'm happy with losing yet another 2.5 kB for SPL when it is already > >> too stuffed to add secure boot via FIT signatures. > > > > Indeed. Can we somehow trim things down a bit for SPL ? > > > > I am able to trim overall size delta to within 1KB for porter_defconfig. > Pushed new set of patches to github[1] > > With new this new SF framework and porter_defconfig: > size spl/u-boot-spl > text data bss dec hex filename > 15749 184 1100 17033 4289 spl/u-boot-spl > > Current mainline: > size spl/u-boot-spl > text data bss dec hex filename > 14881 184 1100 16165 3f25 spl/u-boot-spl > > Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different > platforms depending on flash devices supports enabled. > > I am not sure if its possible to trim this down further, as there is > addition of new code to handle 4 Byte addressing feature and moving to > spi-mem framework to support direct mapping capable SPI controllers. > These features will add to code size and I hope that's an acceptable > tradeoff. > > I believe, once SPI NOR is completely integrated with MTD framework, > there will be some size reduction(such as due to getting rid of sf_mtd.c > and spi_flash_* APIs completely. Also, loading of U-Boot images across > NAND/SPI NOR can be consolidated). There are already multiple SPL-specific drivers out there. While I don't see a problem building MTD in U-Boot, I wonder if building MTD in the SPL is a good idea. Instead, Why not just build a tiny "SPL MTD stack", a lightweight MTD stack just with minimal features? > > I will post revised patches to mailing list after travis ci report. > > [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-v2 > Thanks, Miquèl
On Thu, Nov 29, 2018 at 11:56 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Vignesh, > > > >> While I think porting this from Linux is the right thing to do, I can't > > >> say I'm happy with losing yet another 2.5 kB for SPL when it is already > > >> too stuffed to add secure boot via FIT signatures. > > > > > > Indeed. Can we somehow trim things down a bit for SPL ? > > > > > > > I am able to trim overall size delta to within 1KB for porter_defconfig. > > Pushed new set of patches to github[1] > > > > With new this new SF framework and porter_defconfig: > > size spl/u-boot-spl > > text data bss dec hex filename > > 15749 184 1100 17033 4289 spl/u-boot-spl > > > > Current mainline: > > size spl/u-boot-spl > > text data bss dec hex filename > > 14881 184 1100 16165 3f25 spl/u-boot-spl > > > > Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different > > platforms depending on flash devices supports enabled. > > > > I am not sure if its possible to trim this down further, as there is > > addition of new code to handle 4 Byte addressing feature and moving to > > spi-mem framework to support direct mapping capable SPI controllers. > > These features will add to code size and I hope that's an acceptable > > tradeoff. > > > > I believe, once SPI NOR is completely integrated with MTD framework, > > there will be some size reduction(such as due to getting rid of sf_mtd.c > > and spi_flash_* APIs completely. Also, loading of U-Boot images across > > NAND/SPI NOR can be consolidated). > > There are already multiple SPL-specific drivers out there. While I don't > see a problem building MTD in U-Boot, I wonder if building MTD in the > SPL is a good idea. Instead, Why not just build a tiny "SPL MTD stack", > a lightweight MTD stack just with minimal features? I think that would be a good idea. Simple read access should probably be enough for SPL to load U-Boot. That would free some space I need to verify FIT signatures... Simon > > > > > I will post revised patches to mailing list after travis ci report. > > > > [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-v2 > > > > > Thanks, > Miquèl
On 11/29/2018 11:44 AM, Vignesh R wrote: > Hi Marek, Simon Hi, > On 29/11/18 3:20 AM, Marek Vasut wrote: >> On 11/28/2018 09:34 PM, Simon Goldschmidt wrote: >>> On 28.11.2018 18:52, Marek Vasut wrote: >>>> On 11/28/2018 06:26 PM, Vignesh R wrote: >>>>> Enable tiny printf to reduce SPL foot print >>>> This should be enabled already on Gen2, no ? > > Right, its already enabled, please ignore this particular patch. I saw > sram overflow with this config when running buildman and therefore > though this change might help. > >>>> Anyway, what's the size growth on Gen2 with the new Linux SF framework ? >>> >>> After downloading the missing patch 1/6 from github and testing it on >>> socfpga gen5, my SPL got ~2500 byte larger. >>> > > I guess patch 1/6 took a bit more time to get across. I can see it in > patchworks: https://patchwork.ozlabs.org/patch/1004836/ > >>> While I think porting this from Linux is the right thing to do, I can't >>> say I'm happy with losing yet another 2.5 kB for SPL when it is already >>> too stuffed to add secure boot via FIT signatures. >> >> Indeed. Can we somehow trim things down a bit for SPL ? >> > > I am able to trim overall size delta to within 1KB for porter_defconfig. > Pushed new set of patches to github[1] > > With new this new SF framework and porter_defconfig: > size spl/u-boot-spl > text data bss dec hex filename > 15749 184 1100 17033 4289 spl/u-boot-spl > > Current mainline: > size spl/u-boot-spl > text data bss dec hex filename > 14881 184 1100 16165 3f25 spl/u-boot-spl > > Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different > platforms depending on flash devices supports enabled. > > I am not sure if its possible to trim this down further, as there is > addition of new code to handle 4 Byte addressing feature and moving to > spi-mem framework to support direct mapping capable SPI controllers. > These features will add to code size and I hope that's an acceptable > tradeoff. It's not really acceptable if the system cannot boot anymore since the SPL is larger than 16 kiB, which is the limit for this system. So this must be somehow made configurable or fixed. > I believe, once SPI NOR is completely integrated with MTD framework, > there will be some size reduction(such as due to getting rid of sf_mtd.c > and spi_flash_* APIs completely. Also, loading of U-Boot images across > NAND/SPI NOR can be consolidated). This doesn't help if there are systems which cannot boot in the meantime. > I will post revised patches to mailing list after travis ci report. > > [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-v2 >
On 29/11/18 4:48 PM, Simon Goldschmidt wrote: > On Thu, Nov 29, 2018 at 11:56 AM Miquel Raynal > <miquel.raynal@bootlin.com> wrote: >> >> Hi Vignesh, >> >>>>> While I think porting this from Linux is the right thing to do, I can't >>>>> say I'm happy with losing yet another 2.5 kB for SPL when it is already >>>>> too stuffed to add secure boot via FIT signatures. >>>> >>>> Indeed. Can we somehow trim things down a bit for SPL ? >>>> >>> >>> I am able to trim overall size delta to within 1KB for porter_defconfig. >>> Pushed new set of patches to github[1] >>> >>> With new this new SF framework and porter_defconfig: >>> size spl/u-boot-spl >>> text data bss dec hex filename >>> 15749 184 1100 17033 4289 spl/u-boot-spl >>> >>> Current mainline: >>> size spl/u-boot-spl >>> text data bss dec hex filename >>> 14881 184 1100 16165 3f25 spl/u-boot-spl >>> >>> Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different >>> platforms depending on flash devices supports enabled. >>> >>> I am not sure if its possible to trim this down further, as there is >>> addition of new code to handle 4 Byte addressing feature and moving to >>> spi-mem framework to support direct mapping capable SPI controllers. >>> These features will add to code size and I hope that's an acceptable >>> tradeoff. >>> >>> I believe, once SPI NOR is completely integrated with MTD framework, >>> there will be some size reduction(such as due to getting rid of sf_mtd.c >>> and spi_flash_* APIs completely. Also, loading of U-Boot images across >>> NAND/SPI NOR can be consolidated). >> >> There are already multiple SPL-specific drivers out there. While I don't >> see a problem building MTD in U-Boot, I wonder if building MTD in the >> SPL is a good idea. Instead, Why not just build a tiny "SPL MTD stack", >> a lightweight MTD stack just with minimal features? > > I think that would be a good idea. Simple read access should probably > be enough for SPL to load U-Boot. That would free some space I need to > verify FIT signatures... > Okay, I plan to implement spi-nor-tiny.c as part of next version that would support just discovering connected flash via JEDEC ID and reading images from flash at best possible IO mode with 4-byte addressing. This can serve as lightweight SPL stack for SPI NOR to overcome size limitations. Let me know if there are any concerns. Thanks for the suggestions!
diff --git a/configs/porter_defconfig b/configs/porter_defconfig index d51db3d5cb28..14af0f69a278 100644 --- a/configs/porter_defconfig +++ b/configs/porter_defconfig @@ -87,3 +87,4 @@ CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y CONFIG_USB_STORAGE=y +CONFIG_USE_TINY_PRINTF=y
Enable tiny printf to reduce SPL foot print Signed-off-by: Vignesh R <vigneshr@ti.com> --- configs/porter_defconfig | 1 + 1 file changed, 1 insertion(+)