[U-Boot] U-Boot proper(not SPL) relocate option

[Simon Glass]

Hi Philipp,

On 25 November 2017 at 16:31, Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
> Hi,
>
>> On 25 Nov 2017, at 23:34, Simon Glass <sjg at chromium.org> wrote:
>>
>> +Tom, Masahiro, Philipp
>>
>> Hi,
>>
>> On 22 November 2017 at 03:27, Wolfgang Denk <wd at denx.de> wrote:
>>> Dear Kever Yang,
>>>
>>> In message <fd0bb500-80c4-f317-cc18-f7aaf1344fd8 at rock-chips.com> you wrote:
>>>>
>>>> I can understand this feature, we always do dram_init_banks() first,
>>>> then we relocate to 'known' area, then will be no risk to access memory.
>>>> I believe there must be some historical reason for some kind of device,
>>>> the relocate feature is a wonderful idea for it.
>>>
>>> This is actuallyu not so much a feature needed to support some
>>> specific device (in this case much simpler approahces would be
>>> possible), but to support a whole set of features.  Unfortunately
>>> these appear to get forgotten / ignored over time.
>>>
>>>>     many other SoCs should be similar.
>>>> - Without relocate we can save many step, some of our customer really
>>>>     care much about the boot time duration.
>>>>     * no need to relocate everything
>>>>     * no need to copy all the code
>>>>     * no need init the driver more than once
>>>
>>> Please have a look at the README, section "Memory Management".
>>> The reloaction is not done to any _fixed_ address, but the address
>>> is actually computed at runtime, depending on a number features
>>> enabled (at least this is how it used to be - appearently little of
>>> this is tested on a regular base, so I would not be surprised if
>>> things are broken today).
>>>
>>> The basic idea was to reserve areas of memory at the top of RAM,
>>> that would not be initialized / modified by U-Boot and Linux, not
>>> even across a reset / warm boot.
>>>
>>> This was used for exaple for:
>>>
>>> - pRAM (Protected RAM) which could be used to store all kind of data
>>>  (for example, using a pramfs [Protected and Persistent RAM
>>>  Filesystem]) that could be kept across reboots of the OS.
>>>
>>> - shared frame buffer / video memory. U-Boot and Linux would be able
>>>  to initialize the video memory just once (in U-Boot) and then
>>>  share it, maybe even across reboots.  especially, this would allow
>>>  for a very early splash screen that gets passed (flicker free) to
>>>  Linux until some Linux GUI takes over (much more difficult today).
>>>
>>> - shared log buffer: U-Boot and Linux used to use the same syslog
>>>  buffer mechanism, so you could share it between U-Boot and Linux.
>>>  this allows for example to
>>>  * read the Linux kernel panic messages after reset in U-Boot; this
>>>    is very useful when you bring up a new system and Linux crashes
>>>    before it can display the log buffer on the console
>>>  * pass U-Boot POST results on to Linux, so the application code
>>>    can read and process these
>>>  * process the system log of the previous run (especially after a
>>>    panic) in Lunux after it rebootet.
>>>
>>> etc.
>>>
>>> There are a number of such features which require to reserve room at
>>> the top of RAM, the size of which is calculatedat runtime, often
>>> depending on user settable environment data.
>>>
>>> All this cannot be done without relocation to a (dynmaically
>>> computed) target address.
>>>
>>>
>>> Yes, the code could be simpler and faster without that - but then,
>>> you cut off a number of features.
>>
>> I would be interested in seeing benchmarks showing the cost of
>> relocation in terms of boot time. Last time I did this was on Exynos 5
>> and it was some years ago. The time was pretty small provided the
>> cache was on for the memory copies associated with relocation itself.
>> Something like 10-20ms but I don't have the numbers handy.
>>
>> I think it is useful to be able to allocate memory in board_init_f()
>> for use by U-Boot for things like the display and the malloc() region.
>>
>> Options we might consider:
>>
>> 1. Don't relocate the code and data. Thus we could avoid the copy and
>> relocation cost. This is already supported with the GD_FLG_SKIP_RELOC
>> used when U-Boot runs as an EFI app
>>
>> 2. Rather than throwing away the old malloc() region, keep it around
>> so existing allocated blocks work. Then new malloc() region would be
>> used for future allocations. We could perhaps ignore free() calls in
>> that region
>>
>> 2a. This would allow us to avoid re-init of driver model in most cases
>> I think. E.g. we could init serial and timer before relocation and
>> leave them inited after relocation. We could just init the
>> 'additional' devices not done before relocation.
>>
>> 2b. I suppose we could even extend this to SPL if we wanted to. I
>> suspect it would just be a pain though, since SPL might use memory
>> that U-Boot wants.
>>
>> 3. We could turn on the cache earlier. This removes most of the
>> boot-time penalty. Ideally this should be turned on in SPL and perhaps
>> redone in U-Boot which has more memory available. If SPL is not used,
>> we could turn on the cache before relocation.
>
> Both turning on the cache and initialising the clocking could be of benefit
> to boot-time.
>
> However, the biggest possible gain will come from utilising Falcon mode
> to skip the full U-Boot stage and directly boot into the OS from SPL.  This
> assumes that the drivers involved are fully optimised, so loading up the
> OS image does not take longer than necessary.

I'd like to see numbers on that. From my experience, loading and
running U-Boot does not take very long...

>
>> 4. Rather than the reserving memory in board_init_f() we could have it
>> call malloc() from the expanded region. We could then perhaps then
>> move this reserve/allocate code in to particular drivers or
>> subsystems, and drop a good chunk of the init sequence. We would need
>> to have a larger malloc() region than is currently the case.
>>
>> There are still some arch-specific bits in board_init_f() which make
>> these sorts of changes a bit tricky to support generically. IMO it
>> would be best to move to 'generic relocation' written in C, where all
>> archs work basically the same way, before attempting any of the above.
>>
>> Still, I can see some benefits and even some simplifications.
>>
>> Regards,
>> Simon
>

Regards,
Simon