On Mon, Oct 19, 2020 at 11:40:26PM +0200, Marek Vasut wrote:
> This reverts commit eb39d8ba5f0d1468b01b89a2a464d18612d3ea76.
> The commit breaks booting of fitImage by SPL, the system simply hangs.
> This is because on arm32, the fitImage and all of its content can be
> aligned to 4 bytes and U-Bo
On 10/20/20 1:10 PM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 12:01:02PM -0500, Alex G. wrote:
On 10/20/20 10:54 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
On 10/20/20 9:32 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
On 10
On Tue, Oct 20, 2020 at 12:01:02PM -0500, Alex G. wrote:
> On 10/20/20 10:54 AM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
> > > On 10/20/20 9:32 AM, Tom Rini wrote:
> > > > On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> > > > > On 10/20/20 4:07 PM
On 10/20/20 10:54 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
On 10/20/20 9:32 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
On 10/20/20 4:07 PM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
O
On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
> On 10/20/20 9:32 AM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> > > On 10/20/20 4:07 PM, Tom Rini wrote:
> > > > On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> > > > > On 10/20/20 2:27
On 10/20/20 4:32 PM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
>> On 10/20/20 4:07 PM, Tom Rini wrote:
>>> On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
On 10/20/20 2:27 AM, Reuben Dowle wrote:
>>> What assumptions? Any code that assumes
On 10/20/20 9:32 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
On 10/20/20 4:07 PM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
On 10/20/20 2:27 AM, Reuben Dowle wrote:
What assumptions? Any code that assumes 4 byte alignment
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> On 10/20/20 4:07 PM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> >> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> > What assumptions? Any code that assumes 4 byte alignment will also work
> o
On 10/20/20 4:07 PM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
>> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> What assumptions? Any code that assumes 4 byte alignment will also work
on 8 byte alignment.
>
> Reverting is not the same as assuming A
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> >>> What assumptions? Any code that assumes 4 byte alignment will also work
> >> on 8 byte alignment.
> >>>
> >>> Reverting is not the same as assuming ALIGN(...4) if incoming data is not
> >>
On 10/20/20 2:27 AM, Reuben Dowle wrote:
>>> What assumptions? Any code that assumes 4 byte alignment will also work
>> on 8 byte alignment.
>>>
>>> Reverting is not the same as assuming ALIGN(...4) if incoming data is not
>> already aligned to 4 bytes (as was the case when I saw crashes).
>>
>> Ca
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 ins
> > What assumptions? Any code that assumes 4 byte alignment will also work
> on 8 byte alignment.
> >
> > Reverting is not the same as assuming ALIGN(...4) if incoming data is not
> already aligned to 4 bytes (as was the case when I saw crashes).
>
> Can the incoming data _not_ be 4 byte aligned
On 10/19/20 6:02 PM, Marek Vasut wrote:
On 10/20/20 12:58 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
On 10/20/20 12:45 AM, Tom Rini wrote:
On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
On 10/19/20 11:50 PM, Reuben Dowle wrote:
The alignmen
> 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_set
On 10/20/20 1:02 AM, Reuben Dowle wrote:
>> The problem is that the previous alignment was 4 byte, now it is 8 byte and
>> that breaks all the other assumptions. So, this patch should be reverted to
>> fix
>> the platforms which used to work (or use ALIGN(...4), which is the same as
>> reverting i
> The problem is that the previous alignment was 4 byte, now it is 8 byte and
> that breaks all the other assumptions. So, this patch should be reverted to
> fix
> the platforms which used to work (or use ALIGN(...4), which is the same as
> reverting it really).
What assumptions? Any code that as
On 10/20/20 12:58 AM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
>> On 10/20/20 12:45 AM, Tom Rini wrote:
>>> On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
On 10/19/20 11:50 PM, Reuben Dowle wrote:
> The alignment of 8 bytes would also wor
On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
> On 10/20/20 12:45 AM, Tom Rini wrote:
> > On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
> >> On 10/19/20 11:50 PM, Reuben Dowle wrote:
> >>> The alignment of 8 bytes would also work if code was expecting 4 byte
> >>> ali
On 10/20/20 12:45 AM, Tom Rini wrote:
> On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
>> On 10/19/20 11:50 PM, Reuben Dowle wrote:
>>> The alignment of 8 bytes would also work if code was expecting 4 byte
>>> alignment. So the explanation you give for reverting this does not make
>
On 10/20/20 12:17 AM, Reuben Dowle wrote:
[...]
>> On 10/19/20 11:50 PM, Reuben Dowle wrote:
>>> The alignment of 8 bytes would also work if code was expecting 4 byte
>> alignment. So the explanation you give for reverting this does not make
>> sense to me.
>>
>> Well, since U-Boot 2020.10-rc5, a
On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
> On 10/19/20 11:50 PM, Reuben Dowle wrote:
> > The alignment of 8 bytes would also work if code was expecting 4 byte
> > alignment. So the explanation you give for reverting this does not make
> > sense to me.
>
> Well, since U-Boot 2
> -Original Message-
> From: Marek Vasut
> Sent: Tuesday, 20 October 2020 10:59 am
> To: Reuben Dowle ; u-boot@lists.denx.de
> Cc: Tom Rini
> Subject: Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
>
> On 10/19/20 11:50 PM, Reuben D
On 10/19/20 11:50 PM, Reuben Dowle wrote:
> The alignment of 8 bytes would also work if code was expecting 4 byte
> alignment. So the explanation you give for reverting this does not make sense
> to me.
Well, since U-Boot 2020.10-rc5, any STM32MP1 board does no longer boot
and if I revert this p
tober 2020 10:40 am
To: u-boot@lists.denx.de
Cc: Marek Vasut ; Reuben Dowle ; Tom Rini
Subject: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
This reverts commit eb39d8ba5f0d1468b01b89a2a464d18612d3ea76.
The commit breaks booting of fitImage by SPL, the system simply
This reverts commit eb39d8ba5f0d1468b01b89a2a464d18612d3ea76.
The commit breaks booting of fitImage by SPL, the system simply hangs.
This is because on arm32, the fitImage and all of its content can be
aligned to 4 bytes and U-Boot expects just that.
Signed-off-by: Marek Vasut
Cc: Reuben Dowle
C
26 matches
Mail list logo
