STM32MP1 boot slow
patrick.delaunay at st.com
Fri Mar 27 16:35:20 CET 2020
> From: Marek Vasut <marex at denx.de>
> Sent: jeudi 26 mars 2020 17:28
> On 3/26/20 5:19 PM, Simon Glass wrote:
> > Hi Patrick,
> > On Wed, 25 Mar 2020 at 09:57, Patrick DELAUNAY <patrick.delaunay at st.com>
> >> Hi,
> >>> From: Marek Vasut <marex at denx.de>
> >>> Sent: mercredi 25 mars 2020 00:39
> >>> Hi,
> >>> I was looking at the STM32MP1 boot time and I noticed it takes about
> >>> 2 seconds to get to U-Boot.
> >> Thanks for the feedback.
> >> To be clear, the SPL is not the ST priority as we have many
> >> limitation (mainly on power management) for the SPL boot chain
> >> Rom code => SPL => U-Boot
> >> The preconized boot chain for STM32MP1 is Rom code => TF-A => U-Boot
> >> (stm32mp15_trusted_defconfg).
> >>> One problem is the insane I2C timing calculation in stm32f7 i2c
> >>> driver, which is almost a mallocator and CPU stress test and takes
> >>> about 1 second to complete in SPL -- we need some simpler
> >>> replacement for that, possibly the one in DWC I2C driver might do?
> >> Our first idea to manage this I2C settings (prescaler/timings
> >> setting) was to set this values in device tree, but this binding was
> >> refused so this function stm32_i2c_choose_solution()
> > Was the binding refused in linux? Could we add something
> > U-Boot-specific then? I think having 'early' timings, etc. is very
> > handy. We are doing this on x86.
> > Of course it has traditionally been impossible to convince Linux
> > people to add this sort of thing. Still, I think we should do it. Our
> > U-Boot-specific files allow this.
> Or reuse the DWC I2C driver timing calculation, which is real simple, fast, and
> should be accurate enough.
Yes I checked
I agree that something simple should be possible to found 'good enough' setting.
But I don't ding in the ST I2C specification.... I waiting internal feedback
> >> provided the better settings for any input clock and I2C frequency (called for
> each probe).
> >> But it is brutal and not optimum solution: try all the solution to found the better
> >> And the performance problem of this loop (shared code between Linux /
> >> U-Boot/TF-A drivers) had be already see/checked on ST side in TF-A context.
> > We should be able to calculate it, like with dw-i2c.
> >> We try to improve the solution, without success, but finally the
> >> performance issue was solved by dcache activation in TF-A before to execute
> this loop.
> > I would like to see patches to enable the cache. We did this some
> > years ago in a Chromebook and it made a big difference. It is not that
> > hard.
> ACK. Why did the chromebook patches never make it upstream ?
Work in progress
For example, the result on STM32MP157C-DK2 board is:
1,6s gain for trusted boot chain with TF-A
2,2s gain for basic boot chain with SPL
I will push this patch after sanity checks
(ARM requirement on TLB / cache update with MMU activated).
> >> But as in SPL the data cache is not activated, this loop has terrible
> >> We need to ding again of this topic for U-Boot point of view (SPL &
> >> also in U-Boot, before relocation and after relocation) .
> >> And I had shared this issue with the ST owner of this code.
> >> For information, I add some trace and I get for same code execution on DK2
> >> - 440ms in SPL (dcache OFF)
> >> - 36ms in U-Boot (dcache ON)
> >>> Another item I found is that, in U-Boot, initf_dm() takes about half
> >>> a second and so does serial_init(). I didn't dig into it to find out
> >>> why, but I suspect it has to do with the massive amount of UCLASSes
> >>> the DM has to traverse OR with the CPU being slow at that point, as the
> clock driver didn't get probed just yet.
> >>> Thoughts ?
> >> Yes, it is the first parsing of device tree, and it is really slow...
> >> directly linked to device tree size and libfdt.
> > I wonder if we can improve this. There was a change to how the drivers
> > were bound (changing the ordering). We could perhaps revert that for
> > SPL.
> Link ?
> Best regards,
> Marek Vasut
More information about the U-Boot