| Message ID | 2526d077-e7f5-2885-5b52-3eef55f649b9@denx.de |
|---|---|
| State | New |
| Headers | show |
| Series | U-Boot: wandboard ethernet problem with newest mainline | expand |
Hi Heiko, On Thu, Jan 9, 2020 at 5:26 AM Heiko Schocher <hs at denx.de> wrote: > Hmm.. I wonder ... if you want to detect the revd1, you must > access the pmic in SPL, so you need a DTS in which it is > configured, also DM PMIC support in SPL ... which introduces a > lot of dependencies starting with enabling CONFIG_SPL_DM and > blows up SPL ... :-( Yes, as we are very memory limited in SPL, so what about just probing the I2C bus directly at 0x8 via I2C API to detect the presence of the PMIC? This way we do not need DM PMIC support in SPL. Do we need to mark I2C with 'u-boot,dm-pre-reloc;' too and create a arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi ? > 2 problems I see: > > - reorder board_fit_config_name_match > > see attached patch: 0001-wandboard-reorder-board_fit_config_name_match.patch > > With this patch (based on your patches) and hack [2] U-Boot works also again. > > - detect rev D1 board (remaining problem) > > board_fit_config_name_match() is called from board_fit_config_name_match, > so from SPL where you have no access (yet?) to pmic_get(), and so > is_revd1() is always 0 -> which leads to wrong DTB selection. > > First question: other possibility to detect revision D1 ? > > may only probing the chip is enough ? As far as I know probing the PMIC chip is the only way to detect D1. > > Should we use instead CONFIG_DTB_RESELECT ? Not familiar with CONFIG_DTB_RESELECT, sorry. > > This is the way to go I think, added patches: > 0002-wandboard-enable-CONFIG_DTB_RESELECT.patch > 0003-wandboard-use-imx6dl-wandboard-revd1-as-default-DTB.patch > 0004-wandboard-add-u-boot-specific-wandboard-revd1-u-boot.patch > 0005-wandboard-in-SPL-use-only-D1-DTB.patch > > with them, after a soft reset all works fine, see [3] but > on power on I see [4] :-( > > Any idea, why after a power on, pmic does not work? Interesting, I do not see this behavior with a imx6qp wandboard revd1. I have seen I2C errors when booting with an HDMI cable connected: https://lists.denx.de/pipermail/u-boot/2019-December/393503.html ,but haven't had a chance to debug this yet. Regards, Fabio Estevam
Hello Fabio, Am 09.01.2020 um 12:14 schrieb Fabio Estevam: > Hi Heiko, > > On Thu, Jan 9, 2020 at 5:26 AM Heiko Schocher <hs at denx.de> wrote: > >> Hmm.. I wonder ... if you want to detect the revd1, you must >> access the pmic in SPL, so you need a DTS in which it is >> configured, also DM PMIC support in SPL ... which introduces a >> lot of dependencies starting with enabling CONFIG_SPL_DM and >> blows up SPL ... :-( > > Yes, as we are very memory limited in SPL, so what about just probing > the I2C bus directly at 0x8 via I2C API to detect the presence of the > PMIC? > > This way we do not need DM PMIC support in SPL. Yes, i had such a hack also ... > Do we need to mark I2C with 'u-boot,dm-pre-reloc;' too and create a > arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi ? see my patches, I added there such u-boot files. Unfortunately a imx6qdl-wandboard-u-boot.dtsi did not worked, I needed 2 files. >> 2 problems I see: >> >> - reorder board_fit_config_name_match >> >> see attached patch: 0001-wandboard-reorder-board_fit_config_name_match.patch >> >> With this patch (based on your patches) and hack [2] U-Boot works also again. >> >> - detect rev D1 board (remaining problem) >> >> board_fit_config_name_match() is called from board_fit_config_name_match, >> so from SPL where you have no access (yet?) to pmic_get(), and so >> is_revd1() is always 0 -> which leads to wrong DTB selection. >> >> First question: other possibility to detect revision D1 ? >> >> may only probing the chip is enough ? > > As far as I know probing the PMIC chip is the only way to detect D1. Ok, so we must find a way for it ... >> Should we use instead CONFIG_DTB_RESELECT ? > > Not familiar with CONFIG_DTB_RESELECT, sorry. > >> >> This is the way to go I think, added patches: >> 0002-wandboard-enable-CONFIG_DTB_RESELECT.patch >> 0003-wandboard-use-imx6dl-wandboard-revd1-as-default-DTB.patch >> 0004-wandboard-add-u-boot-specific-wandboard-revd1-u-boot.patch >> 0005-wandboard-in-SPL-use-only-D1-DTB.patch >> >> with them, after a soft reset all works fine, see [3] but >> on power on I see [4] :-( >> >> Any idea, why after a power on, pmic does not work? > > Interesting, I do not see this behavior with a imx6qp wandboard revd1. > > I have seen I2C errors when booting with an HDMI cable connected: > https://lists.denx.de/pipermail/u-boot/2019-December/393503.html > > ,but haven't had a chance to debug this yet. Ok, may I find more time for it... If you have time, may I can ask, if you can test my patches, if they do not break other board revisions? Many thanks! bye, Heiko
Hi Heiko, On Thu, Jan 9, 2020 at 8:33 AM Heiko Schocher <hs at denx.de> wrote: > If you have time, may I can ask, if you can test my patches, if they > do not break other board revisions? I haven't had a chance to look at your patches yet, but could you please submit the whole series to the list? I will try to review and test them next week. Thanks
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c index 4cb9bf6..5c64ab5 100644 --- a/board/wandboard/wandboard.c +++ b/board/wandboard/wandboard.c @@ -414,6 +414,7 @@ static bool is_revc1(void) static bool is_revd1(void) { + with_pmic = 1; if (with_pmic) return true; else