On 10.06.16 13:51, Michal Simek wrote: > 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 <[email protected]> >>>>>> 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.
Oh, I see. So U-Boot actually uses completely different memory? But that means that the original memory is also still there, doesn't it? Wouldn't that mean we'd merely have to extend the bdinfo? > 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. Hm, maybe I'm not fully grasping the exact scenario you're envisioning. >> 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? Uh, the patch you posted I guess. Just make sure people don't set it if they don't know *exactly* what they're getting themselves into. Alex _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
