08:53 <dramforever> I've been trying to figure out the device tree stuff with AIA, and I've got pretty confused

08:53 <dramforever> For reference I've been reading the bindings here: https://lore.kernel.org/lkml/20230103141409.772298-1-apatel@ventanamicro.com/

08:54 <dramforever> And I've managed to prettify the QEMU dtb into a nicely readable and 'symbolic' dts here: https://gist.github.com/dramforever/83888cc2e0b8095e1d0890c336728674

08:58 <dramforever> 1. Should we have all the (wired) interrupts pointing to the S-mode APLIC, when in 'hardware' it's really connected to the M-mode APLIC? I'm thinking the most correct way is for the DT to say it's connected to the M-mode APLIC, and whatever handles riscv,delegate should rewrite the interrupt properties to refer to the S-mode APLIC. I don't know if this is a bad idea.

09:08 <dramforever> 2. It doesn't say anywhere about how guest interrupts are sent. Should it? Following riscv,cpu-intc, maybe we even need to add something to handle SGEIE/P and hgeie/p and make IMSIC refer to it in interrupts-extended?

10:11 <conchuod> dramforever: I don't think Anup is here. If you're confused about those bindings it'd be helpful if you commented on the thread.

10:31 <drmpeg> pabs3: I did install the OpenPGP key.

10:33 <drmpeg> Just some weird issues with the regular debian-ports.

10:33 <drmpeg> For example:

10:33 <drmpeg> wireshark: symbol lookup error: /lib/riscv64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform

10:37 <dramforever> conchuod: Good idea, somehow I got too focused on working on the DTB and didn't think to ask on email

10:37 <drmpeg> jrtc27: No spacers with the VisionFive 2.

10:38 <jrtc27> yeah I didn't get any, hence why I was surprised by the statement there were ones in the box...

10:39 <conchuod> dramforever: I'd like to avoid a repeat of the binding for the events that I know people are having issues creating for their hardware

10:39 <conchuod> pmu events*

10:40 <dramforever> mentioned the wrong person? i don't think i've ever talked about pmu events here

10:41 <conchuod> I know you haven't, but I know other people have

10:42 <dramforever> got it

10:42 <conchuod> Best time to get the bindings to a state that people can read and then go implement them is before their get accepted, not after.

10:43 <conchuod> they*

10:47 <dramforever> this current version definitely has more wtfs-per-minute than i'd like for something that's supposed to remain forever

10:47 <drmpeg> lol

10:49 <conchuod> I'd swear I saw a visionfive 2 review where they had metal standoffs in the box jrtc27 but I don't think I got them

10:50 <jrtc27> I wish I had some otherwise I wouldn't have pinched the ones that came with my unmatched

10:50 <drmpeg> I didn't get any. After buying a kit from Amazon, I now have enough spacers to last me until the year 2525.

10:50 <jrtc27> (with different screws.... one looked like it would short a resistor or something)

11:37 <pierce> ... here's me with two sets of standoffs which are going unused...

11:50 <conchuod> dramforever: thanks

11:51 <dramforever> yay

13:24 <pabs3> drmpeg: which version of libharfbuzz? probably a newer version will fix this

13:27 <drmpeg> 6.0.0+dfsg-3 Looks like the latest.

13:29 <pabs3> what does ldd say? ldd {/usr,}/lib/*/libharfbuzz.so.0

13:34 <drmpeg> Nothing obvious there.

13:35 <pabs3> is libfreetype.so.6 in the output?

13:35 <drmpeg> yes

13:36 <drmpeg> Which is in usr/local/lib

13:43 <pabs3> uh thats not from Debian

13:43 <pabs3> is libfreetype6 installed?

13:44 <drmpeg> yes

13:45 <pabs3> rename the usr/local/lib copy, that should fix the issue. also complain to whoever made the image

13:45 <drmpeg> There's a whole bunch of stuff on /usr/local/lib

13:46 <pabs3> IIRC mostly proprietary GPU drivers?

13:47 <drmpeg> Yeah, and X stuff.

13:55 <drmpeg> Renaming those files worked.

16:51 <rneese> so has anyone tested with emmc

16:51 <rneese> or just nvme

16:56 <rneese> 46 dollars just spent emmc 7 to 10 days from now

16:56 <rneese> https://shop.allnetchina.cn/collections/rock-pi-4-accessories/products/emmc-5-0-for-rock-pi-4-also-for-odroid?variant=15415843913830

16:56 <rneese> its says visionfive2 on the page

22:05 <geist> question: somene here might be familiar

22:06 <geist> when using qemu-system-riscv64 and -cpu rv64, it clearly takes some extension fields

22:06 <geist> but ,help or ,? doesn't tell me what the format is

22:06 <geist> and i can't find any documentation on it, the source isn't really even clear

22:06 <geist> any clues as to what the format is? abot to have to start adding printfs to the code to try to figure it out

22:09 <geist> i'm expecting something like `-cpu rv64,extensions=....` but of coruse that's not the case, but inside the `riscv_cpu_realize()` routine there's a bunch of code to parse things and dynamically set it up but can't figure out where the string is coming from

22:09 <geist> and the 'rv64' cpu in the code clearly is expecting to dynamically configure things, since it explicitly sets misa = 0 and then there's a comment that says 'the realize function will fill this in'

22:12 <geist> ah hah. each extension gets a property: https://github.com/qemu/qemu/blob/master/target/riscv/cpu.c#L1069

22:12 <geist> so you have to call them out individually, ie `zba=true`

22:12 <geist> and i think that true/false at the end is the default