On 11/04/2016 10:12 AM, Alexander Graf wrote: > > > On 04/11/2016 17:08, york sun wrote: >> On 11/04/2016 09:53 AM, Alexander Graf wrote: >>> >>> >>> On 04/11/2016 16:43, york sun wrote: >>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote: >>>>>>> >>>>>>> Yes, with the attached patch on top of your original 2 patches, >>>>>>> everything works again. I tested on FVP Foundation and AEMv8 models >>>>>>> and Juno R0, R1 and R2. >>>>>>> >>>>>>> I don't think it would be good to stack these three patches the way >>>>>>> they are presented in the upstream tree because it would not be >>>>>>> bisect-able. Some re-work or re-ordering would be needed. >>>>>>> >>>>>>> Note: I haven't attempted to understand what any of this code is >>>>>>> doing, I'm just testing it with my standard boot flow to make sure >>>>>>> nothing is broken for me. >>>>>> >>>>>> Ryan, >>>>>> >>>>>> I support Alison's patch order for her 32-bit patch sets. This feature >>>>>> doesn't exist before her first set. It is functional if you run U-Boot >>>>>> at EL3 after the first patch. >>>>> >>>>> Which I don't do. I follow the boot flow recommended by ARM and it >>>>> doesn't work for that setup, which I don't think is the right thing to >>>>> do. >>>>> >>>>> >>>>>> It gets EL2 working after the 2nd set. If >>>>>> there is room to clarify in the commit message, please kindly suggest. >>>>>> >>>>> >>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have >>>>> a tree that wasn't bootable at any point in the patch sequence. >>>>> That's generally unacceptable on most projects I work on. Keeping the >>>>> tree bisect-able to prove which commit caused a problem is considered >>>>> to be a valuable tool. >>>>> >>>> >>>> Ryan, >>>> >>>> Thanks for sharing your concern. I support git-bisect. It is valuable, >>>> no doubt. Let me try to understand the issue here. Without Alison's >>>> patches, everything boots OK. With her first set, does something break? >>> >>> Yes, with the patches booting 64bit Linux with U-Boot running in EL2 >>> breaks according to Ryan. >>> >>>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails, >>>> then she needs to fix it. >>> >>> That's his point :). And I concur. >> >> Thanks for the confirmation. >> >>> >>> (btw, you guys really should start thinking about following the ARM >>> recommended boot model. It's pretty cumbersome to do everything >>> different just for NXP) >> >> If you are referring the trusted firmware, we are following that >> direction. Just not fully up yet on some platform. >> >> It is definitely not our intention to be cumbersome. Please point out >> where it went sideway beside the trusted firmware. > > Basically it boils down to the fact that you are the only platform that > runs U-Boot in EL3 :). > > If you want to keep the memory initialization inside of U-Boot, I think > that's great. But you could either split that into SPL/EL2 or degrade > yourself into EL2 as soon as possible by calling into an EL3 firmware. > Whether you build that firmware as part of U-Boot (the stock one could > be very trivial) or externally is not really too much of a problem. > > Things like Alison's patches could then do a simple PSCI call into said > EL3 firmware to call into 32bit code in EL2 for example. >
Basically I agree with you. U-Boot will run at EL2 as soon as we have the trusted firmware in place. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
