<GreaseMonkey>
the bigger question is probably more "where do i find an image that can actually work on this thing"
<GreaseMonkey>
there's an eval image from 2018
<jrtc27>
you don't yet
<jrtc27>
it's extremely new
<vagrantc>
you make it yourself :)
<jrtc27>
aha and here's vagrantc
<jrtc27>
:)
<GreaseMonkey>
maybe i'll grab an unleashed image and use the kernel on the SD card
<GreaseMonkey>
also is it normal for this to hang horribly on networkmanager
<vagrantc>
GreaseMonkey: so far i've managed to boot to the shipped OS, git clone https://salsa.debian.org/.../debootstrap and run debootstrap directly from git onto a new partition
<vagrantc>
GreaseMonkey: and then tweaked extlinux.conf to pass the argument to use that as a rootfs
<GreaseMonkey>
thanks, i'll try that, but first i should probably power this off and remove this GPU
* vagrantc
wonders if there are affordable, low-power GPUs available for the pcie slot
<GreaseMonkey>
at the moment these are known as "second-hand GPUs"
<vagrantc>
even ancient GPUs seem like massive power hogs
<vagrantc>
pretty happy with headless anyways, but wondered if maybe i shouldn't try to actually use it as a desktop for kicks
<GreaseMonkey>
vagrantc: which debootstrap path did you clone?
<vagrantc>
GreaseMonkey: how to run it is in the README
<vagrantc>
GreaseMonkey: you may have to pass --arch=riscv64 (since it's on a different OS)
<GreaseMonkey>
alright
<GreaseMonkey>
formatting the hard drive now
<vagrantc>
not sure if it'll support loading u-boot off of nvme at some point, but you might want to partition the spl/u-boot partitions on the disk in case it is someday possible
TwoNotes has quit [Remote host closed the connection]
<GreaseMonkey>
...i'm now getting stuff installed via apt and whatnot, thanks heaps for pointing me in the right direction
vagrantc has quit [Quit: leaving]
riff-IRC has quit [Quit: PROTO-IRC v0.73a (C) 1988 NetSoft - Built on 11-13-1988 on AT&T System V]
riff-IRC has joined #riscv
riff-IRC has quit [Remote host closed the connection]
<GreaseMonkey>
is there a newer kernel than 5.11.10 which fixes the really janky USB i'm getting?
<GreaseMonkey>
...or an older one if necessary?
<jimwilson>
Janky? Occasional keyboard/mouse disconnect is a documented problem, mentioned in the OpenEmbedded release notes. I don't think that the cause is known yet.
<jimwilson>
I think only UID (user interface devices) are affected.
<GreaseMonkey>
it also affects my USB sound card
<GreaseMonkey>
well, "card"
<jimwilson>
one of the usb connectors goes directly to the asmedia switch, and the other three are indirectly connected via another chip, you could check to see if it matters which usb connector it is plugged into, I think the special one is the one on the upper left when looking at the back of the board, it should be marked on one of the diagrams
<GreaseMonkey>
i may have my powered hub plugged into the special one
<jimwilson>
the board shipped with the SiFive OpenEmbedded 2021.03.1 release, we have been updating this monthly, so 2021.05 is the current one, and 2021.06 will be out next week probably, but as far as I know the usb keyboard/mouse problem is not fixed yet
<jimwilson>
it is getting late for me, I'm done for tonight
<GreaseMonkey>
alright, thanks for that
<dh`>
a lot of usb mice disconnect and reconnect once a minute or so if they aren't being used
<dh`>
wouldn't surprise me if keyboards did too
Sos has joined #riscv
mahmutov_ has joined #riscv
smartin has joined #riscv
valentin has joined #riscv
valentin has quit [Remote host closed the connection]
craigo has quit [Read error: Connection reset by peer]
<jimwilson>
I meant USB HID not UID, human interface device, I'm not a hardware guy
<jimwilson>
the release notes say that you might need to unplug and replug in your mouse/keyboard if they stop working, that isn't normal
<xentrac>
dh`: most keyboards don't do that, although I have had USB keyboards that crash and reboot at times. I notice because my custom keymap gets screwed up on this laptop when that happens
Skyz has joined #riscv
<GenTooMan>
interesting USB devices that "crash". It's more likely what happened is that it locked into an infinite loop and the watch dog reset event occurred resetting the keyboard.
<GenTooMan>
most simple embedded device use a single super thread event processing routine if it gets hung up in event processing then the watch dog doesn't get kicked and "boom" it resets.
<GenTooMan>
often within a few ms but some event loops are more horridly designed than others.
<dh`>
I've had usb devices that choked and needed to be power-cycled
<dh`>
can't remember details though
<GenTooMan>
ugh they didn't even have a watch dog reset? That's bad by design.
<GenTooMan>
hopefully RISC-V processors will have important things like resets for Power On Brown Out and watch dog for embedded use. Well one can hope, the soft cores are a bit more finicky.
devcpu has joined #riscv
<dh`>
just yesterday the flightstick, which has an led in the base that lights up when it's been moved recently, stayed on when I shut down the host machine
<dh`>
no idea why, but had to disconnect it to make it stop
<dh`>
somewhat more excusable issue, but still one to giggle about
<riff-IRC>
no S4 APM?
dionysos is now known as dilfridge
jeancf has joined #riscv
jeancf has quit [Ping timeout: 245 seconds]
smartin has quit [Quit: smartin]
<dh`>
dunno, seemed as if the firmware had shut down but accidentally left the led on, and I guess there's power available for it by default
<xentrac>
GenTooMan: lots of devices are bad by design, yeah
<xentrac>
and RISC-V being open-source guarantees that RISC-V devices will cover roughly the entire spectrum of quality, from nearly the best down to nearly the worst
<xentrac>
dh`: a lot of motherboards have some USB ports that are powered when the machine is "off" so you can have a power-on switch on the keyboard
<dh`>
right
<dh`>
also it's convenient for charging things
<xentrac>
usually it can't source a whole lot of current but yeah
vagrantc has joined #riscv
radu2422 has joined #riscv
<GreaseMonkey>
the fan on the Unmatched is quite loud, but unplugging it is really not a good idea, has anyone done something like hooking up a potentiometer to it?
<vagrantc>
heh. i added two more fans
<leah2>
GreaseMonkey: i replaced it with a 40mm noctua
<leah2>
works reat
<leah2>
great*
<GreaseMonkey>
leah2: alright, i'll have to work out how best to approach that
<olofj>
Without it, you get stuck looping on DataError on boot
<olofj>
... on DataFail, that is.
<olofj>
With that patch, seems like my board at least boots with current mainline.
<olofj>
vagrantc / GreaseMonkey : I just got debian going from nvme here, with the above patch + mainline kernel. debootstrapped on an x86 machine, tarred it up and moved it over. Built a kernel from within the chroot, installed u-boot, etc.
<vagrantc>
olofj: what version of kernel?
<olofj>
vagrantc: current mainline master as of a few days ago
<olofj>
Hm, some network config takes 5m to timeout too, might just be an artifact from the x86 bootstrap. I.e. network link comes up but it still sits there waiting until timeout.
<olofj>
It's slightly annoying that the yocto build doesn't enable CONFIG_BTRFS (the btrfs-progs are there though), which makes it a two-step process to move to debian on btrfs on nvme.
<GreaseMonkey>
olofj: ...that seems rather serious, i'm currently running the openembedded kernel though
<GreaseMonkey>
although it's the shipped one not the latest one but i should probably update it
<olofj>
Yeah, I was using the shipped one too for bootstrapping onto nvme.
<vagrantc>
olofj: oh, you could monkey-patch that .dts change in
<olofj>
Of course, which I did.
<vagrantc>
e.g. no need to recompile the kernel
<olofj>
To confirm above that it is what's needed as well.
craigo has quit [Read error: Connection reset by peer]