<MoeIcenowy>
and H133 is the same die with some 133, right? ;-)
<gamiee>
:D (A133, T133...)
juri_ has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
apritzel has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
<apritzel>
MoeIcenowy: D1 sunxi-fel support> I know, I have started a branch called "notonlyarm" ;-)
moteen has joined #linux-sunxi
<apritzel>
I just stopped working on that when I realised that we don't need different code just yet for the F1C100 ...
<MoeIcenowy>
apritzel: well I am doing some dirty hacks on sunxi-fel as PoC
bauen1 has joined #linux-sunxi
<apritzel>
MoeIcenowy: I was building on top of your original idea of adding an .arch member to soc_info_t
<MoeIcenowy>
smaeul: BTW I am thinking about how to make a firmware for R329/D1's DSP
<MoeIcenowy>
on R329, DSP is expected to handle both audio and standby
<apritzel>
so R329 has *two* cores of the same Tensilica HiFi4 DSP as the D1?
<MoeIcenowy>
apritzel: not very same
<MoeIcenowy>
but quite similar
<MoeIcenowy>
the documents say it's two
<MoeIcenowy>
btw it could be interesting to get SOF to work on D1 DSP
<MoeIcenowy>
well if we're going to push both D1 and R528 support to mainline
<MoeIcenowy>
we will, for the first time, meet the problem to share DTSI between architectures
<MoeIcenowy>
I mean unrelated architectures (so arm and arm64 doesn't count)
Daanct12 has joined #linux-sunxi
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]
moteen has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<apritzel>
MoeIcenowy: why would sharing be a problem, and why would arm and arm64 not count?
<apritzel>
MoeIcenowy: from Linux' perspective, arm and arm64 could be considered unrelated, and that's definitely true for the arch/<xxx>/boot/dts directories
<apritzel>
I mean we have solutions already for H3 and H5, for instance, why would that be different between D1 and R528?
<MoeIcenowy>
apritzel: so just symlink?
<MoeIcenowy>
BTW I think arch/arm*/boot/dts maintaince is done on a different tree with arch/riscv/boot/dts
macromorgan has joined #linux-sunxi
<smaeul>
that's a question for arnd_: should Allwinner RISC-V DTs go through the SoC tree?
<smaeul>
MoeIcenowy: yes, I would really like to see SOF running on the DSP. I looked at this some last year, and the first blocker is that remoteproc does not support paddr != vaddr when loading a firmware
<smaeul>
either the remote processor address space must be identity mapped, or it must have an IOMMU
<apritzel>
you would need ACE just for coherent masters, on those cheap SoCs that just means the core*s*
<jernej>
ah, right
<apritzel>
but since the D1 is a single core ...
<MoeIcenowy>
apritzel: it's why I say the ARM is not coherent with other things
<MoeIcenowy>
openC906 is a newer revision than the core used in D1 (it uses RISC-V Debug Spec 0.13 debug module, not the C-SKY HAD used in the D1's C906), and it has no V enabled
<MoeIcenowy>
(well the V extension on D1 is also not a stable version
<jernej>
so, which AW SoC has cache coherency issue? D1?
<MoeIcenowy>
jernej: I think every that have multiple processors
<MoeIcenowy>
including R329/R528 with DSP
<megi>
MoeIcenowy: lol, a few more SoCs and AW will end up documenting everything publicly, when averaged over all the available user manuals
<MoeIcenowy>
megi: well we're always cross-reading the documents, right?
<jernej>
except DRAM and partially Cedrus
<jernej>
but yeah, that's why I always download new manuals :)
<megi>
I think this is the first I see USB DRD registers documented
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
non-coherent bus masters (DMA engines in MMC, Ethernet, ...) are a common thing, and dealing with them is well understood, at least in the ARM world
<megi>
nice, and it contains documentation for USB DMA, too
<apritzel>
and Arm Cortex cores come with built-in coherency between their caches, at least up to a certain number (within a cluster)
<apritzel>
you need extra circuitry for connecting multiple clusters, or having coherent masters on the bus (GPUs would benefit from that)
<apritzel>
that's why (mostly only single cluster SoCs) AW typically doesn't need to take extra care about coherency, and it still works (TM)
<MoeIcenowy>
apritzel: well I think on the only multi cluster AW SoCs there's a CCI
<apritzel>
yes, that's the typical solution
<MoeIcenowy>
BTW is Cortex CPUs coherent with Mali GPUs on Allwinner SoCs?
<apritzel>
I don't think so, because of the missing cache coherent interconnect
cp-- has joined #linux-sunxi
<MoeIcenowy>
megi: BTW this is the first time I see a MUSB is documented in such a weird way
<megi>
do you have any other docs for musb?
<apritzel>
because that's the cheapest solution: you just rely on the built-in coherency between the cores (which is mandatory), and the rest will be fixed up in software ;-)