All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.