<dramforever>
Esmil: What's the status of QSPI on starfive-tech/linux? I see it's unchecked in README.md and doesn't say [WIP], but I'm not sure what that means
<dramforever>
Not sure what's the correct way to patch this properly though. Just make the driver handle more clocks?
<dramforever>
Also just kinda curious if you've done anything about it
<dramforever>
Well, 'got it working' as in I only tested I can read from /dev/mtdblock0
dramforever_ has joined #riscv
dramforever has quit [Ping timeout: 240 seconds]
dramforever_ is now known as dramforever
<Esmil>
dramforever: ah, that's cool. it sounds like you want to add all the needed clocks to the qspi node in the device tree, and then patch the driver to claim the extra clocks
<Esmil>
ideally you'd also have a patch to the device tree bindings so the device tree can be validated
<dramforever>
Do you think we should make it generic? I talked to Icenowy about it and they suggested doing something like clock-names = "refclk", "ahb_clk", "apb_clk"
<Esmil>
yes, that looks right
<dramforever>
The driver would find clock based on name "refclk" and take that as, well, refclk
<Esmil>
maybe you can also do the same for the resets, so the driver can make sure they're deasserted
<dramforever>
and enable all the rest of the clocks
<Esmil>
yes
<dramforever>
This way we don't even need to base it on a starfive,qspi (or something) quirk
* dramforever
starts to wonder how many drivers would need this treatment
<dramforever>
I'm just thinking, should we add non-SMP cores to /cpus?
<Esmil>
yeah, that's the question that thread is about. it seems like conchuod is waiting for input from Rob and Krzysztof
<dramforever>
Oh there's more on the thread since I last checked oops
___nick___ has joined #riscv
<MoeIcenowy>
Esmil: well I think for this kind of things DT spec is what to check
<MoeIcenowy>
but I can't get a solid conclusion (although I feel that it shouldn't be there)
<MoeIcenowy>
BTW the RV CPU binding requires reg to be mhartid
<MoeIcenowy>
I think there's no way to have E24 in /cpus and get this to be satisfied
loggervicky has quit [Remote host closed the connection]
loggervicky has joined #riscv
<Esmil>
MoeIcenowy: yeah, i agree. you're definitely right that the only way to use the e24 is through something like the remoteproc framework, but it's not clear from the dt-spec what the /cpus is supposed to represent
<Esmil>
yeah, isn't the requirement that reg = mhartid a little weird given that the priviledged spec is designed so s-mode can't access the mhartid
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 244 seconds]
loggervicky has quit [Remote host closed the connection]
loggervicky has joined #riscv
<dramforever>
S-mode can't *access* mhartid, but M-mode passes hart id to a0 on boot, and it's used for sending IPIs too
loggervicky has left #riscv [#riscv]
<dramforever>
You can also be in xVisor/KVM, in which case the hart id isn't mhartid but a virtual id
MoeIcenowy has quit [Ping timeout: 264 seconds]
MoeIcenowy has joined #riscv
loggervicky1 has joined #riscv
loggervicky1 is now known as loggervicky
tsraoien has joined #riscv
<conchuod>
dramforever: define an "non-SMP" core
matt__ has joined #riscv
<conchuod>
Esmil: I am not convinced that just because you cannot run linux on a cpu that it should not in in /cpus
<conchuod>
I would really like Robh or Krzk to chime in, but I don't care all that much so cba bumping it. I'll ping them after a few weeks if they've not seen it
dramforever_ has joined #riscv
cousteau has joined #riscv
<conchuod>
>starfive,qspi (or something) quirk
frkzoid has quit [Ping timeout: 244 seconds]
<conchuod>
you should add a compatible etc if you make the driver have any behaviour that is not generic to cdns,qspi-nor
<dramforever_>
Yeah got that, thanks. Working on that with MoeIcenowy atm
dramforever has quit [Ping timeout: 264 seconds]
<conchuod>
But ye, I don't think that "non-SMP" core is really an argument - that describes software behaviour more than hardware configuration right?
<conchuod>
The only amp stuff I have done on riscv is with polarfire soc, but we can just add status = disabled to any of the u54s and all of a sudden it is not in SMP anymore & can load freeRTOS there or something.
<dramforever_>
Yes so I'm not against adding the non-Linux capable core to fu540/fu740
<conchuod>
The thing that to me seems like more of a problem is how to describe that it is (supposedly) on another bus
<dramforever_>
Oh that part
* cousteau
just joined the conversation and is wondering if a non-Linux capable core is a non-(Linux capable) core or a (non-Linux) capable core
<cousteau>
I guess it's the tiny E31 core that is probably not Linux-capable
<cousteau>
er, not capable of Linux
<dramforever_>
I think we should specify that this discussion is all about non-(MMU Linux capable)
<dramforever_>
Okay, back to the bus thing, the E24 has 4GiB of physical addresses (and no virtual memory)
<conchuod>
tbh, whether it is capable of running Linux is not really relevant
<conchuod>
Does it have access to all of the peripherals over the same ahb/apb buses dramforever_ ?
<cousteau>
is this about "mixing RV32 and RV64 together on the same SoC"? because I looked into that sort of thing before and it appeared it's not possible
<dramforever_>
Yes, but on a different address
<dramforever_>
0x8000_0000 ~ 0xffff_ffff on the E24 is 0x1000_0000 ~ 0x8fff_ffff on the U74
<conchuod>
Ahh
<cousteau>
(at least not with Rocket-chip... you can mix different cores together such as Rocket and BOOM, but RV32 and RV64 is a no-no)
<conchuod>
Thanks for explaining dramforever_ :)
<dramforever_>
I'm only 90% sure about this, since I just found this by poking physical memory
<dramforever_>
So it has access to all the peripherals (but not the PLIC), all of QSPI flash, and first 256MiB of DDR RAM
<dramforever_>
but the DDR RAM it has access to isn't even cache coherent
<cousteau>
I like how in a few minutes we have touched the only two real hard problems in CS :)
<conchuod>
But ye, thanks for explaining that dramforever_, at least I am a lot clearer on what we would be asking Rob/Krzk about now
<conchuod>
cousteau: what do you mean by "mixing RV32 and RV64 together on the same SoC"?
<dramforever_>
As of why I don't think it should be in /cpus, it might be a bit of a slippery slope, but by that logic all of the accelerator CPUs should be in /cpus
<conchuod>
If it doesn't go in /cpus, what does it go in as?
<conchuod>
because "remoteproc" is not a type of peripheral
<cousteau>
having a heterogeneous SoC with different types of RISC-V cores, some of them RV32 and some of them RV64
<dramforever_>
e.g. why isn't the Xtensa Vision P6 /cpus/vp6@0?
<conchuod>
I guess because it does one thing (DSP) and can be described as a DSP peripheral?
<cousteau>
like the FU540, which had one small E31 core and four large U54 cores, except in that case I think that all 5 cores had the same XLEN
<conchuod>
I don't get you still cousteau :/ Does the FU540 not do exactly what you mean? Or do you want all 5 cores to be running <insert OS> in SMP?
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
<dramforever__>
Arrgh, flaky connection
<dramforever__>
The JH7100 doesn't have a RV64/RV32 mix. It's two RV64 U74 cores, then it has one RV32 E24 core.
<dramforever__>
This is kinda a big deal, as the E24 core isn't in any RISC-V-conventional way connected to the U74 cores
<cousteau>
What I was looking into back in the day was to have an asymmetric multiprocessor with one REALLY small core (which might be RV32I or even 32E) along with some big cores (RV64I) which could be turned off for ultra low power mode
<ikke>
What is the E24 core used for?
<dramforever__>
Nothing so far
<ikke>
ok
<dramforever__>
You can use it for low-power applications where the main cores are stopped
<dramforever__>
Or real-time processing
<cousteau>
but what I found out after working with Rocket-chip for a while was that this was not possible... the bus infrastructure must have a specific word length, and the cores must have that same word length
<dramforever__>
Unlike the FU{5,7}40, where the S5/S7 core is connected to the same LLC/L2 cache, same CLINT, same PLIC, same debug module, and share the same hartid space, the E24 is just... another 'thing'
<dramforever__>
I don't think it's inherently different from any other DMA-capable coprocessor
<cousteau>
conchuod: I just looked it up and the FU540 has four big U54 (RV64IMAFDC) and one tiny E51 (RV64IMAC) (not E31 as I said initially; bad memory) -- but both are RV64 after all
<dramforever__>
I don't know if it's reverse-engineering or anything, but I just found those by poking around in JTAG
<dramforever__>
*if it's called
<cousteau>
so that's why I was asking if the conversation was about mixing XLENs in the same AMP architecture, to point out it's impossible or nontrivial... but it probably wasn't about that at all. I'll now remain quiet :I
aerkiaga has joined #riscv
<dramforever__>
It's not impossible or nontrivial, because it is already done
<dramforever__>
It's, for example, sitting here on my desk
<conchuod>
Thanks for your explanations though dramforever, I'll add some more info and bump the thread (prob after the mw) and we can see what the dt lads have to say
<dramforever__>
Yeah
<conchuod>
cousteau: I don't see why you /can't/ have rv32/rv64 amp
<dramforever__>
cousteau: You can for example make two rocket-core SoCs with different XLENs and connect them together. You'd get something like the JH7100
frkzoid has joined #riscv
pecastro has joined #riscv
<cousteau>
conchuod: you probably can, but you can't do that using rocket-chip, as far as I understood
<cousteau>
dramforever__: that's basically two separate processing systems interconnected somehow, right?
<cousteau>
like, not sharing any bus infrastructure? or that's what I understood from what you said before
<cousteau>
or maybe I misread
<dramforever__>
I'm not sure what you mean by 'not sharing any bus infrastructure', but that's basically what's going on in this conversation
matt__ has quit [Ping timeout: 244 seconds]
<dramforever__>
Like, this is the situation of JH7100
<dramforever__>
The RV32 E24 has access to a 2GiB segment of the U74's address space (as mentioned before), and the same external interrupts but on a different interrupt controller
<dramforever__>
What happens now to the device tree?
MoeIcenowy has quit [Ping timeout: 244 seconds]
Andre_H has joined #riscv
<cousteau>
ok... so basically two separate processing systems connected to the same (32b? 64b?) AXI(?) bus
<conchuod>
dramforever__: Or what happens when you have an FPGA and put an rv32 core into the fabric
<dramforever__>
afaik, exactly
<cousteau>
where the same physical peripheral is mapped to different physical addresses on different cores
<cousteau>
and you're wondering how you'd write that on the device tree
Andre_H has quit [Client Quit]
<conchuod>
I wonder if there might be some "magic" that the ranges property can do dramforever__ to solve the different addresses problem. Rob would know if that is possible.
<conchuod>
Ye p much cousteau
matt__ has joined #riscv
* cousteau
. o O ( maybe different processing systems might have different device trees )
<dramforever__>
I'm also guessing that we probably shouldn't spend *too* much effort on this for now, because literally nobody is using the E24. As of writing.
<dramforever__>
But there's a lot of potential for low-power sleep mode etc
<conchuod>
Yeah, but for me there's benefit in knowing what to do with that E24 in terms of what to do with cores in an FPGA's fabric
frkzoid has quit [Ping timeout: 272 seconds]
<conchuod>
btw dramforever__, if you do end up upstreaming changes to that cadence qspi, feel free to CC me & I can give it a try.
<dramforever__>
See kernel-modules/spi-cadence-quadspi.c and dt-overlays/spi-flash.dts
<dramforever__>
I'm starting to think maybe the 'ultimate' solution would be to specify multiple bus rather than just having everything under /soc, but that's way too much of an undertaking
<MoeIcenowy>
conchuod: why aren't remoteproc a type of peripheral
<MoeIcenowy>
on PC we have many peripherals that contains an embedded microcontroller
<MoeIcenowy>
and the difference between FU[57]40 "Management Core" and JH7110 E31 is that, in the first case they're in the same cluster, sharing the same bus and peripherals
<MoeIcenowy>
it's really possible to run a SMP system with those cores if you choose only to use the feature set of the management core (thus not MMU Linux)
iooi has joined #riscv
iooi has quit [Quit: iooi]
iooi has joined #riscv
<cousteau>
MoeIcenowy: do those embedded processors have access to the system bus though?
<cousteau>
like, act as masters of that bus, access the shared memory, etc?
<cousteau>
or are they just slave peripherals, and the embedded processor just handles its own stuff and doesn't directly access other system peripherals through the system bus?
<conchuod>
remoteproc is a subsystem and a way of implementing the access in software MoeIcenowy, no?
<conchuod>
The actual peripherals are things like DSP or system monitors etc
<cousteau>
(...basically, this is in line with what I was thinking of "having multiple device trees for multiple processing systems" -- the main processor could see the secondary processor as a peripheral, not as part of the processing system)
<dramforever__>
E24 has access to the system bus but so does any other DMA-capable peripheral
<cousteau>
ok good point
<cousteau>
but I was thinking on MoeIcenowy's example of PC peripherals with embedded processors
<conchuod>
maybe something like the TI PRU is a good example for how to do this
<conchuod>
Not really looked too hard into that though, busy playing videogames ;)
<cousteau>
let's think of a system with a GPU, for example. Would the GPU appear on the device tree as another processor, or as a peripheral?
<conchuod>
The PCI host root port is in the DT
<conchuod>
Or if it's a graphics co-processor, it goes right into the dt like any other device on a bus p sure
<cousteau>
if it appears as another processor, with the same or different memory address mappings, then that's a similar case to what we have here. If it appears as some sort of peripheral, then it doesn't apply because I guess you want the E24 be as a "first-class processor" and not some sort of peripheral guy
<kettenis>
most arm systems have cortex-m management cores as well, but those are never added to /cpus
<conchuod>
Ye but this is not a true "management core" since you can run w/e you like it on (I think)
Andre_H has joined #riscv
loggervicky has quit [Ping timeout: 264 seconds]
MoeIcenowy has quit [Ping timeout: 240 seconds]
<conchuod>
I am being convinced that /cpus is not the right place to put it, but "remoteproc" (afaik) has no meaning in a device tree
matt__ is now known as freakazoid333
MoeIcenowy has joined #riscv
loggervicky has joined #riscv
<conchuod>
Either way, I'll ask Rob/Krzk after the mw so thanks for all your info :)
dor has quit [Ping timeout: 244 seconds]
frkzoid has joined #riscv
matt__ has joined #riscv
freakazoid333 has quit [Ping timeout: 244 seconds]
frkzoid has quit [Ping timeout: 272 seconds]
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 240 seconds]
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 240 seconds]
frkazoid333 has joined #riscv
dramforever_ has joined #riscv
matt__ has quit [Ping timeout: 244 seconds]
dramforever__ has quit [Ping timeout: 240 seconds]
jacklsw has joined #riscv
loggervicky has quit [Remote host closed the connection]
loggervicky has joined #riscv
frkzoid has joined #riscv
frkazoid333 has quit [Ping timeout: 244 seconds]
Gravis has quit [Quit: Murdered]
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 272 seconds]
frkzoid has joined #riscv
GenTooMan has quit [Ping timeout: 244 seconds]
matt__ has quit [Ping timeout: 264 seconds]
loggervicky has quit [Remote host closed the connection]
matt__ has joined #riscv
frkazoid333 has joined #riscv
frkzoid has quit [Ping timeout: 264 seconds]
loggervicky has joined #riscv
matt__ has quit [Ping timeout: 240 seconds]
kanka has joined #riscv
GenTooMan has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
frkzoid has joined #riscv
EchelonX has joined #riscv
frkazoid333 has quit [Ping timeout: 255 seconds]
matt__ has joined #riscv
Andre_H has quit [Ping timeout: 244 seconds]
frkazoid333 has joined #riscv
frkzoid has quit [Ping timeout: 272 seconds]
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 255 seconds]
frkzoid has quit [Read error: Connection reset by peer]
frkazoid333 has quit [Ping timeout: 272 seconds]
frkzoid has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 272 seconds]
jacklsw has quit [Read error: Connection reset by peer]
BootLayer has joined #riscv
kanka has quit [Remote host closed the connection]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
matt__ has joined #riscv
matt__ is now known as freakazoid333
frkzoid has quit [Ping timeout: 244 seconds]
frkzoid has joined #riscv
freakazoid333 has quit [Ping timeout: 240 seconds]
frkzoid has quit [Ping timeout: 244 seconds]
iooi has joined #riscv
dor has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 272 seconds]
frkazoid333 has joined #riscv
GenTooMan has quit [Ping timeout: 244 seconds]
loggervicky has quit [Remote host closed the connection]