Hi Quentin, On Thu, 8 Oct 2026 at 23:53, Quentin Schulz <[email protected]> wrote: > > Hi Simon, > > On 8/7/26 9:46 PM, Simon Glass wrote: > > 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] > > > > Please refrain from pointing contributors to patches that are > written/assisted by AI/LLMs as those aren't currently welcome in the > project.
Do you have any update on the VBE series I sent? [3] It was written before the AI era. I believe it was originally sent 18 months ago. It is the final thing to get VBE running on a real board in mainline. Regards, Simon [3] https://patchwork.ozlabs.org/project/uboot/list/?series=506457&state=*
