Hi,
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.
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 installed Fedora-Minimal-armhfp-31-1.9-sda.raw.xz and it boots but the ethernet shows "no carrier" when I run "ip addr".
:-(
-derek
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.
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.
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.
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
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
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/boo... https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/ar...
-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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
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.
-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/boo... https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/ar...
-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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
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/boo... https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/ar...
-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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Thu, April 16, 2020 10:01 am, Peter Robinson wrote:
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.
*sigh* I acquired this board only a few months ago.
I tried doing a "setenv" within uboot to change the board-name from B1 to D1 but obviously that didn't do anything since I think it needs to be detected earlier than that. So this requires a change to u-boot? I must admit that I've never looked at uboot code so not even sure where to start to see where I would need to add something for my board, let along figure out what it is I need to add. (Well, I suppose once I figure out what it's looking for I can hopefully probe the board to figure out what it's saying).
Why can't they make this easy? :(
-derek
On Thu, Apr 16, 2020 at 3:14 PM Derek Atkins derek@ihtfp.com wrote:
On Thu, April 16, 2020 10:01 am, Peter Robinson wrote:
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.
*sigh* I acquired this board only a few months ago.
I tried doing a "setenv" within uboot to change the board-name from B1 to D1 but obviously that didn't do anything since I think it needs to be
It'll be using a GPIO or availability of something to detect the board so that won't make any difference.
detected earlier than that. So this requires a change to u-boot? I must admit that I've never looked at uboot code so not even sure where to start to see where I would need to add something for my board, let along figure out what it is I need to add. (Well, I suppose once I figure out what it's looking for I can hopefully probe the board to figure out what it's saying).
Why can't they make this easy? :(
The proper question is why is Wandboard hostile to upstream by not sending their device support upstream. The original commit was by a NXP maintainer, but there's been little on the Wandboard stuff at all since the addition of the D1 support.
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Thu, April 16, 2020 10:19 am, Peter Robinson wrote:
The proper question is why is Wandboard hostile to upstream by not sending their device support upstream. The original commit was by a NXP maintainer, but there's been little on the Wandboard stuff at all since the addition of the D1 support.
Another good question. But even looking at the wandboard github stuff, there doesn't appear to have been any changes since 2015 to the uboot-imx tree or the u-boot-fslc tree. C.f. https://github.com/wandboard-org
I feel like they used to be so much better about pushing upstream. Or maybe the hardware manufacturer made a change without telling the wandboard crew?
I find it odd that github is showing 2015 when there were clearly changed in 2017? I'm confused.
Okay, I was looking at an old branch. There is a 2017 branch which has a commit to add D1 to u-boot: https://github.com/wandboard-org/uboot-imx/commit/978c09eb0d49dba37b86c23e61...
Of course I don't know if this commit ever made it upstream?
-derek
Taking a look at the u-boot I've got (running "strings" on the dd image from the first 20MB /dev/mmcblk) I see:
strings /tmp/mmc.dat | grep -i wand | grep -i d1 imx6qp-wandboard-revd1 _imx6qp-wandboard-revd1 _imx6qp-wandboard-revd1 imx6qp-wandboard-revd1 Board: Wandboard rev D1 ...
So clearly there is some D1 detection going on in u-boot, but it's not working for my instance of the board. :-(
-derek
On Thu, April 16, 2020 10:30 am, Derek Atkins wrote:
On Thu, April 16, 2020 10:19 am, Peter Robinson wrote:
The proper question is why is Wandboard hostile to upstream by not sending their device support upstream. The original commit was by a NXP maintainer, but there's been little on the Wandboard stuff at all since the addition of the D1 support.
Another good question. But even looking at the wandboard github stuff, there doesn't appear to have been any changes since 2015 to the uboot-imx tree or the u-boot-fslc tree. C.f. https://github.com/wandboard-org
I feel like they used to be so much better about pushing upstream. Or maybe the hardware manufacturer made a change without telling the wandboard crew?
I find it odd that github is showing 2015 when there were clearly changed in 2017? I'm confused.
Okay, I was looking at an old branch. There is a 2017 branch which has a commit to add D1 to u-boot: https://github.com/wandboard-org/uboot-imx/commit/978c09eb0d49dba37b86c23e61...
Of course I don't know if this commit ever made it upstream?
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Peter,
Sorry for inundating your email box! One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
-derek
On Thu, Apr 16, 2020 at 3:54 PM Derek Atkins derek@ihtfp.com wrote:
Peter,
Sorry for inundating your email box! One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
TBH no idea.
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
Thanks Peter,
I've emailed wandboard and I registered for the forum and responded to that thread, so HOPEFULLY I'll get an answer.
Very disappointing :( (not with you -- you've been great!)
-derek
On Thu, April 16, 2020 1:02 pm, Peter Robinson wrote:
On Thu, Apr 16, 2020 at 3:54 PM Derek Atkins derek@ihtfp.com wrote:
Peter,
Sorry for inundating your email box! One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
TBH no idea.
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Thu, Apr 16, 2020 at 10:55 AM Derek Atkins derek@ihtfp.com wrote:
One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
Probably -ENODEV.
Jeff
On Thu, April 16, 2020 2:31 pm, Jeffrey Walton wrote:
On Thu, Apr 16, 2020 at 10:55 AM Derek Atkins derek@ihtfp.com wrote:
One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
Probably -ENODEV.
Maybe.
Interestingly, I just came across https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board%2Fwandboard which has the following commit message:
Only the wandboard revD1 boards have PMIC, so when running on a wandboard of different revision the following error is always shown on every boot:
pmic_get() ret -19
Instead of printing this error message, move it to debug level instead.
However, the board is labelled as D1 but isn't acting like a D1. *cries* I wonder if I should email that author directly?
Jeff
-derek
One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean?
Probably -ENODEV.
Maybe.
Interestingly, I just came across https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board%2Fwandboard which has the following commit message:
Only the wandboard revD1 boards have PMIC, so when running on a wandboard of different revision the following error is always shown on every boot:
pmic_get() ret -19
Instead of printing this error message, move it to debug level instead.
Actually I suspect that's because it's a different config and hence the issue, I suspect once the detection bit is fixed that issue may just go away.
Hi,
On Thu, April 16, 2020 3:50 pm, Peter Robinson wrote:
One more thing I just noticed from the uboot output:
PMIC: pmic_get() ret -19
Looking at the commit I sent earlier, this appears to be part of the
D1
detection. So what does return code -19 mean?
Probably -ENODEV.
Maybe.
Interestingly, I just came across https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board%2Fwandboard which has the following commit message:
Only the wandboard revD1 boards have PMIC, so when running on a wandboard of different revision the following error is always shown on every boot:
pmic_get() ret -19
Instead of printing this error message, move it to debug level instead.
Actually I suspect that's because it's a different config and hence the issue, I suspect once the detection bit is fixed that issue may just go away.
Could be. I'm working with a U-Boot dev right now who sent me two patches to u-boot to try to fix the detection. So now I get to figure out how to build u-boot to test it out.
Pulling down 2020.04 from F32-beta was easy. Building it.... We'll see! Can I build it on my x86_64? ;)
-derek
Hi,
On Thu, April 16, 2020 4:38 pm, Derek Atkins wrote:
Hi,
[snip]
Actually I suspect that's because it's a different config and hence the issue, I suspect once the detection bit is fixed that issue may just go away.
Could be. I'm working with a U-Boot dev right now who sent me two patches to u-boot to try to fix the detection. So now I get to figure out how to build u-boot to test it out.
Pulling down 2020.04 from F32-beta was easy. Building it.... We'll see! Can I build it on my x86_64? ;)
He saved me hours and sent me files to test and they worked. So he's preparing a patch to send to the u-boot list. Hopefully that patch can get pulled into Fedora 32?
-derek
Actually I suspect that's because it's a different config and hence the issue, I suspect once the detection bit is fixed that issue may just go away.
Could be. I'm working with a U-Boot dev right now who sent me two patches to u-boot to try to fix the detection. So now I get to figure out how to build u-boot to test it out.
Pulling down 2020.04 from F32-beta was easy. Building it.... We'll see! Can I build it on my x86_64? ;)
He saved me hours and sent me files to test and they worked. So he's preparing a patch to send to the u-boot list. Hopefully that patch can get pulled into Fedora 32?
We don't tend to build U-Boot once a release goes GA, primarily just due to lack of resources. That said U-Boot is firmware and completely independent of the OS, we only build it due to convenience so using a f33/rawhide build with F-32 OS is completely stable and works just fine.
Hi,
On Fri, April 17, 2020 8:33 am, Peter Robinson wrote:
He saved me hours and sent me files to test and they worked. So he's preparing a patch to send to the u-boot list. Hopefully that patch can get pulled into Fedora 32?
We don't tend to build U-Boot once a release goes GA, primarily just due to lack of resources. That said U-Boot is firmware and completely independent of the OS, we only build it due to convenience so using a f33/rawhide build with F-32 OS is completely stable and works just fine.
Understood. Indeed, I pulled down the F32-beta package to run on F31. It's just a bit of a pain that it's not available "immediately" so I will have to remember to manually fix the uboot install ex-post-facto until it gets pulled in.. Actually, not too bad because I only have this one D1 device, so it's just this one time that I will need to do it.
But at least we know it'll get into upstream "soon".
-derek
He saved me hours and sent me files to test and they worked. So he's preparing a patch to send to the u-boot list. Hopefully that patch can get pulled into Fedora 32?
We don't tend to build U-Boot once a release goes GA, primarily just due to lack of resources. That said U-Boot is firmware and completely independent of the OS, we only build it due to convenience so using a f33/rawhide build with F-32 OS is completely stable and works just fine.
Understood. Indeed, I pulled down the F32-beta package to run on F31. It's just a bit of a pain that it's not available "immediately" so I will have to remember to manually fix the uboot install ex-post-facto until it gets pulled in.. Actually, not too bad because I only have this one D1 device, so it's just this one time that I will need to do it.
But at least we know it'll get into upstream "soon".
Yep, I've seen the upstream discussion, I'll test the patches on my revB1 when I get a moment, I've asked in the community if there's someone with a revC to test. I suspect with the delays we might well have another U-Boot build. Any chance you could do a bug report for me here?
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=32&...
Peter
Peter,
On Fri, April 17, 2020 9:07 am, Peter Robinson wrote:
Yep, I've seen the upstream discussion, I'll test the patches on my revB1 when I get a moment, I've asked in the community if there's someone with a revC to test. I suspect with the delays we might well have another U-Boot build. Any chance you could do a bug report for me here?
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=32&...
Done:
https://bugzilla.redhat.com/show_bug.cgi?id=1825247
Peter
-derek
Hi,
On Fri, April 17, 2020 9:07 am, Peter Robinson wrote:
Yep, I've seen the upstream discussion, I'll test the patches on my revB1 when I get a moment, I've asked in the community if there's someone with a revC to test. I suspect with the delays we might well have another U-Boot build. Any chance you could do a bug report for me here?
FYI, I've got an old Rev C1 Wandboard-Dual and I can verify that this u-boot works there:
U-Boot SPL 2020.04-00005-g081df7dca7 (Apr 17 2020 - 09:00:31 -0300) Trying to boot from MMC1
U-Boot 2020.04-00005-g081df7dca7 (Apr 17 2020 - 09:00:31 -0300)
CPU: Freescale i.MX6DL rev1.1 at 792 MHz Reset cause: POR DRAM: 1 GiB MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Board: Wandboard rev C1 Net: Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000
-derek
Yep, I've seen the upstream discussion, I'll test the patches on my revB1 when I get a moment, I've asked in the community if there's someone with a revC to test. I suspect with the delays we might well have another U-Boot build. Any chance you could do a bug report for me here?
FYI, I've got an old Rev C1 Wandboard-Dual and I can verify that this u-boot works there:
FYI this is fixed in the uboot-tools-2020.04-2.fc32 and will in in F-32. Available now for testing.
P
On Wed, April 22, 2020 6:47 am, Peter Robinson wrote:
Yep, I've seen the upstream discussion, I'll test the patches on my revB1 when I get a moment, I've asked in the community if there's someone with a revC to test. I suspect with the delays we might well have another U-Boot build. Any chance you could do a bug report for me here?
FYI, I've got an old Rev C1 Wandboard-Dual and I can verify that this u-boot works there:
FYI this is fixed in the uboot-tools-2020.04-2.fc32 and will in in F-32. Available now for testing.
Thanks, Peter!
P
-derek
-
Derek Atkins -
Jeffrey Walton -
Peter Robinson