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
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
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
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:
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
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
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
>
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
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).
>>
>>
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
> > 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
> 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
>
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
> 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
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
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
> >>>
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,
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
> -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
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.
The version I use in production uses 4 byte alignment, but on advice of Tom
Rini I extended to 8 bytes. Maybe we could switch to just
25 matches
Mail list logo
