Welcome to the new VisionFive Board Projects

[Jeff Scheel]

All,

I'd like to welcome round 3 of our DevBoards into our community -- the VisionFive Boards.  Their boards are presently being shipped to them and I heard of the first ones arriving today.  I don't yet have tracking information for the boards but will pass them along as soon as I get it.  As you receive your VisionFive board, please respond directly back to me to confirm it's receipt.  

Those you are not familiar with the board, can learn more here:

VisionFive Single Board Computer Quick Start Guide | RVspace

To those who are newly added to the community, it serves as my communication vehicle with all projects in the DevBoard Seed program and should be your starting point for getting started and finding help when stuck elsewhere.  As new members, you will have the benefits of two additional programs before you -- one for the D1 Nezha board and one for the Unmatched board. The people on this list are passionate about RISC-V and eager to help.  So, please reach out as needed.

To get started with your StarFive, VisionFive boards, you'll find the board information anchored at rvspace.org which included the following 3 user documents:

• Quick Start Guide - the "Getting Started" section has information about both flashing the SD card but also logging into the pre-configured Fedora image
• Software Technical Reference Manual - provides details about building components of the platform software stack -- SBI, u-boot, kernel, ...
• GPIO Header User Guide - details the technical aspects of the attaching peripherals through the GPIO header

Additionally, VisionFive has started an English forum for their board at https://forum.rvspace.org/c/visionfive/6.  This should be your first stopping place for any problems you encounter while getting started with your board.  (Note: you do have to create an account to participate.)

To my knowledge, I have not found any distro-specific pages yet for the VisionFive board, but here are the generic pages for RISC-V which may be helpful:

• Debian for RISC-V:
  https://wiki.debian.org/RISC-V
• Fedora for RISC-V (Unmatched not supported yet):
  https://fedoraproject.org/wiki/Architectures/RISC-V
• openSUSE for RISC-V (Unmatched not supported yet):
  https://en.opensuse.org/openSUSE:RISC-V
• FreeBSD on RISC-V:
  https://wiki.freebsd.org/riscv
• OpenBSD on RISC-V:
  https://www.openbsd.org/riscv64.html
• Zephyr on RISC-V:
  https://docs.zephyrproject.org/latest/boards/riscv/index.html

Note: that this hardware is quite close to the old BeagleV board and thus some legacy documentation may exist.

As you find other links which you think might be helpful, please post them so that others can benefit.  

As you hit roadblocks, have questions, or just want to leverage the wisdom of the community, please reach out with questions.  We are here to help.

-Jeff

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

[Robert Lipe]

On Fri, May 6, 2022 at 1:59 PM Jeff Scheel <je...@riscv.org> wrote:

I'd like to welcome round 3 of our DevBoards into our community -- the VisionFive Boards. 

I have a mystery box arriving via Fedex later today. That could explain that.
 

To get started with your StarFive, VisionFive boards, you'll find the board information anchored at rvspace.org which included the following 3 user documents:

The RVSpace doc is quite good. I still haven't sussed out the relationship between RVSpace and VisionFive, though. RVSpace doesn't make these boards, do they? Aren't they a reseller of boards made by others?   This doc starts a floor or two higher than where we started about this time last year with Starlight. This "Getting started with software" guide is "how to use (or rebuild) a Linux distro" - which is absolutely needed - while a year ago we started with "let's port OpenSBI to JH7100". I'm happy to report THAT doc is also quite good compared to other chips in similar orbit. The chip level doc isn't prominently linked, but for those of us doing OS work StarFive's own chip-level doc at https://github.com/starfive-tech/JH7100_Docs is handy. There are several good repos to explore at https://github.com/orgs/starfive-tech/repositories

If you are doing OS-level work, you need to understand the Cache Coherency TB. RISC-V spec said to not build chips that didn't bus-snoop DMA transfers, but they did. (We were given the impression that 7100 was short-lived and the 7110 would fix lots of the issues we had.) This was a protracted "discovery" the first time around, and the symptoms will make you crazy. You poke the DMAC on an ethernet or USB transfer, you'll get a completion interrupt, but packets won't show up in memory for tens of seconds. Other activity (jiggling your mouse, building GCC, whatever) will make the contents of those packets "suddenly" appear. Oh, and the DMA to your SD card would have the 'wrong' data in it. Your operating system can temporarily sprinkle LOTS of magic calls to poke two registers in the L2 controller to make it DTRT OR explicitly add support for non-coherent ops. For Linux, Emil and others did the work to already upstream that support now. In the beginning, it was a bunch of #ifdef JH7100 / poke registers / memcpy from board#endif style special casing and it wasn't pretty. The current situation in Linux is quite elegant, but this is a trap on this chip waiting for the rest of us building OSes. Be mindful. 

To my knowledge, I have not found any distro-specific pages yet for the VisionFive board, but here are the generic pages for RISC-V which may be helpful:

• Debian for RISC-V:
  https://wiki.debian.org/RISC-V
• Fedora for RISC-V (Unmatched not supported yet):
  https://fedoraproject.org/wiki/Architectures/RISC-V

Fedora was the original bringup vehicle.  A lot of doc went poof when that relationship dissolved, but let's thank our Internet Gods for archive.org. 

https://web.archive.org/web/20210427151250/https://wiki.seeedstudio.com/BeagleV-Getting-Started/

...this may not map exactly to current Fedora and the new board, but there may be some nuggets in there to mine for a new Wiki. (Hint, hint.)

For the Linux kernel itself, much of the work to support these is already upstreamed. https://lwn.net/Articles/872651/ (See that even in October, we were told that JH-7100 was to be short-lived in favor of JH-7110.)  ISTR having reps from many of the other OSes in the original groups

• Note: that this hardware is quite close to the old BeagleV board and thus some legacy documentation may exist.

The original had hazards in the serial comms used. The serial console port was 3.3v. It was MOSTLY compatible with older 5V USB/Serial adapters, but there was one brand (PL2303 maybe?) whose low wasn't low enough to reliable transmit all the characters. It would misreceive bytes with more than N consecutive 0 bits or some such obscure thing. Without a scope, you'd never figure it out. Use 3.3V adapters.

There was something (ddrinit) that had to be sent to the 7100 via Xmodem or Kermit or something directly to pins on the 7100 and not via the console. That was a 1.8V level I/O and attaching a 5V to that resulted in Bad Things. Hopefully, ddrinit doesn't need to be reprogrammed regularly by now. IIRC, the 40-pin was 3.3V and there was a debug header that was still raw 1.8.

Both of these COULD be resolved on the fiberglass by using better level-shifted I/Os to front-end the pins. I've not compared the schematics yet, but I'm pretty sure that "don't use 5V USB Serial" on this generation of board is solid advice.

EDIT: https://github.com/beagleboard/beaglev-starlight/issues/11 seems to capture this. Some digging around in closed issues may be useful.

Once I have a board in hand where I can scope signals and figure out how many times I'd have to turn it to get it right side up again, i'll be checking out "Blinky Toy", a board we made that added buffered LEDs to all the I/Os, extra pins for attaching logic analyers and scope probes, headers for JTAG (2.54 and 1.27 pitch), and serial pins. This isn't an advertisement (at least not yet...) but in case any of you have the urge to build such a board from scratch, buzz me before you do.  Hopefully these should basically work. I received and soldered up the batch like two weeks before Starlight went dark. :-(

My time with this board will be split with two other RISC-V projects I'm working on (BL604 and BL706) but I look forward to getting back to these. They were really nice boards and the SoC and doc was generally pleasant to work with. I look forward to working with all of you. (again?)

RJL

[Jeff Scheel]

The RVSpace doc is quite good. I still haven't sussed out the relationship between RVSpace and VisionFive, though...

 I'm glad you like it.

As I understand the history of the site, StarFive (the maker of the  VisionFive board) created the RVSpace for their boards and are very active in following it.  Thus, as we have suggestions for improvement, I suspect they'll be well received. 

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

[Jeff Scheel]

Commenting on this thread as it appears that somehow I failed to add all of the new VisionFive folks before sending the email.  Doh.

So, new VisionFive members, welcome and checkout the head posting on this thread as a reference for your newly arrived boards:

https://groups.google.com/a/riscv.org/g/devboard-community/c/3w_9bm9pBEE

-Jeff

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

[Richard Brezak]

Hi! I'm Richard, but you can call me Magic I guess (my nickname everywhere is Magic_RB). I've yet to receive my board, when I do I'll let you know. Unfortunately I'm currently right in the middle, actually 2 weeks before the biggest final exam in my life. So I'll be available right after that. It's unfortunate but there isn't anything I can do about it.

Now to the board itself,  I have no experience with porting anything to anything, but as it looks to me, we need to take Fedora and then get it to boot. Then we can reverse engineer that image into a bootable version of NixOS, eventually compiling our own kernel. That's how I'd go about it.

Am I the only one who'll be working on porting NixOS to this thing?

Dne úterý 10. května 2022 v 1:34:23 UTC+2 uživatel je...@riscv.org napsal:

[Daniel Maslowski]

Hi,

I'll be working on porting oreboot (https://github.com/oreboot), based on the preliminary support that we already had for the JH7100 for the Beagle V board. :-)

With that, you can then simply run LinuxBoot (https://linuxboot.org) with u-root (https://u-root.org), so there remains no need for fanciness, as you can then simply boot using well-known mechanisms such as BLS (Boot Loader Spec). Or even simpler, run cpud (https://github.com/u-root/cpu) and do anything with it, no more need for SD cards etc..

Good luck with your exam!

Cheers

Daniel

--
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.

[Felix Yan]

Hi,

Nice to meet you all :)

The board didn't make it to me yet, either. I'll add it to our (Arch
Linux RISC-V) build array and will probably include it in our automated
image generation some time later.

One relevant news is that just yesterday thanks to Houge's experiments,
our current rootfs has been successfully installed and running on the
VisionFive board:

https://forum.rvspace.org/t/starfive-visionfive-v1-archlinux/405
(in Chinese)

--
Regards,
Felix Yan

[Robert Lipe]

On Mon, May 9, 2022 at 10:40 PM Richard Brezak <ric...@brezak.sk> wrote:

it looks to me, we need to take Fedora and then get it to boot. Then we can reverse engineer that image into a bootable version of NixOS, eventually compiling our own kernel.

Fedora is one of many OSes that's already working.  Slurp the December zstd/raw to the provided SD card via  Etcher (or dd or whatever), attach a console (I found that unlike Starlight, the serial console HAS to be on the GPIO pins and not on the pins labeled 'Debug' - it's more than just TX/RX being swapped; it's a different socket) and you're off to the races.

You don't really have to reverse engineer anything. You literally have all the source available to build it.

Actually, you may even have a fast-forward on that. https://github.com/zhaofengli/nixos-riscv64

https://github.com/NickCao/nixos-riscv had jh7100 supported less than two weeks ago and https://github.com/ius/jh7100 is a bit older, having only StarFive and not Vision Five.

Not knowing Nix, but just scanning zhaofengli's tree, it looks at least a serious attempt.


Good luck and enjoy!

RJL

[Richard Brezak]

You're ruining all the fun :( looking at sources is boring. Looking at the build product is way more fun

Dne úterý 10. května 2022 v 12:34:06 UTC+2 uživatel rober...@gmail.com napsal:

[Robert Lipe]

On Tue, May 10, 2022 at 5:25 AM Felix Yan <felix...@archlinux.org> wrote:

The board didn't make it to me yet, either. I'll add it to our (Arch
Linux RISC-V) build array and will probably include it in our automated
image generation some time later.

Felix, if you have more virtualization space than slots for boards (and power and ethernet and JTAG and serial and...) an option that's handy for automated tests is Renode.io.

https://renode.io/news/Linux-on-BeagleV-Starlight-in-Renode/

That would emulate Starlight and not VisionFive. They differ in things like the NIC and USB but some of the OSes so far (Fedora) are just supporting both at the same time from the same boot image. 

For an OS where you need to build and retest user space on a frequent basis that may be more convenient than doing it on a large SBC/small desktop class computer. You'll need both at some point, but Renode is a good trick to have in the bank.

Richard Brezak said:
> You're ruining all the fun :( looking at sources is boring.

I am the killer of fun. :-) If your kink is reverse engineering, Ghidra has a RISC-V target that works well. Go nuts.

RJL

[Gerald Normandin Jr]

Hello all!

My name is Gerry, and I’m glad to be part of this group. I’m currently finishing my MS studies, finals next week and a capstone requirement in two months. Going to be busy, but wish me luck!

 Looking forward to trying our ROS on VisionFive and possibly some security related work in the near future after that. (I also have a D1 based board on the way… been waiting a while for that one) So far, I’ve been able to boot Ubuntu 22.04 using the image (not my work) available at this link

https://forum.rvspace.org/t/ubuntu-22-04-lts-has-a-risc-v-version-anyone-got-this-running-on-visionfive-v1/339/39

Note: I highly recommend growing the / LVM volume to fill your SD!

Anyway that’s as far as I’ve had time for thus far, looking forward to reading of your progress and sharing my own!

On May 10, 2022, at 9:48 AM, Robert Lipe <rober...@gmail.com> wrote:



--

[Felix Yan]

On 5/10/22 16:41, Robert Lipe wrote:
> On Tue, May 10, 2022 at 5:25 AM Felix Yan <felix...@archlinux.org> wrote:
>
>> The board didn't make it to me yet, either. I'll add it to our (Arch
>> Linux RISC-V) build array and will probably include it in our automated
>> image generation some time later.
>>
>
> Felix, if you have more virtualization space than slots for boards (and
> power and ethernet and JTAG and serial and...) an option that's handy for
> automated tests is Renode.io.
>
> https://renode.io/news/Linux-on-BeagleV-Starlight-in-Renode/

Thanks for the info. Renode is indeed very new to me :)

We are currently building & testing most packages under qemu-user, and
for the problematic ones (due to limitations or bugs of qemu's user
mode) we utilize qemu-system or real boards. 3D / graphics related works
are still exclusive to real boards at the moment, as even mesa/llvmpipe
isn't very usable.

--
Regards,
Felix Yan

[Robert Lipe]

>
> https://renode.io/news/Linux-on-BeagleV-Starlight-in-Renode/

Thanks for the info. Renode is indeed very new to me :)

It's cool. We're all here to learn from each other.
 

