Just want to note something to everyone here that I discovered tonight:
If you flip both dip switches (to the bottom left of the sd card) to the right, it allows you to boot from an EMMC module.
The board will not show signs of life if it can’t find a valid bootable storage connected to the designated device. But, the dip switches control where it looks.
I’m not sure what the other two options are. One might even be pcie - if someone has an SSD that will fit in the WiFi slot, give it a try! I’m going to mess around with it a bit myself, but I don’t have an SSD that will fit in that slot.
@ryanpetris, you may want to update your initial post with this. In the other post (board schematics thread) I’ve been messing around with the board a bit with some others, too. I’d love to figure out exactly what we have to work with!
Note: this is where it will look for the firmware, it does not determine what is actually used to boot Linux of off. So the u-boot/sbi firmware gets loaded from this location, then it does its usual efi boot procedure trying to find an EFI executable at the place it expects, and then boots that. This EFI partition can be on any storage device that is compatible with the firmware, I believe USB is currently not in that list if I’m not mistaken, so only the sd-card or eMMC module are actually valid places for the EFI partition.
In that picture I am running from eMMC actually, that is the 256GB orangepi module
You can also boost the speed of the eMMC:
did some testing, sd-card did not really want to go faster.
In the other thread, someone else mentioned similar documentation for the dip switches, but it was on the DC Roma reference board. I’m just excited to confirm it did, in fact, work - since there’s absolutely no real documentation for this specific board.
And yeah, I sort of misspoke, and meant that the switches are where it would be looking for uboot. I’m unsurprised that it wouldn’t be able to boot an efi partition from USB - though I’d certainly love to try - but what I’m particularly interested in is the idea of having just uboot/grub on the EMMC/SD, but then having the actual root partition be on the USB. This wouldn’t work with a unified kernel, but it MIGHT work with a more traditional kernel loading process. I’ve done something like this before on several ARM boards that didn’t support booting from USB. You could boot into grub from an SD card, but then grub to USB.
It could lead to some level of performance gain - though, I’m not entirely sure how noticeable it would be. The board is definitely limited entirely by the CPU - 4 cores at 1.5GHz just isn’t really enough to do anything substantial. Still, any improvement is an improvement.
Part of the reason I’m particularly interested in this idea is that I’d love to build an arch linux root partition to point it to. I know, that’s very much a living “arch btw” meme, but I’m just more familiar with arch as a whole so it would be more comfortable to use while “playing”.
I’ll have to take a look at the EMMC “overclock” though - my module is pretty old, so I’m not expecting much out of it, but it’s currently only really getting 40MB/s read and write, which is… not great.
once you get to grub from sd/eMMC you can indeed hop over to USB, I did this to test a bit with the rEFInd boot loader.
get to grub
go to grub cmdline
navigate to boot partition on USB
load the dtb/initrd/kernel and boot or chainload a different bootloader that is on there
As a fellow arch btw enjoyer I fully understand, so far my experience with arch riscv has been quite good, seems a bit better than arch linux arm in some aspects, but the patch mechanism feels quite manual, mainline kernel updates are not as frequent as I am used to on regular arch/alarm
Yeah I just discovered by accident it’ll work fine. But the way I discovered it annoys me.
My EMMC had a fresh install on it. My previous install that I had on a microSD I moved to USB. I put that in, and booted from EMMC - and it grabbed the root partition from USB.
So, the grub config isn’t going by disk UUID, which is absolutely insane to me. Arch recommends you do UUID by default, for this exact reason.
Funny enough though, just from that limited time using it, there was DEFINITELY a noticeable improvement in system smoothness. This is encouraging.
I will play with it more later. I’ve now stayed up all night tinkering, which was dumb of me. The keyboard also stopped working (I have it in a laptop chassis) - which I’ve seen is a not uncommon problem with the 13 inch boards, so, I’ll have to figure that out too. Fun.
Hmm interesting, I’ve had no issues whatsoever with the keyboard, I have one from the presale program, lucky maybe?
Jeah on my eMMC I have it set up to use UUID.
My biggest issue right now is that it takes very long to load the kernel in grub, I believe there is a fix already out there, I believe it is actually related to the keyboard polling if I’m not mistaken.
Can you post a little note on what you did to get Arch up to date on this? I switched from fedora to ubuntu already and am looking pretty good, but not using the 6.13 kernel like you and have an ancient version of firefox, I could build from scratch but if arch is looking good might play over there.
just arch is not really workable right now, you will have to build your own kernel. The kernel I run doesn´t have gpu acceleration and many other features, you might be able to install firefox but it will be unusable.
I have not yet put a lot of effort into getting the 6.6 vendor kernel working with arch.
In all practicality you’ll still be building from scratch.
But I’ll post a bit:
pacstrap an archriscv rootfs, very similar to the arch wiki but tweak some stuff to use the archriscv sources instead of upstream arch. some info here
build the kernel from what source you want here is my source do a make defconfig and you’ll have a pretty minimal config to get it booted (plus whatever it takes to cross compile/install)
I ordered one of the first waves of mainboards and 13 inch chassis packages. I’ve been really enjoying using the RISC-V Fedora and Ubuntu images inside the chassis but wanted to use the UART/Serial port that was documented on USB port 4 (right side further from the hinge). I designed a simple expansion card to JST and pin header while I wait for the parts to arrive from overseas. I designed this to use with my raspberry pi debug probe and thought that it would be useful for the rest of the group that wants to use the serial channel.
So… I finally have my own RISC-V board up and running after wrestling with incompatible SD cards and having to swap out the 2.8k display. Got Fedora on a 256 gb card now, and it’s OK, though lacking in the multimedia department, and uBlock Origin and Ghostery both seem to mess Firefox up somehow so that it won’t load pages at all.
I’m left with many questions now, including:
• What eMMC would be compatible?
• What would the process be to transfer my SD card installation to it, or what would I have to do to install a fresh system on it?
• Would Ubuntu offer a better experience? I am not eager to redo this SD card after having so much trouble getting any card to work at all. The system hated both 64 gb SanDisk Ultras that I tried, as well as a 128 gb Samsung.
Part of why I went ahead with this crazy experiment is that my AMD board was poorly behaved with every Linux distro I tried. I figured it would be nice to try a RISCy alternative, even if it’s not a consumer-oriented product. I have a couple of Pis and know how janky the experience outside of x86 or Apple can be, but alternatives to x86 are still fairly rare and less than ideal for various reasons.
It’s “janky” IMO because x86 for a long time has had autodiscovery features where the operating system can probe various busses/systems for hardware along with the bios feeding it information about what’s available. ARM has relied on device trees to do the same but they have to be provided for every device, though this is getting better as there is now a way of the bios providing this to the kernel on boot. However not even the brand new snapdragon ultra processors are doing this thus it’s taking a while to get those devices working.
On top of that, arm devices typically use things like gpus that are, I’ll say, allergic, to providing open source drivers. While they might work on Android and ChromeOS, they’ll have proprietary drivers (like Nvidia) that are made for the very specific kernel version they’ve shipped with, and without an update from the manufacturer, won’t be compatible with any other kernel version. This is why for some devices you might have to choose between an older kernel that provides GPU acceleration vs. a newer kernel that does not.
Thus, it’s not really the processor architecture that’s “janky”, it’s the ecosystem around it. A lot of people are wanting ARM or something else to take over the CPU landscape, and maybe it’s time for that, but I hope before that happens we have some sort of standard autodiscovery mechanism to make it as easy as it is today to throw a distro on new hardware it wasn’t designed for and just have it work.
Absolutely. x86 has been developed into a standard, but at the center of it is something proprietary, and that’s a crying shame. No better than having Microsoft’s OS and office products treated as de facto standards. I love the idea of computer hardware and software being 100% open, with manufacturers adding value on top of that free IP. I hope RISC-V will evolve into something like this, an entirely open computing standard.
While the CPU architecture is open, if it’s ever used by mainstream manufacturers, you can bet that the firmware/bios/whatever you want to call it will be closed source and locked down. It has to be for something like Secure Boot to “work,” which is never going to go away. Those of us that actually care about things being open are a tiny minority; the sad truth is that most people see their computers as just an appliance they use to access the internet.
Moving it over is going to be interesting, I have a usb eMMC adapter which helps a lot. But you might need to do some funky bootloader stuff if you want to do it on the laptop itself. By default it will load the efi partition from the sd-card first. So whatever is at /efi/boot/boot*.efi on the efi partition of the sd-card. If there is nothing there it should switch over to checking the efi partitoin on the eMMC module.
waiting for the imagination gpu driver to get upstreamed got me like
There is something happening in the imagination/riscv space though, but different SoC, but I think that when that one is upstreamed it should not be a very big deal to get the one in the jh7110 upstream aswell.
But yeah this needs to get in first but it seems to have kind off died.
I’m open to doing a fresh install using an adapter as well. If it’s as simple as flashing it in Balena Etcher like I flashed the SD card and flipping the dip switches to boot from the eMMC, I’d certainly be willing to give that a try.
