ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-sunxi
moteen has joined #linux-sunxi
mehdix has quit []
mehdix has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<gamiee> Hi, did anyone hears about AW H133?
<MoeIcenowy> gamiee: no idea
<MoeIcenowy> apritzel: it takes a lot of work to get D1 working with sunxi-fel
<MoeIcenowy> check it against R528 is just the most minor problem
apritzel has quit [Ping timeout: 480 seconds]
tomf has quit [Read error: Connection reset by peer]
tomf has joined #linux-sunxi
<MoeIcenowy> gamiee: I asked someone, it's another sister of R528
<MoeIcenowy> w/o integrated DRAM
<gamiee> MoeIcenowy: oh thanks! Well, Allwinners naming is really confusing recently
<MoeIcenowy> gamiee: they're always
cnxsoft has quit [Ping timeout: 480 seconds]
<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
<smaeul> 11
<smaeul> this is as far as I got on the remoteproc driver: https://github.com/smaeul/linux/commit/cd2bc09135d71902b89f8cd216d940e2ca0b4533
<smaeul> there's a new msgbox hardware as well, which needs a new driver so it can be used here
<MoeIcenowy> smaeul: BTW V853 E907 seems to have an IOMMU
juri_ has joined #linux-sunxi
vpeter has joined #linux-sunxi
<smaeul> that's good!
<MoeIcenowy> smaeul: well in fact I don't know how the IOMMU works
<MoeIcenowy> e.g. how do RISC-V access peripherals
moteen has joined #linux-sunxi
<apritzel> MoeIcenowy: very incoherently :-D
<MoeIcenowy> apritzel: I expect no coherency between ARM and any non-ARM coprocessors
<MoeIcenowy> (well theortically it can be solved by ACE, but I doubt whether ACE will be implemented by any non-AP CPU cores
<MoeIcenowy> apritzel: BTW I wonder whether RV is totally masked out on T113, like how ARM is masked out on D1
<apritzel> is there any documentation on the RV power switches? I now have the T113 here ...
<gamiee> What does masked out mean? It's not in silicon or?
<MoeIcenowy> gamiee: disabled
<MoeIcenowy> apritzel: refer to D1 user manual
<MoeIcenowy> it has RISC-V clocks and a "RISC-V System" block
<MoeIcenowy> and I think some bits in "RISC-V_CFG" block is initialized as not 0 by default
<MoeIcenowy> gamiee: the ARM CPUCFG is read as full 0 on D1
cp-- has joined #linux-sunxi
cp- has quit [Ping timeout: 480 seconds]
juri_ has quit [Ping timeout: 480 seconds]
<MoeIcenowy> eh? r528 user manual contains USB OTG controller's register info?
<gamiee> MoeIcenowy: ah makes sense, thanks!
<MoeIcenowy> but I am not sure whether these register addresses are the same with my memory
<MoeIcenowy> weird they fused some 1 byte registers to a 4 byte word in the document
<MoeIcenowy> s/to/into/
juri_ has joined #linux-sunxi
<MoeIcenowy> and interestingly this document shows TESTMODE register
<MoeIcenowy> which we assume to not exist in Linux kernel musb/sunxi.c
cp--- has joined #linux-sunxi
cp-- has quit [Ping timeout: 480 seconds]
<jernej> MoeIcenowy: what is ACE?
<wens> some ARM thingy?
cnxsoft has quit []
<MoeIcenowy> jernej: as wens says
<MoeIcenowy> well it's technically part of AMBA
<MoeIcenowy> an extension to AXI that provides support for cache coherency
<jernej> ok, thanks
<jernej> so it shouldn't be ARM specific
<MoeIcenowy> technically not ARM specific, but done by ARM
<MoeIcenowy> oh ACE is short for "AXI Coherency Extensions", I finally found this word in some document
<jernej> yeah, whole AMBA is invented by ARM, but since it's open standard, it's used on other architectures too
<MoeIcenowy> BTW from what I observed on openC906, C906 doesn't speak ACE, just plain AXI
<MoeIcenowy> (I think it's AXI4
cp- has joined #linux-sunxi
cp--- has quit [Ping timeout: 480 seconds]
<jernej> how do you know these things? do you have access to HDL?
<MoeIcenowy> jernej: openC906 is a fixed-configuration version of C906 that has HDL available on github
<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 ;-)
cp- has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
<MoeIcenowy> megi: some confidential one
<megi> hm, looks like USB PHY can be switched to RC oscillator, presumably to be able to wakeup the SoC from sleep https://megous.com/dl/tmp/825d6394f61f7a0d.png
<MoeIcenowy> I think it's also uploaded to linux-sunxi by someone.
<megi> hm
<megi> perfect
juri_ has quit [Read error: Connection reset by peer]
tnovotny has quit [Quit: Leaving]
juri_ has joined #linux-sunxi
<jernej> so it's possible to implemend wake up by HID device?
<MoeIcenowy> well I wonder whether RC oscillator could generate accurate enough clock for USB
<jernej> it can be recalibrated now and then :)
<MoeIcenowy> apritzel: should I place the swap buffer of V853 a little higher?
<apritzel> MoeIcenowy: well, it would help if you want to load bigger SPLs, but is not a real issue yet
<MoeIcenowy> apritzel: then I don't think the memory addresses assigned now have any issues now
<apritzel> technically each SoC would benefit from having its separate buffer address, as far away as possible
<MoeIcenowy> BTW the BSS cleared at boot is 0x40800~0x41000
<apritzel> which would mean some refactoring
<MoeIcenowy> oh I need to check stack
juri__ has joined #linux-sunxi
<MoeIcenowy> initial sp is 0x403fc
<apritzel> MoeIcenowy: and yeah, I stared at your V853 patch, and think it's fine now, from what I can see
<apritzel> I wanted to do some testing for the I$ hack, then will review it on GH
juri_ has quit [Ping timeout: 480 seconds]
digetx has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has quit [Ping timeout: 480 seconds]
rajkosto has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.5]
megi has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
moteen has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
moteen has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
moteen_ has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
igraltist has joined #linux-sunxi
JohnDoe_71Rus has quit []
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
rajkosto has quit [Read error: Connection reset by peer]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
hentai has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
paulk-ter has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
juri__ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
moteen has joined #linux-sunxi
juri_ has quit [Read error: Connection reset by peer]
moteen has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
juri_ has quit [Read error: Connection reset by peer]
moteen has joined #linux-sunxi
juri_ has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
juri_ has quit [Read error: Connection reset by peer]
juri_ has joined #linux-sunxi
paulk-ter has quit [Ping timeout: 480 seconds]
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
<smaeul> apritzel: for power switches see here: https://linux-sunxi.org/PPU
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi