Hi Jonas, On Tue, 4 Aug 2026 at 13:57, Jonas Karlman <[email protected]> wrote: > > Hi Simon, > > On 8/4/2026 9:19 PM, Simon Glass wrote: > > Hi Jonas, > > > > On Tue, 4 Aug 2026 at 04:57, Jonas Karlman <[email protected]> wrote: > >> > >> This series takes the initial steps required to try and remove use of > >> syscon_get_first_range() or syscon_get_regmap_by_driver_data() to get > >> GRF base addresses at runtime for the Rockchip platform. > >> > >> The GRF base addresses are fixed and known at compile time, yet drivers > >> keep trying to resolve them at runtime delaying some operations by > >> several ms. > > > > I suppose all addresses are known at compile-time, if you have a > > single device tree. I have always hoped that we might end up with a > > generic U-Boot for rockchip. > > I do not understand how removing these unneeded syscon drivers and > helpers would stop such goals or make that any harder. From my point of > view, they are currently making such things harder and only adds extra > code, runtime and energy waste. E.g. around 227 ms was wasted resolving > fixed known base addresses for RK3399 last time I measured it, see [1]. > > Most drivers or any SoC specific code is already identified using a > compatible that is SoC specific, i.e. the RAM or CLK drivers are matched > using a SoC specific compatible and seeing how all GRF variants are > unique there will always need to be SoC specific code to handle the GRFs > base address and reg offsets. > > And for drivers that are more dynamic in nature the DT typically have a > phandle to the GRF syscon node anyway, so getting it from the phandle > will be a better option and closer matches how Linux handles similar > references. > > The biggest current blocker for a more generic U-Boot proper on Rockchip > platform is rockchip_get_cru() and how it currently makes it impossible > to support multiple SoCs in one build due to how it is used in the > sysreset driver. Fortunately, I have a pending series that also cleans > up the unneeded rockchip_get_cru/clk() related helpers. > > > > > I wonder if there is another way to do this, perhaps reading the > > address once and caching it? > > I really do not see the need for that; it would only make things more > complex than it really needs to be. We should use constants where > appropriate, e.g. soc specific drivers/code and use generic phandle > lookups elsewhere. > > At least that is my end goal with this and pending follow-up series.
Long delay while I took some time to look at this area in detail. Pre-relocation is an area which I sort-of glossed over with the driver model implementation. There was talk about keeping the pre-relocation devices around rather than recreating them. We also looked at providing post-relocation devices access to the pre-relocation info. Over the years we have had discussions about having 'simple' versions of drivers (that don't go through driver model and perhaps don't use device tree) but no one has made the effort to implement this. Anyway, after a few days of hacking I've come up with some improvements to the existing code, at the cost of about 500 bytes of size increase. It works by using slightly better algorithms for four key functions - fdt_parent_offset(), __of_translate_address(), ofnode_pre_reloc() and lists_bind_fdt(). The result is saving on firefly-rk3399 of 230ms, about what you are getting. Note that I have made no attempt to enable the relevant options in TPL/SPL (it only saves another 13ms), so your work is mostly complimentary. The key difference is that this should help all boards, not just Rockchip, plus it still uses DT for everything. Tom doesn't want me to send patches at present but I did write up a post about it as a way of providing the comparison. [2] Regards, Simon > > [1] > https://git.u-boot-project.org/u-boot/contributors/kwiboo/u-boot/-/commit/cfb736dea37f834e849e54d39fb086c91697fc24 [2] https://www-concept.deinde.dev/blog/speeding-up-devicetree-access-before-relocation
