RISCV Mainboard Schematic/Block Diagrams

Framework Laptop 13
,
1

I just got my DeepComputing RISCV Mainboard in the mail, my main goal being messing around with the hardware itself. I noticed there are no published block diagrams, schematics, or pinouts for the DC RISCV Mainboard, do we know when those will be published?

In particular, I was curious about a few things.

There are three flat flex connectors on the bottom right of the board, right next to the keyboard connector. There’s an unpopulated tact switch footprint as well. Given their proximity to (what I assume) is the STM32 based system management controller, are those connectors/buttons for debugging and flashing the STM32?

I also wanted to attach a JTAG debugger to the main StarFive SoC. I see some pads directly underneath the SoC that look suspiciously like TDI, TDO, TCK, TMS, and GND (and maybe VREF). Will there be any documentation on debug ports into the StarFive SoC?

I tagged this with the 13 inch AMD tag because there doesn’t seem to be one for the DeepComputing Mainboard yet.

4 Likes
2

Sorry op to ping you with a notification for nothing, but I literally signed up to say the same thing.

I just got the riscv mainboard too, and I’m also very curious about board schematics. Obviously I could look up each little microcontroller, but I’d prefer if there was just straight up documentation on it. Not to mention the connectors that OP mentioned - what sort of interface are they? What’s the pinout? How would it be exposed to the OS?

There’s also a few seemingly unpopulated solder points on the board - with one side clearly marked as the positive pole. Why are these there?

Unlike a pi or an arduino or something, this board wasn’t exactly cheap. I don’t want to risc (ha) frying something just playing with it.

Personally, I’m already disappointed that multiple parts of the firmware for it are proprietary- including the graphics driver, probably the absolute biggest letdown - but if we don’t even know what everything on the mainboard is, it feels kind of silly to call it a developers board. The entire point of the board is to help push riscv adoption along and get it in the hands of people who can work towards that end - at least, that’s what it’s marketed as - so it would be disappointing if it ends up being just another black box.

People support riscv because it’s supposed to be a more open platform. I know a lot of companies just look at it as a way to create a CPU without royalty fees for the ISA, but the only people who are going to buy this are largely FOSS nerds.

Sorry if this comes off as hostile. Honestly, I’m very excited for riscv to start being worked on more seriously. I just don’t want it to end up like ARM, where it was sold to people as a simpler ISA that wasn’t beholden to the x86-64 licensing BS, but just ended up creating insane fragmentation and a million different completely undocumented chipsets and boards that are borderline unserviceable. Because if that’s the direction it heads in, then what’s the point of using it over ARM? Might as well just use the more developed architecture, right?

2 Likes
3

Ask them?
Contact form is here About us - DeepComputing

No block diagram or schematics on their github. But they did just add something 3 days ago. Maybe they just haven’t put together everything for release yet.

1 Like
4

Is anyone able to test to see if the RISCV board supports CCD (closed case debug). On the FW13 and FW16 you can plug a CCD into the back right usb slot and get console output from the EC.

5

Did you look at their github? There is a guide on using their serial port debugging connection which is available via one of the USB-C ports.

1 Like
6

There is a tag for the RISC-V mainboard now!

1 Like
7

I grabbed a couple of StarFive VisionFive boards from a coworker. These use the same SoC as the framework mainboard and are the reference design for the SoC. While I don’t have the framework mainboard in front of me right now, I recall a lot of similarities between the VisionFive boards and the framework mainboard. From memory, they both have the exact same DDR chip (same vendor even) and bank of two SMD dip switches. On the VisionFive, the dip switches control the boot medium (qspi, sdcard, sdio, nvme) and I bet they do the same thing on the mainboard. I’ll mess around with them tonight when I get home and document what I find. Perhaps there’s an unpoplated qspi pad on the board that I can populate.

Not knocking deepcomputing for using the ref design by the way, thats what it is for!

8

The Framework mainboard sure does look a lot like the StarFive VisionFive 2 board. We can probably learn a lot about the mainboard by referencing it. Here are some of the similarities:

  1. Exact same DRAM. Same vendor and everything. If this was a major vendor (Micron, Samsung, SK Hynix, etc) this wouldn’t be weird, but I have literally never heard of this company before (Biwin). Maybe they are popular in China.
  2. Both have a pair of DIP switches to control the boot medium. Presumably, the Framework mainboard will support booting from NVMe and QSPI at some point, like the VisionFive.
  3. Both have very similar QSPI chips, 128Mbit Flash from Gigadevices. On the Framework this is a WSON package and will be very hard to read externally. It probably mounts in Linux as a block device (I haven’t actually booted my board up yet)
  4. Same PMIC, the APX105060.

Honestly I kind of just want to flash the StarFive VisionFive image to this mainboard and see how far it gets in the boot process.

1 Like
9

Since you mentioned not having booted it yet, and not having looked at the available devices, I made a gist of various hardware info commands, run on the Fedora image they provide

I also posted on their github asking for board schematics for this board

Note that I put a random EMMC module I had at home in it. I bought it YEARS ago for my odroid xu4. I was largely curious. If there’s any tests you’d like me to run related to EMMC, let me know!

2 Likes
10

Be careful with that eMMC module! If I am remembering correctly, Hardkernel rolled their own pinout instead of using the standard one that everyone else uses. I did some cursory searches to try to find something to back that up but didn’t come up with anything (I remember reading it in a bunch of Amazon reviews).

I’m not sure if the QSPI flash on the board would actually come up as a block device. It might just be mapped to something in /dev/. Thank you for the gist! There’s probably some good info in there, just need to go through it.

1 Like
11

Another thing for those curious about JTAG like me: it sounds like you can map the JTAG pins to any arbitrary GPIO on the SoC. You can do this in a low stage bootloader or somewhere in GRUB I think. My point is, if deepcomputing did not actually port out the standard JTAG pins to some pad on the board, you can redirect them to a different GPIO that is exposed.

This info comes from a friend, need to read the StarFive datasheet to confirm and actually implement it (if it’s needed).

12

I’ll keep that in mind about the EMMC. I do know that they did have this whole thing about “only use this EMMC with this board.” When I get home and can get back into the chassis, I can get the exact model of the module.

I will say that I was successfully able to dd zeros over it and then create a new partition table (the odroid needed a protected special read only partition in the first few kilobytes of the disk for the bootloader, which partition managers don’t particularly love). I formatted it as ext4, it mounts just fine. Doing a dd of /dev/random to a file on the EMMC module results in a throughput of around 25-30MB/s… which isn’t great, but it’s a product of its time.

13

Nice! It sounds like I was wrong then. I have an eMMC module from the odroid too, that will be a fun thing to play with.

14

Interestingly, it seems like DC went with so much of the VisionFive 2 design (beyond just the JH7110 SoC) that it actually self-reports as the VF2 in several Linux fetch programs.

15

I uses a 256G module from orange pi and it did got recognized correctly. The speed is about 30-60% faster (roughly 30MiB/s to 40 MiB/s sequential and 4 to 6MiB/s 4k random) ( compares to a 200/150 MiB/s, 4000,2000 iops rated microSD card) . Still did not got it to boot from the eMMC yet. Tried to clone the OS from micro SD but did not work. I’ll try just DD the image to the eMMC card next

16

@kaybarkbark @Yufei_Pan

EUREKA! I flipped both dip switches (bottom left from the sd card slot) to the right (towards 3 and 4) and it boots from an EMMC! You’ll have to make sure to actually image the EMMC properly (I tried copy/pasting the partitions but that wasn’t enough).

My next goal is to see if I can get it so the EMMC just holds GRUB/a bootloader, and bthen have the root partition/kernel all be on a USB device. I imagine that will work out, but, one thing at a time! It’s already quite late where I live haha

