Tiny Core Base > Other architectures

Which board to support?

<< < (9/10) > >>

Yleisajattelija:

--- Quote from: gadget42 on July 28, 2025, 09:18:18 PM ---hat-tip @CNK for referencing:

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

especially intriguing(from the above weblink):
--- Quote ---There are different versions of the instruction set for 32, 64 and 128 bits; operating as little-endian by default.
--- End quote ---

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

--- End quote ---


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

Navigation

[0] Message Index

[#] Next page

[*] Previous page