Which board to support?

[gadget42]

this commentary refers to the Rock-PI 4 from Radxa

https://research.exoticsilicon.com/articles/sbc_bootcamp_2021

[Yleisajattelija]

Manual for VSRV:

https://www.vlsi.fi/fileadmin/products/vsrv/vsrv_guide.pdf


Implemented RISC-V flavour:

----------------
The exactflavour of the core is RV32IMSU zicsr zifencei.
----------------

--RV32I = "base integer instruction set" (fixed 32bit)
--M = "Extension for Integer Multiplication and Division" (for FIR-filters?)
--S = "Supervisor mode" (=separate mem ja cmds for root space)
--U = "User mode" (=separate mem and cmds for user space)
--zicsr = "Extension for Control and Status Register (CSR) Istructions (physical mem control?)
--zifencei = "Extension for Istruction-Fetch Fence" (for protected mode caches?).

Memory controller:

-----------------------------
LPDDR2 Interface

LPDDR2 is connected to the Instruction and Data Caches of VSRV1, making it themain RAM memory of the unit. RISC-V cannot be run without LPDDR2.
------------------------------

SD-card is connected to VSDSP6-core bus, not VSRV1RISC-VCORE bus, which may be problem for tc-port.

Those buses are MUX:ed, but mux may prevent boot from SD-card.

UART-boot:
----------------------------------------------
(I think there is bug on document, these two UART boot sections are on wrong sections)

Boot UART
Connected either to pins RV_TX and RV_RX and/or to VSDSP6’s UARTMUX.
Speed is always RVCLKI/12, where RVCLKI is RISC-V’s internal clock.


UARTMUX
UARTMUX connects to VSRV1 boot UART.
-----------------------------------------------

Anyway, UART-boot is GOOD news for tc port....

DSP-core IS real time:

--------------------------
Having all these features gives VSDSP high signal processing power beyond its MHz
figures.

The extremely low latency in serving an interrupt (usually significantly below 10 µs even
in a loaded system) allows for implementing a real-time system with audio latencies from
input to output in the order of less than 5 milliseconds.
-------------------------

[Yleisajattelija]

Fresh VSRV -board shell documentation:

https://www.vlsi.fi/fileadmin/products/vsrv/vsrv_vsos_shell.pdf

Tristan RISC-V documentation:

https://www.vlsi.fi/fileadmin/vsriscv/VSRV1/TRISTAN_D2.1_Architecture_Description_and_Design_Specification_VLSI.pdf


https://www.vlsi.fi/fileadmin/vsriscv/VSRV1/TRISTAN_D2.2_Design_and_Implementation_of_RISC-V_Cores_and_Extensions_VLSI.pdf

There is SOC data sheet (pin numbers etc.):

https://www.vlsi.fi/fileadmin/datasheets/vsrves01_ds.pdf


Very pro...


Couple of pins:

Pin 33: Mem mux, jumper maybe?
Pin 43/44 UART RV_RX/TX (RV = RISC-V?)
Pin 67/68 UART RX/TX (DSP core UART?)

But Tristan document "rv_uart" UART mux pin missing? How to select RISC-V/DSP core UART? (might be pin 57 rx_ctl)

Boot from SD-card is possible:

https://www.vlsi.fi/fileadmin/news/PressReleaseVSRVES01.pdf

[Yleisajattelija]

VSRV Device Tree:

https://www.vsdsp-forum.com/phpbb/viewtopic.php?t=3241

There is two UART connectors on board, so uart_mux pin is not needed (or it is automatically controlled):

https://www.vlsi.fi/en/support/evaluationboards/vsrves01catboard.html

[Yleisajattelija]

I think Rasperry Pi DTO- type problems cannot be solved without physical memory managing system. If I understand correctly, it is optional feature on RISC-C processors:

https://github.com/ultraembedded/riscv/blob/master/doc/riscv_isa_spec.pdf
https://github.com/ultraembedded/riscv/blob/master/doc/riscv_privileged_spec.pdf

"An optional physical memory protection (PMP) unit provides per-hart machine-mode control registers to allow physical memory access privileges (read,write, execute) to be specified for each physical memory region."

Probably this "Flavour" switch "Smpmpmt" (= PMP-base memory types (for cores w/o MMU) (cacheable/uncacheable, idempotency, ordering) .

Not implemented on VSRV1 -board (yet).

I think this is very promising board for new Tinycore port. Very open source and very good documentation. It is RISC-V, and supported for scommunity. Company's business is to sell chips, and there is company strategy to support linux -ports:

---------------------------------------------------------------------
Resources
Below is a list of various free and open resources available now or soon from VLSI Solution. They will be updated regulardly as new information becomes available. Our goal is to in time provide
all information needed for our customers to compile and if necessary modify their own Linux kernels and applications.

Documentation:

VSRV Datasheet (NEW! 250507) - An extremely work-in-progress version at the moment
VSRV User's Guide (NEW! 250528) - What the VSRV chip and VSRVES01 Cat Board are and how to use them
VSRV VSOS Shell (NEW! 250530) - How to use the VSDSP VSOS Shell
VSRV VSOS Audio (NEW! 250617) - Introduction to the VSDSP VSOS audio subsystem
Software:

VSOS Root Image (NEW! 250604) - Latest version of the files for the VSRVES01 Cat Board's microSD card (including both VSDSP/VSOS and RISC-V/Linux)
elf2vri (NEW! 250618) - Linux C source code for program needed to convert Linux ELF and binary files to the VRI format required by CAT Board's DDRLoad
Other:

Linux Device Tree (NEW! 250602)
VSRVES01 discussion thread (NEW! 250508)
VSRVES01 Cat Board discussion thread (NEW! 250523)
-----------------------------------------------------------------------------------------

https://www.vlsi.fi/en/products/vsrves01.html

[Yleisajattelija]

Maintainer for VSRVES01 CAT Board needed?

https://www.vlsi.fi/en/support/evaluationboards/vsrves01catboard.html

Mental support:

https://www.idealist.org/en

[Yleisajattelija]

If there is no volunteers, I can try...

I have been professional embedded coder (ASM+C), but it was 30 years ago (I have been RF-designer and R&D project manager for most of my career), so it will take some time to start deep coding for port. I have tried Guruplug plus few years ago  and tried to install armel Debian by U-boot (I even got some help from Martin Michlmayr for that, but installer didn't succeed for some reason), so I have some experience of problems.

Now I have studied kernel, RISC-V, SOC and board internals for few weeks, and now is time to connect plug and try bootloader.

I did contact board manufacturer for support, I think it is mandatory to succeed.

[Yleisajattelija]

I got an answer fron VLSI-Solution for few important issues:

"VSRVES01 doesn't have ROM on RISC-V side so it doesn't know how to boot. The booting is done through VSDSP with RvParam and DDRLoad."

Actually this is ideal situation for tc port, a "raw" HW, support from SOC/Board manufacturer and open DT/boot proces-spesification.

[Yleisajattelija]

Toolchain:

https://github.com/riscv-collab/riscv-gnu-toolchain

Is there all, or something missing to compile kernel + tc?

[gadget42]

hat-tip @CNK for referencing:

https://wiki.debian.org/RISC-V

especially intriguing(from the above weblink):

There are different versions of the instruction set for 32, 64 and 128 bits; operating as little-endian by default.

which led to:

https://en.wikipedia.org/wiki/128-bit_computing

definitely thought-provoking, especially the "other uses" section(UUID, IPv6, ZFS,key-sizes, etc)

also did visit:

https://www.howtogeek.com/858423/why-dont-we-have-128-bit-computers-yet/

which led to:

https://www.howtogeek.com/why-i-bought-a-160-mac-mini-instead-of-a-raspberry-pi/

and naturally back to a forum search for "mac mini"...ha!

https://forum.tinycorelinux.net/index.php/topic,11323.0.html
https://forum.tinycorelinux.net/index.php/topic,13445.0.html

[Yleisajattelija]

hat-tip @CNK for referencing:

https://wiki.debian.org/RISC-V

especially intriguing(from the above weblink):

There are different versions of the instruction set for 32, 64 and 128 bits; operating as little-endian by default.

which led to:

https://en.wikipedia.org/wiki/128-bit_computing

definitely thought-provoking, especially the "other uses" section(UUID, IPv6, ZFS,key-sizes, etc)

also did visit:

https://www.howtogeek.com/858423/why-dont-we-have-128-bit-computers-yet/

which led to:

https://www.howtogeek.com/why-i-bought-a-160-mac-mini-instead-of-a-raspberry-pi/

and naturally back to a forum search for "mac mini"...ha!

https://forum.tinycorelinux.net/index.php/topic,11323.0.html
https://forum.tinycorelinux.net/index.php/topic,13445.0.html

Apple's policy is known to be very proprietary, and "open source hostile". It is almost sure, that Apple won't give "Mac Mini" spesifications for tc -port.

[Yleisajattelija]

Documentation: I have a very bad memory, so I must document everything for my own use. Tc uses wiki for user documentation, but it's not suitable for development stuff. It is quite tedious and frustating job to convert different documentation formats, so I like to use same documentation style and format from start to end. Set of simple ASCII-text files is good for me.

There is lot of related board- and kernel documentation, which creates serius version control problem. Important documents tends to disappear, so it would be necessary to copy some of those for sake of continuation. In linux environment result is typical mess with outdated and missing documents.

For now, i keep personal database for documentation for VSRVES01 board, and if I get first compilation done, I will publish documents for community use some way.

[Yleisajattelija]

One more debugger:

https://openocd.org/pages/about.html

VSRV-board uses RISC-V loader (ddrload), and special ".vri" image format. On load stage device-tree-blob is included. If I understood correctly, newlinux.img is including kernel and additional "catboard.cpio" -part (=I/O + busybox?).

This is obviously problem for tc port, different ramdisk image module would be needed for tc.

"S:>ddrload -brvlbne.bin -B -bcatboard.dtb newlinux.vri

In the above command first parameter causes riscv bootloader to be loaded at default
address which is 0x80000000, then -B makes ddrload to append just after it its param-
eter data which carries mac address, clock and memory configuration, then it appends
dtb file, finally followed by vri which will be loaded at the address we defined on its
creation."

Flash addresses are "hardcoded" at the moment, but probably changeable later.

Drivers missing at this moment.

"11.1.2 VLSI Drivers

TBD"

[Yleisajattelija]

GCC recognices RISC-V:

https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html

...it is not enough to parametrize compiler only:

https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation

[Yleisajattelija]

Another tool chain:

https://llvm.org/

...and ready for RISC-V:

https://llvm.org/docs/RISCVUsage.html

...using Apache licence:

https://releases.llvm.org/14.0.0/LICENSE.TXT

...which is not open source:

https://en.wikipedia.org/wiki/Apache_License

...so Stallman selected...