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
> > 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
> >
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.
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
> >> 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
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
> >> 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
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
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?
>>
> >> 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
On Thu, April 16, 2020 2:31 pm, Jeffrey Walton wrote:
> On Thu, Apr 16, 2020 at 10:55 AM Derek Atkins 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
On Thu, Apr 16, 2020 at 10:55 AM Derek Atkins 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
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
On Thu, Apr 16, 2020 at 3:54 PM Derek Atkins 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
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
--
Derek Atkins
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
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
On Thu, Apr 16, 2020 at 3:14 PM Derek Atkins 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
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
> 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 +)
> Trying to boot from MMC1
>
>
> U-Boot 2019.10 (Oct 09 2019 - 00:00:00 +)
>
> CPU:
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 +)
Trying to boot from MMC1
U-Boot 2019.10 (Oct 09 2019 - 00:00:00 +)
CPU: Freescale i.MX6Q
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
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
23 matches
Mail list logo
