indy has quit [Read error: Connection reset by peer]
indy has joined #linux-sunxi
hlauer has joined #linux-sunxi
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
prefixcactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
tnovotny has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
Heh. #40 of that list of Falsehoods about names... Anyway, we've had runins with #27 at work. A student with the last name O'Malley has been having difficulties because the system is written to follow Swedish naming rules, where the apostrophy is not in the list of valid characters...
jaganteki has joined #linux-sunxi
<karlp>
same drama for addresses when you start working with them :)
<MoeIcenowy>
apritzel: I think we may need to refactor many things to support D1
<MoeIcenowy>
from sunxi-fel, to U-Boot
<MoeIcenowy>
(the former embeds in too much ARM codes
<MoeIcenowy>
(the latter placed too much sunxi-related codes in arch/arm/mach-sunxi/
<apritzel>
MoeIcenowy: I am more than happy to consolidate board/sunxi and arch/arm/mach-sunxi
<apritzel>
I always felt that those two directories overlap in a confusing way
<apritzel>
just not sure if our "sunxi is the board name" trick now comes and bites us
choozy has joined #linux-sunxi
jaganteki has quit []
<apritzel>
MoeIcenowy: if you have some RFC, and be it only refactoring, please send it, so that we can start the process
choozy has quit [Remote host closed the connection]
Mangy_Dog has joined #linux-sunxi
jaganteki has joined #linux-sunxi
<apritzel>
MoeIcenowy: is there actually any special *devices* in the D1, apart from the PLIC?
<apritzel>
(special as in: new in sunxi world)
choozy has joined #linux-sunxi
gsz has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 480 seconds]
choozy has quit [Ping timeout: 480 seconds]
<megi>
are there some ~$30 D1 boards already?
<megi>
there were some reports that ~$15 board should have been released in may
BroderTuck has quit [Quit: Page closed]
<MoeIcenowy>
apritzel: some Xtensa DSP?
<MoeIcenowy>
but the GPIO register layout is changed on D1
<apritzel>
oh really? the only thing that so far was stable for all those years?
<MoeIcenowy>
yes
<MoeIcenowy>
0x30 per bank
<MoeIcenowy>
(original SoCs is 0x24 per bank
<apritzel>
but the relative offsets per bank stay?
<MoeIcenowy>
nope
<MoeIcenowy>
the driving strength register changed
<MoeIcenowy>
now it's 4 bit per pin (originally 2 bit per pin)
<MoeIcenowy>
although the high 2 bit in per 4 bit is now reserved
<apritzel>
I guess that's shared with the other "NCAT2" SoCs?
<MoeIcenowy>
maybe, lemme check r329
<MoeIcenowy>
oops r329 is still 0x24 per bank
lurchi_ has joined #linux-sunxi
<MoeIcenowy>
BTW D1 comes with a LED controller (which is not first on D1, but not driven by anything community yet
<MoeIcenowy>
and a IR TX
<MoeIcenowy>
the LED controller seems to be a controller for WS2812
<apritzel>
alright, so the usual AW game: tweak some bits here and there on a new SoC, because they can
<MoeIcenowy>
(not fully checked yet
<MoeIcenowy>
well to be honest, WS2812 is always a pain for application processors running Linux
<MoeIcenowy>
because it's timing is too strict for a time-slice-based OS
<apritzel>
yeah, fair enough
<MoeIcenowy>
BTW for sunxi-fel I have some very dirty hack now
<apritzel>
I am not so much concerned about added IP like IR TX or the LED controller
<MoeIcenowy>
(and I am not sure whether the CSR saving part is suitable for a real SPL
<apritzel>
that's alright for now, allows us to see what's needed
<MoeIcenowy>
apritzel: modify all arrays named "arm_code" in fel.c and fel_lib.c ;-)
<MoeIcenowy>
BTW generating a RISC-V JAL instruction manually is really a disaster
<MoeIcenowy>
because of its strange shuffled arrangement of immediate
<apritzel>
really? that's annoying (but probably the least of our problems)
<MoeIcenowy>
ah mkimage -T sunxi_egon should be modified to be RV-sensible, too, currently in this branch I shipped a hacked version of mksunxiboot that generates RV JAL x0, offset instruction instead of ARM B offset instruction
<apritzel>
MoeIcenowy: is everything 64-bit in the D1 BROM and firmware?
<MoeIcenowy>
yes
<apritzel>
at least that saves us some pain
<MoeIcenowy>
well I don't think RISC-V defined any way to switch between RV32 and RV64
<MoeIcenowy>
BTW have you heard of rumors saying D1 comes with ARM cores on die too?
<MoeIcenowy>
(some arrangements of D1 is also showing it, e.g. there's a CPU clock and a RISC-V clock
<apritzel>
yes, I heard about this
<apritzel>
that it's actually the same die as some dual-A7 SoC
<apritzel>
are the ARM cores somehow disabled, or just not used?
<MoeIcenowy>
BTW the reset address register which is RO from RISC-V itself is setting via MMIO too
<MoeIcenowy>
I think somehow disabled
<MoeIcenowy>
because D1 boots directly from RV core
<apritzel>
so the BROM is not still ARMv7? ;-)
<MoeIcenowy>
yes, it's RV64
<MoeIcenowy>
fortunately the BROM does not use T-Head extended instructions
<MoeIcenowy>
(the libdram uses them, and being nearly impossible to RE
<apritzel>
so they have custom instructions in the core? Are they at least documented somewhere?
<MoeIcenowy>
it's documented by T-Head
<MoeIcenowy>
I have a document, but in Chinese
<megi>
it should be fairly straightforward to add those instructions to ghidra processor description file
<apritzel>
MoeIcenowy: is it supported by toolchains (binutils)?
<MoeIcenowy>
they provided a patched, no source version
<megi>
if the encoding and behavior is known
lurchi_ has quit [Ping timeout: 481 seconds]
<apritzel>
I think those additions are the biggest problem for RISC-V
lurchi_ has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
choozy has joined #linux-sunxi
<MoeIcenowy>
apritzel: for D1 there's another problem
<apritzel>
non-coherent devices?
<MoeIcenowy>
it implements an unstable (and not compatible to stable) version of RV V extension
<MoeIcenowy>
it's RV V 0.7.1
<MoeIcenowy>
(maybe I should say it's a problem of C906 CPU core
<lurchi_>
MoeIcenowy: Using DMAed SPI with matching bit patterns works fine for WS2812
<MoeIcenowy>
congratulations, RV starts to be fragmented now ;-)
<apritzel>
that was quick!
<MoeIcenowy>
other silicon implementations select to wait for RV V 1.0
<MoeIcenowy>
and I think there's no way to distinguish 0.7.1 and 1.0 except for checking instruction behavior
<apritzel>
and I saw this one patch suggesting compile time decisions for certain SoCs (the D1 in particular, I believe) ...
<MoeIcenowy>
this reminds me of the era when there
<MoeIcenowy>
there's semi-compatible CPUs
<MoeIcenowy>
(or should we say when people tend to rely on silicon implementation details other than specifications
<apritzel>
yeah, one was hoping that they would have learned from the gloomy past
<MoeIcenowy>
maybe we can make SBI to mask the V bit of misa?
<MoeIcenowy>
and just use the CPU as RV64GC no V
<MoeIcenowy>
RV M mode is powerful enough that I saw someone implemented a ICE on it (as a SBI)
<apritzel>
but I guess you don't want to do that for the V extension ;-)
<MoeIcenowy>
apritzel: a not-compatible V extension is equal to no V extension
<MoeIcenowy>
I prefer to see it as part of Xthead
<apritzel>
yeah, I meant you just disable it, but don't try to emulate it in software
<MoeIcenowy>
I mean just mask its existence
<apritzel>
yeah, if you can do this
<MoeIcenowy>
I think there's no way to trap it in software
<apritzel>
is the V extension optional, or considered part of the required extensions for 64-bit Linux?
<MoeIcenowy>
optional.
<MoeIcenowy>
at least currently optional for general purpose distros
<MoeIcenowy>
required is GC
<smaeul>
apritzel: some other changes in D1: 2nd generation mailbox, uart1 has internal DMA, audio ADC/DAC now each do DMA instead of connecting an internal I2S DAI, there are 2 general purpose LDOs in the audio MMIO range (but not in the audio power/reset domain)
<jakllsch>
V is virtualization?
<smaeul>
V is vector
<apritzel>
MoeIcenowy: ah, I see, thanks
<apritzel>
smaeul: general purpose LDOs in audio MMIO sounds nasty ...
<MoeIcenowy>
apritzel: BTW for U-Boot, Allwinner BSP duplicated the whole mach-sunxi directory to arch/riscv from arch/arm
<MoeIcenowy>
smaeul: what? it has internal LDO?
<apritzel>
MoeIcenowy: of course the BSP did that ... ;-)
<MoeIcenowy>
well it's a fastest way to get something working
<MoeIcenowy>
like my fork of sunxi-fel
<apritzel>
sure, but they are a group of paid professionals and had quite some head start
<apritzel>
so they don't have any excuses for hacks
<smaeul>
MoeIcenowy: yes, LDOA and LDOB, see SYS_LDO_CTRL_REG
<smaeul>
there are also HPLDO and ALDO in POWER_REG. those are mostly single-purpose, but nezha does power the LRADC external pull-up with ALDO
<apritzel>
smaeul: but in general this all sounds like new-SoC-generation changes/additions, so nothing RISC-V specific?
<MoeIcenowy>
User manual chapter 3.5 "RISC-V System" is RISC-V specific ;-)
<MoeIcenowy>
it's like CPUCFG part, but for RV
<smaeul>
apritzel: there's that too, but nothing RISC-V specific is relevant for compatibility :)
<smaeul>
the IRQ control is interesting, because there are two separate ranges in RISCV_CFG (wakeup and edge/level control) in addition to the PLIC
<smaeul>
so we will need another stacked irqchip driver
<smaeul>
the currently-executing PC is exported to MMIO, but that's not too useful when the RISC-V is the main/only CPU
<smaeul>
the CPUX and RISCV clocks now have gates in a separate register from their muxes, protected by a key. the CCU driver does not have a way to model this
<apritzel>
smaeul: you mean you can't gate the PLL, after reparenting it to OSC24M? Which is what we do right now, but might not be needed anyway?
<MoeIcenowy>
apritzel: it's still able to
<MoeIcenowy>
and BSP does it (by using sunxi-ng)
<MoeIcenowy>
it's just the clock gate is moved out of the main clock register
<smaeul>
apritzel: CPUX has the special gate, not PLL_CPUX
<apritzel>
smaeul: but Linux would never want to gate CPUX anyway?
<smaeul>
it would when there is nothing hooked up to it (or if there is, it is fused off)
<MoeIcenowy>
apritzel: if you're RISC-V, you may want to gate/ungate CPUX
<apritzel>
so CPUX refers to the ARM core clock here?
<MoeIcenowy>
I think so
<smaeul>
yes, RISCV is a separate clock (which can also be muxed to PLL_CPUX)
<MoeIcenowy>
RISC-V can be parented to PLL-CPUX, PLL-PERI and even PLL-AUDIO
<apritzel>
but then you just don't expose this extra gate register at all, and fix this to disable CPUX, enable RISCV?
<MoeIcenowy>
apritzel: if we want to use the ARM as a coprocessor, then we need to be able to gate/ungate it
<smaeul>
apritzel: the same die is available with the ARM CPUs enabled, so they would share a CCU driver
<MoeIcenowy>
smaeul: yes, it's also what the BSP does
<MoeIcenowy>
BSP makes a ccu-sun8iw20.c, which matches allwinner,sun8iw20-ccu and allwinner,sun20iw1-ccu
<smaeul>
MoeIcenowy: I don't think you can use ARM as a coprocessor on the D1. I've tried every bit I can find in R_PRCM/R_CPUCFG/R_PPU and nothing shows any sign of life
<apritzel>
and there is nt
<apritzel>
and there is no other management controller?
<apritzel>
like on the H616?
<smaeul>
the running story seems to be that the RISC-V _is_ the management controller :D
<MoeIcenowy>
(BTW ccu-sun8iw20.c is in drivers/clk/sunxi-ng/ and uses sunxi-ng structure
tnovotny has quit []
<MoeIcenowy>
the BSP didn't model the gate in CCU driver
<MoeIcenowy>
cpux_clk is SUNXI_CCU_MUX and riscv_clk is SUNXI_CCU_M_WITH_MUX
<smaeul>
apritzel: there are three mailboxes, one for each CPU in the SoC (ARM, RISCV, DSP)
<apritzel>
smaeul: yeah, a RISC-V mgmt controller would actually make sense, but then just some RV32I would suffice, I guess
<MoeIcenowy>
apritzel: at least there's none usable on D1
<MoeIcenowy>
D1 BSP uses "normal standby", not "super standby"
<MoeIcenowy>
smaeul: before checking R_*, is CPUX clock okay?
<jernej>
just for info, what codename has ARM version of D1 die? R328 or R329?
<MoeIcenowy>
not 328/329
<smaeul>
jernej: R528
<jernej>
ah, thanks
<MoeIcenowy>
and I think CPUX always run from BROM
<MoeIcenowy>
so maybe its hotplug flag should be set
<MoeIcenowy>
otherwise CPUX will be trapped into BROM
<jernej>
looking at R329 manual, it's clearly dual A53 + RISC-V design, which is very similar to D1 in principle
<smaeul>
MoeIcenowy: yes, CPUX is enabled by default. by "signs of life", I'm referring to the CPUCFG registers reading as something other than all zeroes
<MoeIcenowy>
jernej: I think R329 has no RV
<jernej>
MoeIcenowy: I think Zhouyi Z1 AIPU 0.25T is actually RISC-V core
<MoeIcenowy>
whoever knows
<MoeIcenowy>
BTW Zhouyi Z1 is by ARM China
<jernej>
ah, sorry, "The SPU is a microprocessor based on the RISC VLIW architecture."
<jernej>
that is probably not RISC-V
<jernej>
MoeIcenowy, apritzel: just fyi, IR-TX is not a new core, it's already present on H6
<MoeIcenowy>
smaeul: for which part is you checked for CPUCFG ?
<smaeul>
MoeIcenowy: 8100000 and 9010000, the addresses in the manual/BSP. note that the original OpenSBI source blocked them via PMP, so you'll need to skip OpenSBI or use the updated BSP source
<MoeIcenowy>
oops
martinayotte has quit [Remote host closed the connection]
<tuxd3v>
apritzel, many thanks
<tuxd3v>
I added pwm1 to pinctrl-sun8i-h3.c
<tuxd3v>
in sunxi-h3-h5.dtsi
<tuxd3v>
I left pwm0 with: reg = <0x01c21400 0x8>;
<tuxd3v>
pwm1 with: reg = <0x01c21400 0xc>;
<apritzel>
tuxd3v: why pmw0 and pwm1 nodes?
<apritzel>
that's just one device, exposing two channels
<apritzel>
because of .npwm = 2 when using the _dual_ tag
<tuxd3v>
I only wanted to activate pwm1
<tuxd3v>
on pin PA6
<tuxd3v>
PA5 is for uart :)
<tuxd3v>
i don't know if it will work this way :)
<apritzel>
no, you get this wrong
<apritzel>
the pinmux is controlled by the pinctrl driver, via the pinctrl-0 property in the device
<apritzel>
of course most pins are multiplexed and can serve multiple functions, that's the whole idea of it
<apritzel>
the PWM0 channel output is connected to one of the *multiplexer* inputs for pin PA5
<apritzel>
but the multiplexer is programmed to forward the UART pin, which is another input
<apritzel>
so they don't disturb each other
<apritzel>
and you can't have two devices using the same MMIO region anyway, that's not how it works
<apritzel>
also: Linux won't allow two devices to use the same pin, that's ensured by the pinctrl subsystem
<apritzel>
if you would have that set up like this in your DT (which you shouldn't!), then the first device probing would win
choozy has quit [Ping timeout: 483 seconds]
<apritzel>
tuxd3v: so the solution is rather easy: you add pwm1 to the driver, and PA6 to the pio node in the .dtsi
<apritzel>
tuxd3v: then you tweak the PWM driver to make the H3 variant dual channel
<apritzel>
tuxd3v: and then you enable the pwm in your board .dts, and use a pinctrl-0 property to activate PA6 as PWM1
lurchi_ is now known as lurchi__
<tuxd3v>
apritzel, thanks, PA5 is UART0_RX
<apritzel>
yes, and you see that the UART device claims this pin via the uart0_pa_pins reference
<apritzel>
so whatever PWM0 outputs, it never makes it to the pin, because the multiplexer is routing the UART signal to PA5 instead
<tuxd3v>
indeed
<apritzel>
so you don't need to worry about PWM channel 0
<apritzel>
just claim PA6 for the PWM device
<apritzel>
and then use channel 0
<apritzel>
I mean channel 1
<apritzel>
what do you want to use the PWM for?
<tuxd3v>
for now I just want it availlable in GPIO, to use later
<tuxd3v>
so you think that I should only have one pwm node..
<tuxd3v>
I will call it pwm1 :)
<apritzel>
no, you won't ;-)
<apritzel>
you just leave the name as it is
<tuxd3v>
just pwm?
<tuxd3v>
hmm..
<apritzel>
the only change you make is to increase the size