<gamiee>
smaeul: oh ok. Also, from this I guess that full rotpk will be in TOC0 header, and SBROM will just verify if the rotpk hash is same as the one in efuse, correct?
apritzel_ has joined #linux-sunxi
apritzel__ has joined #linux-sunxi
mps has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
lunixoid has joined #linux-sunxi
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
lunixoid has quit []
lunixoid has joined #linux-sunxi
lunixoid has quit []
prefixcactus has joined #linux-sunxi
uwu has joined #linux-sunxi
lunixoid has joined #linux-sunxi
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Read error: Connection reset by peer]
Mangy_Dog has joined #linux-sunxi
warpme_ has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
lunixoid has quit []
apritzel has quit [Ping timeout: 480 seconds]
lunixoid has joined #linux-sunxi
<wens>
LPC RISC-V MC Allwinner D1 session is interesting
apritzel__ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
lunixoid has quit []
lunixoid has joined #linux-sunxi
lunixoid has quit []
lunixoid has joined #linux-sunxi
uwu has quit [Ping timeout: 480 seconds]
lunixoid has quit []
<palmer>
wens: happy to talk, if you guys have any thoughts
lunixoid has joined #linux-sunxi
<wens>
it seems more like an architecture level matter though?
<mripard>
yeah, I couldn't really see what was relevant specifically to the D1
<mripard>
it looks like all the issues were related to the CPU?
<palmer>
it's really ISA issues
<palmer>
essentially: the ISA has a mechanism for supporting non-coherent systems, but it's garbage
JohnDoe_71Rus has joined #linux-sunxi
<palmer>
the C906 guys (the processor core that's in the D1) did it their own way, and the foundation added a different way
<palmer>
the C906 is using some bits that were explicitly not allowed for custom use, making it incompatible with the standard
<palmer>
I get that the old mechanism was unusable (that's why it's being replaced), but we're between a rock and a hard place now with the D1
<palmer>
I was hoping that the foundation would defend the ISA and tell them they can't do this (also see the platform spec discussions, and the "Linux is a compatibility suite" discussions), but it looks like RISC-V is essentially going to be a free-for-all on the ISA side of things
<palmer>
that'll be a mess for software, but at some point there's just nothing we can do about it
cnxsoft1 has quit []
tnovotny has quit []
uwu has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<jernej>
wens: link?
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<apritzel>
palmer: so can you patch Linux' riscv pagetable code using an errata/alternative mechanism for the D1? Or does it get too messy?
<palmer>
IMO this isn't really a technical problem
<palmer>
there's been some code posted that's pretty broken, but at a fundamental level there's not really a whole lot to do here
<apritzel>
well, what I saw was #ifdef's, so a build time decision, which sounds horrible
<palmer>
ya, so that's a complete non-starter
<apritzel>
indeed, stay strong on this!
<palmer>
we're 100% on the "a normal-smelling kernel can run everywhere" rule
<palmer>
we don't want to devolve into the problems that arm had
<palmer>
(I think I explained that in the MC)
<palmer>
so it's not all that hard to turn the "set the bits in the page table to do non-coherent stuff" mechanisms into functions, have those load a global, and probe that global from the DT
<palmer>
IIRC it's just like one generic kernel place where they're relying on the #define for that, so it's not a big deal to fix
<palmer>
if that load is too slow we can always leverage one of the many runtime patching mechanisms to make it cheap, but i'm not all that worried about it for now (converting page tables to non-coherent is going to require some flushing, so the load shouldn't really be a big deal)
<apritzel>
I see, just typically the paging code is super optimised and full of cpp tricks, which makes it hard to reach with alternatives
<palmer>
ya, but the non-coherent page table code sort of expects chaos and therefor can handle it
<palmer>
this would be a whole different question if we were talking about them having different page table bits for some sort of normal memory, as that's super optimized
<apritzel>
ah, I see
<palmer>
ya, so that's why I'm not super worried about the code
<palmer>
definately there would be some generic kernel changes, and it would be a bit of work to make this low-overhead
<palmer>
I'm way more worried about how we manage the ISA
<palmer>
if we're going to allow vendors to just do whatever they want, even when it's explicitly disallowed by the specifications, then we're going to have a mess
<palmer>
that's why, at a bare minimum, I want to have the standard mechanism for this defined before we start accepting vendor-specific ones
<palmer>
then we can at least make the in-kernel interfaces match the standard, and just map that to the C906's stuff as best we can
<palmer>
that at least keeps the non-standard behavior to the implementation of a standard interface, which is way less likely to go off the rails
<apritzel>
can't you establish some Linux subset (which you already have?) And then say: You can build whatever you want, but if you want to run mainline Linux, you need to comply to those terms?
<palmer>
that's what the platform spec was meant to be, but the foundation isn't going to play ball with that tplan
<palmer>
that's why we had these discussions about what's actually required for being called RISC-V
<palmer>
IMO to be called RISC-V you need to be compatible with all the specs, not any of the specs
<palmer>
that's a huge difference, but it looks like the folks at the foundation want it the other way and that will lead to huge fragmentation
<apritzel>
but there is nothing preventing people to build something 99% compatible, right? Is "RISC-V" a trademark you can defend legally?
<palmer>
RISC-V is a trademark
<palmer>
the specifications are released under a pretty liberal license, so you can do whatever you want with them (including using it as a base for something different), but "RISC-V" is a trademark just like any other
<apritzel>
so AW would technically need to call that RISC-IV.IX then? ;-)
<palmer>
I'm not lawyer so IDK what would actually fly, but IIUC the foundation could prevent them (or any other vendor) from calling their chip "RISC-V"
<apritzel>
because that is how USB solves this: if you are not compliant, you cannot use the USB logo (and name, maybe)
<palmer>
and that's essentially been my bar for support: if the chip is called "RISC-V", then we'll figure out how to support it
<palmer>
ya, IIUC we're in the same spot (and it's a pretty common mechanism)
<palmer>
the specs are free to do whatever with, but if you want to logo you need to play ball
<palmer>
it's just that the foundation's definition of playing ball is very weak
<apritzel>
I see, that's a shame, I thought they would have learned from MIPS
<palmer>
this is kind of a reductionist argument, but I wasn't kidding when I said this policy would allow me to call my x86 box a RISC-V implementation: essentially the rule as currently described (nothing's written down) is that you can call a chip "RISC-V" if you are compatible with any of the specs.
<gamiee>
So also vendor of core (XuanTie) can't name it "RISC-V" ?
<palmer>
the user spec defines each instruction as its own extension, so I could claim essentially anything is compatible with the ISA that just has NOP
<palmer>
the x86 thing was sort of a joke, but based on my understanding of the rule I could put a RISC-V sticker on a potato if I wanted
<palmer>
on the core vendor: IMO it's kind of tricky to talk about compatibility with soft IP (ie, an RTL core) as it's not really a concrete object -- a lot of the things we're talking about here depend on the whole system that core is integrated into
<palmer>
for the actual core: sure it has these page table bits, but if no devices need them to be set then is it really non-compliant?
<palmer>
the ISA says they must be 0 in software right now, some future extension may change that but they'll just not implement that extension and everything would be fine
<palmer>
IMO that's kind of an academic argument, though, as in practice people are only really going to broadly care about silicon implementations of RISC-V
<apritzel>
you mean if you take a C906 and only attach coherent devices to it, it would work?
<palmer>
yes
<palmer>
those bits would still be there, but the system would function correctly without them ever being set
<apritzel>
understood
<palmer>
IMO that's fine -- every chip has some special magic in it, but if software doesn't need to use that to function normally then it's fine
<palmer>
the SiFive chips, for example, have a bunch of super ugly instructions to control the cache. They're just meant for bringup of the hardware, though, so it's fine.
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<apritzel>
with "bringup" you mean once per boot, in firmware, or like "initial hardware bringup in the lab, to test and debug things"?
MoeIcenowy has joined #linux-sunxi
lunixoid has quit []
<palmer>
bringup in the lab
<palmer>
there also tends to be a lot of the firmware/boot custom stuff, that's a bit of a headache but I don't think there's any way around it so it's not the end of the world
<wens>
reminds me of some talk about cache coherency in ARM, it was mentioned that if you had some external bus that didn't play well with the coherency protocols in ARM, you're screwed
<palmer>
there's a whole additional set of possible issues with the ARM coherency stuff, because they not only have an ISA (with memory ordering constraints) but also have a lot of license terms around their coherency implementation that limits what devices can do
<palmer>
at least with RISC-V we only have the technical issues to solve, but it's going to be pretty common to have vendors just port over their existing SOCs from ARM to RISC-V and as a result we're going to end up dragging along a lot of those ARM issues
<jakllsch>
(is that why so many devices end up with bad coherency?)
<palmer>
IMO it's part of the problem
<palmer>
coherence is difficult (both in terms of gate count, and technical complexity), so pushing that complexity into software is often times the right decision from a system perspective (even if it sucks for me)
<palmer>
I've never worked at an ARM shop, but based on trying to compete with them a handful of times these licensing issues definitely add an additional cost to doing coherent stuff
prefixcactus has quit [Ping timeout: 480 seconds]
<apritzel>
IIRC coherency is also power hungry, which is another reason to only have it when you desperately need it
<jakllsch>
now if only linux didn't kinda assume everything is a cache-coherent x86..
<apritzel>
jakllsch: the solution is called DMA API
<jakllsch>
good for you all, where i'm from we've had that sort of feature for decades
<palmer>
I don't write RTL, but IMO coherency isn't fundamentally power hungry -- it's just that, for a given power/performance target, you're pushing more of the complexity into hardware and that's frequently the wrong decision (maybe you licensed the IP and can't change it, maybe you don't want to couple you schedule to it, etc)
<gamiee>
How the Linux solves the cache coherency, when there isn't an hardware one ?
<palmer>
DMA API
<gamiee>
So Linux will use DMA HW block to move data from D-Cache to RAM, correct?
<palmer>
IMO the "DMA API" is really mis-named: it's not to talk to DMA engines (that's dmaengine), it's to talk to non-coherent devices
<palmer>
maybe someone understands that better than I do, though, as it's never made sense to me
<jakllsch>
basically, it's about explicitly performing the necessary cache flush/invalidation operations needed for your hardware to function
<mripard>
palmer: there's some devices that are DMA capable but don't rely on DMA engines, so it kind of makes sense to me?
<gamiee>
Thank you guys for the explanation :)
<palmer>
I'd somewhat pedanticly argue that it's about transferring ownsership of memory regions, but in practice cache flushes are how everyone does that so ya it's the same thing
<palmer>
mripard: I guess that makes sense. I only mess around with the arch stuff so I always forget about all the address translation going on in the generic DMA API code
<palmer>
and I guess if that's all there, it makes sense to just add the non-coherent device support into it
<apritzel>
palmer: I am just a software guy, but AFAIK h/w coherency typically means bus snooping, so those extra gates are in business all of the time, on every transaction, which sounds bad if you are on a power budget
<palmer>
IIUC most coherence protocols these days are directory based
<palmer>
but we're probably the wrong people to have that discussion, as I'm also more of a software guy these days ;)
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit []
uwu has quit [Ping timeout: 480 seconds]
mps has quit [Ping timeout: 480 seconds]
mps has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
apritzel_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cmeerw has quit [Ping timeout: 480 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]