Re: iMX ddrphy_utils difference with U-boot
Ahmad Fatoum <[email protected]>
| Newsgroups | org.infradead.lists.barebox |
|---|---|
| Message-ID | <[email protected]> |
On 8/19/26 10:26 AM, Ahmad Fatoum wrote: > Hi, > > On 6/15/26 10:49 AM, Sascha Hauer wrote: >> On 2026-06-08 19:26, Ahmad Fatoum wrote: >>> Hello Andrei, >>> >>> On 6/8/26 16:24, Andrei Lalaev wrote: >>>> Hi, >>>> >>>> I am moving an iMX8MP module from vendor U-Boot 2024.04 to Barebox 2025.02 >>> >>> Sidenote: You'll probably want to use one of the still supported >>> v2026.04 or v2026.06 releases. >>> >>>> and found a strange difference in the DDR training code: >>>> >>>> vim drivers/ddr/imx/ddrphy_utils.c +94 >>>> >>>> And the corresponding line in U-Boot: >>>> >>>> vim drivers/ddr/imx/phy/ddrphy_utils.c +101 >>>> >>>> Is there any chance that somebody knows/remembers why "return -1" was replaced with "hang()"? >>> >>> I can't speak for Sascha, but having looked at the code, I see no reason >>> why not to propagate the error. >>> >>>> I couldn't find any explanation in the commits/mailing lists. >>> >>> My guess is that it wasn't anticipated that boards would handle >>> the error gracefully to fall back to a different DDR init. >> >> That's my guess as well. Note the callers of >> imx8m_wait_ddrphy_training_complete() which is only a wrapper around >> calling wait_ddrphy_training_complete() do not check the error code, so >> when changing it back to return an error code we likely want to add >> error checking where missing. > > I just stumbled upon this patch: > https://lore.kernel.org/all/[email protected]/ > > If we start allowing ddr_cfg_phy to propagate this error, you'll likely > want above patch as well. Or maybe not. Just thought to let you know. Cheers, Ahmad > > Cheers, > Ahmad > >> >> Sascha >> > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |