guerby has quit [Read error: Connection reset by peer]
guerby has joined #riscv
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
pabs3 has joined #riscv
Gravis_ has quit [Ping timeout: 252 seconds]
Gravis has joined #riscv
jmdaemon has joined #riscv
jacklsw has joined #riscv
<solrize>
no i just saw the mention of DAP in that article and wanted to know what it was. although, in the pine64 Ox risc-v board, apparently the uart doesn't work too well
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #riscv
Leopold has joined #riscv
<smaeul>
several of the complaints about the Ox64 UART turned out to be a misunderstanding about how the BOOT button works (you have to hold it down while applying power to enter flashing mode)
<smaeul>
once that was cleared up, the non-working USB-UART adapters magically started working
vagrantc has quit [Quit: leaving]
<solrize>
interesting thanks
BootLayer has joined #riscv
billchenchina has joined #riscv
elastic_dog is now known as Guest6674
Guest6674 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
bjoto has joined #riscv
bjoto has quit [Ping timeout: 268 seconds]
eroux has quit [Read error: Connection reset by peer]
eroux has joined #riscv
raym has quit [Ping timeout: 255 seconds]
eroux has quit [Ping timeout: 264 seconds]
eroux_ has joined #riscv
eroux_ has quit [Remote host closed the connection]
eroux has joined #riscv
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #riscv
junaid_ has joined #riscv
Leopold_ has joined #riscv
Leopold has quit [Remote host closed the connection]
eroux has quit [Remote host closed the connection]
eroux has joined #riscv
___nick___ has joined #riscv
jacklsw has quit [Ping timeout: 255 seconds]
ldevulder has quit [Quit: Leaving]
ldevulder has joined #riscv
raym has joined #riscv
BootLayer has quit [Quit: Leaving]
XYZ has quit [Ping timeout: 268 seconds]
ldevulder has quit [Ping timeout: 256 seconds]
cousteau has joined #riscv
tusko has quit [Remote host closed the connection]
tusko has joined #riscv
BootLayer has joined #riscv
junaid_ has quit [Remote host closed the connection]
junaid_ has joined #riscv
XYZ has joined #riscv
XYZ has quit [Read error: Connection reset by peer]
XYZ has joined #riscv
Andre_H has joined #riscv
Starfoxxes has quit [Ping timeout: 255 seconds]
Starfoxxes has joined #riscv
rneese has joined #riscv
bjoto has joined #riscv
iooi has quit [Quit: iooi]
jmdaemon has quit [Ping timeout: 252 seconds]
jacklsw has joined #riscv
junaid_ has quit [Ping timeout: 255 seconds]
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #riscv
Bluefoxicy has quit [Ping timeout: 272 seconds]
Bluefoxicy has joined #riscv
<bjdooks>
hmm, sparse doesn't recognise a pile of the riscv z arch extensions :/
junaid_ has joined #riscv
<conchuod>
Yah, and the sparse maintainer is awol
<bjdooks>
i never finished my va-arg updates :/
<conchuod>
palmer sent patches for the extensions that've been merged
<conchuod>
and then suggested that sparse be re-worked to ignore the extensions in the future
<palmer>
or at least make it a warning or something, IIRC I had a patch that did that as well
<palmer>
yep, I'm just using my sparse tree until it gets sorted out ;)
<palmer>
not really sure what else to do here
<somlo>
does anyone know what the significance of "linux,initrd-end" is in the "chosen" section of a devicetree blob?
<somlo>
this is loosely risc-v related (I'm "manually" loading opensbi, kernel, and initrd images to RAM before jumping to the start of opensbi to boot linux)
<somlo>
and I was unable to figure out if `linux,initrd-end` should point to the ram address immediately following the end of the gzip-compressed initrd (i.e., the blob as I am loading it into RAM), or *uncompressed* initrd (i.e., leave enough room for the uncompressed image to fit)?
* bjdooks
fires a few simple warning fixes at the nouveau driver
<smaeul>
conchuod: should I rebase v4 of my D1 series on v6.2-rc1 or on soc2arch-immutable?
<conchuod>
There's probably no harm in basing it on that tag, right?
<conchuod>
palmer: do you have the patch that downgrades to warnings anywhere?
<conchuod>
note to self: we should go turn sparse on for patchwork bjoto
<palmer>
conchuod: it's on the list, if you can't find it I can go try and find it myself ;)
<bjoto>
conchuod: I'm looking at your sparse tree now... :-)
<bjoto>
Got the right patches in it. :P
<palmer>
smaeul: IMO the general rule is "base your patches on the earliest branch that makes sense". The latest rc1 is usually fine (as would be the previous rc1). If there's going to be a merge conflict then just either point it out or rebase, I'm fine either way as long as you're clear about what you're doing
<conchuod>
Yah, I think I found it palmer. I didn't realise only part of that series from ages ago had been applied.
<palmer>
IIRC the whole thing was sort of just re-spun
<smaeul>
palmer: I need to respin anyway due to the SIFIVE_PLIC selection getting reworked. With v6.2-rc1 there is a conflict, but it's trivial, so I think I'll choose that
<conchuod>
oh ye smaeul dw about the gpio fan thing for application since it seems to be on the way now
<conchuod>
bjoto: I'll pull in palmers other series for sparse & add it there. I use that in my CI so I'll keep it up to date.
<palmer>
FWIW, I have a kernel.org sparse tree and that's what I'm using for testing
<palmer>
so if you just point there it'll get updated when I have a patch I need ;)
<conchuod>
Yah, that sounds better yet
vagrantc has joined #riscv
<palmer>
OK. I have some sparse setup (the "don't break on warnings" flavor) running pre-merge, so that tree should always be OK
<palmer>
don't remember about branches and such, though, as it was a few months ago
<bjdooks>
hmm,
<bjdooks>
fs/aio.c:2073:21: warning: Using plain integer as NULL pointer
* cousteau
isn't completely sure that should be a warning if the integer is a constant 0...
<conchuod>
Just do s/zero/NULL to silence that
<conchuod>
and make it unambiguous
<cousteau>
that too... if you meant NULL, write NULL
<bjdooks>
ah, it's the get_user() code that initialised the result to 0
<conchuod>
palmer: hmm, your riscv-wip branch on there gives me a crap-tonne of extra warnings out of sparse.. I'll keep to just the riscv-zicbom branch I think!
<conchuod>
ah, the wip one is just out of date & needs a rebase
junaid_ has quit [Remote host closed the connection]
<conchuod>
Bjdooks there's hundreds in allmodconfig :/
<conchuod>
I think we got rid of all bar one whenever we had a go at it last
<conchuod>
All bar one in arch/riscv*
<palmer>
I'm happy to turn on some check if there's a way to make them fail, but there tends to be so many issues in drivers I've just given up
jay2718 has joined #riscv
rodrgz has left #riscv [#riscv]
___nick___ has quit [Ping timeout: 272 seconds]
___nick___ has joined #riscv
rneese has quit []
<conchuod>
Nah there's just too many. Best thing is to make patchwork object if someone adds a new one
EchelonX has joined #riscv
<drewfustini>
I'm trying to enable the sign extend badaddr SiFive errata. I've enabled the kconfig option and added debug prints at the beginning of all the SiFive errata functions. However, I don't see them run.
<drewfustini>
Anyone have ideas about what might be gating that code running?
<drewfustini>
I have CONFIG_ERRATA_SIFIVE=y and CONFIG_ERRATA_SIFIVE_CIP_453=y
<drewfustini>
I added a pr_err() at the beginning of errata_cip_453_check_func() but I don't see it run
<drewfustini>
I am missing something but just not sure what exactly
Andre_H has quit [Ping timeout: 252 seconds]
<drewfustini>
The boot process does not actually finish on this system so I suppose I am not getting to the point where the errata would run... but I had thought that would happen in early boot
<drewfustini>
I should that this is not a SiFive SoC but I commented out the part of errata_cip_453_check_func() that checks the cpu version.
<drewfustini>
This SoC has a CPU with a sign extend error on STVAL so I was hoping that SiFive CIP 453 might help. It may well not help, but I'm confused why I can't get the errata to apply in early boot
<drmpeg>
drewfustini: I think arch_id has to match the SiFive magic number.
<drmpeg>
in arch/riscv/errata/sifive/errata.c
<drmpeg>
Sorry, missed your comment.
epony has quit [Ping timeout: 268 seconds]
<drewfustini>
Thanks, I might try overriding arch id to see if that can trick it.
<drewfustini>
I suppose the alternative is to add a new errata for the SoC I'm using and copy the assembly from CIP 453
<drmpeg>
It looks like it runs much later. Back in June, there was a small bug with it, and here's a picture I took. https://www.w6rz.net/errata.png
<drmpeg>
Pretty far in. After kernel modules are loaded.
<drmpeg>
And systemd is running.
epony has joined #riscv
catern has quit [Ping timeout: 260 seconds]
Trifton has quit [Quit: Error: no route to host]
<drmpeg>
I'll build 6.2-rc1 so see exactly when it happens.
BootLayer has quit [Quit: Leaving]
___nick___ has quit [Ping timeout: 272 seconds]
<drewfustini>
ah! very interesting, thanks for that
<drewfustini>
I'll take at a look at how some of the newer alternatives for thead work that I believe happen at early boot at for things like MMU
<drmpeg>
It runs multiple times. I want to make sure I show you the first time.
<drmpeg>
I'll have something in a little while.
<drewfustini>
The boot always fails with "Unable to handle kernel paging request at virtual address 00008f80020a0000" in copy_process() so I suppose I could make a hacky fix in there to better understand what is happening.
<drewfustini>
I think the sign extend error for STVAL in this processor means that badaddr is incorrect (it looses the high bits). I think that actual cause of the exception is misaligned access but I need to figure out a way to demonstrate that
<drewfustini>
I added pr_err("DEBUG ...") at the beginning of each function in arch/riscv/errata/sifive/errata.c so I thought I would have seen that output.
<drewfustini>
My config has CONFIG_ERRATA_SIFIVE=y and CONFIG_ERRATA_SIFIVE_CIP_453=y so I thought that those functions would at least get called
<drewfustini>
The hart I'm running on is based on BOOM and not SiFive but I thought that those functions would at least get called since I have those as yes in my config
<drmpeg>
I also have CONFIG_SOC_SIFIVE=y in my .config.