Finally received and assembled my uConsole R-01 and Im quite happy with i!t It feels solid and handles surprisingly well. The ubuntu based distro is slow on the RISC-V soc, although the well laid out keyboard and trackball + the WiFi and crisp screen makes it decently usable. Too bad there is a single dead pixel!
Id like to experiment with bare metal programming to just side step the OS altogether but its not exactly clear to me how you can run custom boot code without using an existing linux image. I found this page that provides infos and manuals for the SoC used in the R-01 board https://linux-sunxi.org/D1 but neither the page dedicated to the board nor the github repo provide infos on the boot process as far as i can tell.
I am also interested to dip dive to baremetal for RISC-V. Unfortunately, I still waiting for shipping but at this time I ordered Sipeed Lichee RV board with the same D1 MCU and successfully build Debian by this very good manual Building boot software and Debian from sources for a RISC-V board (Sipeed Lichee RV with D1 processor) - Andreas' website (for U-Boot I use d1-2022-04-05 branch).
This manual uses 5.17.0-rc2 kernel, next step for me figure out how to build more newest kernel.
Also this page good illustrated boot process ttps://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
I run a bare metal DX 7 clone, MiniDexed, on a old pi …
These are very cool projects but they seem to be very raspi/ARM specific. Still the circle is particularly interesting and most of the code seem to be portable.
I am also interested to dip dive to baremetal for RISC-V. Unfortunately, I still waiting for shipping but at this time I ordered Sipeed Lichee RV…
Thanks @ylyamin this is very valuable info, i ll try to replicate this on the R-01 when i get some spare time. Hopefully the boot process on the R-01 is identical.
Since I like to shove Haiku on weird devices, here’s my initial research results:
Looking at the Ubuntu distro on the SD card… it looks like:
Boot ROM (check GPIO pins) → MMC → u-boot → UEFI grub → Linux .
- u-boot spl is likely written to a fixed offset on the MicroSD card
- source: The first partition starts at 69632… which generally means something is written to the raw microSD card before the first partition. It’s a common design model with Chinese SoC manufacturers (especially sunxi ones).
- This makes it a pain in the a** to make “generic” arm/riscv64 operating system images since each one has to be custom tailored for the device.
- An offset of 8192 seems likely looking at other Allwinner devices. (unverified)
- uEnv.txt in /boot instructs u-boot to boot the Ubuntu UEFI loader
- The Ubuntu riscv64 UEFI bootloader is on /dev/mmcblk0p2 (/EFI/…) and should be mounted to /boot/efi on the running system (sudo mount /dev/mmcblk0p2 /boot/efi)
- Unsure if there’s a built-in flash device with a embedded u-boot loader in addition to what’s on the microSD card.
- Unknown u-boot source code location
ClockworkPi needs to link to their u-boot source code… otherwise they’re in violation of the GPL.
Yeah noticing the same thing here.
I have a uConsole on hand that I was working towards getting a custom os image loaded onto the device and I’m hitting a roadblock because I can’t tell what has been upstreamed and what is relying on some clever patchwork.
Going to need that u-boot code or otherwise this entire endeavor may be over before it even started.
Booting the uConsole without an SD card inserted results in the USB-C interface showing a “Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode” interface.
So… that seems to confirm no built-in u-boot, it’s only on the sdcard.
$ ./sunxi-fel ver
AWUSBFEX soc=00001859(R528) 00000001 ver=0001 44 08 scratchpad=00005000 00000000 00000000
$ ./sunxi-fel spiflash-info
SPI support not implemented yet for 1859 (R528)!
oop. I think I found the u-boot sources for the uConsole…
Clockwork really needs to better document this.
One final observation… the 40 “GPIOS” on the Clockwork Mainboard 3.14 v5 are wired up exactly like a Rasbperry Pi. That would mean (in theory) the Raspberry Pi uart would be GPIO 14 / 15. (pin 8/10).
There could be serial uart on those pins if they were shooting to be “Raspberry Pi like” with the R-01. I can’t find any documentation on how to get to a serial uart on the uConsole… so some documentation improvements here would be nice.,
thanks for the replies, very interesting stuff, seems like getting some custom code to boot should be doable.
The irony is generally the most difficult part is figuring out the special secret sauce to get the SoC bootstrapped and code loaded. Everything else is pretty easy.
I was really hopeful that it would become standard to have a built-in u-boot “bios” on riscv64 devices.
Then operating system developers could just pack an EFI loader onto a microSD card and make generic / portable images. (u-boot includes a binary device tree and passes it to UEFI boot-loaders, so the OS media technically doesn’t need hardware specific info besides drivers)
Allwinner seems to be continuing their bad habits from ARM though and allowing implementation partners to ship devices with no onboard flash rom’s.