From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex G. Date: Mon, 19 Oct 2020 19:31:12 -0500 Subject: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data" In-Reply-To: <15879d1e49eb40de8859944e7ab7b7f4@4rf.com> References: <20201019214026.888876-1-marex@denx.de> <669974501aec485c9263fe5127c4ccb5@4rf.com> <38fc6118-b7d7-8455-2c05-3cbe368c4f12@denx.de> <20201019224558.GR14816@bill-the-cat> <4f9c0170-1c52-0f2d-c6f8-972ed082cd36@denx.de> <20201019225819.GS14816@bill-the-cat> <3c989798-84a0-256b-e455-6ff2b5a9390f@gmail.com> <15879d1e49eb40de8859944e7ab7b7f4@4rf.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/19/20 6:13 PM, Reuben Dowle wrote: > >> The reverted change linked to some kernel documentation that requires 64- >> bit alignment. I agree with the alignment requirement. >> >> Im my opinion, there are two things that need to be done: >> >> First is to look at an ALIGNED address for the fdt. A summary inspection of >> board_fdt_blob_setup() tells us this is done via the "_end" linker symbol. > > The linker script can only control padding of the executable, but won't > affect the alignment of the fdt that can be appended to this later by > mkimage. Which I've addressed in the second paragraph :) >> Second is to put things in the right place. For FIT, the code, as is, is correct, >> but this alignment is not guaranteed for legacy images. I think somebody >> mentioned changing the arguments to mkimage to achieve this. >> >> I've tried to fix the first point by aligning the _end symbol (appendix A). >> Unfortunately, this is causing other build issues that I don't know how to deal >> with. >> >> Alex > ------------------------------------------------------------------------ > The information in this email communication (inclusive of attachments) > is confidential to 4RF Limited and the intended recipient(s). If you are > not the intended recipient(s), please note that any use, disclosure, > distribution or copying of this information or any part thereof is > strictly prohibited and that the author accepts no liability for the > consequences of any action taken on the basis of the information > provided. If you have received this email in error, please notify the > sender immediately by return email and then delete all instances of this > email from your system. 4RF Limited will not accept responsibility for > any consequences associated with the use of this email (including, but > not limited to, damages sustained as a result of any viruses and/or any > action or lack of action taken in reliance on it). Per your instructions, I have deleted this message and all copies of it from my computer.