D1 Project Office Hours
157 views
Skip to first unread message
Jeff Scheel
Oct 22, 2021, 12:21:05 PM10/22/21
to RISC-V Developer Board Community
D1 Projects,
Given the comments from your first set of status, I'm wondering if I should schedule "office hours" at some cadence for us to all gather, talk about challenges, and discuss how to proceed. There would probably need to be 2 times so that we can handle geographic diversity.
Please share your thoughts on this. Would this be helpful?
-Jeff
--
Jeff Scheel (he/him/his)Linux Foundation, RISC-V Technical Program Manager
Dusten Sobotta
Oct 22, 2021, 1:06:43 PM10/22/21
to RISC-V Developer Board Community, Jeff Scheel
I personally like how the rust community moved their primary community engagement and support to discord. It's smoother to work with than slack, and nice that you can just jump into a voice/video channel in one click. Having collapsible categories of community-driven topic channels is a game-changer; visibility is always first.
Although the target demographic is a bit different, I've also seen twitch/youtube streamers use discord for semi-regular conversations. It's a lot less work to let people self-organize into a audio/video channel than managing invites for a zoom call, etc. No need for organized breakout sessions when people can move themselves into another channel to continue a discussion.
Although the target demographic is a bit different, I've also seen twitch/youtube streamers use discord for semi-regular conversations. It's a lot less work to let people self-organize into a audio/video channel than managing invites for a zoom call, etc. No need for organized breakout sessions when people can move themselves into another channel to continue a discussion.
On October 22, 2021, Jeff Scheel <je...@riscv.org> wrote:
D1 Projects,
Given the comments from your first set of status, I'm wondering if I should schedule "office hours" at some cadence for us to all gather, talk about challenges, and discuss how to proceed. There would probably need to be 2 times so that we can handle geographic diversity.
Please share your thoughts on this. Would this be helpful?
-Jeff
--Jeff Scheel (he/him/his)
Linux Foundation, RISC-V Technical Program Manager --
You received this message because you are subscribed to the Google Groups "RISC-V Developer Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devboard-commun...@riscv.org.
Gabe R
Oct 25, 2021, 9:40:19 PM10/25/21
to RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org
The biggest problem I have with using Discord, Slack, MS Teams, etc is that chat like nature of them makes it harder to look back and review information from earlier conversations. Additionally, whenever I use them, no-one seems to understand the ability to create threads, instead just holding the entire chat in the main thread, making it harder to look backwards.
Robert Lipe
Oct 25, 2021, 11:17:09 PM10/25/21
to Gabe R, RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org
On Mon, Oct 25, 2021 at 8:40 PM Gabe R <lockhee...@gmail.com> wrote:
whenever I use [Discord, Slack, and other email wanna-bes], no-one seems to understand the ability to create threads, instead just holding the entire chat in the main thread, making it harder to look backwards.
That's been true in every Discord and Slack group I've ever been part of. If you don't check it hourly, you see largely a stream of "I like it", "approved", "no" and other one-liners with absolutely no hint what they're attached to.
The problems with this group isn't the format; it's the lack of participation from anyone with authoritative. I have what seems to be a DOA board and couldn't get a single reply about anyone even confirming the power light on these things. The large majority of our traffic has been in simply getting the boards powered on and a meaningful operating system running on them. We've seen very little discussion about individual projects and progress and discovery of memory maps or block layouts or whatever.
Office hours usually quickly become a half duplex 1:1. They work poorly for a crowd of any size.
I'm done being grumpy for now...
RJL
Gabe R
Nov 4, 2021, 9:57:42 PM11/4/21
to RISC-V Developer Board Community, rober...@gmail.com, RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org, Gabe R
Robert,
Looking back through the forum, I don't see a post from you asking about a DOA board. Did you use reply or reply all? If you only use reply it will not go out to the group.
Looking back through the forum, I don't see a post from you asking about a DOA board. Did you use reply or reply all? If you only use reply it will not go out to the group.
Robert Lipe
Nov 9, 2021, 3:43:35 AM11/9/21
to Gabe R, RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org
Hi, Gabe.
I actually owe Jeff an extended write-up on this, but my original post was titled "Nezha DOA or just comatose?" on September 23. It went to devboard-seed instead of devboard-community as the latter didn't exist (at least to me) until Sept. 30. I know it was accepted at the server because I got a response from Jeff to the personal PS at the bottom.
I don't have the board near me now, but the punchline (and I've since learned there IS a power LED in the corner) is that plugged into a wide variety of USB-C cables and power supplies, including official cabling from the likes of Apple and Samsung results in no light.
Of course, I didn't think to confirm the presence of a light until I'd spent a LOT of hours plugging and unplugging host cables, messing with serial hookups, and general USB/serial tty ritual sacrifice.
I now have limited time before I probably have to be away from the board - unless we get it going, then it comes with me on my month-long December trip where time will still be scarce. Since I'm likely to get some of the D1S boards or Seeed's new D1 board (why not both!) if there's a trip for the PCB over the ocean to the U.S. involved, I may just lose interest in this one as can do most of my T-Head PSM work on those.
I've spoken with at least three others that have had DOA boards and a LOT that have had problems getting OSes installed on them. We've seen evidence of the latter in this group.
So I know there's very little technical content here, but with a diagnosis of "no signs of life", are there any secret reset buttons that default to being Normally Active or jumpers or *anything* else beyond "attach power cable, insert SD card formatted with ????, attach supported 3.3V USB at obvious place? (A scope will help debug crossed TX/RX.)
Thanx for listening. Sorry that I ramble at this hour...
RJL
I actually owe Jeff an extended write-up on this, but my original post was titled "Nezha DOA or just comatose?" on September 23. It went to devboard-seed instead of devboard-community as the latter didn't exist (at least to me) until Sept. 30. I know it was accepted at the server because I got a response from Jeff to the personal PS at the bottom.
I don't have the board near me now, but the punchline (and I've since learned there IS a power LED in the corner) is that plugged into a wide variety of USB-C cables and power supplies, including official cabling from the likes of Apple and Samsung results in no light.
Of course, I didn't think to confirm the presence of a light until I'd spent a LOT of hours plugging and unplugging host cables, messing with serial hookups, and general USB/serial tty ritual sacrifice.
I now have limited time before I probably have to be away from the board - unless we get it going, then it comes with me on my month-long December trip where time will still be scarce. Since I'm likely to get some of the D1S boards or Seeed's new D1 board (why not both!) if there's a trip for the PCB over the ocean to the U.S. involved, I may just lose interest in this one as can do most of my T-Head PSM work on those.
I've spoken with at least three others that have had DOA boards and a LOT that have had problems getting OSes installed on them. We've seen evidence of the latter in this group.
So I know there's very little technical content here, but with a diagnosis of "no signs of life", are there any secret reset buttons that default to being Normally Active or jumpers or *anything* else beyond "attach power cable, insert SD card formatted with ????, attach supported 3.3V USB at obvious place? (A scope will help debug crossed TX/RX.)
Thanx for listening. Sorry that I ramble at this hour...
RJL
Jeff Scheel
Nov 9, 2021, 1:57:00 PM11/9/21
to Robert Lipe, Gabe R, RISC-V Developer Board Community, Dusten Sobotta
On Tue, Nov 9, 2021 at 3:43 AM Robert Lipe <rober...@gmail.com> wrote:
I actually owe Jeff an extended write-up on this, but my original post was titled "Nezha DOA or just comatose?" on September 23. It went to devboard-seed instead of devboard-community as the latter didn't exist (at least to me) until Sept. 30. I know it was accepted at the server because I got a response from Jeff to the personal PS at the bottom.
Here's Robert's original email...
I've forwarded it to our contact at Allwinner for assistance.
-Jeff
--
Jeff Scheel (he/him/his)
Linux Foundation, RISC-V Technical Program Manager
---------- Forwarded message ---------
From: Robert Lipe <rober...@gmail.com>
Date: Thu, Sep 23, 2021 at 7:03 PM
Subject: Nezha DOA or just comatose?
To: RISC-V Development Board Seed Program <devboa...@riscv.org>
From: Robert Lipe <rober...@gmail.com>
Date: Thu, Sep 23, 2021 at 7:03 PM
Subject: Nezha DOA or just comatose?
To: RISC-V Development Board Seed Program <devboa...@riscv.org>
I'm not a stranger to Pi and similar (K210, gobs of GD32V, BL60x, etc.) class boards, but I'm failing to make friends with Nezha.
I find no evidence of life. Not a byte over the serial console. Not a single LED anywhere. No difference when an SD card is inserted or not. It's just dead-like.
Is there some recipe I'm missing to powering this up? Should there be any LED activity? Is there a jumper, button, or other "power up" or "do computer stuff" sequence that I'm missing? I've tried multiple power supplies and cables, all of which power my Macbook Pro and similar devices and from the MBP itself.
I'm comfortable with electronics and have a scope if there are readings I can easily take to confirm CPU clocks, power stability, etc. (I also have shaky hands, so pins on GPIO are better for me than pins under a BGA socket or something microscopic.)
I'm really just hoping there is no "power on" LED, that the board doesn't ship with Tuna in flash, and that I'm writing malformed disk images of the Fedora image to boot or something "easy".
Should there BE blinky lights?
Should there be a default OS image installed?
I've sunk about ten hours into the board and am feeling pretty silly that I'm stuck on the launch pad.
Thanx in advance.
RJL
P.S. This question is probably for Jeff or one of his peers, but is this list for ALL the RISC-V boards (to be) shipped by the program or is this just for Nezha? For those of us curious about, say, Unleashed, can we monitor the archives/lurk on the other lists?
I find no evidence of life. Not a byte over the serial console. Not a single LED anywhere. No difference when an SD card is inserted or not. It's just dead-like.
Is there some recipe I'm missing to powering this up? Should there be any LED activity? Is there a jumper, button, or other "power up" or "do computer stuff" sequence that I'm missing? I've tried multiple power supplies and cables, all of which power my Macbook Pro and similar devices and from the MBP itself.
I'm comfortable with electronics and have a scope if there are readings I can easily take to confirm CPU clocks, power stability, etc. (I also have shaky hands, so pins on GPIO are better for me than pins under a BGA socket or something microscopic.)
I'm really just hoping there is no "power on" LED, that the board doesn't ship with Tuna in flash, and that I'm writing malformed disk images of the Fedora image to boot or something "easy".
Should there BE blinky lights?
Should there be a default OS image installed?
I've sunk about ten hours into the board and am feeling pretty silly that I'm stuck on the launch pad.
Thanx in advance.
RJL
P.S. This question is probably for Jeff or one of his peers, but is this list for ALL the RISC-V boards (to be) shipped by the program or is this just for Nezha? For those of us curious about, say, Unleashed, can we monitor the archives/lurk on the other lists?
Gabe R
Nov 9, 2021, 11:24:51 PM11/9/21
to RISC-V Developer Board Community, je...@riscv.org, Gabe R, RISC-V Developer Board Community, Dusten Sobotta, rober...@gmail.com
Robert,
I pulled up the schematics from the Allwinner site. They are for V1, while my board is V1.01, so your mileage might vary. You can also find links in the schematic section of this page: https://linux-sunxi.org/Allwinner_Nezha
There are two LED in the same place that there are on a Raspberry Pi. Once is labeled LED, and is a user controllable RGB LED, the other is labelled PWR, is a red LED, and according to the schematic, is wired directly to VCC.
The VCC Rail can receive power either from the USB-C port next to the HDMI port, the USB-C Port next to the USB-A port
Allwinner did not properly configure the USB-C ports CC pins, so you will need to use a non E-Marked USB-C cable to get it to work. Mine came with a couple of USB-A to USB-C cables.
I would also look through the docs on https://d1.docs.allwinnertech.com/en/, they have some troubleshooting guides, but they are incomplete.
Gabriel Roper
Samuel Holland
Nov 9, 2021, 11:50:12 PM11/9/21
to Robert Lipe, Gabe R, RISC-V Developer Board Community, Dusten Sobotta, Jeff Scheel
Hello Robert,
From Robert Lipe <rober...@gmail.com <mailto:rober...@gmail.com>>:
have inserted a properly-formatted SD card, then you will get no display
and no UART output by default.
As Gabe mentioned, there is a red power LED that you should see
immediately light up, even if you get no other output.
> Is there some recipe I'm missing to powering this up? Should there be
> any LED activity? Is there a jumper, button, or other "power up" or "do
> computer stuff" sequence that I'm missing? I've tried multiple power
> supplies and cables, all of which power my Macbook Pro and similar
> devices and from the MBP itself.
Probably the easiest way to test the hardware without worrying about
software is to boot the board in FEL mode. FEL mode is implemented in
the chip's mask ROM and provides a USB device.
To boot in FEL mode, hold down the "FEL" button (the one closest to the
center of the board) while plugging the USB Type-C OTG port (the one
near the USB Type-A port) into your computer. You should see a
full-speed USB device show up. For example, here is what I see from
`lsusb` on my machine:
Bus 001 Device 072: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG
connector in FEL/flashing mode
If you see that, then likely the board's hardware is okay and the issue
is getting software loaded correctly onto a microSD card. (And you can
use the xfel tool from https://github.com/xboot/xfel to verify you can
communicate with the board.)
If no USB device shows up, with any cable or cable orientation(!), then
at that point the hardware starts to be a concern.
Regards,
Samuel
From Robert Lipe <rober...@gmail.com <mailto:rober...@gmail.com>>:
> I find no evidence of life. Not a byte over the serial console. Not a
> single LED anywhere. No difference when an SD card is inserted or not.
> It's just dead-like.
Unless the SPI NAND is pre-installed with some operating system, or you
> single LED anywhere. No difference when an SD card is inserted or not.
> It's just dead-like.
have inserted a properly-formatted SD card, then you will get no display
and no UART output by default.
As Gabe mentioned, there is a red power LED that you should see
immediately light up, even if you get no other output.
> Is there some recipe I'm missing to powering this up? Should there be
> any LED activity? Is there a jumper, button, or other "power up" or "do
> computer stuff" sequence that I'm missing? I've tried multiple power
> supplies and cables, all of which power my Macbook Pro and similar
> devices and from the MBP itself.
software is to boot the board in FEL mode. FEL mode is implemented in
the chip's mask ROM and provides a USB device.
To boot in FEL mode, hold down the "FEL" button (the one closest to the
center of the board) while plugging the USB Type-C OTG port (the one
near the USB Type-A port) into your computer. You should see a
full-speed USB device show up. For example, here is what I see from
`lsusb` on my machine:
Bus 001 Device 072: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG
connector in FEL/flashing mode
If you see that, then likely the board's hardware is okay and the issue
is getting software loaded correctly onto a microSD card. (And you can
use the xfel tool from https://github.com/xboot/xfel to verify you can
communicate with the board.)
If no USB device shows up, with any cable or cable orientation(!), then
at that point the hardware starts to be a concern.
Regards,
Samuel
Robert Lipe
Nov 29, 2021, 6:46:07 AM11/29/21
to Samuel Holland, Gabe R, RISC-V Developer Board Community, Dusten Sobotta, Jeff Scheel
Thank you Gabe and Samuel. Gabe called it:
Allwinner did not properly configure the USB-C ports CC pins,
This board has a seriously broken USB implementation. I've carefully cultivated a collection of high-quality USB chargers, computers, power supplies, and chargers.
Not a stinking one of them works with this board.
If I replace the cables with cheapos or divert the chain from "pure" USB-C, it powers up, just like Gabe suggests. If I replace the cables with USB-A->USB-C cables, it powers up. If I take an Apple power supply, run it through a USB-C hub, then use the same cable, it'll power up. Remove the hub, no power. If I have a two-headed USB-A + USB-C power supply, it'll work through the A->C cable and it'll work through the C connector if I run it through a hub. Attaching it directly to a Macbook, like one would do for development, results in no power, even if the device is powered through a C->C hub that allows passthrough charging to the computer (like one would do for development).
I'll admit that it sat on my bench for a while, but I spent a huge amount of time swapping things in and out before coming to the conclusion that Gabe did. This board has a seriously broken USB implementation.
That at least let the MMC try to boot, but it ultimately gets to
before dying. Log attached.
I grabbed Fedora per the FAQ. It generated hundreds of:
****retry:start*****
[ 181.932509] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00000000
[ 181.947897] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 181.963356] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 181.979155] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd***
Not a stinking one of them works with this board.
If I replace the cables with cheapos or divert the chain from "pure" USB-C, it powers up, just like Gabe suggests. If I replace the cables with USB-A->USB-C cables, it powers up. If I take an Apple power supply, run it through a USB-C hub, then use the same cable, it'll power up. Remove the hub, no power. If I have a two-headed USB-A + USB-C power supply, it'll work through the A->C cable and it'll work through the C connector if I run it through a hub. Attaching it directly to a Macbook, like one would do for development, results in no power, even if the device is powered through a C->C hub that allows passthrough charging to the computer (like one would do for development).
I'll admit that it sat on my bench for a while, but I spent a huge amount of time swapping things in and out before coming to the conclusion that Gabe did. This board has a seriously broken USB implementation.
That at least let the MMC try to boot, but it ultimately gets to
before dying. Log attached.
I grabbed Fedora per the FAQ. It generated hundreds of:
****retry:start*****
[ 181.932509] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00000000
[ 181.947897] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 181.963356] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 181.979155] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd***
... repeats ...
[ 185.947913] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 185.963173] sunxi-mmc 4020000.sdmmc: send manual stop command failed
[ 185.979625] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 185.995085] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710330
[ 186.010603] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 186.026404] sunxi-mmc 4020000.sdmmc: sunxi v5p3x retry give up
[ 186.042087] sunxi-mmc 4020000.sdmmc: retry:set phase failed or over retry times
[ 186.059563] sunxi-mmc 4020000.sdmmc: retry:give up
[ 186.074263] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.090478] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.106584] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.122582] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.138476] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.154291] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.170042] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.185727] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.201321] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.216804] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.232158] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.247473] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.262712] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.277886] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.292918] sunxi-mmc 4020000.sdmmc: error -110 requesting status
[ 186.307915] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 0Hz bm PP pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 186.338270] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.366932] sunxi-mmc 4020000.sdmmc: no vqmmc,Check if there is regulator
[ 186.396230] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.436482] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.470409] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.520508] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing SD-HS(SDR25) dt B
[ 186.553012] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm ON vdd 21 width 1 timing SD-HS(SDR25) dt B
[ 186.586639] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm ON vdd 21 width 4 timing SD-HS(SDR25) dt B
[ 186.956631] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 18, RD DTO !!
[ 186.975314] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 186.992998] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 187.010715] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 187.028538] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 187.046707] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
[ 187.382274] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 18, RD DTO !!
[ 187.400962] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 187.418649] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 187.436401] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 187.454241] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 187.472425] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
much more repeating
[ 197.899102] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 197.914876] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
[ 197.930697] 4,end
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
Give root password for maintenance
(or press Control-D to continue):
Where it basically locks up. At this point, I figure this is the normal hazing ritual of a daily build not working + maybe a line level issue in my serial cable, but I'd expect it to not receive instead of not transmitting.
On to the 0912 version.
It has a similar stream of what looks like SCSI errors, ending in a [FAILED] ... to mount /sysroot and a prompt I can't use.
If I press and hold the FEL key while booting, it doesn't attempt to load the OS or make an screen output, so it definitely recognizes the keypress. But my iMac plugged into the OTG port (laundered through USB-A for good measure) isn't recognized by
% ./xfel sid
ERROR: Can't found any FEL device
and it doesn't add a USB device to System Information
So I think we have a few parallel situations:
1) That USB power situation is BAD. I just don't know how you ship a USB product that doesn't boot from, say, and Apple power supply. Is this a bug in the prerelease versions we were shipped or are real customers subjected to that? Is there any reasonable fix/workaround I can do on my side?
[ 185.947913] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 185.963173] sunxi-mmc 4020000.sdmmc: send manual stop command failed
[ 185.979625] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 185.995085] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710330
[ 186.010603] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 186.026404] sunxi-mmc 4020000.sdmmc: sunxi v5p3x retry give up
[ 186.042087] sunxi-mmc 4020000.sdmmc: retry:set phase failed or over retry times
[ 186.059563] sunxi-mmc 4020000.sdmmc: retry:give up
[ 186.074263] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.090478] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.106584] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.122582] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.138476] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.154291] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.170042] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.185727] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 12, RTO !!
[ 186.201321] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.216804] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.232158] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.247473] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.262712] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.277886] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 13, RTO !!
[ 186.292918] sunxi-mmc 4020000.sdmmc: error -110 requesting status
[ 186.307915] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 0Hz bm PP pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 186.338270] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.366932] sunxi-mmc 4020000.sdmmc: no vqmmc,Check if there is regulator
[ 186.396230] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.436482] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.470409] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 186.520508] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON vdd 21 width 1 timing SD-HS(SDR25) dt B
[ 186.553012] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm ON vdd 21 width 1 timing SD-HS(SDR25) dt B
[ 186.586639] sunxi-mmc 4020000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm ON vdd 21 width 4 timing SD-HS(SDR25) dt B
[ 186.956631] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 18, RD DTO !!
[ 186.975314] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 186.992998] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 187.010715] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 187.028538] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 187.046707] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
[ 187.382274] sunxi-mmc 4020000.sdmmc: smc 0 p0 err, cmd 18, RD DTO !!
[ 187.400962] sunxi-mmc 4020000.sdmmc: *****retry:start*****
[ 187.418649] sunxi-mmc 4020000.sdmmc: REG_DRV_DL: 0x00030000
[ 187.436401] sunxi-mmc 4020000.sdmmc: REG_SD_NTSR: 0x81710110
[ 187.454241] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 187.472425] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
much more repeating
[ 197.899102] sunxi-mmc 4020000.sdmmc: REG_NTDL_HS400: 0x20000010
[ 197.914876] sunxi-mmc 4020000.sdmmc: *****retry:re-send cmd*****
[ 197.930697] 4,end
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
Give root password for maintenance
(or press Control-D to continue):
Where it basically locks up. At this point, I figure this is the normal hazing ritual of a daily build not working + maybe a line level issue in my serial cable, but I'd expect it to not receive instead of not transmitting.
On to the 0912 version.
It has a similar stream of what looks like SCSI errors, ending in a [FAILED] ... to mount /sysroot and a prompt I can't use.
If I press and hold the FEL key while booting, it doesn't attempt to load the OS or make an screen output, so it definitely recognizes the keypress. But my iMac plugged into the OTG port (laundered through USB-A for good measure) isn't recognized by
% ./xfel sid
ERROR: Can't found any FEL device
and it doesn't add a USB device to System Information
So I think we have a few parallel situations:
1) That USB power situation is BAD. I just don't know how you ship a USB product that doesn't boot from, say, and Apple power supply. Is this a bug in the prerelease versions we were shipped or are real customers subjected to that? Is there any reasonable fix/workaround I can do on my side?
2) The pre-installed OS is fried.
3) It seems I can receive from the board, but not send to the board serially. It's possible that's a cabling issue on my side. The same adapter worked on BeagleV with 1.8V lines, but there's some possibility of a needed voltage shifter.
4) Booting from two different Fedora boot images just self-destruct. The burned cards (one card, two tries) pass Etcher verification, so I don't think the SD card is bad, but I suppose I'll try to eliminate that.
I'm about to travel for a while. If I have time to work through the serial thing on Monday (I think that's the only step that needs my parts library) I'll bring it with me and hope to do some boot work. Otherwise, it sits for another month until my return.
Once you do an 'xfel jtag' (assuming xfel works...) does it just create an FTDI-like interface on USB that gdbserver or such can connect to without a physical pod? That would be nifty if true because having power + console + another JTAG cable would be a drag.
I would have ordered the new Sipeed board this week (gotta catch 'em all) but I'm holding out for an .100 post version for dupont leads and breadboard instead of that high density connector it uses.
I'll admit I've been off and on with this board, but how many others are just stuck behind the starting line?
RJL
P.S. If anyone has contacts with VisionFive, please send 'em my way. I'd like to confirm that the JTAG/Serial/Blinky GPIO boards I had made still work with the new 7100 board.
4) Booting from two different Fedora boot images just self-destruct. The burned cards (one card, two tries) pass Etcher verification, so I don't think the SD card is bad, but I suppose I'll try to eliminate that.
I'm about to travel for a while. If I have time to work through the serial thing on Monday (I think that's the only step that needs my parts library) I'll bring it with me and hope to do some boot work. Otherwise, it sits for another month until my return.
Once you do an 'xfel jtag' (assuming xfel works...) does it just create an FTDI-like interface on USB that gdbserver or such can connect to without a physical pod? That would be nifty if true because having power + console + another JTAG cable would be a drag.
I would have ordered the new Sipeed board this week (gotta catch 'em all) but I'm holding out for an .100 post version for dupont leads and breadboard instead of that high density connector it uses.
I'll admit I've been off and on with this board, but how many others are just stuck behind the starting line?
RJL
P.S. If anyone has contacts with VisionFive, please send 'em my way. I'd like to confirm that the JTAG/Serial/Blinky GPIO boards I had made still work with the new 7100 board.
Gabe R
Nov 29, 2021, 9:27:41 PM11/29/21
to RISC-V Developer Board Community, rober...@gmail.com, Gabe R, RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org, sam...@sholland.org
Robert,
Glad you got the issue figured out. You'd think Allwinner would have learned from when a nearly identical issue occurred with the Raspberry Pi 4 (https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4-usb-c-issue-in-depth). The only difference is that with the Raspberry Pi, they used one resistor for both CC pins instead of one for each, while Allwinner did not attach anything to the CC pins at all.
I'm also behind the starting line, but that is more because I don't have a lot of experience with the Linux Kernel, and was trying to build from scratch (I thought the kernel repo built a full Fedora system, not just the kernel). Was working on u-boot this week, but then my Laptop died, so its going to be a bit before I can continue.
xfel works. I compiled it for Windows. I was going to dump the NAND flash for examination, but see the above paragraph.
Running xfel jtag should enable the JTAG interface for the D1. JTAG is multiplexed with the SD card socket, so you need some sort of breakout to get access to it, (I know SparkFun sells some) and you won't be able to boot from an SD card.
Running xfel jtag should enable the JTAG interface for the D1. JTAG is multiplexed with the SD card socket, so you need some sort of breakout to get access to it, (I know SparkFun sells some) and you won't be able to boot from an SD card.
Also, there seems to be some mixed messages regarding JTAG comatability. Some Chinese language forums suggest that you need to by a C-SKY CK-Link JTAG adapter, but the Ali T-Head website claims that the C906 supports the standard RISC-V JTAG spec and thus works with the Segger J-Link. Additionally, I noticed when looking at the schematic, that there seems to be a few different JTAG lines, one of which goes to test pads, but the labelling suggests that is only for the DSP.
Robert Lipe
Nov 29, 2021, 11:29:16 PM11/29/21
to Gabe R, RISC-V Developer Board Community, Dusten Sobotta, je...@riscv.org, sam...@sholland.org
On Mon, Nov 29, 2021 at 8:27 PM Gabe R <lockhee...@gmail.com> wrote:
Robert,Glad you got the issue figured out. You'd think Allwinner would have learned from when a nearly identical issue occurred with the Raspberry Pi 4 (https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4-usb-c-issue-in-depth). The only difference is that with the Raspberry Pi, they used one resistor for both CC pins instead of one for each, while Allwinner did not attach anything to the CC pins at all.
"History will teach us nothing" -- Sting
I do remember hearing about that, but that article was posted on the week of a personal tragedy,so I missed the impact that I assume ensued.
" Good, compliant USB-A to C cables should work fine off 2-3A bricks. Most USB2 USB-C cables are not e-marked, so they’ll also work. You just can’t unplug a MacBook Pro from its supplied USB-C brick and cable, and use it "
That's exactly the failure. I'm a Mac user. I surround myself with cables that power my Macs. Since the problem trigger is in the cable, you can't use a Mac-quality power supply, plug it into the Mac itself and expect success. It's really surprising to me that nobody in development unplugged their Chromebook, Mac, or Dell or other USB-C computer into these things before they were shipped even to beta. If they shipped some boards with special cables (mine had none) or relied on developers have PCs with only USB-A to avoid this problem instead of fixing the problem at the root, that's really embarrassing.
So is it just our batch of (prerelease?) boards that are defective? If the resistors were just plain left off, it's clear that some percentage of them should be recalled/replaced.
Between this, the borked factory filesystem, and the floating/stuck serial RX line, I'm done with this board.
As a consumer, how to you defend yourself against such noncompliant implementations? Here we have schematics (at this moment dl.linux-sunxi.org has a routing error... that knowledgeable can check, but consumers should be able to buy tested, compliant devices.
I'm also behind the starting line, but that is more because I don't have a lot of experience with the Linux Kernel, and was trying to build from scratch (I thought
Hopefully this group can help fix the messy system software issue(s) that seemingly expects rebuilding such things to be the norm.
the kernel repo built a full Fedora system, not just the kernel). Was working on u-boot this week, but then my Laptop died,
Looks like you have "u-can't-boot" version. :-)
xfel works. I compiled it for Windows. I was going to dump the NAND flash for examination, but see the above paragraph.
Since mine never shows up in the Mac equivalent of Device Manager, I don't think FEL has a chance.
Running xfel jtag should enable the JTAG interface for the D1. JTAG is multiplexed with the SD card socket, so you need some sort of breakout to get access to it, (I know SparkFun sells some) and you won't be able to boot from an SD card.Also, there seems to be some mixed messages regarding JTAG comatability. Some Chinese language forums suggest that you need to by a C-SKY CK-Link
That's a really weird set of limits. If anyone from Allwinner is listening, please add to the wish list of some clarification documents and products here. Having JTAG on the board (yay!) seems defeated if you have to have yet another proprietary dongle to connect it. We already have collections of FTDI boards, Seggers, and mutations of each.
Is that board something like https://www.sparkfun.com/products/11468 that just allows you to snag D0-D3 and get some help from the chip to move JTAG to the SD's SPI pins? https://linux-sunxi.org/Allwinner_Nezha#JTAG sure doesn't mention hijacking SD pins. It implies that there's some interface on the USB OTG port.
JTAG adapter, but the Ali T-Head website claims that the C906 supports the standard RISC-V JTAG spec and thus works with the Segger J-Link.
I've noticed when Googling for random things that Ali and Allwinner seem to disagree on minor things. It's hard to tell what's intentional, what's a translation issue, and just which team is "right" for any given issue.
Additionally, I noticed when looking at the schematic, that there seems to be a few different JTAG lines, one of which goes to test pads, but the labelling suggests that is only for the DSP.
I'd attributed that to remapping. (That was something I was quite involved with on J7100.) J7110 has this feature that works quite well for "normal" systems-level debugging, but that probably works poorly for debugging the bottom levels of cold boot. BL602 has a very similar system. ALL the I/O pins (GPIO, JTAG, UART, etc.) go through a giant multiplexor. You can put the 4 JTAG pins on (almost) any pin that's probably labeled "GPIO".
This has a few downsides.
J7100 booted with a crazy mixture of GPIO pins driven as outputs instead of floating, meaning your attached THING might get power dumped to it for a while during boot.
Pre-boot software that configured RAM and such had to be responsible for putting JTAG where you wanted it. This means your device has to be trusted to fetch and run a couple of opcodes before you'd get that bootup blink that arranged the pins that make system debugging practical.
I appreciate your help, but this board is really on my "do not recommend" list until some of these issues are designed away.
Allwinner/Sipeed/Alibaba, are you listening to these conversations?
RJL
Gabe R
Nov 30, 2021, 12:49:51 AM11/30/21
to RISC-V Developer Board Community, rober...@gmail.com, RISC-V Developer Board Community
Sorry for not using quotes, they never work right for me.
I'm pretty confused that you did not get USB cables. I got 2 USB-A to USB-C cables, 2 power bricks, and a counterfeit FT232 serial adapter in mine. I would have thought that Allwinner would send everyone the same kit.
The schematic from Allwinner (which is what sunxi has as well), does not show that the CC resistors are unpopulated, but they do not exist at all. Allwinner did not bother to read the USB-C spec, or research other SBC that use USB-C. This might not be entirely accuratre though. The schematic is labelled for hardware V1.0, while my Nezha says V1.1 on it.
The adapter you linked to on SparkFun is for a full size SD card, but that is the sort of adapter I was talking about. A shocking number of Allwinner chips put JTAG and SDMMC on the same pins.
I think the D1 has some multiplexing, but it is not comprehensive. So you are limited on what pins can do what. I think the only other JTAG pins are the RGMII Pins, which are used for the Ethernet adapter.
From what I have read, there is not any built-in JTAG debugger for the D1. xfel jtag tells the D1 to disable the SDMMC bus and switch those pins over to JTAG. You would then run OpenOCD (which is what is mentioned on the sunxi page) on your development computer, with a JTAG adapter plugged into the the D1. You need a second processor to act as the JTAG debugger, (or a second CPU core, like on the RP2040) and as far as I can tell, there is not one on the Nezha for that. Maybe you could write some code to run on the HiFi DSP that is in the D1 to make it a debugger for the RISC-V Core, but I don't know for sure.
The example on the sunxi page appears to be connecting using a JATAG debuger from Sipeed (specifically https://www.seeedstudio.com/Sipeed-USB-JTAG-TTL-RISC-V-Debugger-ST-Link-V2-STM8-STM32-Simulator-p-2910.html). If openOCD can connect to the D1, then that means that the C-SKY CK-Link is not required to connect to the D1. That Specific debugger is based on the FTDI 2232H (a fancier version of the FT232 UART Chip that essentially has hardware-accelerated bit-banging, and has two channels). I suspect that means that a Segger J-Link will work with the D1 as well. Segger does not have support for the D1, so we would need to create a custom configuration for it.
There are quite a few really nice FT2232H JTAG adapters on the market for dirt cheap. I have the ESP-PROG from Espressif since it breaks out the second channel as a UART port.
I realized that I have a spare monitor and a Raspberry Pi lying around, so I am going to try to use that to dump the NAND flash from my D1. It is pretty much unchanged from when I got the board, other me me disabling the blinking green LED since it was driving me nuts. Maybe we can figure out a bit more about how to interface with this thing from a flash dump.
Robert Lipe
Nov 30, 2021, 2:44:47 AM11/30/21
to Gabe R, RISC-V Developer Board Community
On Mon, Nov 29, 2021 at 11:49 PM Gabe R <lockhee...@gmail.com> wrote:
Sorry for not using quotes, they never work right for me.
They're hard on mobile. I'm on a real computer so they're easy for me. This conversation is "hot" (I don't have to research back six weeks to figure out the context of what you said an hour ago) so this is all great!
I'm pretty confused that you did not get USB cables. I got 2 USB-A to USB-C cables, 2 power bricks, and a counterfeit FT232 serial adapter in mine. I would have thought that Allwinner would send everyone the same kit.
Not a stitch. A box in a box, some brass standoffs, a circuit board.
Confusing, indeed. Two bricks? Maybe you got my brick and power cable. :-)
The schematic from Allwinner (which is what sunxi has as well), does not show that the CC resistors are unpopulated, but they do not exist at all. Allwinner did not bother to read the USB-C spec, or research other SBC that use USB-C. This might not be entirely accuratre though.
[ CENSORED ] [ Unicode table flip ]
The schematic is labelled for hardware V1.0, while my Nezha says V1.1 on it.
D!_DEV_DDR3_16X2_V1_2
I know there is at least one Allwinner employee in this group, since he emailed back and forth
Hopefully, he takes a whole laundry list of TODOs from this exercise.
However, Allwinner has a history of refusing to work with the open source communituy (they also like to violate the GPL,
There's a reason why I never heard of FEL until recently. As a hobbyist, I usually vote with my checkbook and more importantly, my time. I've remembered Allwinner not playing particularly nice for a long time. I'd hoped that Alibaba being a top-level RISC-V member would have the processor more compliant and that Allwinner's presence in this group would be putting forth their best foot forward for the developer community.
they have a hiostory of very poor kernel support. (They tend to release the chip with a single modded kernel version, and then leave the community to figure
The contrast in the amount of work visible on this list and progress of upstreaming things between Nezha and BeagleV is stark.
The adapter you linked to on SparkFun is for a full size SD card, but that is the sort of adapter I was talking about. A shocking number of Allwinner chips put JTAG and SDMMC on the same pins.
Oops. I almost sank that battleship. Is (the micro SD version of) that what you're using? [ Answered later: no. ] So "SD Sniffer" is the magic phrase here to Allwinner JTAG joy? It's just a contract that you have to pull the SD card out of circuit to prevent the card from reacting to the JTAG signalling?
From what I have read, there is not any built-in JTAG debugger for the D1
https://linux-sunxi.org/Allwinner_Nezha#JTAG implies it exists, but skates right over the physical details. I even inventory that very BL702 JTAG board. (RISC-V board for < $4!)
Seems to me that if you're building a comm protocol for FEL, you could do it over something that looks like an FT232 itself. In my imagination, that would eliminate the need to do weird stuff with SD and have an external FT232(clone). Of course, this remains in my imagination since I can't get FEL to show any device at all to the host. (I tried on x86 Macbook Pro, too...)
. xfel jtag tells the D1 to disable the SDMMC bus and switch those pins over to JTAG. You would then run OpenOCD (which is what is mentioned on the sunxi page) on your development computer, with a JTAG adapter plugged into the the D1. You need a second processor to act as the JTAG debugger, (or a second CPU core, like on the RP2040) and as far as I can tell, there is not one on the Nezha for that. Maybe you could write some code to run on the HiFi DSP that is in the D1 to make it a debugger for the RISC-V Core, but I don't know for sure.
Putting it on SD seems such a weird choice. It's odd enough that I've not heard of any board doing it. (That doesn't mean none such exist, of course. I'm learning a lot here!) Maybe it's common enough that the Sunxi folks don't even bother to mention the physical embodiment of all this. Funny how perspectives can be so different.
The "second processor" is basically the easy way to clone an FTDI232 these days. SiPeed also makes a $2-ish version that uses some really tiny core for the bitbanging in JTAG. I can't remember if it's reprogrammable or not.
It's kind of annoying for Sipeed to make a $4 board that plugs into a $10 board to debug their $100 board...that has two USB ports already on it. :-(
The example on the sunxi page appears to be connecting using a JATAG debuger from Sipeed (specifically https://www.seeedstudio.com/Sipeed-USB-JTAG-TTL-RISC-V-Debugger-ST-Link-V2-STM8-STM32-Simulator-p-2910.html).
I stock those, too.
I also stock the SiPeed version on the bottom price point that's a really humble core that also emulates the FT232.
If openOCD can connect to the D1, then that means that the C-SKY CK-Link is not required to connect to the D1. That Specific debugger is based on the FTDI 2232H (a fancier version of the FT232 UART Chip that essentially has hardware-accelerated bit-banging, and has two channels). I suspect that means that a Segger J-Link will work with the D1 as well. Segger does not have support for the D1, so we would need to create a custom configuration for it.
I've run my Segger Mini on new and unknown RISC-V cores. Sometimes it takes some coercion to skip over parts of the JTAG equivlant of the device descriptor and it (obviously) doesn't know the CPU-specific CSR names, but I've been able to get them to work.
But we can be pretty sure that the chip maker has run JTAG internally during development. We shouldn't be blazing any paths here.
Allwinner, please work with the likes of Segger and OpenOCD to get these devices supported and document the physical side.
There are quite a few really nice FT2232H JTAG adapters on the market for dirt cheap. I have the ESP-PROG from Espressif since it breaks out the second channel as a UART port.
If you crack open the Sipeed unit you linked above, it's an FT2232 (or a clone) internally. It's what all the Sipeed boards ($2 Lite, $4 Plus, $10 STM8/STM32/STLink ) above are emulating. (BTW, A special thanks to Sipeed for using a unique pinout on all three of them, zero of which match the RISC-V recommended pinout...) Ditto for Pine64 making yet another device with yet another pinout. I think they're using the real FTDI part, but mine is hiding right now.
But, yes, that's the kind of thinking I'm looking for. I don't want to manage a bunch of wires and hubs for a serial port AND a JTAG port AND an FEL port AND power.
I realized that I have a spare monitor and a Raspberry Pi lying around, so I am going to try to use that to dump the NAND flash from my D1. It is pretty much unchanged from when I got the board, other me me disabling the blinking green LED since it was driving me nuts. Maybe we can figure out a bit more about how to interface with this thing from a flash dump.
That sounds like an interesting project. It would be interesting to see how D1 compares to everything else and just how much Allwinner secret sauce is added. My GUESS is that the NAND will look like a PC partition table, sometimes with different filesystems inside them. You have to be able to update ddr/spi, OpenSBI, and FreeBSD partition, , after all.
Good luck!
RJL
Peter Gutmann
Nov 30, 2021, 3:33:26 AM11/30/21
to Robert Lipe, RISC-V Developer Board Community
Robert Lipe <rober...@gmail.com> writes:
>As a consumer, how to you defend yourself against such noncompliant
>implementations?
In their defence, we did volunteer to be the guinea pigs for this thing... in
any case so far the hardware bugs haven't been anywhere near as bad as the
ones the Pi had.
Peter.
Jonathan Carter
Nov 30, 2021, 3:52:44 AM11/30/21
to devboard-...@riscv.org
On 2021/11/30 10:33, Peter Gutmann wrote:
> In their defence, we did volunteer to be the guinea pigs for this thing... in
> any case so far the hardware bugs haven't been anywhere near as bad as the
> ones the Pi had.
Yep, I don't have one of these boards but that's pretty much how I
> In their defence, we did volunteer to be the guinea pigs for this thing... in
> any case so far the hardware bugs haven't been anywhere near as bad as the
> ones the Pi had.
understood it as well.
My suggestion is that there's some page somewhere that describes all
current known issues so that people working with the boards don't have
to re-learn all its issues from scratch each time.
-Jonathan
Denis Ovsienko
Nov 30, 2021, 8:27:10 AM11/30/21
to devboard-...@riscv.org
On Tue, 30 Nov 2021 10:51:20 +0200
Jonathan Carter <j...@debian.org> wrote:
> My suggestion is that there's some page somewhere that describes all
> current known issues so that people working with the boards don't
> have to re-learn all its issues from scratch each time.
The best place to record hardware-specific quirks seems to be this:
Jonathan Carter <j...@debian.org> wrote:
> My suggestion is that there's some page somewhere that describes all
> current known issues so that people working with the boards don't
> have to re-learn all its issues from scratch each time.
https://linux-sunxi.org/Allwinner_Nezha
The best place to record firmware/OS/software-specific quirks seems to
be this: https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
--
Denis Ovsienko
Jeff Scheel
Nov 30, 2021, 8:48:30 AM11/30/21
to Robert Lipe, RISC-V Developer Board Community
Hey, Robert, I have an extra board in the box with contents that match Gabe's description. If you'd like, I'd be happy to send it to you. Drop me a direct email if you're game to try it.
-Jeff
--
Jeff Scheel (he/him/his)Linux Foundation, RISC-V Technical Program Manager
Gabe R
Nov 30, 2021, 9:45:29 PM11/30/21
to Jeff Scheel, Robert Lipe, RISC-V Developer Board Community
Ok. Hopefully I can get quotes working, and this goes to the right people.
The schematic is labelled for hardware V1.0, while my Nezha says V1.1 on it.D!_DEV_DDR3_16X2_V1_2
I checked again, I was mistaken. That is what I have as well.
The sniffer that you linked should work (no promises though). I might order one for myself.
It's just a contract that you have to pull the SD card out of circuit to prevent the card from reacting to the JTAG signalling?
I believe so
https://linux-sunxi.org/Allwinner_Nezha#JTAG implies it exists, but skates right over the physical details
I'm not sure where you are seeing this to be honest. All I see suggests that you will still need an external adapter. Can you point me towards where you are seeing that in more detail?
Putting it on SD seems such a weird choice. It's odd enough that I've not heard of any board doing it. (That doesn't mean none such exist, of course. I'm learning a lot here!)
I think it is common on Allwinner boards, which are fairly rare these days as most companies have switched to Rockchip or Mediatek based boards (Orange Pi and Pine64 to name a couple)
See these pages on the Sunxi Wiki. They apply to other Allwinner boards, but might be valid for the D1 too.
I think they're using the real FTDI part
Couple of tests that will quickly establish if ou have a counterfeit. Proving it is real is much harder.
- Try to change the information of the EEPROM of the FTDI chip. You can use FT Prog on Windows, and there is a CLI program on Linux that I can't remember the name of. Be careful what you change, as some options break things. I would suggest just change the product name. If after changing it and unplugging and plugging the device back in, the old data is still showing up, it's fake.
- Google the serial number. If you find people in forums with the same serial number, it is fake.
I don't want to manage a bunch of wires and hubs for a serial port AND a JTAG port AND an FEL port AND power.
FEL runs over the USB-C OTG connector (The one next to the serial port), which also can power the board from a laptop USB port at the same time, so you will probably have FEL and JTAG.
My GUESS is that the NAND will look like a PC partition table
IIRC NAND normally does not use a partition table (such as MBR or GPT), the filesystems are placed raw on the NAND (this is not an Allwinner thing, but a NAND thing). I managed to dump the contents last night and will create a new thread with a report on it in a little bit.
The best place to record hardware-specific quirks seems to be this:
https://linux-sunxi.org/Allwinner_Nezha
The best place to record firmware/OS/software-specific quirks seems to
be this: https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
Once I am more sure of what I have figured out, I will probably put stuff on the sunxi page.
[ CENSORED ] [ Unicode table flip ]
Ha. Here you go. Might be worth saving it.
(╯°□°）╯︵ ┻━┻
Peter Gutmann
Jan 21, 2022, 12:00:02 PM1/21/22
to Gabe R, RISC-V Developer Board Community, rober...@gmail.com
Gabe R <lockhee...@gmail.com> writes:
>I'm pretty confused that you did not get USB cables. I got 2 USB-A to USB-C
>cables, 2 power bricks, and a counterfeit FT232 serial adapter in mine. I
>would have thought that Allwinner would send everyone the same kit.
I finally got mine (it got caught up at the University when we went into
lockdown, which was then followed by the summer break), and can confirm that
it's a counterfeit FTDI cable. One giveaway is that it doesn't actually work,
after endless messing around with baud rates and whatnot in case the board had
somehow been set to something other than 115200 I tried it on another device
and it didn't work there either, while a genuine FTDI cable did. So first
thing is, toss the included cable and use a known-good one.
Now to figure out how to boot Fedora on it... is
fedora-riscv64-d1-developer-xfce-rawhide-Rawhide-20220104-012902.n.0-sda.raw.zst
the way to go?
Peter.
Reply all
Reply to author
Forward
0 new messages