[21.02] Backport mvebu updates for U-boot and add support for Turris Omnia #9409
Conversation
Refresh the patches. Switch to AUTORELEASE while at it. Signed-off-by: Andre Heider <a.heider@gmail.com> (cherry picked from commit 0208b3b)
Signed-off-by: Andre Heider <a.heider@gmail.com> (cherry picked from commit 1404ed2)
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> Tested-by: Andre Heider <a.heider@gmail.com> # ESPRESSObin (cherry picked from commit 782d4c8)
* Add U-boot support for Turris Omnia Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit 5c804bc)
This solves issue with DDR training on Turris Omnia. Log: ******** DRAM initialization Failed (res 0x1) ******** DDR3 Training Sequence - FAILED ERROR ### Please RESET the board ### Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit d16bd89)
100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch [1]: SoC Marvell A38x is used in Turris Omnia, and we thought that with recent fiddling around DDR training to fix it once for all, there were reproduced the issue in the upcoming new revision Turris Omnia boards. 101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch [2]: This is useful when some board may occasionally fail with DDR training, and it adds the option to reset the board on the DDR training failure 102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch [3]: This enables the option CONFIG_DDR_RESET_ON_TRAINING_FAILURE (added by 101 patch), so the Turris Omnia board is restarted immediately, and it does not require to reset the board manually or wait 120s for MCU to reset the board [1] https://patchwork.ozlabs.org/project/uboot/patch/20220217000837.13003-1-kabel@kernel.org/ [2] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-1-kabel@kernel.org/ [3] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-2-kabel@kernel.org/ Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit 696f0a1)
Steps to reproduce: 1. Insert NVMe disk with a reduction to Turris Omnia 2. Go to U-boot 3. Run these two commands: a) ``nvme scan`` b) ``nvme detail`` 4. Wait for crash This is backported from U-boot upstream repository. It should be included in the upcoming release - 2022.04 [1]. It was tested on Turris Omnia, mvebu, cortex-a9, OpenWrt master. [1] https://patchwork.ozlabs.org/project/uboot/patch/20211209100639.21530-1-pali@kernel.org/ Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> [Export the patch from U-Boot git] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 0f432fa)
hauke
added
release/21.02
|
I'm not sure if bumping U-Boot from 2021.01 to 2022.01 in the release being out for one year is ok. |
|
I understand why you might be against doing that, but from my point of view, it has so many benefits to manufacturers (in my case) or users as well. In both cases, you don't need to wait until there is a new version of OpenWrt, which happens approx. once per year. You can enjoy more features and bug fixes with a new version during that time in the stable branch. For me, it helps that we (at least in Turris) can unify the U-boot version across all Turris Omnia revisions with the stable branch already, and we don't need to wait until a new OpenWrt release. In the meantime, we can have it on our playground and fiddle around it, but I know that some users don't use Turris OS and already use OpenWrt. On the other hand, I can see that you are against bumping the U-boot version as updating U-boot can be very dangerous. You could argue that there is possible to use the older version of U-boot and add Turris Omnia straight away. That could also be possible, but it will require to backport so many patches. The DDR training mostly gets into the upcoming version Features enabled for Turris Omnia: It means that you can boot from PCIe-USB, PCIe-SATA controllers, and even from NVME disks, including GPT partitions. It could be helpful in cases for users who wear out their eMMC. In general, I'm talking about improvements for A38x, where there is now an RTC driver, fixed and improvement things related to SPL and PCIe. That could help for the existing U-boot images for It is going to help So, it is improvements for all U-boot mvebu targets. |
|
By looking at recent OpenWrt 21.02 changes, I see that we can just think what is better - adding a new U-boot package for a new device (45b3f2a) or bumping the U-boot version? Who knows, right? |
I fail to see, how can this cause regressions.
We now know for sure a703830. |
If we both wants to nitpicking, I can mention several reasons when regressions were introduced to the stable version, but we would go off topic on this thing.
Oops. That happens even if things are tested. Right? I hope that you cherry-pick it to OpenWrt 22.03 branch as well. |
|
Also, the commit which you mentioned affected only CortexA53 (thus the Cortex A9 was safe, though) and I asked even in the OP @dhewg to test it on the platform. In that case, I think my PR can be re-opened. I can not do it on my end. |
|
Yeah, sorry, I didn't have any free time for stuff like this at all. |
This patch series was submitted to OpenWrt [1], but it was somehow agreed that new versions might cause regressions and that there is no man power for testing it on each devices and the only way is for OpenWrt release more often, but we can not force users to use the latest master branches even though customers wants to have always the latest features while using the stable branch. We would like to sync all U-boot versions in upcoming Turris OS 6.x releases, so we dont need to maintain various U-boot versions related to DDR training on Marvell Armada 38X, we need to backport it and as someone could be saying playing our playground instead of submitting stuff to upstream, which we tried and we have at least reference. For curious users, they can check following discussion on this thing on IRC channel #openwrt-devel on OFTC server dated 21/3/2022. (since 18:46:14, ...) [1] openwrt/openwrt#9409
Since
tools/libresslwas updated in OpenWrt 21.02 in this PR #9326, which was required to compile recent U-boot versions. This allowed backporting newer U-boot versions from the master branch to have up-to-date U-boot and added U-boot for Turris Omnia router with additional patches related to it, which will be included in the upcoming U-boot release 2022.04.This compiles successfully on Ubuntu 21.10 and compiled U-boot was tested on the Turris Omnia router.
@dhewg Can you check it on your end that it works for you? Since I don't backport #4709.
If my proposal gets accepted, it would allow me to drop separate package omnia-uboot within the Turris OS and use and test U-boot versions provided by OpenWrt.