Re: [PATCH u-boot-mvebu 1/2] arm: mvebu: turris_omnia: force 40 MHz speed on SPI NOR

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Fri, Jul 09, 2021 at 05:00:09PM +0200, Marek Behún wrote:
> On Fri,  9 Jul 2021 16:56:13 +0200
> Marek Behún <marek.behun@nic.cz> wrote:
> 
> > Commit e2e95e5e2542 ("spi: Update speed/mode on change") changed the
> > boot time on Turris Omnia from ~2.3s to over 8s, due to SPL loading
> > main U-Boot from SPI NOR at 1 MHz instead of 40 MHz.
> > 
> > This is because the SPL code passes the CONFIG_SF_DEFAULT_SPEED option
> > to spi_flash_probe(), and with the above commit spi_flash_probe()
> > starts prefering this parameter instead of the one specified in
> > device-tree.
> > 
> > The proper solution here would probably be to fix the SF subsystem to
> > prefer the frequency specified in the device-tree, if it is present,
> > but I am not sure what else will be affected on other boards with
> > such a change. So until then we need a more simple fix.
> > 
> > Since the CONFIG_SF_DEFAULT_SPEED option is used by the code, put the
> > correct value there for Turris Omnia. Also put the correct value to
> > CONFIG_SF_DEFAULT_MODE and use 40 MHz when reading environment.
> 
> BTW this change is currently needed even if the other series (making
> use of BootROM code to load main U-Boot instead of SPL doing it) is
> accepted: commit e2e95e5e2542 also changed the behavior of the
>   sf read / sf update
> command - it is slower since it operates at 1 MHz now instead of 40 MHz
> as specified in the device-tree.

Ugh.  This is the second bit of unexpected fall-out from that change.
Since it's the start now of the merge window, no point in reverting the
change now.  Sorry about that!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]