From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reuben Dowle Date: Mon, 19 Oct 2020 23:13:51 +0000 Subject: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data" In-Reply-To: <3c989798-84a0-256b-e455-6ff2b5a9390f@gmail.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> Message-ID: <15879d1e49eb40de8859944e7ab7b7f4@4rf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > 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. > 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 > > > APPENDIX A: > > > -- a/arch/arm/cpu/u-boot.lds > +++ b/arch/arm/cpu/u-boot.lds > @@ -196,7 +196,6 @@ SECTIONS > * for FIT images. > * See common/spl/spl_fit.c: spl_fit_append_fdt > */ > + . = ALIGN(8); > .end : > { > *(.__end)