> AHA. The plot thickens.. The board says "D1" written on it, but when I > boot it up I get this output which seems to say it thinks its a B1 board: > > U-Boot SPL 2019.10 (Oct 09 2019 - 00:00:00 +0000) > Trying to boot from MMC1 > > > U-Boot 2019.10 (Oct 09 2019 - 00:00:00 +0000) > > CPU: Freescale i.MX6Q rev1.3 at 792 MHz > Reset cause: POR > DRAM: 2 GiB > PMIC: pmic_get() ret -19 > MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > No panel detected: default to HDMI > Display: HDMI (1024x768) > In: serial > Out: serial > Err: serial > Model: Wandboard i.MX6 Quad Board rev B1 > Board: Wandboard rev B1 > Net: Board Net Initialization Failed > No ethernet found. > ..... [snip] > append: console=ttymxc0,115200 console=tty0 ro > root=UUID=b0abeeb4-7c58-4b29-9c8 > Retrieving file: /dtb-5.3.7-301.fc31.armv7hl/imx6q-wandboard-revb1.dtb > > > So where is this Rev B1 coming from? Why does it not know it's a Rev D1 > board? This is clearly causing it to pull in the wrong DTB file, which > explains why it isn't working. It's the last option in the statement check in board detection which means it's basically the board of last resort. so it seems your rev of the D1 isn't being detected, there was initial support for the revD1 land upstream in U-Boot in Oct 2017. > -derek > > > On Thu, April 16, 2020 9:17 am, Derek Atkins wrote: > > From that website I posted, I found this in a post by Jaime » Wed May 31, > > 2017 3:59 pm: > > > > There is a new dtsi "imx6qdl-wandboard-revd1.dtsi" what contents pinout > > changes, ethernet power driving, and others > > https://github.com/TechNexion/linux/blo ... revd1.dtsi > > https://github.com/wandboard-org/linux/ ... revd1.dtsi > > > > Apparently on the RevD1 you have to explicitly power on the Ethernet, > > which apparently isn't happening? > > > > NB: these two links are: > > https://github.com/TechNexion/linux/blob/tn-imx_4.1.15_2.0.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi > > https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi > > > > -derek > > > > On Thu, April 16, 2020 9:10 am, Derek Atkins wrote: > >> HI, > >> > >> On Thu, April 16, 2020 4:21 am, Peter Robinson wrote: > >>> Hi Derek, > >>> > >>>> I just acquired a wandboard quad rev d1 (to replace an older > >>>> dual-core > >>>> model), but apparently even though there is a revd1 DTB tree, the > >>>> ethernet > >>>> still isn't working. > >>> > >>> I have a Wandboard Quad B1 and ethernet works, I know others have > >>> other > >>> revs. > >> > >> Me too. It's the D1 that doesn't work. Strangely I can plug the same > >> SD > >> card into the B1 and it works, whereas in the D1 it does not. So there > >> is > >> something strange going on. > >> > >>>> According to http://forums.wandboard.org/viewtopic.php?t=1460 this > >>>> issue > >>>> should have been fixed a couple years ago. Is there something > >>>> special > >>>> I > >>>> need to do to get fedora working on this board? > >>> > >>> I'm not sure the context of where that is fixed as I wasn't sure of > >>> where it was fixed. I suspect it was maybe in their downstream kernel > >>> fork. We only use upstream/mainline kernels. > >> > >> I dont know. > >> > >>> So for the vast majority of device support we rely on things being > >>> upstream, both in the linux kernel and in firmware like U-Boot. We > >>> don't have the resources to upstream everything and follow downstream > >>> problems/fixes for every random device. > >> > >> Right, as we should expect. I'm surprised that a proposed change from > >> 2017/2018 hasn't made it into mainline in 2-3 years! > >> > >>> Looking at the upstream changes for the D1 specific rev I see the > >>> following since the D1 one support landed, nothing about network > >>> issues. > >>> > >>> So looking quickly at the post you mention, and looking at the > >>> upstream kernel commits back to when D1 support landed to 5.7-rc1 > >>> there doesn't look to be anything network related: > >>> 404c0c9314f4 ARM: dts: imx6qdl: Fix memory node duplication > >>> d9359f580797 ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier > >>> 5dda6159aaab ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier > >>> 6e1386b2ee68 ARM: dts: imx6qdl-wandboard: Let the codec control MCLK > >>> pinctrl > >>> ad00e080eb75 ARM: dts: imx: Add memory node unit name > >>> 74fe676cb518 ARM: dts: imx6qdl-wandboard-revd1: Make EDID functional > >>> 7721dce68a30 ARM: dts: imx6qp-wandboard-revd1: Add sata support > >>> d016b46ac959 ARM: dts: imx6qdl-wandboard: Add support for the revd1 > >>> variants > >> > >> So where does this leave us? I am not at all sure where the problem > >> lays. > >> I don't know if it's a GPIO issue or something else? But when I plug > >> the > >> Rev D1 board in the ethernet lights do not light up at all, as if it's > >> not > >> being powered on. And of course "ip addr" claims "NO CARRIER" for > >> eth0. > >> > >> Any idea how I can (help) debug this? > >> > >> -derek > >> > >> -- > >> Derek Atkins 617-623-3745 > >> derek@xxxxxxxxx www.ihtfp.com > >> Computer and Internet Security Consultant > >> _______________________________________________ > >> arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx > >> To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx > >> > > > > > > -- > > Derek Atkins 617-623-3745 > > derek@xxxxxxxxx www.ihtfp.com > > Computer and Internet Security Consultant > > _______________________________________________ > > arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx > > > > > -- > Derek Atkins 617-623-3745 > derek@xxxxxxxxx www.ihtfp.com > Computer and Internet Security Consultant > _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
