[U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

[Michal Simek <michal.simek@xilinx.com>]

On 10.6.2016 13:13, Alexander Graf wrote:
> 
> 
> On 10.06.16 13:07, Michal Simek wrote:
>> On 9.6.2016 16:40, Alexander Graf wrote:
>>> On 06/09/2016 04:32 PM, Michal Simek wrote:
>>>> On 9.6.2016 16:29, Alexander Graf wrote:
>>>>> On 06/09/2016 04:23 PM, Michal Simek wrote:
>>>>>> Disable arch_fixup_fdt() calls for cases where U-Boot shouldn't update
>>>>>> memory setup in DTB file.
>>>>>> One example of usage of this option is to boot OS with different memory
>>>>>> setup than U-Boot use.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>>> Could we instead just have the board file provide a fixup? It could then
>>>>> also fix up the efi memory map.
>>>> Not sure what exactly you are asking for.
>>>> Do you mean to add fixup function to board file and overwrite default
>>>> one?
>>>
>>> You have to touch some other code anyway to make this work with a
>>> particular board, right? In that case, you can as well add a function to
>>> the board file that explicitly provides a different, known good memory map.
>>
>> I cant' see the reason to touch particular board. In past AMP solution
>> where one core use the part of memory and second another part was the
>> reason I needed this.
>> For ARM64 case as you know from arm IRC I was trying to boot Linux from
>> memory above 32bit space and for these tests I need to convince u-boot
>> not to touch dtb memory setup.
>>
>> But for the same board I want to use standard behavior but for some case
>> this needs to be enabled.
> 
> For that particular case, can you try to see whether you can convince
> U-Boot to just run in high memory instead? That would make things much
> more consistent IMHO.
> 
> Giving U-Boot and Linux different views of the memory map is really just
> asking for trouble. You'd have to make sure that you flush your caches
> for example so that Linux doesn't suddenly get memory overwritten from
> stale cache entries on the low memory even though Linux is already
> accessing the high addresses.

For systems where you have one main memory and standard usage model with
OS I agree that having this option enabled is bring more problems.
But for our use cases you can add memory controller to PL and it will be
ready when bitstream is loaded which can be done after u-boot is loaded.
It means u-boot have to work with different memory setup then Linux
later on.

Caches should be flushed before u-boot pass control to Linux that's why
there shouldn't be any stale entries.

For ZynqMP you can partitioned memory that part of it goes to A53s and
part to R5s and u-boot is capable to boot both cores.

> For testing, sure, but to actually make use of it I'd rather see a clean
> solution.

Do we have any experimental Kconfig entry which I can use for it?

Thanks,
Michal