[ANN] U-Boot v2021.10-rc4 released

[ANN] U-Boot v2021.10-rc4 released

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

Hey all,

Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
regressions pop up of late, unfortunately.  I've pushed the fix for
(what I believe are) existing FIT images showing a problem where we
calculated the crc32 wrong.  And we're just now starting to figure out
the proper fix for a problem that was introduced late in v2021.07 with
SPI buses not being configured in the right mode (or in Linux Kernel
terms, spi-cpha/spi-cpol being set on platforms where that's not
correct).

In terms of a changelog, 
git log --merges v2021.10-rc3..v2021.10-rc4
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

We should be releasing on October 4th, 2021 as expected.  Thanks all!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [ANN] U-Boot v2021.10-rc4 released

[Christophe Leroy]

Hi Tom,

Le 15/09/2021 à 01:01, Tom Rini a écrit :
> Hey all,
> 
> Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
> regressions pop up of late, unfortunately.  I've pushed the fix for
> (what I believe are) existing FIT images showing a problem where we
> calculated the crc32 wrong.  And we're just now starting to figure out
> the proper fix for a problem that was introduced late in v2021.07 with
> SPI buses not being configured in the right mode (or in Linux Kernel
> terms, spi-cpha/spi-cpol being set on platforms where that's not
> correct).
> 
> In terms of a changelog,
> git log --merges v2021.10-rc3..v2021.10-rc4
> contains what I've pulled but as always, better PR messages and tags
> will provide better results here.
> 
> We should be releasing on October 4th, 2021 as expected.  Thanks all!
> 


Commit 3b84809b7b ("MAINTAINERS: POWERPC MPC8XX: Update email address") 
has been washed-out by commit 047e31ed4b ("led: led_cortina: Add CAxxx 
LED support").

Can you please re-apply it

Thanks
Christophe

Re: [ANN] U-Boot v2021.10-rc4 released

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Fri, Sep 17, 2021 at 08:29:07AM +0200, Christophe Leroy wrote:

> Hi Tom,
> 
> Le 15/09/2021 à 01:01, Tom Rini a écrit :
> > Hey all,
> > 
> > Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
> > regressions pop up of late, unfortunately.  I've pushed the fix for
> > (what I believe are) existing FIT images showing a problem where we
> > calculated the crc32 wrong.  And we're just now starting to figure out
> > the proper fix for a problem that was introduced late in v2021.07 with
> > SPI buses not being configured in the right mode (or in Linux Kernel
> > terms, spi-cpha/spi-cpol being set on platforms where that's not
> > correct).
> > 
> > In terms of a changelog,
> > git log --merges v2021.10-rc3..v2021.10-rc4
> > contains what I've pulled but as always, better PR messages and tags
> > will provide better results here.
> > 
> > We should be releasing on October 4th, 2021 as expected.  Thanks all!
> 
> Commit 3b84809b7b ("MAINTAINERS: POWERPC MPC8XX: Update email address") has
> been washed-out by commit 047e31ed4b ("led: led_cortina: Add CAxxx LED
> support").
> 
> Can you please re-apply it

Queued up for my next push now.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [ANN] U-Boot v2021.10-rc4 released

[Simon Glass]

Hi Tom,

On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini@konsulko.com> wrote:
>
> Hey all,
>
> Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
> regressions pop up of late, unfortunately.  I've pushed the fix for
> (what I believe are) existing FIT images showing a problem where we
> calculated the crc32 wrong.  And we're just now starting to figure out
> the proper fix for a problem that was introduced late in v2021.07 with
> SPI buses not being configured in the right mode (or in Linux Kernel
> terms, spi-cpha/spi-cpol being set on platforms where that's not
> correct).
>
> In terms of a changelog,
> git log --merges v2021.10-rc3..v2021.10-rc4
> contains what I've pulled but as always, better PR messages and tags
> will provide better results here.
>
> We should be releasing on October 4th, 2021 as expected.  Thanks all!

We still don't have the EFI revert in here and I'm concerned that if
it makes it into a release it will be hard to back out.

I can try sending a pull request in the hope of putting this to bed?

Regards,
Simon

Re: [ANN] U-Boot v2021.10-rc4 released

[Heinrich Schuchardt]

Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass <sjg@chromium.org>:
>Hi Tom,
>
>On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini@konsulko.com> wrote:
>>
>> Hey all,
>>
>> Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
>> regressions pop up of late, unfortunately.  I've pushed the fix for
>> (what I believe are) existing FIT images showing a problem where we
>> calculated the crc32 wrong.  And we're just now starting to figure out
>> the proper fix for a problem that was introduced late in v2021.07 with
>> SPI buses not being configured in the right mode (or in Linux Kernel
>> terms, spi-cpha/spi-cpol being set on platforms where that's not
>> correct).
>>
>> In terms of a changelog,
>> git log --merges v2021.10-rc3..v2021.10-rc4
>> contains what I've pulled but as always, better PR messages and tags
>> will provide better results here.
>>
>> We should be releasing on October 4th, 2021 as expected.  Thanks all!
>
>We still don't have the EFI revert in here and I'm concerned that if
>it makes it into a release it will be hard to back out.
>
>I can try sending a pull request in the hope of putting this to bed?

Linaro clearly said that your concept does not fulfill the industrial needs.

So no, we should not merge this.

Best regards

Heinrich 

>
>Regards,
>Simon

Re: [ANN] U-Boot v2021.10-rc4 released

[Simon Glass]

Hi Heinrich,

On Sat, 18 Sept 2021 at 03:54, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi Tom,
> >
> >On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> Hey all,
> >>
> >> Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
> >> regressions pop up of late, unfortunately.  I've pushed the fix for
> >> (what I believe are) existing FIT images showing a problem where we
> >> calculated the crc32 wrong.  And we're just now starting to figure out
> >> the proper fix for a problem that was introduced late in v2021.07 with
> >> SPI buses not being configured in the right mode (or in Linux Kernel
> >> terms, spi-cpha/spi-cpol being set on platforms where that's not
> >> correct).
> >>
> >> In terms of a changelog,
> >> git log --merges v2021.10-rc3..v2021.10-rc4
> >> contains what I've pulled but as always, better PR messages and tags
> >> will provide better results here.
> >>
> >> We should be releasing on October 4th, 2021 as expected.  Thanks all!
> >
> >We still don't have the EFI revert in here and I'm concerned that if
> >it makes it into a release it will be hard to back out.
> >
> >I can try sending a pull request in the hope of putting this to bed?
>
> Linaro clearly said that your concept does not fulfill the industrial needs.
>
> So no, we should not merge this.

I have not seen anything clear here, yet. I did ask for a doc
describing the ultimate design. In the absence of that I have to
assume that is unclear also. I admit it is complicated, with all the
other projects and so on, but just ignoring the bigger picture is not
going to make things any easier. As to industrial needs, I am not sure
which needs are affected by this issue. We are talking about how it is
implemented, not whether it is feasible.

We need to resolve this and there is not enough time before the
release to do that, so a revert is the safest path. Once this release
is passed we can work together to figure out the path forward. It is
becoming a little clearer I think with the recent mailing-list
discussions and I suspect another few weeks of that might get us to
the point where most bases are covered. I believe that my devicetree
doc series is a good first step for that (small) part of the design,
but we also need to look at issues raised by the OF.PRIOR_STAGE and
OF_BOARD stuff. Also QEMU needs a look and any other pre- and post-
U-Boot things.

Regards,
Simon