Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On 5 December 2016 at 15:14, Andre Przywarawrote: > Hi, > > On 02/12/16 19:20, Tom Rini wrote: >> On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote: >>> On 2 December 2016 at 15:41, Tom Rini wrote: On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > I've been working with Soby Mathew to get U-Boot booting on ARM's > AEMv8 FVP model in Aarch32 mode. > > Soby worked out what needed to be changed and I'm refining the changes > into patches that can be built for both Aarch64 and Aarch32 mode. > > There are two patches for discussion: > > [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs > [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant > > I expect the first patch to be controversial. I also don't expect it to > be accepted, but to demonstrate what changes we needed to make to get an > ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of > ARM64 as the CPU type. This in itself may be the wrong approach. > > It adds an ARMV8_AARCH32 config option and some checks in generic code > for that option to allow the code to differentiate between the two > modes. > > The second patch should be less controversial. It adds support for a > new AEMv8 variant that runs in 32-bit mode. The most awkward part is > that it defines itself not as ARM64, but as CPU_V7. I expect this to > change based on feedback from patch 1/2. > > The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but > takes an extra per-core model launch parameter to switch the cores into > Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". So my first and slightly ignorant question is, why isn't this just a new regular ARMv7 board being added rather than a special cased ARMv8? >>> >>> That's a valid question. >>> >>> I guess it could be either. At the moment, it's a bit of both. >>> arch/arm/Kconfig says it's an ARMv7, but then it's added to >>> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. >>> >>> But there's no reason it couldn't be added to >>> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that >>> isn't special cased at all. That approach seems more copy/paste-y >>> than what I've done in this series, though. >>> >>> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is >>> confused. Really, all of these armlt boards are the same with minor >>> variations, even if the minor variation could be ARMv7 vs ARMv8. >> >> Maybe this gets to the heart of the problem then, and we should >> re-structure and fix this. If you look in board/raspberrypi/rpi/ we >> support rpi1 2 and 3, and that includes rpi3 in 64bit mode. > > You might also want to take a look at my latest Allwinner A64 series[1]. Thanks, the more ideas the better. > There I provide two defconfigs: one for "armv8" (aka. AArch64) and one > for "armv7" (aka AArch32). I've just reworked my patch based on Tom's feedback and I'm doing something like this now. I'll post it for reference as a new RFC. > The series contains a lot of fixes, but when the code is eventually in > the correct place, it's merely a matter of "select CPU_V7" vs. > "select ARM64" to switch between the two architectures [2]. > I think this is mostly due to earlier work from Alex, who moved common > board support code into arch-agnostic directories[3]. > > The reason for this exercise in my case is just the SPL, but it actually > works for the whole of U-Boot: By just changing between the two symbols > you'll get a complete AArch32 or a complete AArch64 build, which runs on > the very same board. > >> So if we >> want to re-work board/armlt/vexpress/ to support the various ways the >> base hardware can be (/ has been over the years), lets. Does that sound >> like a plan? > > +1, I am very much for cleaning up this slightly convoluted vexpress64 code. > > Cheers, > Andre. > > [1] http://lists.denx.de/pipermail/u-boot/2016-December/275288.html > [2] http://lists.denx.de/pipermail/u-boot/2016-December/275308.html > [3] > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e6e505b93cb3fd264227c65ae1bfc9e4681555d8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
Hi, On 02/12/16 19:20, Tom Rini wrote: > On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote: >> On 2 December 2016 at 15:41, Tom Riniwrote: >>> On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: >>> I've been working with Soby Mathew to get U-Boot booting on ARM's AEMv8 FVP model in Aarch32 mode. Soby worked out what needed to be changed and I'm refining the changes into patches that can be built for both Aarch64 and Aarch32 mode. There are two patches for discussion: [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant I expect the first patch to be controversial. I also don't expect it to be accepted, but to demonstrate what changes we needed to make to get an ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of ARM64 as the CPU type. This in itself may be the wrong approach. It adds an ARMV8_AARCH32 config option and some checks in generic code for that option to allow the code to differentiate between the two modes. The second patch should be less controversial. It adds support for a new AEMv8 variant that runs in 32-bit mode. The most awkward part is that it defines itself not as ARM64, but as CPU_V7. I expect this to change based on feedback from patch 1/2. The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but takes an extra per-core model launch parameter to switch the cores into Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". >>> >>> So my first and slightly ignorant question is, why isn't this just a new >>> regular ARMv7 board being added rather than a special cased ARMv8? >>> >> >> That's a valid question. >> >> I guess it could be either. At the moment, it's a bit of both. >> arch/arm/Kconfig says it's an ARMv7, but then it's added to >> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. >> >> But there's no reason it couldn't be added to >> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that >> isn't special cased at all. That approach seems more copy/paste-y >> than what I've done in this series, though. >> >> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is >> confused. Really, all of these armlt boards are the same with minor >> variations, even if the minor variation could be ARMv7 vs ARMv8. > > Maybe this gets to the heart of the problem then, and we should > re-structure and fix this. If you look in board/raspberrypi/rpi/ we > support rpi1 2 and 3, and that includes rpi3 in 64bit mode. You might also want to take a look at my latest Allwinner A64 series[1]. There I provide two defconfigs: one for "armv8" (aka. AArch64) and one for "armv7" (aka AArch32). The series contains a lot of fixes, but when the code is eventually in the correct place, it's merely a matter of "select CPU_V7" vs. "select ARM64" to switch between the two architectures [2]. I think this is mostly due to earlier work from Alex, who moved common board support code into arch-agnostic directories[3]. The reason for this exercise in my case is just the SPL, but it actually works for the whole of U-Boot: By just changing between the two symbols you'll get a complete AArch32 or a complete AArch64 build, which runs on the very same board. > So if we > want to re-work board/armlt/vexpress/ to support the various ways the > base hardware can be (/ has been over the years), lets. Does that sound > like a plan? +1, I am very much for cleaning up this slightly convoluted vexpress64 code. Cheers, Andre. [1] http://lists.denx.de/pipermail/u-boot/2016-December/275288.html [2] http://lists.denx.de/pipermail/u-boot/2016-December/275308.html [3] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e6e505b93cb3fd264227c65ae1bfc9e4681555d8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
>> >> I've been working with Soby Mathew to get U-Boot booting on ARM's >> >> AEMv8 FVP model in Aarch32 mode. >> >> >> >> Soby worked out what needed to be changed and I'm refining the changes >> >> into patches that can be built for both Aarch64 and Aarch32 mode. >> >> >> >> There are two patches for discussion: >> >> >> >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs >> >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant >> >> >> >> I expect the first patch to be controversial. I also don't expect it to >> >> be accepted, but to demonstrate what changes we needed to make to get an >> >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of >> >> ARM64 as the CPU type. This in itself may be the wrong approach. >> >> >> >> It adds an ARMV8_AARCH32 config option and some checks in generic code >> >> for that option to allow the code to differentiate between the two >> >> modes. >> >> >> >> The second patch should be less controversial. It adds support for a >> >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is >> >> that it defines itself not as ARM64, but as CPU_V7. I expect this to >> >> change based on feedback from patch 1/2. >> >> >> >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but >> >> takes an extra per-core model launch parameter to switch the cores into >> >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". >> > >> > So my first and slightly ignorant question is, why isn't this just a new >> > regular ARMv7 board being added rather than a special cased ARMv8? >> > >> >> That's a valid question. >> >> I guess it could be either. At the moment, it's a bit of both. >> arch/arm/Kconfig says it's an ARMv7, but then it's added to >> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. >> >> But there's no reason it couldn't be added to >> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that >> isn't special cased at all. That approach seems more copy/paste-y >> than what I've done in this series, though. >> >> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is >> confused. Really, all of these armlt boards are the same with minor >> variations, even if the minor variation could be ARMv7 vs ARMv8. > > Maybe this gets to the heart of the problem then, and we should > re-structure and fix this. If you look in board/raspberrypi/rpi/ we > support rpi1 2 and 3, and that includes rpi3 in 64bit mode. So if we > want to re-work board/armlt/vexpress/ to support the various ways the > base hardware can be (/ has been over the years), lets. Does that sound > like a plan? That sounds great to me, I would like to be able to use the vexpress u-boot through qemu but be able to pass through the qemu generated DT so as to get the HW passed through correctly. I'm interested as it makes for a nice means of automation for some of my testing but also for virt based build systems too. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On Fri, Dec 02, 2016 at 09:40:28PM +, Ryan Harkin wrote: > On 2 Dec 2016 19:20, "Tom Rini"wrote: > > > > On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote: > > > On 2 December 2016 at 15:41, Tom Rini wrote: > > > > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > > > > > > > >> I've been working with Soby Mathew to get U-Boot booting on ARM's > > > >> AEMv8 FVP model in Aarch32 mode. > > > >> > > > >> Soby worked out what needed to be changed and I'm refining the > changes > > > >> into patches that can be built for both Aarch64 and Aarch32 mode. > > > >> > > > >> There are two patches for discussion: > > > >> > > > >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs > > > >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant > > > >> > > > >> I expect the first patch to be controversial. I also don't expect > it to > > > >> be accepted, but to demonstrate what changes we needed to make to > get an > > > >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead > of > > > >> ARM64 as the CPU type. This in itself may be the wrong approach. > > > >> > > > >> It adds an ARMV8_AARCH32 config option and some checks in generic > code > > > >> for that option to allow the code to differentiate between the two > > > >> modes. > > > >> > > > >> The second patch should be less controversial. It adds support for a > > > >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is > > > >> that it defines itself not as ARM64, but as CPU_V7. I expect this to > > > >> change based on feedback from patch 1/2. > > > >> > > > >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, > but > > > >> takes an extra per-core model launch parameter to switch the cores > into > > > >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". > > > > > > > > So my first and slightly ignorant question is, why isn't this just a > new > > > > regular ARMv7 board being added rather than a special cased ARMv8? > > > > > > > > > > That's a valid question. > > > > > > I guess it could be either. At the moment, it's a bit of both. > > > arch/arm/Kconfig says it's an ARMv7, but then it's added to > > > board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. > > > > > > But there's no reason it couldn't be added to > > > board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that > > > isn't special cased at all. That approach seems more copy/paste-y > > > than what I've done in this series, though. > > > > > > I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is > > > confused. Really, all of these armlt boards are the same with minor > > > variations, even if the minor variation could be ARMv7 vs ARMv8. > > > > Maybe this gets to the heart of the problem then, and we should > > re-structure and fix this. If you look in board/raspberrypi/rpi/ we > > support rpi1 2 and 3, and that includes rpi3 in 64bit mode. So if we > > want to re-work board/armlt/vexpress/ to support the various ways the > > base hardware can be (/ has been over the years), lets. Does that sound > > like a plan? > > > > Thanks, yes, it sounds like a great idea. I haven't looked at the rpi > stuff yes, but I'll check it out next week. > > I believe that would only resolve the issues in my 2nd patch, though. > Wouldn't the generic part of using an ARMv8 CPU with the ARMv7 code still > need addressing? I guess reviewing the rpi3 code will tell me more. I think everything you need is in there somewhere as there's also a rpi3-as-32bit option. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On 2 Dec 2016 19:20, "Tom Rini"wrote: > > On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote: > > On 2 December 2016 at 15:41, Tom Rini wrote: > > > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > > > > > >> I've been working with Soby Mathew to get U-Boot booting on ARM's > > >> AEMv8 FVP model in Aarch32 mode. > > >> > > >> Soby worked out what needed to be changed and I'm refining the changes > > >> into patches that can be built for both Aarch64 and Aarch32 mode. > > >> > > >> There are two patches for discussion: > > >> > > >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs > > >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant > > >> > > >> I expect the first patch to be controversial. I also don't expect it to > > >> be accepted, but to demonstrate what changes we needed to make to get an > > >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of > > >> ARM64 as the CPU type. This in itself may be the wrong approach. > > >> > > >> It adds an ARMV8_AARCH32 config option and some checks in generic code > > >> for that option to allow the code to differentiate between the two > > >> modes. > > >> > > >> The second patch should be less controversial. It adds support for a > > >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is > > >> that it defines itself not as ARM64, but as CPU_V7. I expect this to > > >> change based on feedback from patch 1/2. > > >> > > >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but > > >> takes an extra per-core model launch parameter to switch the cores into > > >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". > > > > > > So my first and slightly ignorant question is, why isn't this just a new > > > regular ARMv7 board being added rather than a special cased ARMv8? > > > > > > > That's a valid question. > > > > I guess it could be either. At the moment, it's a bit of both. > > arch/arm/Kconfig says it's an ARMv7, but then it's added to > > board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. > > > > But there's no reason it couldn't be added to > > board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that > > isn't special cased at all. That approach seems more copy/paste-y > > than what I've done in this series, though. > > > > I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is > > confused. Really, all of these armlt boards are the same with minor > > variations, even if the minor variation could be ARMv7 vs ARMv8. > > Maybe this gets to the heart of the problem then, and we should > re-structure and fix this. If you look in board/raspberrypi/rpi/ we > support rpi1 2 and 3, and that includes rpi3 in 64bit mode. So if we > want to re-work board/armlt/vexpress/ to support the various ways the > base hardware can be (/ has been over the years), lets. Does that sound > like a plan? > Thanks, yes, it sounds like a great idea. I haven't looked at the rpi stuff yes, but I'll check it out next week. I believe that would only resolve the issues in my 2nd patch, though. Wouldn't the generic part of using an ARMv8 CPU with the ARMv7 code still need addressing? I guess reviewing the rpi3 code will tell me more. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote: > On 2 December 2016 at 15:41, Tom Riniwrote: > > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > > > >> I've been working with Soby Mathew to get U-Boot booting on ARM's > >> AEMv8 FVP model in Aarch32 mode. > >> > >> Soby worked out what needed to be changed and I'm refining the changes > >> into patches that can be built for both Aarch64 and Aarch32 mode. > >> > >> There are two patches for discussion: > >> > >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs > >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant > >> > >> I expect the first patch to be controversial. I also don't expect it to > >> be accepted, but to demonstrate what changes we needed to make to get an > >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of > >> ARM64 as the CPU type. This in itself may be the wrong approach. > >> > >> It adds an ARMV8_AARCH32 config option and some checks in generic code > >> for that option to allow the code to differentiate between the two > >> modes. > >> > >> The second patch should be less controversial. It adds support for a > >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is > >> that it defines itself not as ARM64, but as CPU_V7. I expect this to > >> change based on feedback from patch 1/2. > >> > >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but > >> takes an extra per-core model launch parameter to switch the cores into > >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". > > > > So my first and slightly ignorant question is, why isn't this just a new > > regular ARMv7 board being added rather than a special cased ARMv8? > > > > That's a valid question. > > I guess it could be either. At the moment, it's a bit of both. > arch/arm/Kconfig says it's an ARMv7, but then it's added to > board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. > > But there's no reason it couldn't be added to > board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that > isn't special cased at all. That approach seems more copy/paste-y > than what I've done in this series, though. > > I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is > confused. Really, all of these armlt boards are the same with minor > variations, even if the minor variation could be ARMv7 vs ARMv8. Maybe this gets to the heart of the problem then, and we should re-structure and fix this. If you look in board/raspberrypi/rpi/ we support rpi1 2 and 3, and that includes rpi3 in 64bit mode. So if we want to re-work board/armlt/vexpress/ to support the various ways the base hardware can be (/ has been over the years), lets. Does that sound like a plan? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On 2 December 2016 at 15:41, Tom Riniwrote: > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > >> I've been working with Soby Mathew to get U-Boot booting on ARM's >> AEMv8 FVP model in Aarch32 mode. >> >> Soby worked out what needed to be changed and I'm refining the changes >> into patches that can be built for both Aarch64 and Aarch32 mode. >> >> There are two patches for discussion: >> >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant >> >> I expect the first patch to be controversial. I also don't expect it to >> be accepted, but to demonstrate what changes we needed to make to get an >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of >> ARM64 as the CPU type. This in itself may be the wrong approach. >> >> It adds an ARMV8_AARCH32 config option and some checks in generic code >> for that option to allow the code to differentiate between the two >> modes. >> >> The second patch should be less controversial. It adds support for a >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is >> that it defines itself not as ARM64, but as CPU_V7. I expect this to >> change based on feedback from patch 1/2. >> >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but >> takes an extra per-core model launch parameter to switch the cores into >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". > > So my first and slightly ignorant question is, why isn't this just a new > regular ARMv7 board being added rather than a special cased ARMv8? > That's a valid question. I guess it could be either. At the moment, it's a bit of both. arch/arm/Kconfig says it's an ARMv7, but then it's added to board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. But there's no reason it couldn't be added to board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that isn't special cased at all. That approach seems more copy/paste-y than what I've done in this series, though. I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is confused. Really, all of these armlt boards are the same with minor variations, even if the minor variation could be ARMv7 vs ARMv8. I'd quite like to address that, but I'm unsure how to approach the problem in the most flexible way. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support
On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote: > I've been working with Soby Mathew to get U-Boot booting on ARM's > AEMv8 FVP model in Aarch32 mode. > > Soby worked out what needed to be changed and I'm refining the changes > into patches that can be built for both Aarch64 and Aarch32 mode. > > There are two patches for discussion: > > [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs > [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant > > I expect the first patch to be controversial. I also don't expect it to > be accepted, but to demonstrate what changes we needed to make to get an > ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of > ARM64 as the CPU type. This in itself may be the wrong approach. > > It adds an ARMV8_AARCH32 config option and some checks in generic code > for that option to allow the code to differentiate between the two > modes. > > The second patch should be less controversial. It adds support for a > new AEMv8 variant that runs in 32-bit mode. The most awkward part is > that it defines itself not as ARM64, but as CPU_V7. I expect this to > change based on feedback from patch 1/2. > > The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but > takes an extra per-core model launch parameter to switch the cores into > Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". So my first and slightly ignorant question is, why isn't this just a new regular ARMv7 board being added rather than a special cased ARMv8? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot