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
No panel detected: default to HDMI
Display: HDMI (1024x768)
Model: Wandboard i.MX6 Quad Board rev B1
Board: Wandboard rev B1
Net: Board Net Initialization Failed
No ethernet found.
append: console=ttymxc0,115200 console=tty0 ro
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.
> 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
> > changes, ethernet power driving, and others
> > https://github.com/TechNexion/linux/blo
> > https://github.com/wandboard-org/linux/
> > Apparently on the RevD1 you have to explicitly power on the Ethernet,
> > which apparently isn't happening?
> > NB: these two links are:
> > -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
> >> 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
> >>>> 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
> >>> 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
> >>> 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
> >> 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
> >> eth0.
> >> Any idea how I can (help) debug this?
> >> -derek
> >> --
> >> Derek Atkins 617-623-3745
> >> derek(a)ihtfp.com www.ihtfp.com
> >> Computer and Internet Security Consultant
> >> _______________________________________________
> >> arm mailing list -- arm(a)lists.fedoraproject.org
> >> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> >> 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://email@example.com
> > --
> > Derek Atkins 617-623-3745
> > derek(a)ihtfp.com www.ihtfp.com
> > Computer and Internet Security Consultant
> > _______________________________________________
> > arm mailing list -- arm(a)lists.fedoraproject.org
> > To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> > 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://firstname.lastname@example.org
> Derek Atkins 617-623-3745
> derek(a)ihtfp.com www.ihtfp.com
> Computer and Internet Security Consultant