Hi Lukasz,
On 15/02/2018 15:58, Lukasz Majewski wrote:
Hi Tom,
On Thu, Feb 15, 2018 at 03:33:29PM +0100, Lukasz Majewski wrote:
Hi Fabio,
This reverts commit d695d6627803dbb78a226e04b0436a01633a9936.
Commit d695d6627803 ("spl: eMMC/SD: Provide one __weak spl_boot_mode() function") breaks the boot on several i.MX6 boards, such as cuboxi and wandboard:
U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33 +1300) Trying to boot from MMC1 Failed to mount ext2 filesystem... spl_load_image_ext: ext4fs mount err - 0
Revert it so that we can boot U-Boot again.
This is IMHO throwing the baby with the batch....
I kind of feel we need to revert this too, sorry. I'm also worried that we've broken some of the other platforms that also have funky if-else expected logic, and we'll be at the point soon where we have enough platforms that need to override the spl_boot_mode func with what they had before that it's not a huge win.
Just my 2 cents.
I add my two cents, too.
- IMHO 2 months release cycle is too short, regarding the peace of
development; we move Kconfig, perform DM conversion, and deal with legacy code
+1
I have always the feeling to be late and, if shortening the release cycle has advantages, the side-effect is that each release must take care of some new improvement without breaking past because, yes, it is a release.
I understand that two months matches the Linux release cycle, but I agree with Lukasz that we need more time to stabilize a release, taking into account the goals we have (DM,...). And most of use are not working full time at the bootloader, that makes thing worst.
Even if distros release cycle is independent from U-Boot / Kernel, I do not know how many people take advantage of fast releasing. The most used embedded buildsystems (Buildroot / Linux) have a most relaxed release cycle and usually a Yocto release have just a U-Boot version.
- As we removed the obsolete / not maitained archs. We also need to
scrutinize the "core" u-boot code (which is often 10+ years old).
As this patch showed - spotting some "implicit" errors - which cannot be found with travis CI build tests consumes some time. What is even more strange - this code from the very beginnig was developmed on iMX6 board ....
We JUST need MORE time to stabilize thing......
+1
Best regards, Stefano