I can see that arm64 requires 8 bytes. That is stated in section 2 of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu....
I can't see a similar requirement for arm, although my search was not exhaustive. More generally I can see that all device trees must be at least 4 byte aligned (from section II.2 of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu...)
So it does seem that 8 bytes would work for at least both of these. I would be happy with hard-coding that, as I doubt it would cause any problems with other architectures.
I don't have anything to add on the ability to relocate the device tree. In my case the device tree is for the next stage u-boot, so won't need relocating. This might become an issue if this was booting direct to linux from the SPL perhaps.
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Tuesday, 25 August 2020 8:40 am To: Reuben Dowle reuben.dowle@4rf.com Cc: u-boot@lists.denx.de Subject: Re: [PATCH] Fix data abort caused by mis-aligning fit data in
On Mon, Aug 24, 2020 at 08:05:24PM +0000, Reuben Dowle wrote:
Should I submit a new patch with the alignment set to 8 bytes? I would
think a hard coded 8 bytes would not be the best solution, since not all architectures will need that much alignment. I suspect some would work with any alignment, and most 32-bit archs would be fine with 4-byte alignment.
Our released software is actually using a patch to align to 4096 bytes, but I
knew that was unnecessarily large. I was not really sure what would be an appropriate value here, and took a guess at ARCH_DMA_MINALIGN when I cleaned it up for submitting upstream. Is there a better define to use?
I am also interested to know where the 8 byte alignment requirement is
documented.
So we're talking about the device tree file, and only that, in this part of the code, right? In the Linux kernel documentation, both arm and arm64 document that the device tree must be on an 8-byte aligned address. That is the bare minimum. If we aren't further relocating it (as fdt_high is set to 0xffffffff for example, which in general is wrong and bad), that's still the best we can do. It would be good to allow for further relocation down the line as we aren't making sure it wouldn't be overwritten by the kernel BSS, etc.
-- Tom