<yoq>
jernej: i think the HDMI_CEC on G6 is only an optional multiplex, there are also dedicated pins called HCEC on G17, and others for I2C. only mentioned in the H616 datasheet, not the manual
<yoq>
looks like that is connected on the Zero2
yoq has quit [Remote host closed the connection]
jstein has quit [Quit: quit]
popolon has quit [Quit: WeeChat 3.0]
<apritzel>
yoq: good research, that seems to be correct: the Zero2 connects the dedicated pins
gaston1980 has quit [Quit: Konversation terminated!]
tglx has left #linux-sunxi ["gone"]
Mangy_Dog has quit [Ping timeout: 240 seconds]
<apritzel>
jernej: I finished the (first version of) the clock drivers, also have the .dtsi and .dts. It compiles at least, will do some testing tomorrow and push it somewhere.
ChriChri_ has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
ChriChri has quit [Ping timeout: 256 seconds]
ChriChri_ is now known as ChriChri
apritzel has quit [Ping timeout: 246 seconds]
victhor has quit [Read error: Connection reset by peer]
victhor has joined #linux-sunxi
tlwoerner has quit [Quit: Leaving]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
victhor has quit [Ping timeout: 256 seconds]
tlwoerner has joined #linux-sunxi
sunshavi has quit [Ping timeout: 256 seconds]
tlwoerner has quit [Quit: Leaving]
asdf28 has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Client Quit]
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
tmlind has quit [Quit: leaving]
tmlind has joined #linux-sunxi
faruk has joined #linux-sunxi
lkcl has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
reinforce has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
yan6 has quit [Changing host]
yan6 has joined #linux-sunxi
asdf28 has joined #linux-sunxi
lvrp16 has quit [Ping timeout: 260 seconds]
lvrp16 has joined #linux-sunxi
hlauer has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
faruk_ has joined #linux-sunxi
faruk has quit [Ping timeout: 246 seconds]
faruk__ has joined #linux-sunxi
faruk_ has quit [Ping timeout: 256 seconds]
ldevulder_ is now known as ldevulder
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
Nemo_bis has quit [Ping timeout: 240 seconds]
<mripard>
jernej: there's already a CEC-over-gpio implementation in Linux
<mripard>
it's pretty much what we're using for the !DW HDMI controller
apritzel has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
tnovotny has joined #linux-sunxi
Nemo_bis has joined #linux-sunxi
victhor has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 256 seconds]
<hlauer>
is there a possibility to access a i2c adress occupied by a kernel driver?
<bauen1>
apritzel: what is this about a "secure I2C" ?
<bauen1>
isn't i2c just done over gpio ?
<apritzel>
bauen1: there is traditionally an extra I2C controller dedicated to the management processor
<apritzel>
named "R_TWI0" in the manual
<apritzel>
that is typically used to connect the PMIC
<hlauer>
which soc?
<apritzel>
you can switch that to being secure only (given the SPC is effective, so only with the secure boot fuse burnt)
<apritzel>
hlauer: R_TWI? Most modern, H3, A64, H5, H6, ...
<apritzel>
bauen1: you *can* bitbang I2C, but it's a pain. The I2C h/w controller still requires some hand holding, but it's much easier to drive from a non-realtime OS
<apritzel>
bauen1: and for bitbanging you would need control over the pins, which are controlled by the R_PIO controller, which is also switchable
<bauen1>
right, i was still thinking of goold old atmegas :D
<KotCzarny>
arisc is nice too
<KotCzarny>
:)
<apritzel>
bauen1: didn't the Megas have some I2C hardware? The first ATxxx didn't, but I think they added it later?
gaston1980 has joined #linux-sunxi
<apritzel>
bauen1: it looks like Allwinner had this idea of having a "secure" enclave on the chip, with dedicated peripherals
<hlauer>
so the answer to my previous question is: steal the gpio pins and do bitbanging i2c on older chips like the a20?
<bauen1>
apritzel: yes, the idea is there (and it
<bauen1>
apritzel: yes, the idea is there (and it's nice), but the implementation is a bit lacking
<apritzel>
bauen1: The ARISC is meant to drive them, but they are accessible from the ARM cores as well, and they can be made secure world only
<bauen1>
it makes sense too since these chips are targeting tv hardware that (might) need hdcp keys
<apritzel>
bauen1: yeah, it's not watertight
<apritzel>
hlauer: if you can access those pins, you can, every pinmux can be set to GPIO
<bauen1>
i mean they did put quite a lot of effort into the sbrom, no off-by-one errors, everything allocated on the stack to avoid using a heap, mostly proper length handleing
<bauen1>
they only really missed 2 things: checking the total image length before loading it and verifying the asn.1 length of the outer item before using it
<apritzel>
bauen1: I would say they missed a security audit ;-)
<bauen1>
yeah ...
<apritzel>
bauen1: in general they seem to miss external input. They have some good ideas, but some things look wrong, like if they misunderstood some ideas
<apritzel>
bauen1: which happens, but is typically cleared up in a review, or by asking the right people
<bauen1>
apritzel: right, which reminds me that i should probably try sending them an email about this glaring hole
<apritzel>
bauen1: ah, this enthusiasm of yound people someone dealing with Allwinner for the first time :-D
<apritzel>
young*
<KotCzarny>
:>
<bauen1>
well go figure why i haven't done it yet
<apritzel>
bauen1: try going via TL Lim, he has actual contacts and already established communication in the past
<apritzel>
bauen1: thought this mostly didn't last long or went astray quite quickly
<apritzel>
like the first question they asked me once was how to best include binary blobs in a kernel ...
<apritzel>
bauen1: or try this guy who sent the A100 support to the kernel
<bauen1>
apritzel: yeah, my idea was to just grep the kernel git log for allwinner emails and put all of them on copy if going through "support" wouldn't work
<apritzel>
bauen1: you seem to misunderstand Allwinner's engagement in the mainline kernel ;-)
<maz>
do we have a single AW patch?
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
<bauen1>
i suppose i could start by writing down everything i've found in some form
camus is now known as kaspter
asdf28 has quit [Ping timeout: 264 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
asdf28 has joined #linux-sunxi
<apritzel>
maz: there are some contributions to pstore in 2019, and the recent addition of the A100 SoC support
<apritzel>
maz: though rumour has it that the latter is done by some Allwinner employee in his spare time
<maz>
apritzel: I guess that's progress, one way or another...
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
apritzel has joined #linux-sunxi
faruk__ has quit [Quit: Leaving]
kaspter has quit [Quit: kaspter]
hlauer has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
<jernej>
yoq: thanks for clearing this up!
<jernej>
mripard: I'm aware of that implementation and I'm using it on H3 because DW HDMI implementation depends on 32k clock being accurate (plenty of H3 and H5 boards don't have 32k crystal)
<jernej>
but there is a caveat - if CPU changes frequency, like enabling DVFS, doesn't work well
asdf28 has quit [Ping timeout: 260 seconds]
<mripard>
jernej: that would be worth reporting to hans
<jernej>
I assume that this depends on timers being accurate
<jernej>
and kernel should select high precision timer for such tasks, right?
<mripard>
iirc the framework / library to do that depends on the HR timers yep
<jernej>
timer is enabled 4 years already in DT, so I'm not sure why this doesn't work
<jernej>
anyway, I added HEVC support to LibreELEC some time ago and as I said, H6 is capable of decoding 10-bit 4k HEVC videos
<buZz>
jernej: yeah functional would be nice :P
<jernej>
not all quirks are worked out and currently a several out-of-tree patches are used, but it works well
<buZz>
ooo H3 even?
<buZz>
sweet!
<buZz>
i guess i'll go try a H3 as mediacenter then
<jernej>
yes, HEVC was first introduced in H3
<buZz>
there's one idle on my desk :)
<buZz>
nanopi m1 1gb version
<jernej>
a bit shameless promotion - take a look at LibreELEC images :)
<apritzel>
jernej: so what happens if a reference is not in memory (b/c CMA too small)? Does it work around it somehow (delaying frame, mapping somewhere else)? Or does it just drop the frame?
<jernej>
if CMA is too small you'll have issue allocating frames in userspace already
<jernej>
btw, references are previously decoded frames, so you have them in memory for sure
<jernej>
well, depends on HW design, but that's the case here
<jernej>
because you are cycling around buffers in same pool
<apritzel>
so you need to be able to allocate resources for the worst case, and won't even start if that's not possible?
<jernej>
ideally yes
<jernej>
first thing, I didn't yet found video with 16 references, so it's not so bad
<jernej>
but then you have some uncertainties, like how to determine max. size of bitstream
<jernej>
for one frame
<jernej>
you can apply some heuristics but at the end of the day, case can be found which doesn't fit in that estimated max. size
<jernej>
if you have iommu, you don't need to worry at all...
<jernej>
at least I imagine so, I didn't worked with iommu much
<apritzel>
jernej: yeah, I would hope that Linux would just allow you to allocate DMA buffer bigger than the CMA, when you have a scatter/gather IOMMU driver in place
<apritzel>
jernej: but I am also just a spectator here ;-)
<jernej>
apritzel: OPi 02 doesn't want to reboot - is there anything special needed for that? Reset works ok for me in U-Boot
<apritzel>
jernej: I needed to use the regular wdt in TF-A, it didn't work with the H6 R_TWD address
<apritzel>
(which we only use b/c of some H6(?) bug, IIRC)
<jernej>
is reset triggered over scpi?
<apritzel>
reset via PSCI should work (works from U-Boot when enabling PSCI_RESET)
<tuxd3v>
I believe CMA defaults to 128MB which could be less than what is needed..
<tuxd3v>
a value of 256Mb should work for all situations..
<jernej>
tuxd3v: default is 64 MiB IIRC
<tuxd3v>
256MB
<apritzel>
yeah, I think some distros tweak that via the cmdline?
<tuxd3v>
humm, I believe in kernel 5.10.x is 128MB i think
<jernej>
for H6 I have it set to 320 MiB
<tuxd3v>
you can use bootargs with 'cma=256M'
<jernej>
could be, I haven't checked defaults for some time
<tuxd3v>
I believe in the past, I also saw 64MB for cma in older kernels, I think
<jernej>
apritzel: so any clue why reset doesn't work?
<apritzel>
jernej: will tell you once I booted that kernel with the new allwinner,sun50i-h616-mmc compatible support
<apritzel>
ah, I should probably copy the kernel to the TFTP server directory for that, not the .dtb ;-)
<jernej>
or you can point TFTP directly in arch/arm64/boot folder :)
<apritzel>
where is the fun in that :-)
<apritzel>
\o/
<apritzel>
jernej: many thanks for digging this out!
<apritzel>
indeed reset doesn't work, investigating (I have those TF-A debug patches still around)
<apritzel>
(b/c working reset is a killer feature for developers)
<apritzel>
jernej: and then I will finish the TF-A patches, pinky promise! ;-)
<jernej>
:)
aliosa27 has quit [Ping timeout: 256 seconds]
<apritzel>
ohh, I should tell Linux to not touch the beginning of DRAM ... ;-)
aliosa27 has joined #linux-sunxi
duracrisis has quit [Ping timeout: 256 seconds]
duracrisis has joined #linux-sunxi
yann has quit [Ping timeout: 256 seconds]
<apritzel>
jernej: yup, fixed by adding a reserved-memory node into the .dts, covering the first 512K of DRAM (I think 128K would be enough already)
<apritzel>
jernej: so the memory was still alive when Linux brought up the secondary CPUs, but was then overwritten later
<jernej>
ah, makes sense
<jernej>
do you have patch or commit handy?
cmeerw has quit [Ping timeout: 240 seconds]
<apritzel>
pushing in a sec ...
dddddd has quit [Ping timeout: 256 seconds]
yann has joined #linux-sunxi
dddddd has joined #linux-sunxi
<apritzel>
jernej: pushed
zumbi has quit [Ping timeout: 256 seconds]
<apritzel>
jernej: was that "host->dma_mask = DMA_BIT_MASK(64);" line from the BSP?
<jernej>
yes
<jernej>
not sure if it's needed
<apritzel>
it's not, but it should be DMA_BIT_MASK(34); in any case
<apritzel>
not that it really matters in a 32.25 bit system ;-)
<apritzel>
jernej: I guess this applies to the MMC2 controller as well?
<jernej>
why 34? doesn't manual say 33-bit address space
<apritzel>
they shift the hardware address by 2 bits, so the IDMA controller can now handle up to 16GB
zumbi has joined #linux-sunxi
<jernej>
btw, USB port doesn't want to work...
<jernej>
maybe something similar...
<apritzel>
yeah, I couldn't get it to work in U-Boot either
<apritzel>
I don't think so, it's probably more the clocks
<apritzel>
H6 has this weird retro-fit USB clocks, and I still based on them
<apritzel>
need to compare against the H5, which is probably closer
<apritzel>
mmh, so MMC is not stable, I now got "[ 464.962379] sunxi-mmc 4020000.mmc: data error, sending stop command; [ 465.965943] sunxi-mmc 4020000.mmc: send stop command failed" after a while
<apritzel>
could be my dodgy SD card (found an Ubuntu 16.04 on it!), but that was the same message as before
<jernej>
I didn't observe such issue...
<jernej>
but so early you can't be sure
vagrantc has quit [Quit: leaving]
asdf28 has quit [Ping timeout: 240 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
<apritzel>
jernej: do you plan on splitting your U-Boot patches?
netlynx has quit [Quit: Ex-Chat]
<jernej>
that's the boring part :)
<jernej>
I didn't plan it, but I can do it soon
<jernej>
unless you want to do that?
<apritzel>
it's tempting to procrastinate from the TF-A part ;-)
<jernej>
go ahead :)
<apritzel>
but we are somewhat review-limited in U-Boot, so I definitely would prefer you sending them, so that I can review them
<apritzel>
first need to keep my pinky promise ;-)
<jernej>
that's good, I send U-Boot patches, you send kernel patches
<apritzel>
jernej: your awesome work on the DRAM driver made this really a smooth sailing experience, and we even have TFTP from the start (that helps a lot!)
<jernej>
well, I tried to enable GPU but then kernel crashed...
<jernej>
apritzel: and 64-bit FEL also helps a lot
<jernej>
apritzel: I'm not sure what to say about all those magic numbers in DRAM driver
<apritzel>
the truth! No documentation, but it works. People who complain are welcome to provide meaning.
<apritzel>
I prefer well structured code with magic values over dodgy binary blobs cluttering the serial console with exclamation marks
<apritzel>
I mean this is really a crucial part of the whole firmware stack, and by having an Open Source driver we are already light years ahead of many other SoCs
* karlp
cheers
<jernej>
apritzel: you missed second GPU clock :)
<apritzel>
jernej: yeah, I left that in to test the review quality :-P
hlauer has quit [Ping timeout: 265 seconds]
* apritzel
couldn't care less about the GPU, not to speak of the *second* clock ;-)
<jernej>
as I said, completely different use cases :)
<apritzel>
which is good! increases the coverage
<jernej>
yeah, at one point I'll have to check HDMI
<apritzel>
jernej: you might want to keep an ace or two up your sleeve for the public review ...
<jernej>
but I don't have micro HDMI cable yet
<apritzel>
jernej: no RPi4 around? ;-)
<jernej>
I don't care much about RPi4, so no
<apritzel>
this USB-C + microHDMI smells a lot like someone is mimicking that ...
<jernej>
I had/have 1 and 3
<jernej>
probably, but that FEL over USB-C is very nice for board bring up
<karlp>
yar, boards that don't have a proper usb port to the host are trash.
<karlp>
what do you mean, you only connected power to this?! or it's only connected to a hub port?!
<jernej>
USB-C port is used for powering board and at the same time, OTG USB from SoC is connected to it
<jernej>
it's a win for SoC bring up but maybe not so useful afterwards
<apritzel>
jernej: which is the same as the OrangePi Zero (with H2+), only that it's microB there
<jernej>
ah, I don't think I ever booted it
<apritzel>
the problem is that you can't hook it to a USB PSU easily and still have FEL
<apritzel>
but it's nice for those small boards that don't draw much power anyway
<jernej>
powered USB hub?
<apritzel>
jernej: that's what I use as well, yes
<jernej>
I don't but I should be
<apritzel>
actually the one on the FT4232 HUB module, so I also get serial consoles
<apritzel>
jernej: for DRAM controller setup some USB port should be good enough ;-)
<jernej>
I still run from USB port
<jernej>
because there is no nice way to put U-Boot together yet :P
jstein has quit [Quit: quit]
<apritzel>
jernej: I think it should work, let me try
<apritzel>
I added a patch to read the SPL size from the eGON header, and adjust the FIT image load offset accordingly
<apritzel>
so you don't need to tweak that variable at U-Boot config time
<jernej>
great!
<jernej>
interesting is that H6 and H616 completely freeze if driver try to use GPU when powered down
<jernej>
anyway, there is a hidden switch for GPU in PRCM :)
<apritzel>
jernej: isn't that the expected behaviour on a typical AXI bus?
<jernej>
I don't know, really
<apritzel>
I mean it's also a bus implementation choice, but if the other side is never acknowledging the transaction, then it's quite IMPDEF what happens, AFAIK
<apritzel>
I think I have seen this on normal MMIO register accesses, when the unit was in reset
<apritzel>
(or bus clock gated)
<jernej>
apritzel: there is gpu power off bit in PRCM, not sure if this should be modeled as clock or something else, like power domain...
<apritzel>
jernej: from the BSP, I guess? Does it explicitly say "power"? Or is it more like just a reset?
<jernej>
yes, bsp definition of this register is: gpu power off gating register
<apritzel>
idk, for simplicity we could claim it's a clock gate, and put it in the CCU, but I guess that's up to the maintainers to decide
<apritzel>
so that's for the Mali G31, right?
<smaeul>
normally I would say "please don't put power off gating bits in the CCU driver, because that would really mess up crust", but I guest that doesn't apply for this chip
zoobab has quit [Ping timeout: 240 seconds]
<jernej>
yes
<apritzel>
so there is mali-supply property in the binding, but I guess we need that already for the VDD_GPU power rail from the AXP
<jernej>
that's for regulators
<apritzel>
not sure if there is a generic regulator (ala fixed) that can be switched by a register
<smaeul>
where is this bit defined?
<apritzel>
PRCM
<jernej>
smaeul: H6 has same bit in same place
<jernej>
0x07010254
<jernej>
I guess it's just that default value is different
<apritzel>
because the H616 is more power efficient!!!
<apritzel>
I could take one for the team and flip it on in TF-A ;-)
<apritzel>
but I guess the co-maintainer would complain ..
<smaeul>
these "power off gating" bits are neither a clock gate, nor a reset, nor a power switch -- they're to isolate power domains so you can turn one off without it affecting others
<apritzel>
smaeul: sure, the same we have for the cores
<jernej>
smaeul: well, if I don't set it to 0, then SoC crashes when gpu driver is loaded
<smaeul>
so you need to turn in on after you enable the regulator, and turn it off before you disable the regulator
<apritzel>
smaeul: that's similar to those fixed regulators gated by a GPIO
<apritzel>
smaeul: and SCPI can abstract those specialities quite nicely
<smaeul>
SCPI?
<jernej>
GPU on H6 usually crashes when frequency and voltage is switched, so maybe this gating should be used
<smaeul>
jernej: the gating is only needed when you want to turn off the regulator
<apritzel>
smaeul: set/get device power state
<smaeul>
apritzel: but there's no AR100 on the H616, right?