Octa core Risc V .....sbc

[CentralWare]

Ubuntu Server and Desktop both have odd poweroff/reboot scenarios.
With SERVER, reboot puts it to sleep - without means to wake it. poweroff+poweron hangs at boot loader
With DESKTOP, reboot/poweroff+poweron hang at the boot loader screen.
If I remove power for >40 seconds it works as expected upon reconnecting.
I'm speculating this is either heat related or boot loader related - too soon to tell.
(multiple SD cards used, 2 power supplies with manual adjustment +/- 0.01v detail)
I may have also just received a bad board - will know more in the near future.

Debian - I haven't found a RV2 compatible image yet - but I haven't dug too deeply either.
Armbian is also supposed to have one - I just haven't found it yet.

I have eMMC and M2->SATAx6 boards coming in the next few days to see about pushing this thing to the limits.

@vinceASPECT: Ubuntu Noble images from the OPi website.  (See @gadget42's link above)

[vinceASPECT]

ahh Right

Good to learn about the RISC V board.

You are using THEIR official OS from their website for the RISC V board.....

makes sense.

Do you find it runs APPS ok?....say GIMP 3 from the repo?

Yes, some SBC's come ready to go with the OS already inside onboard memory



thanks
C

[CentralWare]

@vinceASPECT: I wasn't sure if the board was damaged (It IS a rework item - the mounting lugs for both M.2 sockets are missing and the primary capacitor has a chip out of it) but after today I'm reasonably certain it's not the board causing the warm boot hiccups, but more likely u_boot failing.

The eMMC board arrived today - once installed, the installation of Ubuntu from the SD card to the eMMC took only a matter of minutes, rebooted a handful of times on its own and SO FAR it hasn't acted up even once booting from the MMC.  (Mind you, we tried numerous Micro-SD cards from different brands and they all acted in the same manner, so I'm leaning toward a boot loader that's flaky on SD boot.

Ubuntu Noble image comes with Chromium pre-installed, I updated APT and installed a few low-end items, compiler, even Samba - but not much in relation to the desktop breed.  (I don't use a general desktop too often and "startx" when I do need to )

REPO: It's a third party repository I haven't created an image for yet (we're still deciding whether or not to port OPi) but did speak with someone overseas last night hinting "...if you want to lend a hand in the porting process..." so we'll see if OPi's crew joins in the fun!  (The board I received is, in fact, physically damaged but I have a replacement due to arrive tomorrow from a US supplier - once that gets here we'll see if OPiRV2 can handle being turned into a 6-drive RAID NAS   If so, I'll order one or two more for further experimentation and we'll dig further.)

As for onboard memory/storage...  there's a mere 16MB SPI flash onboard for the boot loader and settings - nothing more.  Even the 16MB is broken into five or six partitions making it otherwise useless to the outside world.  There's a 3-pin ICP connection next to the DC-in (I'm assuming serial i/o for low-level editing/programming/flashing) but documentation is limited, so if that specific SPI can be accessed through the operating system - I haven't found it yet.  Not that I've spent a great deal of time at this point!

Overall: Assuming tomorrow's board arrives unscathed, and assuming it has the same warm-boot problems this one had, the board's u_boot and operating system are both flagged as Beta - so issues are bound to surface...  but considering the price tag along with the onboard components, this 8-Core/Thread unit @ 1.6GHz runs circles around RPi2 when it first released at $30ea...  The RPi5 has a faster engine @ 2.4GHz, but half as many pistons.  RPi5 also has dual-head GPU option and an integrated GPU; whereas the OPi is lacking in the GPU arena from what I read - especially support for it.  When you add the M.2 ports and eMMC port, the scales get tipped well toward the OPi.

CPU Cooling...  is a must on the OPi.  At least on the one I have here already.  After installing the MMC chip I watched as the system flashed itself onto it, which brought CPU temp up to 69°C just copying files.  I have copper heat-sinks arriving tomorrow BUT if you use the 2230 M.2 port, you cannot put a sink on the RAM chip - which does tend to get a little toasty.  There are no holes where an active cooler could be mounted, so designing is going to take some time - but thus far it looks as though thermal glue is going to be a necessity.

Once the new board is in place I'll load up a desktop and see about Gimp - maybe edit the boot loader screen to be a little more aesthetic, and get back to you on the results.
HOWEVER, their most recent Gimp is 2.8.16 from the looks of it. https://repo.huaweicloud.com/ubuntu-ports/pool/main/ but again, I haven't dug too deeply yet.

Cheers!

[vinceASPECT]

Sir,

That's great that you got really "into" the RISC V board
and hope to port OS's to it.

GIMP got an update to 3.0 across the board.....i expect they have not yet updated
their repo.

 I just wondered how the board performed with a typical desktop graphics
app....

i expect RISC V sbc's will further improve and you'll eventually  be getting what YOU have
for ten dollars and such....
It will be a good reason to actually make more widespread use of them.
i bet ARM and intel and AMD etc won't like it........

thanks
C

[CentralWare]

i bet ARM and intel and AMD etc won't like it........

LOL!  Intel/AMD don't see ARM/RISC/DRIOD as "too much" competition yet; no, I don't imagine they're "happy" about IoT, but if it bothered them that much, they'd get IN THE GAME!

Okay - last update until this weekend:

1. The bottom M.2 (2280) crashes into the eMMC if it's installed.  (See Pic)  Granted, there are probably paper-thin M.2 devices out there, but that's irrelevant at this point since I'm not using one of those.
    The top M.2 (2230) if installed sits on top of the cap/coil next to the power LED...  both of these ports should have been thought out a little better.
2. I'm watching the demo screen for FreeDoom - it's flawless (and graphics isn't this board's strongest area)
3. I loaded up Gimp - not that I was editing a 50 layer masterpiece, but it operated almost as nicely as my workstation
4. I dumped the GUI and reloaded "Server" - turning it into a two port router/firewall...  iptables+dnsmasq...  almost effortless!
5. I ordered RasPi5 heat-sinks (which include the ~1.5mm copper pad that fits nicely under the top M.2 2230 for the onboard RAM) and with Ambient of ~27° she's running at 67° with all cores loaded down to about 80% - withOUT a fan.  (...that doesn't arrive for a couple more days )
6. I haven't connected drives yet, but there's a 6-port SATA3 M2 adapter underneath just waiting for some exercise - this weekend probably

Take care!

T.J.

[CentralWare]

UPDATE:

• Booting from SD card is temperamental - experimentation necessary for different brands
• Booting from USB, thus far, is flawless.  Burn the image directly to USB and skip a good deal of headaches!  USB M.2/SATA is not only easy, but happily fast!
• Booting from NVMe is available only on the 2280 slot - there's no u_boot support for the top slot yet. HOWEVER, sources are available.
• Booting from eMMC is the best option, but far from the cheapest
• Attached a M2 to 6-Port SATA3 adapter - worked effortlessly.  Connected a few drives, created a generic RAID6, everything as expected under mdadm.
• Still have not exceeded 2AMPs with all of the different layouts, but voltage drop is concerning >0.7W (Hard drives were externally powered.)
• The OPi repository is a little dated, but considering most of the files are *.deb expansion shouldn't be an issue.
• The RTC battery connection is a 1.25mm JST connector - one connector + 1 CR2032 Socket = Easy RTC
• Using RasPi v4/v5 heat-sinks we were able to amply cover the processor and a 1mm copper plate was affixed to the RAM chip - 41°C under high load with a 5010 fan blowing on it.

We've designed an enclosure (which is ALPHA stage at this point!) that we're printing as we speak.  The power button is going to be redesigned (I don't like the "clunky" nature of the current one (light blue) but in the end, this will be a three-layer cake, in essence, the OPi on the top, a CD/DVD/BDR in the middle and a six bay 2.5" SATA hot-swap cage on the bottom, all in a 5.25" modular concept considering we're probably going to end up using an ATX power supply to make it all function so why not put it into a case!?  There's going to be a number of relay boards implemented for power management and the likes, so a Mini ATX case should be cheap and easy!

There's also going to be either a 1602 or 2004 LCD on the front, a couple RGBIC status LEDs, two tiny internal 3W speakers, a 50mm turbine cooling fan (still working out airflow dynamics) and a rear-mounted wireless IPEX antenna for BT and WiFi.

BUT...

• The USB-C connector on the OPi is surface mount - we'll have to manufacture a Molex or SATA to USB-C adapter just to feed it 5V (documentation makes it sound like feeding it from GPIO is a bad idea. Then again, so did RasPi back in the day.)
• GPIO numbering is going to take some getting used to and WiringPI compiled for OPi is supposedly ready for such numbers
• BOOT and RESET buttons are surface mount in very hard to reach locations - probably not something we'll be creating headers for
• POWER button is a very thin through-hole which MAY be able to be given headers - or at least a wired socket, otherwise we're stuck using a mechanical bar like in the picture

[neonix]

https://old.reddit.com/r/RISCV/comments/se50ur/some_good_news_in_the_gpu_department/?rdt=40186

Most probably GPU drivers will be distributed as binary blob. If I want to use it in 2035 or 2045, will I get working GPU driver on Linux?

If GPU and CPU is in one chip, radiator or fan will be essential. New RPies also has overheating problem.

You also need to invest in non-standard power supply and computer case. If you don't have HDMI monitor, VGA-HDMI converter costs 15 USD.

[CentralWare]

https://old.reddit.com/r/RISCV/comments/se50ur/some_good_news_in_the_gpu_department/?rdt=40186

Most probably GPU drivers will be distributed as binary blob. If I want to use it in 2035 or 2045, will I get working GPU driver on Linux?

If GPU and CPU is in one chip, radiator or fan will be essential. New RPies also has overheating problem.

You also need to invest in non-standard power supply and computer case. If you don't have HDMI monitor, VGA-HDMI converter costs 15 USD.

Good morning, @Neonix!

CPU/GPU look to be in the same chip.
DMesg | grep has two responses for "video"

Code: [Select]

videodev: Linux video capture interface: v2.00
usbcore: registered new interface driver uvcvideo
...which is driven by

Code: [Select]

ky-drm-drv c0440000.display-subsystem-hdmi: bound soc:port@c0440000 (ops dpu_component_ops)
ky-drm-drv c0440000.display-subsystem-hdmi: bound c0400500.hdmi (ops ky_hdmi_ops)
[drm] Initialized rvdisplay 1.0.0 20231115 for c0440000.display-subsystem-hdmi on minor 1
...and yes, the driver is probably a blob found here at their hub.  (I haven't dug for it yet.)

Yes, radiator(s) and a fan are important (though there are reports of people using them without...  I don't see that as being wise with the testing we've done.)

Power Supply - they actually have an "oem" power supply that looks good enough for standard use, but when dealing with hard drives and other items requiring 9v/12v/15v/etc. their USB-C port is pretty useless, so yes, a non-usb-c power supply is in order, but "non-standard" may not be the case if using an ATX or similar PSU.

Computer Case - I've already begun design of two cases, one of which is intended for a NAS build and fits quite nicely.  (See Pic)

As for the HDMI to VGA adapter, we have plenty of those in stock and in the States (Amazon for example) they're about $8 ea.

[CentralWare]

Minor Update:

• OPi is now connected to an ATX (1U) power supply using 5vSB (purple PSU wire) inside a $30 Mini ITX computer case which had a 150w power supply included (see photo)
• GPIO is being used to turn the power supply "on" which launches fans, HDDs, etc. (green PSU wire)
• Mini ITX to OPi mount built to create an I/O plate on the rear of the case and even a small "tube" for the WiFi antenna to hide in
• 5015 Turbine/Centrifuge Fan added to cool top and bottom of board (38 degrees was the max at 100% CPU) - tiny bit noisy, but expected due to size and type of cooling fan
• USB-C power connection bypassed by utilizing the *FAN* header and used as 5v DC INPUT (from any RED PSU wire.)
• Power and Reset buttons will need to have wired headers soldered on to them to utilize the case's front buttons
• GPIO pin(s) might get used for the case's front LEDs and HDD LED assigned to sys/class/leds for displaying "activity"
• RTC battery adapter (with on/off switch) implemented to keep time
• 6 Port SATA M.2 board temporarily connected to top socket to test SATA capabilities/throughput

I'm about 1/3 of the way of putting a sane kernel config together to accommodate TCL's way of doing things, we have about 75% of the toolchain apps gathered and set up, cross-chain built and tested for kernel, u-boot and SOME of the apps needed for our foundation (still a ways to go), graphics binary/blob is now in our archive, but still being investigated and wireless is still being looked into as we found a few weak spots/bugs while testing the cross-compilation environment and technical support at the factory...  less than ideal.  (No response to my last handful of emails once moneys had been exchanged.)  I don't want to get TOO carried away with compiling just yet as I want to test a number of build scripts on the RISCV board and also through the cross-compiler environment to make sure we can accomplish everything in a more automated fashion.

If anyone wants to lend a hand, go to our project's Git Hub and read the page's info, then take a look inside the "final" directory for a few examples of working (tested under ASH thus far) builder scripts.  Initially, we will want and need virtually anything compiler/linker/library related. Take a look at one of the existing builder scripts in ./final, it should be reasonably easy to follow.  For go_version() there are going to be plenty of people who can code in C in their sleep, but "web" anything isn't in their wheel-house.  For anyone wanting to help but not sure how to scrape information from online resources, simply have go_version() return the word "unknown" and we'll tend to version scraping for you.  (Be sure to fill out SRC_SITE="" so we know where to look!)