[U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state

[Andreas Dannenberg]

Hi Philipp,

On Fri, Aug 24, 2018 at 06:00:31PM +0200, Dr. Philipp Tomsich wrote:

<snip>

> >> If I remember correctly, David had a concern regarding an increase in
> >> boottime if we ran this twice… adding Kever, as he was also involved
> >> in the discussion.
> >> 
> >> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
> >> boottime increase comes from the fact that some devices have a large
> >> number of assigned-clocks, that the device-tree processing has a cost,
> >> and that we don’t have a way of synchronising between SPL and full
> >> U-Boot to avoid redoing the complete init-flow.
> > 
> > Good to know some of the background; when I did this patch initially it
> > was not really clear why this was removed and it obviously was an issue
> > for what I was doing that I had to overcome and re-adding this was the
> > simpliest thing to do at that time.
> > 
> >> Maybe we should have a SPL-specific property for the assigned-clocks
> >> to be set pre-reloc?
> > 
> > Need to think about this some more. Generally we probably want to do as
> > little as possible before relocation. Unfortunately for the K3 family of
> > SoCs much is dependent on loading/installing the system firmware (SYSFW)
> > image including to get DDR operational which itself requires us to use a
> > lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
> > problem…
> 
> If you need someone to throw your thoughts at, feel free to share them with
> me.  With the newer Rockchip devices that I am focused on, we also do a lot
> DT/DM stuff pre-reloc (I have a 100+KB SPL stage on the RK3399 at the 
> moment) and this trend is likely to increase … e.g. I may split the RK3399
> to use TPL for DRAM-init and will then have the SPL stage running from
> DRAM which will remove the last remaining size constraints.

Ok thanks for the offer. For what it's worth, I'm currently experimenting
with not doing any relocation in SPL at all (which is really "only"
stack/heap/bss/gd) as there is sufficient on-chip SRAM in our case to do
so, if it works out this could be an alternative way to avoid the issue
under discussion in the first place. Main reason however wanting to do
that is that I started needing to use drivers that have globals and
static variables which is when the wheels really came off trying to use
those pre-reloc. I suppose should you use TPL for DDR init on RK devices
there would also be no need for relocation in your SPL.

--
Andreas Dannenberg
Texas Instruments Inc