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? My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
