From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 02/10] Makefile: use "arm64" architecture for U-Boot image files
Date: Thu, 3 Nov 2016 10:10:33 +0100 [thread overview]
Message-ID: <581AFF09.5070901@suse.de> (raw)
In-Reply-To: <28c4e360-9dbe-ec8e-6ada-b58a2d78b9ce@arm.com>
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
next prev parent reply other threads:[~2016-11-03 9:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 1:36 [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support Andre Przywara
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 01/10] sun6i: Restrict some register initialization to Allwinner A31 SoC Andre Przywara
2016-11-03 8:52 ` Alexander Graf
2016-11-04 13:18 ` Chen-Yu Tsai
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 02/10] Makefile: use "arm64" architecture for U-Boot image files Andre Przywara
2016-11-03 8:54 ` Alexander Graf
2016-11-03 9:08 ` Andre Przywara
2016-11-03 9:10 ` Alexander Graf [this message]
2016-11-03 9:14 ` Andre Przywara
2016-11-05 16:11 ` Simon Glass
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 03/10] sunxi: provide default DRAM config for sun50i in Kconfig Andre Przywara
2016-11-03 8:54 ` Alexander Graf
2016-11-03 9:10 ` Andre Przywara
2016-11-03 9:13 ` Hans de Goede
2016-11-03 9:17 ` Andre Przywara
2016-11-03 9:35 ` Hans de Goede
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 04/10] sunxi: H3: add and rename some DRAM contoller registers Andre Przywara
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 05/10] sunxi: H3: add DRAM controller single bit delay support Andre Przywara
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 06/10] sunxi: A64: use H3 DRAM initialization code for A64 Andre Przywara
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 07/10] sunxi: H3/A64: fix non-ODT setting Andre Przywara
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 08/10] SPL: read and store arch property from U-Boot image Andre Przywara
2016-11-05 16:10 ` Simon Glass
2016-11-18 1:50 ` André Przywara
2016-11-19 13:49 ` Simon Glass
2016-11-19 16:35 ` André Przywara
2016-11-19 19:59 ` Simon Glass
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 09/10] sunxi: introduce RMR switch to enter payloads in 64-bit mode Andre Przywara
2016-11-05 16:10 ` Simon Glass
2016-11-03 1:36 ` [U-Boot] [RFC PATCH 10/10] sunxi: A64: add 32-bit SPL support Andre Przywara
2016-11-03 8:49 ` [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 " Alexander Graf
2016-11-03 9:34 ` Hans de Goede
2016-11-03 9:51 ` Andre Przywara
2016-11-03 10:36 ` Alexander Graf
2016-11-03 10:49 ` Hans de Goede
2016-11-03 11:36 ` Alexander Graf
2016-11-03 9:38 ` Andre Przywara
2016-11-03 9:45 ` Hans de Goede
2016-11-09 9:21 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=581AFF09.5070901@suse.de \
--to=agraf@suse.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox