sorear has quit [Read error: Connection reset by peer]
mturquette has quit [Read error: Connection reset by peer]
DynamiteDan has quit [Read error: Connection reset by peer]
mturquette has joined #riscv
sorear has joined #riscv
DynamiteDan has joined #riscv
Slide-O-Mix has quit [Ping timeout: 244 seconds]
Slide-O-Mix has joined #riscv
dramforever_ has joined #riscv
davidlt has quit [Ping timeout: 240 seconds]
dramforever_ has quit [Ping timeout: 276 seconds]
jacklsw has quit [Quit: Back to the real world]
___nick___ has joined #riscv
raym has quit [Remote host closed the connection]
dramforever_ has joined #riscv
bauruine has quit [Remote host closed the connection]
<Esmil>
smaeul: To fix this sun8i-ce 3040000.crypto: Cannot get trng CE clock err=-517, I was looking at making the rtc driver export the CLK_IOSC. But in the D1 user manual I found they don't seem to write anything about that clock. On page 1365 (10.1.3.17) they only list the 3 first clocks
<Esmil>
Sorry, I mean in the chapter about the crypto peripheral they don't seem to write anything about that clock
<mmind00>
Esmil: do you have any more information about your mmc problem? I.e. I moved my d1-nezha rootfs over to a sd-card (full Debian) and bootet from it just fine right now
<mmind00>
Esmil: https://github.com/mmind/linux-riscv/tree/fromlist/cmo-v7 ... essentially smaeul 's d1-wip branch with the cmo parts replaced with my v7, but that shouldn't make a difference functionality wise (was just me re-testing my cmo series)
<Esmil>
mmind00: Yeah, I also got something similar with a rootfs on a usb-stick, so I think it's a caching issue in the current d1-wip branch
<Esmil>
Ah yeah, so if you updated that it might fix it
<Esmil>
I'll try your tree
<mmind00>
Esmil: as I said, I don't really think so ... i.e. smaeul fixed some issues I had in the cmo version in there already, so there is not really a functional change
<Esmil>
Hmm.. ok. Well I also use btrfs which checksums all the data and complains when it reads something that doesn't match
<mmind00>
Esmil: hmm, ok I'm on an ext4 ;-)
<Esmil>
yeah, so you might only see it if you're unlucky and the metadata reads breaks I guess
<mmind00>
with the d1-wip being at 5.19-rc1, I guess something btrfs-related might also be possible
<Esmil>
I guess that's possible but I didn't see an issue on the jh7100 boards when I ran rc1
jmdaemon has quit [Ping timeout: 244 seconds]
<mmind00>
Esmil: so I've re-created the rootfs on the sd-card using btrfs - never used that before ;-) ... anyway still a full Debian and it booted to the console login fine so far
<Esmil>
mmind00: do you have a config file so I can compare a recreate your kernel?
<mmind00>
though I think that's the standard nezha defconfig from that tree with only btrfs enabled too
dramforever_ has left #riscv [Leaving]
<Esmil>
Thanks, it's building now
dramforever_ has joined #riscv
dramforever_ is now known as dramforever
raym has joined #riscv
<Esmil>
mmind00: Cool. Your branch with your config works. Let me try the d1-wip with your config then
<mmind00>
Esmil: yay - progress
<Esmil>
mmind00: Interesting. The d1-wip branch with your config also works. I guess it's time to narrow down which option is broken..
bauruine has joined #riscv
davidlt has quit [Ping timeout: 260 seconds]
davidlt has joined #riscv
<Esmil>
mmind00: Ok, I was wrong. The d1-wip with your config also errored after a while. Now I'm running your branch with my old config and no read errors so far. I don't dare call it fixed yet though..
<mmind00>
Esmil: that is really puzzling, as I don't think there are functional differences between d1-wip and my cmo-v7 on the d1-specific parts
dramforever has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
aerkiaga has joined #riscv
<Esmil>
mmind00: Well all I can say is that so far your branch is looking good. I've now compiled, installed and run severeal iterations of it. Even rebased on rc5
<Esmil>
..and so far I've had no read errors
<mmind00>
Esmil: ok ... sounds great then :-)
DoubleJ has quit [Quit: Ping timeout (120 seconds)]
DoubleJ has joined #riscv
montjoie has joined #riscv
dramforever has joined #riscv
BootLayer has joined #riscv
erg_ has joined #riscv
dor has quit [Ping timeout: 276 seconds]
dramforever_ has joined #riscv
dramforever has quit [Ping timeout: 244 seconds]
dramforever_ has quit [Ping timeout: 240 seconds]
Andre_H has quit [Ping timeout: 260 seconds]
drmpeg has left #riscv [#riscv]
<smaeul>
Esmil: the RTC driver already exports CLK_IOSC, so no changes should be needed. IOSC really is needed for the TRNG to work.
<Esmil>
smaeul: oh, it doesn't here. what name do you see it under in /sys/kerne/debug/clk/clk_summary ?
<smaeul>
"iosc". it's first in the list
<smaeul>
do you have the RTC driver bound at all?
<smaeul>
(right now your change will appear to work because osc32k has IOSC as parent, so IOSC is always on, but when switching osc32k to use the external 32768 Hz crystal, that "trng" clock consumer will be the only consumer of IOSC)
drmpeg has joined #riscv
<Esmil>
right
amjad has joined #riscv
aburgess has quit [Ping timeout: 276 seconds]
amjad has quit [Quit: Client closed]
bauruine has quit [Remote host closed the connection]
dramforever has joined #riscv
dramforever has quit [Client Quit]
dramforever has joined #riscv
EchelonX has joined #riscv
jacklsw has joined #riscv
<Esmil>
smaeul: ah, sorry. got it. you can't have RTC_DRV_SUN6I=y and SUN6I_RTC_CCU=m then you get the rtc driver, but not the exported clocks
dramforever has quit [Ping timeout: 276 seconds]
dramforever has joined #riscv
vagrantc has joined #riscv
<conchuod>
2 months (and a ?free? radxa zero later) I finally got my VisionFive (:
dramforever_ has joined #riscv
dramforever has quit [Read error: Connection reset by peer]
dramforever_ has quit [Remote host closed the connection]
dramforever_ has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
aburgess has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
mechaniputer has joined #riscv
motherfsck has quit [Quit: quit]
motherfsck has joined #riscv
dramforever__ has quit [Ping timeout: 255 seconds]
jacklsw has quit [Read error: Connection reset by peer]
<conchuod>
Hmm, I wonder is there a reason riscv makes GENERIC_ARCH_TOPOLOGY depend on SMP
<conchuod>
(arm64 does not have the same depend)
<geist>
oh wow! I've had my vision five on order since february, still no sign of shipping
<conchuod>
They just delivered me a radxz zero the first time around!
<Esmil>
oh
<conchuod>
:thinking: what will the next board to get upstreamed that I will buy
<conchuod>
be?*
<geist>
yeah i ordered from Ameridroid, which i've usually had good luck with
<geist>
but this time it's not so good
<conchuod>
btw esmil, I sent another patch for topology stuff, it's broken atm for !SMP but is a better fix for the cpu-map/topology info
<Esmil>
yeah, i saw
<conchuod>
(not that added the cpu-map nodes is not a good idea, I think that has merit in its own right)
<geist>
hmm are the HARTs numbered 0-3 on that one?
<geist>
was wondering if that has something to do with non zero based hart numbering like you get with sifive socs
<conchuod>
What do you mean by "one"?
<geist>
oh on the visionfive
<conchuod>
I think technically what is in the dts as cpu0 & cpu1 are really hart 1 & 2 b/c there is a monitor core or w/e you want to call it
<conchuod>
But that isn't in the dt
<geist>
yeah. the sifive stuff has a machine only hart at 0. it was a bit of a pain for my kernel since it was assuming hart 0 was the boot one. but so it goes
<conchuod>
what is "your kernel"?
<Esmil>
that's right, but I think when you read the mhartid you get 0 or 1 on the 64bit cores and 0 on the 32bit core
<geist>
Oh I work on an embedded kernel called Little Kernel and the fork of it, Fuchsia
<conchuod>
Cool :) See I really dunno what anyone's irc name equates to haha. Not that I expect any different from the other side.
<conchuod>
Esmil: my OCD really wants to add that 32bit core to the dt :/
<geist>
haha yeah, i always use geist but alas when i'm at google geist was taken and i have to use travisg
<conchuod>
My first name is what I would prefer to use, but it is far too common to get anywhere
<Esmil>
conchuod: you're most welcome to do so ;)
<conchuod>
haha, well most of my commits atm seem to be fixing devicetrees, so wouldn't be out of place..
<mmind00>
palmer: and I guess you're still swamped, but it looks like with Zicbom v7 I seem to have everybody on board now ... patch4 (t-head variant) is of course still using pre-coded instructions, but at least patches 1-3 should definitly be good to go after I moved to using the actual zicbom instructions
<palmer>
OK, thanks
<palmer>
poking stuff here is fine, I'll go reply to that patch
<palmer>
IMO it's fine to just get back to what we had before, but there's probably a better way to do it
<conchuod>
I always feel bad poking people haha
<palmer>
no worries
<palmer>
if it's just a "these patches are ready to go", then that's better for me
<palmer>
otherwise I have to keep trying to scrub through stuff, which is actualy more work in the end
<palmer>
and if it's all stuff that's mergable, then there's no reason to delay it
<conchuod>
Whenever I make a 5.20 PR I'll go through and reply "these patches are ready to go" to w/e else I have and you can do them all when you have time
<conchuod>
mmind00: I keep telling myself I'll try your THEAD stuff and then don't get to it
<mmind00>
conchuod: no worries :-)
<conchuod>
(I might have a vested interesting in non-coherent dma :))
<conchuod>
interest*
<mmind00>
conchuod: there is this nice Zicbom extension :-)
<conchuod>
The thing I don't get about Zicbom is, do I need a new CPU core for it.
<palmer>
unfortunately there's probably going to be a lot of pre-Zicbom hardware, it was way to olate
<conchuod>
Sorry if that's a silly question
<palmer>
ya, you need a core with the instructions
<mmind00>
conchuod: yeah, that will turn up in new cores somewhere in the future
<conchuod>
Ye so I am going to want something that isn't Zicbom then
<palmer>
yep. Though if you're worried about g5soc, you're kind of just screwed there
<conchuod>
Ye I am ^
<palmer>
yep
<palmer>
so IMO there's going to be no reliable way to make non-coherent devices work
<conchuod>
We *think* we have a way out
<palmer>
the L2 control registers?
<conchuod>
idk, we call them SEG registers
<mmind00>
what is the g5soc?
<conchuod>
polarfire soc
<palmer>
OK, I can't find any SEG registers
<palmer>
but IMO it's going to be hard to make anything non-coherent talk to the SiFIve IP, or at least the generations of SiFive IP I was familiar with
<conchuod>
idk if you know them under another name, basically it's mapping the addresses presented to the core complex to the actual addresses in hardware
<palmer>
OK, those were outside the SiFive IP at the time so I wouldn't know that much about how they worked
<palmer>
but I still think the aliasing approach is going to just be fundamentally broken, there's no way to tell the HW not to talk to the cacheable alias
aburgess has joined #riscv
<conchuod>
Ye idk, we'll see.
<conchuod>
At least we aren't in a THEAD situation & things do work.
davidlt has quit [Ping timeout: 260 seconds]
<mmind00>
conchuod: t-head thankfully implemented something that matches zicbom very much - just with different instructions :-) ... so apart from getting these into binutils the implementation was very easy
<mmind00>
conchuod: I recently looked at the beagle-v and the non-coherent handling there looked harder to do
<conchuod>
Or more like, Zicbom matches them very well?
<mmind00>
conchuod: no clue :-) or it's just easier to implement stuff that way
<conchuod>
I have ~everything set up to tftpboot now at least so should be able to test the various boards, took inspiration from yourself and Geert mmind00 :)
<mmind00>
conchuod: congrats
<conchuod>
No fancy remote power cycling though haha
<palmer>
it'll be on fixes when it passes the tests
<conchuod>
I already have 3 PCs & a bunch of RPis etc on top of what's on that shelf mmind00
<conchuod>
In a country that doesn't have A/C that makes for hot summers!
<conchuod>
mmind00: what is the 3rd bay from the top?
ldevulder has quit [Quit: Leaving]
mechaniputer has quit [Quit: leaving]
<mmind00>
palmer: cool, thanks
<palmer>
ya, no problem
<mmind00>
conchuod: below the hdmi-switch are 2*1U of management ... 19in cases containing the boards doing all the tftp, nfs, boardfarm-webapplication, power-supply ... and in the future hdmi->v4l->webbrowser :-)
<conchuod>
Ah I see. My "server", ie a desktop PC that I use as a fileserver etc, does hosts my NFS, TFTP etc.
<mmind00>
conchuod: i.e. https://imgur.com/a/K4YdYi2 ... fully interactive serial access in a web-browser :-)
<conchuod>
That's cool
<conchuod>
I can't believe I wasted so much time before setting up tftp & nfs
<conchuod>
I had a whole load of issues with getting NFS set up though, I badly misinterpreted the kernel docs on it.
<conchuod>
palmer: sorry to bother you, if I want to move risc-v and arm64 to a asm-generic version of a function can I do that one 1 patch?
<conchuod>
in 1*
<palmer>
IMO you better off splitting it up: make the asm-generic bit, then have each arch use it
<palmer>
it's just kind of a headache to do the multi-tree stuff
<conchuod>
I thought you'd say that :/ How do I deal with the multiple definitions of the same function doing it that way?
<palmer>
ya, that's usually the headache
<conchuod>
Can I just wrap it it an #ifndef function_foo ?
<palmer>
ya, that's one way to do it -- and if some other arches have a different version of the function then it can be the right way to go
<palmer>
but if it's something that pretty much every arch is going to have generic then that can make more work than it's worth
<palmer>
so I guess it really just depends, there's frequently no good way to do it
<palmer>
if it's really just a small function that refactors stuff then one patch might be fine, as Arnd will sometimes pick those up
zjason has quit [Read error: Connection reset by peer]
<conchuod>
Dunno if that qualifies as small enough, might just do it in one and see if people complain...
zjason has joined #riscv
<conchuod>
I guess I could just change the name
<conchuod>
But that seems like the lazy way out
<conchuod>
hmm what about __weak palmer
motherfsck has quit [Quit: quit]
<palmer>
I don't like __weak, but it's not my subsystem ;)
<palmer>
IMO there's always a better way to do things that making functions __weak, but if it's a short-term thing it could be the way to go
<palmer>
probably better than #1 adding an ifdef, then #2-N converting, then #N+1 removing the ifdef
motherfsck has joined #riscv
<palmer>
mmind00: I can't tell if my tests have just recently started flaking out, or if that patch is broken
<palmer>
something's up, though
<mmind00>
palmer: what happens?
<palmer>
it hangs in the medany config boot
<palmer>
but then I re-ran it and it's hanging somewhere else (maybe strict RWX, I foroget)
<palmer>
doesn't seem like any of that should come from the patch
<mmind00>
yeah ... it just prevents spurious warnings when loading modules ... very strange
<palmer>
yep
<palmer>
looks like I recently updated QEMU, so I'm rolling it back
<conchuod>
I'll do __weak and Sudeep (or someone with more exp with this sort of thing) can "guide" me
<palmer>
IIRC there was another mystery failure, so maybe that'll sort it out
<palmer>
conchuod: seems reasonable, __weak is all over the kernel but if folks don't like it then they'll say something pretty quickly
<conchuod>
I just wanna do it this way rather than move arm first and then add the risc-v one to make the backports more straight forward
<conchuod>
which is what Sudeep suggested anyway.
<palmer>
ya, go for it
<palmer>
if it's what was suggested then that's probably the way to go
<palmer>
I'm not going to have any objections to deleting code from arch/riscv
<palmer>
it's just that having something touch arch/{riscv,arm64} is going to result in one of those "who merges this" threads, and sometimes those can take months to resolve
<conchuod>
What I have is adding code to arch/riscv, followed immediately by removing most of it and the same function from arch/arm64
<conchuod>
I only care about the first part being relatively quick b/c it's a fix for user visible arch-topology mistakes
<conchuod>
Gonna just build it for arm & then you can see what horrible mess I have come up with.
<palmer>
OK, but if it's user visible then we might have a uABI issue to deal with as well
<conchuod>
eugh
<conchuod>
Sent, you can all proceed to yell at me now (:
<conchuod>
One last thing before I stop bothering you palmer, looks like Arnd will take that maintainers update via soc so should be sorted :S
<palmer>
ah, great, thanks
<palmer>
sorry I forgot about that again
<conchuod>
nah dw about forgetting. thats about as low prio as things can be haha