From: Simon Glass <sjg@google.com>
To: David Virag <virag.david003@gmail.com>
Cc: u-boot@lists.denx.de, Tom Rini <trini@konsulko.com>
Subject: Re: [BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access
Date: Mon, 10 Jul 2023 13:45:46 -0600 [thread overview]
Message-ID: <CAPnjgZ3xUzbs0MGJybA2xg_AQ=nshQjD+rCL=gVAj81UMetgzg@mail.gmail.com> (raw)
In-Reply-To: <e821d722df61654ed64798cfa698e8e915a30764.camel@gmail.com>
Hi David,
On Sun, 9 Jul 2023 at 19:11, David Virag <virag.david003@gmail.com> wrote:
>
> Hi,
>
> I'm trying to port U-Boot to a new board (Samsung JACKPOTLTE, ARMv8,
> Exynos7885) but when CONFIG_ARCH_FIXUP_FDT_MEMORY is enabled, the bootm
> command leads to an unaligned memory access, which results in a
> synchronous abort.
>
> After a long debugging session, I concluded that fdt_pack_reg in
> common/fdt_support.c writes to unaligned addresses in its for loop.
> In the case of address_cells being 2, and size_cells being 1, the
> buffer pointer gets incremented by 12 in each loop, making the second
> iteration (i=1) write a 64bit value to a non 64bit aligned address.
>
> Turning the alignment check enable bit (A) off in SCTLR makes the
> function work as intended. I couldn't find code that touches this bit,
> but I may have missed something. I don't think writing in two parts
> should be the fix, but something should be done about this. As far as I
> understand, any arm64 board that has this bit turned on, either from
> previous code or just the initial status of the bit after power on,
> could crash here.
>
> This is on top of the latest commit as of now
> (0beb649053b86b2cfd5cf55a0fc68bc2fe91a430)
>
> What should be done here?
+Tom Rini
>
> Best regards,
> David
next prev parent reply other threads:[~2023-07-10 19:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-09 21:42 [BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access David Virag
2023-07-10 19:45 ` Simon Glass [this message]
2023-07-10 20:13 ` Tom Rini
2023-07-10 21:38 ` Simon Glass
2023-07-11 10:34 ` David Virag
2023-07-11 19:13 ` Simon Glass
2024-03-27 6:18 ` Sam Protsenko
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='CAPnjgZ3xUzbs0MGJybA2xg_AQ=nshQjD+rCL=gVAj81UMetgzg@mail.gmail.com' \
--to=sjg@google.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=virag.david003@gmail.com \
/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.