sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Backup if libera.chat and freenode fall over: irc.oftc.net
devcpu has quit [Ping timeout: 272 seconds]
devcpu has joined #riscv
jbowen has joined #riscv
iorem has joined #riscv
<geist> irc
<geist> heh, wrong window. that's my bash alias to connect to a screen session
jbowen has quit [Quit: leaving]
FluffyMask has quit [Quit: WeeChat 2.9]
jbowen has joined #riscv
jbowen has quit [Quit: leaving]
jbowen has joined #riscv
frost has joined #riscv
frost has quit [Ping timeout: 240 seconds]
frost has joined #riscv
frost has quit [Client Quit]
frost has joined #riscv
frost has quit [Client Quit]
frost has joined #riscv
justyb11 has joined #riscv
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
peepsalot has quit [Read error: Connection reset by peer]
pierce has joined #riscv
pierce has quit [Ping timeout: 256 seconds]
mahmutov has joined #riscv
mahmutov has quit [Ping timeout: 240 seconds]
pabs3 has quit [Ping timeout: 272 seconds]
smartin has joined #riscv
Sos has joined #riscv
pabs3 has joined #riscv
davidlt has joined #riscv
GreaseMonkey has quit [Ping timeout: 240 seconds]
greaser|q has joined #riscv
valentin has joined #riscv
<sirn> I'm currently running 5.11 kernel with patches from meta-sifive 2021.04.00 (for a distro port), and getting `hwclock: Cannot access the Hardware Clock via any known method.` error when accessing hwclock. is hwclock still unsupported or is there any patches i need to apply?
hendursa1 has joined #riscv
hendursaga has quit [Ping timeout: 252 seconds]
iorem has quit [Ping timeout: 272 seconds]
greaser|q has quit [Changing host]
greaser|q has joined #riscv
greaser|q is now known as GreaseMonkey
<enthusi> hm, I have x crashes with Radeon 6450 in FreedomUSDK on unmatched
<enthusi> [ 1229.813678] radeon 0000:07:00.0: ring 0 stalled for more than 10244msec
<enthusi> [ 1229.819573] radeon 0000:07:00.0: GPU lockup (current fence id 0x0000000000001574 last fence id 0x0000000000001578 on ring 0)
<enthusi> has anyone seen similar things?
Andre_H has joined #riscv
psydroid has quit [Quit: Bridge terminating on SIGTERM]
CarlosEDP has quit [Quit: Bridge terminating on SIGTERM]
ahs3[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
demostanis[m] has quit [Quit: Bridge terminating on SIGTERM]
llamp[m] has quit [Quit: Bridge terminating on SIGTERM]
llamp[m] has joined #riscv
demostanis[m] has joined #riscv
CarlosEDP has joined #riscv
psydroid has joined #riscv
ahs3[m] has joined #riscv
khem has joined #riscv
<sirn> (hwclock issue) I just found a mention that RTC clock is not supported yet on SW Reference Manual; I guess this behavior is expected.
<enthusi> thanks for your input. However I would expect this to be more wide spread then?
<enthusi> they explictly mention the Radeon HD 6450 to be most widely used
iorem has joined #riscv
<sirn> enthusi: sorry for confusing message; I was replying to my own issue from an hour ago
<enthusi> ah, ok. Sorry and thax for clearifying
<sirn> by the way, Radeon 6450 is using `radeon` driver rather `amdgpu` right?
<sirn> I remembered seeing this ring 0 stall message with x86 machine too, it's a bug within the driver
<enthusi> yes, and while I heard it is less maintained it still is listed as 'most used'
<enthusi> (if you google deep enough you see people resoldering the chips to solve this... hmmm)
<enthusi> maybe I should go for the rx550 instead
<sirn> wonders if the "most widely used" was referring to pre-production testers, since from what I've seen in the forum/reddit is most people either use RX 500 series or GeForce 750/1080 (with nouveau)
<sirn> I'm using RX 560 (amdgpu driver) and it has been pretty stable; newer cards than RX 5xx doesn't seems to work at all though.
<enthusi> just ordered a used rx 550 now
<enthusi> fingers crossed and thanks :)
<sirn> good luck!
jotweh has quit [Quit: Konversation terminated!]
<davidlt> sirn, I have tested RTC to be working properly, but currently there is no support for DA9063 particular variant in upstream
<davidlt> note that there are no patches, because whatever I did to test it was not a proper thing for upstream
<davidlt> enthusi, Radeon HD 6450 was really popular with Unleashed + Expansion board, cheap also
<davidlt> enthusi, right now RX 500 series probably is more popular, but way more harder to get due to the current market situation
<sirn> davidlt: I see, thank you! I guess I'll have to wait until the variant was upstreamed (was wondering if I misconfigure anything)
<davidlt> sirn, upstreaming is still WIP (linux, u-boot, opensbi)
<davidlt> enthusi, I suggest to try a different FUSDK release (basically anything after 2021.03.01 should work)
<davidlt> or a different GPU if you have
<sirn> davidlt: thank you for your work! looking forward to see these patches upstreamed. right now patches in meta-sifive is working great for my distro porting attempt :-)
<davidlt> some of that (e.g. u-boot) just landed in upstream
<davidlt> so there is now basic support in u-boot upstream (by basic I mean it boots)
rah has quit [Quit: lols]
rah has joined #riscv
rah has quit [Client Quit]
Guest38 has joined #riscv
rah has joined #riscv
<sirn> ah nice, is that for 2021.07? or would it be included in other release?
<davidlt> 2021.07, but it will not have everything upstream
<sirn> I see.
<davidlt> e.g. network doesn't work due to missing I2C EEPROM driver (which is needed to get serial number and MAC address)
<davidlt> There is no SPI-NOR Flash boot mode, so you cannot place firmware in the SPI-NOR Flash
<davidlt> there are probably more things
<davidlt> Canonical posted a patch recently to sort out fdtfile name for extlinux support
<davidlt> Bin just posted a patch to enable microSD card detection pin
<sirn> Hmm I guess patches from meta-sifive is still required for the time being then, even after u-boot 2021.07 is released
<davidlt> yeah, I plan to rebase U-Boot so the number of patches will be smaller
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
Guest38 has quit [Quit: Client closed]
Guest38 has joined #riscv
<enthusi> davidlt: Hi, I run may version but just ordered an used rx550 and hope for it to arrive soon! Thank you!
<davidlt> enthusi, I have RX550 and RX580 for testing
<davidlt> ops, RX570
<enthusi> 550 and 570?
<enthusi> they are widely available as 'used' ~ 100-130 eur at least
<davidlt> IIRC that used to be "new" price point :)
<sirn> I got my 560 around $120. managed to grab it the moment the seller put it on sale :p
<sirn> tried to find a "new" one and it was like $800...
<davidlt> yeah, the prices are ridiculous right now
<davidlt> even for multiple years old GPUs
<davidlt> not for the current one, which goes up to 1500-3000 USD/EUR range these days
<enthusi> yeah, but I dont think these age alot (technically)
<enthusi> unless there's cuda I dont see what do to with a high end GPU on the unmatched but then again, Im not much into AI either
TwoNotes has joined #riscv
zjason has quit [Ping timeout: 252 seconds]
zjason` has joined #riscv
<davidlt> Also with RX550 you can run Vulkan
* jrtc27 grumbles at the lack of an sd host controller on the unmatched
<jrtc27> would it really have been that hard to add?..
<jrtc27> SD/MMC-over-SPI is no fun
<davidlt> jrtc27, don't use it ;) keep it only for the firmware
<davidlt> you can boot with rootfs on USB or NVMe
<davidlt> You only need microSD card for two partitions that hold the firmware
<jrtc27> it'd be a bit sad if it didn't work, and you just know users are going to want to use it
<sirn> I've come to accept that SD slot on the board is there for OpenSBI and u-boot
<jrtc27> no, that's the on-board flash
<jrtc27> which I assume can be flashed similarly to the unleashed
<davidlt> yes, but it's currently not enabled in U-Boot (something to upstream)
<jrtc27> and as soon as there's documentation for where to write to I will do that so I can ditch the stupid fsbl+u-boot partitions from the sd card...
<davidlt> out of the factory SPI-NOR Flash is empty thus people don't have something that's too old out of the box
<davidlt> Back in Unleashed times the DTB in SPI-NOR was extremely not OK for upstream stuff IIRC
<davidlt> We used to patch it up in OpenSBI because no one wanted folks to attempt flashing the board and bricking it
wingsorc has quit [Quit: Leaving]
Guest38 has quit [Ping timeout: 250 seconds]
choozy has joined #riscv
Sos has quit [Quit: Leaving]
Sos has joined #riscv
iorem has quit [Ping timeout: 268 seconds]
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
zjason` is now known as zjason
<xentrac> happy John TUkey day
psydroid has quit [Changing host]
psydroid has joined #riscv
<rjek> I think I would have gone for an RTC battery to be included and not a shielded patch lead
<rjek> Esp. given it's not a CR262
SpaceCoaster has joined #riscv
SpaceCoaster has quit [Client Quit]
SpaceCoaster has joined #riscv
SpaceCoaster has quit [Remote host closed the connection]
mhorne has quit [Read error: Connection reset by peer]
mhorne has joined #riscv
ln5 has quit [Changing host]
ln5 has joined #riscv
jrjsmrtn_ has joined #riscv
iorem has joined #riscv
jrjsmrtn_ is now known as _jrjsmrtn
<rjek> god, that fan
<sirn> I think a lot of us swapped the fan for a 40mm one
<rjek> How hot does it get? There are two chassis fans pointing at it in this case :)
<davidlt> rjek, you are most likely fine with two fans
<davidlt> rjek, the newer FUSDK releases program critical temperature for SoC to be 85C
<sirn> I replaced the CPU fan with Noctua NF-A4x10, with 120mm as an intake. have been building packages continously for >14h, temp is sitting at 34c (mb) 42.2c (cpu)
<davidlt> that's nice temps
<rjek> Aww I'm gonna have to build my own kernel because the SDK one doesn't include LVM
<rjek> Is there an official repo for the kernel for it?
<davidlt> no, it's within patches part of FUSDK
<rjek> argh
<davidlt> git am quickly generates what you want
* rjek begs to know why :)
<davidlt> rjek, most of things are upstream now
<rjek> Anything essential that is not?
<davidlt> fixes to DT
<davidlt> are the most important that's left
<davidlt> errata and PCIe landed in 5.13
<rjek> really, the kernel should be entirely seperate from some OpenEmbedded project - people are going to want to use other things
<davidlt> git am *.patch will apply all the patches on top of whatever kernel version you want
<rjek> Yeah but I don't want to have download and unpack the universe :/
<davidlt> a shallow clone should be cheap
<sirn> I'm using my own kernel (still 5.11 here), and patches from meta-sifive applies cleanly :-)
<rjek> When this should just be a git repo with just the kernel and local changes in
<davidlt> the FUSDK is updated at least once a month, that's a lot of branches to keep around
<rjek> It really isn't, branches are cheap
<rjek> It's just a release tag really anyway
<davidlt> this way you can save a tarball and reproduce the build a year or two away
<rjek> Yeah you can do that keeping it in git instead of as patches in git too :)
<rjek> (See BuildStream, for example)
<davidlt> makes a little bit harder for people who want to do builds without internet connectivity
<davidlt> (assuming you have source tarballs cached in your premirrors or local mirrors within an organization)
<rjek> That's a somewhat small niche
<rjek> atm they can't get hold of it at all without the internet :)
<davidlt> FUSDK is not really a distro replacement, it's a more of a demo
<rjek> Indeed, that's why I want to replace it with something else, and as such just having the kernel easily accessible would be a win for people wanting to do stuff
<davidlt> Most people will use Debian, Fedora, Ubuntu, OpenSUSE, etc.
justyb11 has quit [Quit: Leaving]
<rjek> Also I don't want repo or bitbake anywhere near me :(
* sirn hope to have void linux join that list soon
* rjek notices that the latest release doesn't have the dtb or an extlinux folder in /boot, and not being in the boot to brick the thing on day one or faff about with repo and git, will just use the 5.11 that shipped with it for now
<sirn> hmm, I'm sure fusdk's rootfs.wic.xz has all the extlinux/dtb/etc.
<rjek> the tar doesn't
<rjek> I just watched to fish the stuff out from /boot rather than blat an SD card
<TwoNotes> It it better to avoid using MMU 4KB pages (saving TLB space) even if it wastes a couple MB of Physical RAM space?
aburgess_ has joined #riscv
<jrtc27> rjek: just use efi?
<jrtc27> I don't know why it's using extlinux in the first place...
<jrtc27> or has the linux world not yet caught up to efi on riscv?..
aburgess has quit [Ping timeout: 244 seconds]
peeps[zen] has joined #riscv
<rjek> jrtc27: It's already booting a kernel, it's software that's so short lived I don't care what it is
<rjek> (Also EFI is just as terrible as U-Boot)
<jrtc27> U-Boot *is* EFI
<jrtc27> among other things
* rjek notes it can't reboot itself
* rjek pops downstairs to powercycle
<jrtc27> yeah this is another known issue...
<rjek> OOI, what is the other UART channel on the FTDI used for?
<jrtc27> JTAG
<rjek> Right OK, I suppose I can't reboot it easily via that
<jrtc27> hm, you could use the debug module to reset the harts
<palmer> assuming this new chip works like all the others, the debug module only reset a subset of the chip and can leave you in awkward states
<rjek> Something for somebody who knows more about the hardware than I to do and write a nice HOWTO I think
<enthusi> davidlt: after a few days I feel like FUSDK is (currently) the best OS for the unmatched
<enthusi> but, indeed, compiling several things of it reminds one of the painful lack of package repositories
FluffyMask has joined #riscv
davidlt has quit [Ping timeout: 240 seconds]
iorem has quit [Quit: Connection closed]
_whitelogger has joined #riscv
aburgess has joined #riscv
aburgess_ has quit [Ping timeout: 272 seconds]
valentin has quit [Quit: Leaving]
radu2422 has joined #riscv
Narrat has joined #riscv
<jemarch> IT BOOTS!!!!
* jemarch dances in circles and jumps up and down
radu2422 has quit [Quit: The Lounge - https://thelounge.chat]
radu2422 has joined #riscv
vagrantc has joined #riscv
Sos has quit [Quit: Leaving]
Sos has joined #riscv
<rjek> Yeah I've got it booting straight into Debian now that I mmdebstrapped onto the NVMe.
<rjek> There is a kafkaesque boot setup in U-Boot, it might be possible to boot from the NVMe without the SD card at all, perhaps a project for tomorrow
mahmutov has joined #riscv
pjw has quit []
pjw has joined #riscv
<TwoNotes> If sstatus.SPP is zero, I am in S-mode, and do an sret, the processor will drop to U-mode, correct? The priv spec does not come right out and say this.
<sorear> TwoNotes: look under the description of the mstatus reg "When executing an xRET instruction, supposing xPP holds the value y, xIE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1; and xPP is set to U (or M if user-mode is not supported)."
frost has quit [Ping timeout: 268 seconds]
<TwoNotes> Elsewhere it says that the modes are U=00, S=01, M=11 and 10 is reserved. The SPP field is one bit. Apparently it is the low-order bit - they just do not come right out and say that
Sos has quit [Quit: Leaving]
<geist> yah it's a bit obtuse. it's like the docs dont say anything more than absolutely minimum
<geist> but i do remember puzzling over that too
<geist> effectively it's a 2 bit field but the top bit can't be set to 1 during sret or you're in trouble. i'd prefer it to be mentioned that way instead of trying to be clever here
<geist> thoguh i guess if it literally can't be set to 1 then that saves a few transistors, so strictly speaking it's actually beneficial to spec it as MBZ
<sorear> if it were a 2 bit field you'd (a) need to prevent S-mode from using sret to elevate privilege (b) you'd waste one of 32 precious bits in mstatus
<geist> in general though i dont like how the sections are segmented into M S and U stuff. some of those register sets, *status one in particular, would i think be much more clearly described in a section where it puts mstatus/sstatus/status right next to each other, then it's obvious how parts of it 'turn off' as you go to lower priviledged modes
<xentrac> yah
<geist> but since all the modes but M are optional, it's described as is
<geist> yeah re-reading it now it's definitely pretty confusing. the section on the mstatus register is halfway descrbigin the mstatus one, but then going through a fairly obtuse way of also describing how it is for lower levels
<geist> and i get the jargon, but its pretty confusing the first time you read it
<geist> though i'm using the last released one. may have been rewritten on the current spec
<sorear> as much as I hate how it makes the intel and arm specs five times longer, there's probably no way to make this completely clear without pseudocode
<geist> yah
Forty-Bot has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<geist> in this particular case i think it'd help if section 3.1.6 (mstatus register) also showed a picture of the sstatus and ustatus. since it all over the text after it refers to lower priviledged views of the register and how in mode 'x' you only get this or that
<geist> it's that whole mode x stuff that's sort of understandable once you grok the whole thing, but i think a picture is probably worth a thousand words
<geist> but then actually having a picture of sstatus there would violate the layout of the doc because theres a sectino later that does, so it's kinda painted into a corner via layout
<geist> perhaps a few hyperlinks there would help
meowray has joined #riscv
radu2422 has quit [Quit: Ping timeout (120 seconds)]
<dh`> part of the problem is that mstatus, sstatus, and ustatus shouldn't be separate registers, they should be views of the same register
radu2422 has joined #riscv
<dh`> since (a) they really are anyway and (b) there's nothing especially useful to be gained by accessing a different mode's status view directly
<dh`> the only counterargument I can think of is that the current organization potentially lets a hypervisor avoid needing to take a trap when the guest accesses ustatus... except that in practice it probably needs to anyway
<dh`> but griping about how the privileged spec is borked isn't productive :-|
mahmutov has quit [Ping timeout: 268 seconds]
<geist> heh, yah but knowing what the sharp edges are still helps us help folks that are just reading it and may ask questions
mahmutov has joined #riscv
<geist> if i find a real bug i'd definitely try to push a fix in, but some of my gripes about the doc are stylistic and organizational, so i figure there's probalby little point trying to actually fix it
<geist> and i'm sure lots of folks would disagree, etc
<TwoNotes> I agree putting all the *Register explanations together would be clearer
<TwoNotes> mcasue, scause, etc
davidlt has joined #riscv
Sos has joined #riscv
cousteau has joined #riscv
<jrtc27> hmm
<jrtc27> it's a shame reset-gpios for the fu740 dw pcie isn't marked GPIO_ACTIVE_LOW
<jrtc27> but can't change that now otherwise it'll break linux....
<jrtc27> grrr
Narrat has quit [Ping timeout: 272 seconds]
Narrat has joined #riscv
davidlt has quit [Ping timeout: 244 seconds]
Narrat has quit [Ping timeout: 244 seconds]
Narrat has joined #riscv
ewdwasright has joined #riscv
ewdwasright is now known as tbotty2702
tbotty2702 is now known as ewdwasright
Sos has quit [Quit: Leaving]
ewdwasright has quit [Quit: Leaving]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
aburgess has quit [Remote host closed the connection]
aburgess has joined #riscv
riff_IRC has joined #riscv
riff-IRC has quit [Ping timeout: 240 seconds]
cousteau has joined #riscv
cousteau has quit [Client Quit]
Sos has joined #riscv
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
mahmutov has quit [Ping timeout: 264 seconds]
Andre_H has quit [Ping timeout: 272 seconds]
smartin has quit [Quit: smartin]
elastic_dog has quit [Ping timeout: 272 seconds]
Forty-Bot has joined #riscv
elastic_dog has joined #riscv
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
iorem has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
vagrantc has quit [Quit: leaving]