When "memory" node is being processed in fdt_pack_reg() on ARM64
platforms, an unaligned bus access might happen, which leads to
"synchronous abort" CPU exception. Consider next dts example:
/ {
#address-cells = <2>;
#size-cells = <1>;
memory@80000000 {
device_type = "memory";
reg = <0x0 0x80000000 0x3ab00000>,
<0x0 0xc0000000 0x40000000>,
<0x8 0x80000000 0x80000000>;
};
};
After fdt_pack_reg() reads the first addr/size entry from such memory
node, the "p" pointer becomes 12 bytes shifted from its original value
(8 bytes for two address cells + 4 bytes for one size cell). So now it's
not 64-bit aligned, and an attempt to do 64-bit bus access to that
address will cause an abort like this:
"Synchronous Abort" handler, esr 0x96000021, far 0xba235efc
This issue was originally reported by David Virag [1] who observed it
happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
was observed on Samsung Exynos850 (ARM64).
Fix the issue by using put_unaligned_be64() helper, which takes care of
possible unaligned 64-bit accesses. That solution was proposed by Simon
Glass in the original thread [1].
[1] https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Fixes: 739a01ed8e ("fdt_support: fix an endian bug of fdt_fixup_memory_banks")
Suggested-by: Simon Glass <sjg@google.com>
Reported-by: David Virag <virag.david003@gmail.com>
Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This relates to booting since it fixes up the devicetree for the OS. Move
it into the boot/ directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