2 Likes
17

OHhhh
thanks a lot! didn’t notice that before (actually spent 5min with a flashlight even after you tip )
I actually just managed to mount the root at emmc while the boot loader stay in the sd… well good knowing that there is a dip switch, might use that after all.
I was going to use a 32G low capacity microcenter free sd card as the esp / boot / boot/efi partition and mount / to the emmc for more performance but might not be necessary now.
But my steps should be helpful if you want to use usb drive for root:

  1. modify /etc/fatab to add read only option. this is done by modifying the first line (the one with / entry), add a ,ro option to the fourth field. reboot the system to boot into read only mode.
    (LABEL=cloudimg-rootfs / ext4 discard,commit=30,errors=remount-ro,ro 0 1)
    (i have already removed gnome desktop and use systemctl set-default multi-user.target to boot into text mode by default, so I am not sure can you still use gnome or not with ro mode root, but you can switch to a different tty if gnome crashes (ctrl alt f3))
    (this is done so systemd etc uses read only root mode allowing us to clone the current live system)
  2. create the new root with another drive, format it to ext4 or btrfs (mkfs -t ext4)
    (it appears in the fedora kernel at least it was not compiled with xfs support)
    (but xfs utils were pre installed… so you can make one but not mount it…)
  3. label the file system something unique, like fedora-riskv-laptop
    (e2label or btrfs filesystem label )
  4. use mount -o remount,rw / to remount the fs to read write, we need to modify some files first.
  5. change the partition label (name) to root (same as the image). Although I doubt this is needed but just in case.
    (you will need a tool to do so, I use gdisk)
  6. use blkid to find the new partition (and old) uuid, labels etc
    (you will need the new fs uuid and label noted somewhere or open multiple sessions, ssh or tty)
  7. modify /boot/grub/grub.cfg:
  8. – search and replace all occurrences of cloudimg-rootfs (old label) to the new label you made (like fedora-riskv-laptop)
  9. – search and replace the old fs uuid (1e0435f2-7cd6-41c5-bd72-655d5d5f124c) with the new one
  10. modify /etc/fstab:
  11. – replace LABEL=cloudimg-rootfs with LABEL=<new label>
  12. modify /etc/kernel/cmdline:
  13. – replace root=UUID=1e0435f2-7cd6-41c5-bd72-655d5d5f124c with root=UUID=<new uuid>
  14. mount -o remount,ro / to remount the root fs to read only, we are now trying to clone to the new drive
  15. mkdir /tmp/oldroot
  16. double mount the old root partition to /tmp/oldroot
    (ex. mount /dev/mmcblk1p4 /tmp/oldroot)
    (This is done so we do not have to worry about virtual fs like /proc /sys /dev /run etc)
  17. mkdir /tmp/newroot
  18. mount the new root partition to /tmp/newroot
    (ex. mount /dev/mmcblk0p1 /tmp/newroot)
  19. use your favorite copy tool to clone the old root to the new root
    (I will recommmend stick to the simple cp -a /tmp/oldroot/* /tmp/newroot/ )
    (I personally use hpcp /tmp/oldroot -d /tmp/newroot, hpcp · PyPI, but we don’t really need it for this simple imaging)
  20. Optional: change your /tmp/newroot/etc/fstab to remove the ,ro option to let the system boot into read write mode by default.
  21. It will be a good idea to umount both /tmp/oldroot and /tmp/newroot first to ensure data was actually written.
  22. reboot and hope.
  23. If you succeed, you can also now remove the oldroot’s extra files (everthing that is not in boot) ( or leave them there )
    (you will still need your old partition as the efi will boot into that partition and use contents in boot to load the linux kernel etc.)
  24. Your kernel will still be loaded from the old partition. If you want the old partition to mount at /boot as convention, you can modify /etc/fstab to do so.
    ( you need to mount the old partition to some other mount point like /mnt/old_root, then bind mount /mnt/old_root/boot to /boot)
    ex.
    LABEL=fedora-riscv / ext4 discard,commit=30,errors=remount-ro 0 1
    UUID=1e0435f2-7cd6-41c5-bd72-655d5d5f124c /mnt/old_root ext4 discard,commit=30,errors=remount-ro 0 1
    /mnt/old_root/boot /boot none bind 0 0
    LABEL=UEFI /boot/efi vfat umask=0077 0 1

Would love to go how it went! probably the external drive for root idea is best as the pretty abysmal performance for both the emmc and sd card…

18

I was able to get it to run from USB yeah. I discovered it was mounting using labels on accident, and switched it to UUIDs. I use arch (btw), so I’m used to configuring my fstab with UUIDs. Anyhow, I now have it using the emmc for uboot/grub then booting the root dir from USB. There is a noticeable speed increase. It’s still not good, but it’s noticeably better.

Honestly, I don’t love that all we have to work with is SPL → uboot, it’s… not great. Using any other linux OS will basically need to come down to making an install, then bringing over the boot dir from one of the current images - because running linux on uboot is hacky.

I knew what I was getting in to when I bought this to be fair, but it would be a nice if I wasn’t forced to use whatever images they decide to release on their schedule.

19

I’ve done a bit of digging/inspecting, and some preliminary results I’ve discovered are thus:

I believe it is using a Gigadevice 25LQ128E variant for its BIOS flash memory - 128Mbit
There’s a Lontium LT6711A HDMI to DP converter
It uses an Asmedia ASM1074 for USB3.2
There’s also a slimport ANX7447 for usb switching
The PMIC is the AXP15060

Some of this stuff is listed in their DC ROMA reference board schematics

Seems as if on the Roma, they may have had built in wifi that went over USB?

There’s multiple other chips on there as well, like two USB2 hub chips that I believe are probably split with 1 for camera/mic and 1 for touchpad and keyboard, could be wrong on that though. This is once more why the schematics would be nice.

Honestly, half of this stuff isn’t particularly useful, though if that GigaDevice is indeed where it stores the boot related firmware, that is interesting for me. I would LOVE to mess around with that in the future.

Sadly though, no real leads on the actual headers on the boards. @kaybarkbark, I see you posted on the github too. Hopefully they throw us a bone haha.

2 Likes
20

Lots of great progress here! Kuroi I think your comment on their GitHub is worded much better lol. I am very direct.

I am excited to give the eMMC boot a try. I haven’t done much, but I played around with the board tonight a bit and found out a couple things.

I have a PINETAB-V machine that uses the same SoC, and the accompanying UART board to go with it. I discovered that the PINETAB-V does UART debug the same way, with the UART coming over the SBUx pins on USB-C. I just had to flip the TX and the RX, conveniently this was just bridging a couple jumpers with solder (see pictures). I wonder if this way of getting UART out of the machine is recommended in the datasheet or something.

photo_2025-02-18_00-41-57
photo_2025-02-18_00-41-57720×1280 177 KB

photo_2025-02-18_00-42-02
photo_2025-02-18_00-42-02720×1280 170 KB

I also tried to boot the system with the same image that the VisionFive 2 uses, and it booted up until it tried to load the DTB, where it failed. Makes sense honestly, the DTB is for totally different hardware.

U-Boot SPL 2021.10 (Sep 19 2024 - 15:43:53 +0800)
LPDDR4: 8G version: g8ad50857.
Trying to boot from MMC2

OpenSBI v1.2
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|___ /_____|
        | |
        |_|

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 4000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform PMU Device       : ---
Platform Reboot Device    : pm-reset
Platform Shutdown Device  : pm-reset
Platform Suspend Device   : ---
Firmware Base             : 0x40000000
Firmware Size             : 392 KB
Firmware RW Offset        : 0x40000
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 1
Domain0 HARTs             : 0*,1*,2*,3*,4*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff M: (I,R,W) S/U: ()
Domain0 Region01          : 0x0000000040000000-0x000000004003ffff M: (R,X) S/U: ()
Domain0 Region02          : 0x0000000040040000-0x000000004007ffff M: (R,W) S/U: ()
Domain0 Region03          : 0x0000000000000000-0xffffffffffffffff M: (R,W,X) S/U: (R,W,X)
Domain0 Next Address      : 0x0000000040200000
Domain0 Next Arg1         : 0x0000000042200000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes
Domain0 SysSuspend        : yes

Boot HART ID              : 1
Boot HART Domain          : root
Boot HART Priv Version    : v1.11
Boot HART Base ISA        : rv64imafdcbx
Boot HART ISA Extensions  : none
Boot HART PMP Count       : 8
Boot HART PMP Granularity : 4096
Boot HART PMP Address Bits: 34
Boot HART MHPM Count      : 2
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109


U-Boot 2021.10 (Sep 19 2024 - 15:43:53 +0800)

CPU:   rv64imacu_zba_zbb
Model: StarFive VisionFive V2
DRAM:  8 GiB
MMC:   sdio0@16010000: 0, sdio1@16020000: 1
Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
StarFive EEPROM format v2

--------EEPROM INFO--------
Vendor : StarFive Technology Co., Ltd.
Product full SN: FML13V01-2451-D008EC00-00000313
data version: 0x2
PCB revision: 0xb2
BOM revision: A
Ethernet MAC0 address: 6c:cf:39:6c:de:ad
Ethernet MAC1 address: 6c:cf:39:7c:ae:5d
--------EEPROM INFO--------

In:    serial
Out:   serial
Err:   serial
Model: StarFive VisionFive V2
Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
Hit any key to stop autoboot:
starting USB...
No working controllers found
Scanning mmc 1:3...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1414 bytes read in 7 ms (197.3 KiB/s)
U-Boot menu
1:	Debian GNU/Linux trixie/sid 6.6.20-starfive
2:	Debian GNU/Linux trixie/sid 6.6.20-starfive (rescue target)
3:	Debian GNU/Linux trixie/sid 5.15.0-starfive
4:	Debian GNU/Linux trixie/sid 5.15.0-starfive (rescue target)
Enter choice: 1:	Debian GNU/Linux trixie/sid 6.6.20-starfive
Retrieving file: /initrd.img-6.6.20-starfive
14366058 bytes read in 626 ms (21.9 MiB/s)
Retrieving file: /vmlinuz-6.6.20-starfive
9528895 bytes read in 417 ms (21.8 MiB/s)
append: root=/dev/mmcblk1p4 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0
Retrieving file: /dtbs/6.6.20-starfive//boot/dtbs/starfive/jh7110-starfive-visionfive-2-framework.dtb
Failed to load '/dtbs/6.6.20-starfive//boot/dtbs/starfive/jh7110-starfive-visionfive-2-framework.dtb'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
   Uncompressing Kernel Image
Device tree not found or missing FDT support
### ERROR ### Please RESET the board ###

Tried to boot with the PINETAB-V image too, but it failed immediately with

BOOT fail,Error is 0xffffffff

Finally, I designed a couple PCBs to aid in reverse engineering/debugging. I made a passive eDP to Displayport adapter (cause I can’t get thunderbolt to displayport working for some reason) and my own version of the UART debug board. Ordered them through PCBWay and hope to have them both by the end of the week. If they work, I’ll put them both on a git repo somewhere.

Screenshot from 2025-02-18 00-35-55
Screenshot from 2025-02-18 00-35-551393×1106 145 KB

Screenshot from 2025-02-18 00-35-17
Screenshot from 2025-02-18 00-35-171507×992 123 KB

Has anyone read the QSPI chip yet? Usually I just read these externally, but the WSON package makes this super hard. I am sure there’s a way to read it through Linux.

1 Like