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