From trini at konsulko.com  Wed Sep 15 01:01:23 2021
From: trini at konsulko.com (Tom Rini)
Date: Tue, 14 Sep 2021 19:01:23 -0400
Subject: [ANN] U-Boot v2021.10-rc4 released
Message-ID: <20210914230123.GR12964@bill-the-cat>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot-custodians/attachments/20210914/80bedcf5/attachment.sig>

From sjg at chromium.org  Sat Sep 18 11:29:27 2021
From: sjg at chromium.org (Simon Glass)
Date: Sat, 18 Sep 2021 03:29:27 -0600
Subject: [ANN] U-Boot v2021.10-rc4 released
In-Reply-To: <20210914230123.GR12964@bill-the-cat>
References: <20210914230123.GR12964@bill-the-cat>
Message-ID: <CAPnjgZ1aftk+zKXoxZ_9HV+WqObB+kwdJFOh75fMePdaTP41=A@mail.gmail.com>

Hi Tom,

On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini at 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

From xypron.glpk at gmx.de  Sat Sep 18 11:48:51 2021
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Sat, 18 Sep 2021 11:48:51 +0200
Subject: [ANN] U-Boot v2021.10-rc4 released
In-Reply-To: <CAPnjgZ1aftk+zKXoxZ_9HV+WqObB+kwdJFOh75fMePdaTP41=A@mail.gmail.com>
References: <20210914230123.GR12964@bill-the-cat>
 <CAPnjgZ1aftk+zKXoxZ_9HV+WqObB+kwdJFOh75fMePdaTP41=A@mail.gmail.com>
Message-ID: <D6C56BF7-FFC9-4055-84A5-93D3D40EBD93@gmx.de>



Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass <sjg at chromium.org>:
>Hi Tom,
>
>On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini at 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

From sjg at chromium.org  Sat Sep 18 13:33:09 2021
From: sjg at chromium.org (Simon Glass)
Date: Sat, 18 Sep 2021 05:33:09 -0600
Subject: [ANN] U-Boot v2021.10-rc4 released
In-Reply-To: <D6C56BF7-FFC9-4055-84A5-93D3D40EBD93@gmx.de>
References: <20210914230123.GR12964@bill-the-cat>
 <CAPnjgZ1aftk+zKXoxZ_9HV+WqObB+kwdJFOh75fMePdaTP41=A@mail.gmail.com>
 <D6C56BF7-FFC9-4055-84A5-93D3D40EBD93@gmx.de>
Message-ID: <CAPnjgZ2-7f5Evx2n3OY=+AU33HFsM4iV+auZy3buAsCOGG-dig@mail.gmail.com>

Hi Heinrich,

On Sat, 18 Sept 2021 at 03:54, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass <sjg at chromium.org>:
> >Hi Tom,
> >
> >On Tue, 14 Sept 2021 at 17:01, Tom Rini <trini at 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