| Message ID | 1478137001-847-3-git-send-email-andre.przywara@arm.com |
|---|---|
| State | RFC |
| Delegated to: | Hans de Goede |
| Headers | show |
On 11/03/2016 02:36 AM, Andre Przywara wrote: > At the moment we use the arch/arm directory for arm64 boards as well, > so the Makefile will pick up the "arm" name for the architecture to use > for tagging binaries in U-Boot image files. > Differentiate between the two by looking at the CPU variable being defined > to "armv8", and use the arm64 architecture name on creating the image > file if that matches. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> Why is this important? To know the state you have to be in for SPL->U-Boot transition later? Why didn't anyone else stumble over this yet? Because nobody's using SPL? Alex
Hi, On 03/11/16 08:54, Alexander Graf wrote: > On 11/03/2016 02:36 AM, Andre Przywara wrote: >> At the moment we use the arch/arm directory for arm64 boards as well, >> so the Makefile will pick up the "arm" name for the architecture to use >> for tagging binaries in U-Boot image files. >> Differentiate between the two by looking at the CPU variable being >> defined >> to "armv8", and use the arm64 architecture name on creating the image >> file if that matches. >> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > Why is this important? To know the state you have to be in for > SPL->U-Boot transition later? Yes. > Why didn't anyone else stumble over this yet? Because nobody's using SPL? Given the warnings and bugs I found when I compiled the SPL for 64 bit I'd assume the latter. But I was asking this question myself already. Apparently everyone just hacked their firmware chain to live with "arm" in there, APM being a prominent example. So given this I am a bit wary about the implication of this patch, I hope that people holler if this breaks their platform (and then fix that instead of hacking U-Boot again). Cheers, Andre.
On 11/03/2016 10:08 AM, Andre Przywara wrote: > Hi, > > On 03/11/16 08:54, Alexander Graf wrote: >> On 11/03/2016 02:36 AM, Andre Przywara wrote: >>> At the moment we use the arch/arm directory for arm64 boards as well, >>> so the Makefile will pick up the "arm" name for the architecture to use >>> for tagging binaries in U-Boot image files. >>> Differentiate between the two by looking at the CPU variable being >>> defined >>> to "armv8", and use the arm64 architecture name on creating the image >>> file if that matches. >>> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >> Why is this important? To know the state you have to be in for >> SPL->U-Boot transition later? > Yes. > >> Why didn't anyone else stumble over this yet? Because nobody's using SPL? > Given the warnings and bugs I found when I compiled the SPL for 64 bit > I'd assume the latter. > > But I was asking this question myself already. Apparently everyone just > hacked their firmware chain to live with "arm" in there, APM being a > prominent example. APM is "special". They even use the "arm" marker for kernels. > So given this I am a bit wary about the implication of this patch, I > hope that people holler if this breaks their platform (and then fix that > instead of hacking U-Boot again). Well, I guess it's a step into the right direction. I'm still not a huge fan of having both 32bit and 64bit binaries on the same platform, but indicating which one we are is a good idea :). Alex
Hi, On 03/11/16 09:10, Alexander Graf wrote: > On 11/03/2016 10:08 AM, Andre Przywara wrote: >> Hi, >> >> On 03/11/16 08:54, Alexander Graf wrote: >>> On 11/03/2016 02:36 AM, Andre Przywara wrote: >>>> At the moment we use the arch/arm directory for arm64 boards as well, >>>> so the Makefile will pick up the "arm" name for the architecture to use >>>> for tagging binaries in U-Boot image files. >>>> Differentiate between the two by looking at the CPU variable being >>>> defined >>>> to "armv8", and use the arm64 architecture name on creating the image >>>> file if that matches. >>>> >>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >>> Why is this important? To know the state you have to be in for >>> SPL->U-Boot transition later? >> Yes. >> >>> Why didn't anyone else stumble over this yet? Because nobody's using >>> SPL? >> Given the warnings and bugs I found when I compiled the SPL for 64 bit >> I'd assume the latter. >> >> But I was asking this question myself already. Apparently everyone just >> hacked their firmware chain to live with "arm" in there, APM being a >> prominent example. > > APM is "special". They even use the "arm" marker for kernels. Yeah, I remember this ;-) >> So given this I am a bit wary about the implication of this patch, I >> hope that people holler if this breaks their platform (and then fix that >> instead of hacking U-Boot again). > > Well, I guess it's a step into the right direction. I'm still not a huge > fan of having both 32bit and 64bit binaries on the same platform, but > indicating which one we are is a good idea :). I was thinking the same. Even if we eventually scratch that idea this patch shouldn't hurt, and makes U-Boot more versatile. Cheers, Andre.
On 2 November 2016 at 19:36, Andre Przywara <andre.przywara@arm.com> wrote: > At the moment we use the arch/arm directory for arm64 boards as well, > so the Makefile will pick up the "arm" name for the architecture to use > for tagging binaries in U-Boot image files. > Differentiate between the two by looking at the CPU variable being defined > to "armv8", and use the arm64 architecture name on creating the image > file if that matches. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > Makefile | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org>
diff --git a/Makefile b/Makefile index 37cbcb2..e76aeff 100644 --- a/Makefile +++ b/Makefile @@ -912,13 +912,18 @@ quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $< +ifeq ($(CPU),armv8) +IH_ARCH := arm64 +else +IH_ARCH := $(ARCH) +endif ifdef CONFIG_SPL_LOAD_FIT -MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ +MKIMAGEFLAGS_u-boot.img = -f auto -A $(IH_ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) else -MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ +MKIMAGEFLAGS_u-boot.img = -A $(IH_ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" endif
At the moment we use the arch/arm directory for arm64 boards as well, so the Makefile will pick up the "arm" name for the architecture to use for tagging binaries in U-Boot image files. Differentiate between the two by looking at the CPU variable being defined to "armv8", and use the arm64 architecture name on creating the image file if that matches. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)