We are currently building & testing most packages under qemu-user, and
for the problematic ones (due to limitations or bugs of qemu's user

Depending on the nature of your (cross?) build, it could go either way over Qemu. For now, it can be just another tool to keep in mind. I suspect the breaking points will be in different places (QEmu's virtfs would probably be faster than emulating the disk adapter, but thats not helpful if you're developing the disk adapter, for example) but they'll still be there.
 

3D / graphics related works
are still exclusive to real boards at the moment, as even mesa/llvmpipe
isn't very usable.

I think the intersection of "real" 3D video and RISC-V is still only with the SiFive "Un" boards, isn't it? I can't think of anyone besides SiFive that's shipped a system with enough of a  PCI  interface to allow even a third party attachment of a 3D GPU. Oh, T-Head's $400 C910 with a small GPU for mobile screen/Android development.

3D and RISC-V is still a bit of a lonely place. Given enough time and VC money, we'll see results. 

JH-7110 was to have onboard 3D, but that isn't where we are today. :-/


I can report my own board booted Fedora. I ran out of steam just after getting it booted, but it's at least working.

RJL

[Matthew Croughan]

I've created a private room on Matrix called visionfive-devboard, in case anybody wants to join and talk asynchronously. https://matrix.to/#/!eUxQScIiKitwTULZrZ:matrix.org?via=matrix.org

Also, I'd like to introduce myself. I'm Matthew Croughan, and I'll be working along with 10 other people in the same community to document, socialize and improve RISC-V Support on NixOS, starting with the VisionFive board. A lot of work unrelated to our effort has already been accomplished here https://github.com/NixOS/nixpkgs/pull/168826, so most of my work will be tweeting about it, documenting how to utilize this work, and contributing/polishing in general where I can.

If anyone believes Nix can be used to improve anything that already exists, don't hesitate to reach out to me, I may be able to contribute to your projects too.

Cheers,

Matt

------- Original Message -------

--

[Jeff Scheel]

Thanks, Matt!

-Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to devboard-community+unsub...@riscv.org.

[Daniel Maslowski]

I've announced dev live streams for the work on the oreboot port.

That will probably be weekly on Wednesdays, at 8pm CEST, as soon as I received the board. I'd be happy to see some folks join the party, and I'll upload the recordings to some video platforms. ✨👩‍💻✨

Will let you know when it's set in stone.

https://twitch.tv/cyrevolt 👈🥳

[Waldek Kozaczuk]

Hello everyone!

Last Saturday I received my VisionFive board and I have since found a bit of time to boot it with pre-installed Fedora and all seems fine!

Now, my project involves porting OSv unikernel (https://github.com/cloudius-systems/osv) to RISC-V. For those unfamiliar with unikernels, OSv is in essence "enough of OS" to run a single Linux app or process on it as a micro virtual machine on a hypervisor (QEMU/KVM, Xen, Firecracker, VBox, etc). So OSv does not implement any "real" device drivers but mostly those from the family of VirtIO ones. Finally, the core of OSv has been mostly written in C++ 11 but key elements like networking and libc are in C and come from FreeBSD and musl respectively.

Currently, OSv supports both x86_64 and aarch64. I do not have much experience with RISC-V architecture but I hope there is some similarity with ARM so I should be able to use the aarch64 port as my basis to port to RISC-V to some extent. My plan is to start with the boot process which would involve implementing preboot.S (or equivalent, see https://github.com/cloudius-systems/osv/blob/master/arch/aarch64/preboot.S) and boot.S (see https://github.com/cloudius-systems/osv/blob/master/arch/aarch64/boot.S) for RISC-V. Then everything else logically that corresponds to what we have under arch/aarch64 - exception handling, memory mapping, and device drivers including the clock, timers, console, etc. Any hints (the equivalent of arm clock and GIC on risc-v for example), or pointers would be much appreciated.

I think I will be developing and running most of my tests on QEMU in emulated mode (TCG) mostly on my non-risc-v dev machines. But eventually, I would like to run some tests on my VisionFive board. But to do it efficiently I would need KVM which I do not think VisionFive supports. Based on my research the KVM support was upstreamed to Linux only last December (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.16-KVM) after the hypervisor extension was frozen not much earlier. As I also understand there are no really boards yet with CPUs that support hypervisor extension, right? I have found this article about Dubhe series that is supposed to implement hypervisor extension - https://starfivetech.com/en/site/cpu-tianshu.

Anyway, this is my first post on this forum and I hope to write more in the coming weeks.

Cheers,

Waldek 

PS. Is there an equivalent of the ARMv8 Foundation Model for RISC-V that could simulate KVM?

[Robert Lipe]

On Fri, May 13, 2022 at 1:14 PM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

extent. My plan is to start with the boot process which would involve implementing preboot.S (or equivalent, see https://github.com/cloudius-systems/osv/blob/master/arch/aarch64/preboot.S) and boot.S (see https://github.com/cloudius-systems/osv/blob/master/arch/aarch64/boot.S) for RISC-V. Then everything else logically that corresponds to what we have under arch/aarch64 - exception handling, memory mapping, and device drivers including the clock, timers, console, etc. Any hints (the equivalent of arm clock and GIC on risc-v for example), or

That's pretty much the basic recipe for all porting action.

These days there are a TON of blogs and GitHub projects where you can find inspiration. I still like some of the really older ones because they focus on RISC-V itself and don't get distracted by shiny lights.

https://www.sifive.com/blog/all-aboard-part-0-introduction starts a bit slowly (not a bad thing - just a caution to stick with it) by the TL of the Linux RISC-V port.

Also golden is the "interrupt cookbook" by SiFive, maker of the core used by StarFive, the maker of the SoC used by VisionFive.  (It's a lotta fives. I'm just the messenger...) Cookbook is cited in Five-Embeddev's own doc, which includes really good discussions on modern OSDev for RISC-V which includes a bit on timers specifically. (The addresses may be different.) I like some of their C++, but I cringe at their "lets make everything a void* and then reinterpret_cast endlessly" when folks like Dan Saks have shown better ways.

One of my own areas to hunker down into are the "new" bootflow on these larger chips and the use of OpenSBI. I understand it's hip for Linux-class chips (my own RISC-V background is in the embedded MCUs that don't implement this kind of stuff) to use OpenSBI for the base timer (exception handling is still your problem) and debug console I/O. (It's not even as smart as PC Bios decades ago that could read and write a disk sector, send a network packet,  or print a string, but it seems to be key for booting.)

 

I think I will be developing and running most of my tests on QEMU in emulated mode (TCG) mostly on my non-risc-v

Most do. It's faster and is just less fussy when it crashes. Instead of wiring up a JTAG cable when it goes off into space, a host debugger like QEMU or Renode (which works Really Well for this board's predecessor) can issue a printf that said "you did a byte read of a word register, which isn't supported but doesn't trigger a bus error" and then catch your $pc before it romps off into unmapped space.
 

last December (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.16-KVM) after the hypervisor extension was frozen not much earlier. As I also understand there are no really boards yet with CPUs that support

I don't know of any shipping silicon with this support.

It's like Vector 1.0 which was officially frozen around the same time. It was in frozen limbo long enough for it to be simulated and run on FPGA and maybe - maybe - some shuttle run chips, but I don't think any are available even to common developers. I mean, SiFive or Andes may have some running for customers somewhere under NDA, but I've not even heard leaked part numbers/code names for boards with KVM yet.

 

hypervisor extension, right? I have found this article about Dubhe series that is supposed to implement hypervisor extension - https://starfivetech.com/en/site/cpu-tianshu.

We've heard about Dubhe since StarFive uncloaked outside of China. It went from 3.5Ghz down to 2.0, but I still haven't heard any partners that have actually seen chips yet.

<cynic> Companies like PicoRio have taught us that making RISC-V press releases is easier than shipping RISC-V chips.</cynic>
Right now, we're in this kind of weird gap where the specs are way ahead of what you can actually buy. That flurry of spec finalizations in December hasn't yet been translated into volume silicon and boards.

 

PS. Is there an equivalent of the ARMv8 Foundation Model for RISC-V that could simulate KVM?

Anup Patel of WD, cited above, had a couple of posts that outlined the tools they were using for the KVM work, including building it on a (then) custom branch of QEMU and friends.
https://lwn.net/Articles/830078/
QEMU 7, after that article,  may include some of this work.

My guess is that unless you're interested in developing KVM software itself (and someone has to), it's probably a distraction to have KVM in your critical path for now.

...but you don't work for me, so you do you. :-)

RJL

[Akira Tsukamoto]

Hi Jeff and all,

I received my Fedex package yesterday.

It contains entire package of StarFive dev board,
USB-C power adapter, USB-C cable, SanDisk 64GB microSD.

Great!

I attached the pictures.

Please wait for my updates on my project.

Best,
-Akira

On 5/7/2022 3:58 AM, Jeff Scheel wrote:
> All,
>
> I'd like to welcome round 3 of our DevBoards into our community -- the VisionFive Boards.  Their boards are presently being shipped to them and I heard of the first ones arriving today.  I don't yet have tracking information for the boards but will pass them along as soon as I get it.  As you receive your VisionFive board, please respond directly back to me to confirm it's receipt.  
>
> Those you are not familiar with the board, can learn more here:

> VisionFive Single Board Computer Quick Start Guide | RVspace <https://rvspace.org/en/Product/VisionFive/Technical_Documents/VisionFive_Single_Board_Computer_Quick_Start_Guide#specifications>

>
> To those who are newly added to the community, it serves as my communication vehicle with all projects in the DevBoard Seed program and should be your starting point for getting started and finding help when stuck elsewhere.  As new members, you will have the benefits of two additional programs before you -- one for the D1 Nezha board and one for the Unmatched board. The people on this list are passionate about RISC-V and eager to help.  So, please reach out as needed.
>

> To get started with your StarFive, VisionFive boards, you'll find the board information anchored at rvspace.org <http://rvspace.org> which included the following 3 user documents:
>
> * Quick Start Guide <https://rvspace.org/en/Product/VisionFive/Technical_Documents/VisionFive_Single_Board_Computer_Quick_Start_Guide> - the "Getting Started" section has information about both flashing the SD card but also logging into the pre-configured Fedora image
> * Software Technical Reference Manual <https://rvspace.org/en/Product/VisionFive/Technical_Documents/VisionFive_Software_Technical_Reference_Manual> - provides details about building components of the platform software stack -- SBI, u-boot, kernel, ...
> * GPIO Header User Guide <https://rvspace.org/en/Product/General/StarFive_40-Pin_GPIO_Header_User_Guide> - details the technical aspects of the attaching peripherals through the GPIO header
>
> Additionally, VisionFive has started an English forum for their board at https://forum.rvspace.org/c/visionfive/6 <https://forum.rvspace.org/c/visionfive/6>.  This should be your first stopping place for any problems you encounter while getting started with your board.  (Note: you do have to create an account to participate.)

>
> To my knowledge, I have not found any distro-specific pages yet for the VisionFive board, but here are the generic pages for RISC-V which may be helpful:
>

> * Debian for RISC-V:
> https://wiki.debian.org/RISC-V <https://wiki.debian.org/RISC-V>
> * Fedora for RISC-V (Unmatched not supported yet):
> https://fedoraproject.org/wiki/Architectures/RISC-V <https://fedoraproject.org/wiki/Architectures/RISC-V>
> * openSUSE for RISC-V (Unmatched not supported yet):
> https://en.opensuse.org/openSUSE:RISC-V <https://en.opensuse.org/openSUSE:RISC-V>
> * FreeBSD on RISC-V:
> https://wiki.freebsd.org/riscv <https://wiki.freebsd.org/riscv>
> * OpenBSD on RISC-V:
> https://www.openbsd.org/riscv64.html <https://www.openbsd.org/riscv64.html>
> * Zephyr on RISC-V:
> https://docs.zephyrproject.org/latest/boards/riscv/index.html <https://docs.zephyrproject.org/latest/boards/riscv/index.html>

>
> Note: that this hardware is quite close to the old BeagleV board and thus some legacy documentation may exist.
>
> As you find other links which you think might be helpful, please post them so that others can benefit.  
>
> As you hit roadblocks, have questions, or just want to leverage the wisdom of the community, please reach out with questions.  We are here to help.
> -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 <mailto:devboard-commun...@riscv.org>.

[Vadim Malenboim]

Hello,

Board and all including components arrived !

To unsubscribe from this group and stop receiving emails from it, send an email to devboard-commun...@riscv.org.

[Richard Brežák]

Same!

May 23, 2022 11:43:45 AM Vadim Malenboim <vad...@gmail.com>:

[Rehan MALAK]

Hi,

I got the Fedex package this morning.
Thank you Jeff !

Have a good week

Rehan

[LABBE Corentin]

Le Mon, May 09, 2022 at 04:34:22PM -0700, Jeff Scheel a écrit :
> Commenting on this thread as it appears that somehow I failed to add all of
> the new VisionFive folks before sending the email. Doh.
>
> So, new VisionFive members, welcome and checkout the head posting on this
> thread as a reference for your newly arrived boards:
> https://groups.google.com/a/riscv.org/g/devboard-community/c/3w_9bm9pBEE
>
> -Jeff
>
> --
> Jeff Scheel (he/him/his)
> Linux Foundation, RISC-V Technical Program Manager
>
>

Hello

I am Corentin LABBE, I maintain 2 kernelCI labs.
I have just received the board and started to setup it in my lab for CI testing.

I am happy that the documentation is good, as for example I needed to update uboot on the board. (For disabling automatic boot)

Regards

[Dylan McNamee]

On Friday, May 13, 2022 at 11:14:54 AM UTC-7 jwkoz...@gmail.com wrote:

...

PS. Is there an equivalent of the ARMv8 Foundation Model for RISC-V that could simulate KVM?

According to this page as of Linux 5.16, KVM is supported on RISC-V systems that implement the "hypervisor extension". The version of Fedora running on the starfive is 5.16, so that should be good. I see that the latest version of qemu (7.0.0) implements this extension. The ISA extensions implemented by the CPU on the starfive boards we got, according to /proc/cpuinfo, is rv64imafdc. According to the RISC-V wikipedia page, hypervisor support is denoted by the "h" flag, which our CPUs do not have (makes sense, it was only finalized in November).

So I think we can experiment with KVM using qemu 7.0, but our hardware doesn't support it.

dylan

[Jeff Scheel]

Dylan, et. al,

While software may support the Hypervisor extension ratified late last year, no RISC-V hardware (to my knowledge) available today, including the VisionFive board, supports running KVM on the hardware.  We all anxiously await that hardware when it arrives in the market!

-Jeff

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

[Jonas Hahnfeld]

On Mon, 2022-05-09 at 16:34 -0700, Jeff Scheel wrote:
> Commenting on this thread as it appears that somehow I failed to add
> all of the new VisionFive folks before sending the email.  Doh.
>
> So, new VisionFive members, welcome and checkout the head posting on
> this thread as a reference for your newly arrived boards:
> https://groups.google.com/a/riscv.org/g/devboard-community/c/3w_9bm9pBEE
>
> -Jeff
>
> --

> Jeff Scheel (he/him/his)Linux Foundation, RISC-V Technical Program
> Manager
>
>

Hi all,

I'd also like to introduce myself: My name is Jonas, @hahnjo on most
development platforms. My board arrived on Monday and I've been playing
with it during the evenings. I started with Fedora, which worked fine
out-of-the-box after flashing the image, then compiled my own kernel,
and now switched to Debian (I mostly followed [1] but invested some
time to simplify the setup, ie only two partitions and u-boot directly
starting the Linux kernel without GRUB in between; let me know if there
is interest to document the needed steps).

Originally I wanted to work on compiler support (mostly LLVM), but that
seems to be already in good shape, and also the hardware support in the
(downstream) Linux kernel is working well. I'm not sure if somebody is
trying to upstream the missing pieces? My understanding is that
StarFive won't for the JH7100, but only for the JH7110...

So now that many things are already working (boring), I'll probably
shift to higher levels. I noticed that OpenMPI already works, but it
mis-recognizes the hardware as 1 core with 2 threads, instead of 2
cores with 1 thread each. At least that's how I understand "dual-core",
right?

Cheers
Jonas


1: https://forum.rvspace.org/t/create-debian-system-image-on-risc-v-visionfive/234

[Robert Lipe]

On Fri, May 27, 2022, 9:58 AM 'Jonas Hahnfeld' via RISC-V Developer Board Community <devboard-...@riscv.org> wrote:

 Linux kernel is working well. I'm not sure if somebody is
trying to upstream the missing pieces? My understanding is that
StarFive won't for the JH7100, but only for the JH7110...

Much is upstreamed.  It's likely that Emil has a list of what's still needed and what's being held. I perceive the list as small, but I last looked last fall when Vision Five was announced. 

Now that the chip is available to buy on a real board, this platform exists and I don't know that holding into anything for the mythical 7110 is going to help those customers with boards today. (I don't particularly get a vote in this - or any other - matter. I'm just replaying past observations and reframing them in current context.)

StarFive has gone pretty silent on 7110, presumably to not Osbourne Effect the boards on the market today. 

So now that many things are already working (boring), I'll probably
shift to higher levels. I noticed that OpenMPI already works, but it
mis-recognizes the hardware as 1 core with 2 threads, instead of 2
cores with 1 thread each. At least that's how I understand "dual-core",
right?

Cheers
Jonas


1: https://forum.rvspace.org/t/create-debian-system-image-on-risc-v-visionfive/234

[Daniel Maslowski]

Hey everyone,

I'm doing weekly Twitch streams now, sharing the oreboot firmware development I'm doing, over at https://www.twitch.tv/cyrevolt - every Wednesday at 20:00 CEST.

The videos are retained for 14 days, and I reupload them again to my YouTube channel: https://www.youtube.com/playlist?list=PLenOHeTI_A9PSGshDnEc4dYK-GSnCshk6

(if you click right away, bear in mind that I'm uploading the first one right now and it'll take a while to finish and process)

Feel free to subscribe to my channels and follow along. :-)

Cheers!

[Fufezan Mihai]

​Hello!

My board just arrived today, and I'm thrilled to finally have it!
Unfortunately, I won't be able to work on it until my exam session ends, at the end of June. I hope that's alright!

Again, thank you Jeff!

Have a great day,

Mihai

------- Original Message -------

--

[Tiago Alves]

Hi everybody,

Has anyone managed to connect to a wifi network using the DevBoard (+Fedora)?

I have tried the Fedora image which came in the SDcard but only Bluetooth was enabled.

I managed to connect to the wired network without issues.

Best regards,

TA

[Milan P. Stanić]

Hello all,

Let me introduce myself.
I'm member of Alpine Linux development, a distro based on musl libc.
We got our boards previous week.
https://alpinelinux.org/

We started to make Alpine Linux running on SBC and create IRC
channel #alpine-riscv64 on OFTC. Also we have gitlab page here:
https://gitlab.alpinelinux.org/nmeum/alpine-visionfive
Where we plan to work on this SBC.

Besides this I created small guide and script to install Alpine Linux on
SBC and run it.

In our test everything works fine except sound driver.

For now we are working on fixing and porting some important packages to
musl libc.

Is there somewhere IRC channel where we can join and talk more quickly
than on mailing list?

--
Kind regards

> >> <https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Cache%20Coherence%20V1.0.pdf>.

> >> RISC-V spec said to not build chips that didn't bus-snoop DMA transfers,
> >> but they did. (We were given the impression that 7100 was short-lived and
> >> the 7110 would fix lots of the issues we had.) This was a protracted
> >> "discovery" the first time around, and the symptoms will make you crazy.
> >> You poke the DMAC on an ethernet or USB transfer, you'll get a completion
> >> interrupt, but packets won't show up in memory for tens of seconds. Other
> >> activity (jiggling your mouse, building GCC, whatever) will make the
> >> contents of those packets "suddenly" appear. Oh, and the DMA to your SD
> >> card would have the 'wrong' data in it. Your operating system can
> >> temporarily sprinkle LOTS of magic calls to poke two registers in the L2
> >> controller to make it DTRT OR explicitly add support for non-coherent ops.
> >> For Linux, Emil and others did the work to already upstream that support
> >> now. In the beginning, it was a bunch of #ifdef JH7100 / poke registers /
> >> memcpy from board#endif style special casing and it wasn't pretty. The
> >> current situation in Linux is quite elegant, but this is a trap on this
> >> chip waiting for the rest of us building OSes. Be mindful.
> >>
> >> To my knowledge, I have not found any distro-specific pages yet for the
> >>> VisionFive board, but here are the generic pages for RISC-V which may be
> >>> helpful:
> >>>

> >>> - Debian for RISC-V:
> >>> https://wiki.debian.org/RISC-V
> >>> - Fedora for RISC-V (Unmatched not supported yet):

> >>> https://fedoraproject.org/wiki/Architectures/RISC-V
> >>>
> >>> Fedora was the original bringup vehicle. A lot of doc went poof when
> >> that relationship dissolved, but let's thank our Internet Gods for
> >> archive.org.
> >>
> >>
> >> https://web.archive.org/web/20210427151250/https://wiki.seeedstudio.com/BeagleV-Getting-Started/
> >>
> >> ...this may not map exactly to current Fedora and the new board, but
> >> there may be some nuggets in there to mine for a new Wiki. (Hint, hint.)
> >>
> >> For the Linux kernel itself, much of the work to support these is already
> >> upstreamed. https://lwn.net/Articles/872651/ (See that even in October,
> >> we were told that JH-7100 was to be short-lived in favor of JH-7110.) ISTR
> >> having reps from many of the other OSes in the original groups
> >>
> >>

> >>> - Note: that this hardware is quite close to the old BeagleV board

> >>> and thus some legacy documentation may exist.
> >>>
> >>> The original had hazards in the serial comms used. The serial console
> >> port was 3.3v. It was MOSTLY compatible with older 5V USB/Serial adapters,
> >> but there was one brand (PL2303 maybe?) whose low wasn't low enough to
> >> reliable transmit all the characters. It would misreceive bytes with more
> >> than N consecutive 0 bits or some such obscure thing. Without a scope,
> >> you'd never figure it out. Use 3.3V adapters.
> >>
> >> There was something (ddrinit) that had to be sent to the 7100 via Xmodem
> >> or Kermit or something directly to pins on the 7100 and not via the
> >> console. That was a 1.8V level I/O and attaching a 5V to that resulted in
> >> Bad Things. Hopefully, ddrinit doesn't need to be reprogrammed regularly by
> >> now. IIRC, the 40-pin was 3.3V and there was a debug header that was still
> >> raw 1.8.
> >>
> >> Both of these COULD be resolved on the fiberglass by using better
> >> level-shifted I/Os to front-end the pins. I've not compared the schematics
> >> yet, but I'm pretty sure that "don't use 5V USB Serial" on this generation
> >> of board is solid advice.
> >>
> >> EDIT: https://github.com/beagleboard/beaglev-starlight/issues/11 seems
> >> to capture this. Some digging around in closed issues

> >> <https://github.com/beagleboard/beaglev-starlight/issues?q=is%3Aissue+is%3Aclosed> may

> >> be useful.
> >>
> >> Once I have a board in hand where I can scope signals and figure out how
> >> many times I'd have to turn it to get it right side up again, i'll be

> >> checking out "Blinky Toy <https://robertlipe.com/tmp/blinky.mp4>", a

[Clayton Auld]

Milan,

Glad to hear you are working on Alpine for the VisionFive! I've been working to get some Docker images ported over and ran into some software requirements that were missing for RISC-V on the Alpine base image. Due to that I moved over to an Ubuntu base.

Once Alpine package support is more stable and available I will be moving back to that for my base images.

Thanks,

Clayton Auld

---- On Fri, 03 Jun 2022 12:25:13 -0800 Milan P. Stanić <m...@arvanta.net> wrote ----

[Jeff Scheel]

Thanks for asking, Lan.  I know of nothing about the board which is confidential.  Given the public sale of the board and public wiki space (rvspace.org), I think you're clear.

-Jeff

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

On Mon, Jun 6, 2022 at 9:26 AM Lan Hu <l...@shiko.nl> wrote:

Hi all,

I was wondering if there is any confidentiality required for the starfive board?

I am keeping an online blog at www.shiko.nl so for the purpose of keeping track of my developments I could make it blog posts, which make it searchable and is a good way to keep track.

As for now, there don't seem to be any restrictions.

Thanks,

Lan