[U-Boot] [RFC PATCH 4/6] porter_defconfig: Enable tiny printf

[Vignesh R]

On 29/11/18 4:48 PM, Simon Goldschmidt wrote:
> On Thu, Nov 29, 2018 at 11:56 AM Miquel Raynal
> <miquel.raynal at 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!


-- 
Regards
Vignesh