[PATCH] mvebu: x530: Reduce SPL image size

[Stefan Roese]

Hi Chris,

On 12.05.21 23:20, Chris Packham wrote:
> On Wed, May 12, 2021 at 8:06 PM Stefan Roese <sr at denx.de> wrote:
>>
>> On 12.05.21 09:59, Chris Packham wrote:
>>> On Wed, May 12, 2021 at 7:18 PM Stefan Roese <sr at denx.de> wrote:
>>>>
>>>> Currently, building U-Boot for x530 fails since the SPL image is too
>>>> big.
>>>
>>> Currently? It's working for me on master. Are there upcoming mvebu
>>> changes that push us over the limit?
>>
>> Yes, I'm working on a pull request right now. Some enhancements to the
>> SPI driver are most likely responsible for the code increase.
>>
>>>> This patch reduces the SPL size by changing the following Kconfig
>>>> options:
>>>>
>>>> Enable CONFIG_SPL_TINY_MEMSET
>>>> Disable CONFIG_SPI_FLASH_BAR
>>>>
>>>> By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be
>>>> used.
>>>
>>> I've got a nagging feeling I needed CONFIG_SPI_FLASH_BAR for some
>>> reason. Possibly for some alternate part we were looking at, on the
>>> other hand it could also be from the db88f6820-amc board which I based
>>> the initial defconfig on.
>>>
>>> Looking at what CONFIG_SPI_FLASH_BAR does I think we should be safe.
>>> We only fit 16MiB parts and aren't likely to start fitting bigger
>>> parts unless all the spi-nor vendors decide to stop making ones
>>> <16MiB.
>>
>> Please note that there are better ways to handle the > 16MiB SPI
>> NOR issue. E.g. by using 3 vs 4 byte commands and Serial Flash
>> Discoverable Parameters (SFDP) parsing, which is supported in
>> U-Boot since quite some time. I did not use CONFIG_SPI_FLASH_BAR
>> for a longer time now IIRC.
>>
> 
> I think (but am not sure) that the 4 byte command mode upsets the
> bootrom when booting from spi flash. On and off I've hit a problem on
> the db-88f6820-amc which does have a 32MiB flash fitted where the
> bootrom can't fetch the first boot stage on reboot after booting linux
> (for some kernel versions). Power cycling resolves the problem. I
> think this might be because the bootrom only speaks the 3 byte
> protocol and once the chip is put into 4 byte mode the bootrom lacks
> the ability to change back. None of this affects the x530 so there is
> no problem with this change. I'm just putting this out there for
> future mailing list readers.

Yes, this is known issue. Or it was a known issue. Newer version support
the stateless 4-byte opcodes, which don't configure the SPI NOR into
4-byte mode. This resolves this problem with the bootrom AFAIR.

Thanks,
Stefan