rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
<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...
<apritzel> right, let's stay positive!
sunshavi has joined #linux-sunxi
jbrown has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
apritzel has quit [Ping timeout: 240 seconds]
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
iyzsong has quit [Quit: ZNC 1.7.5 -]
<jernej> unfortunately I'm not the one who had issues with this...
iyzsong has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
asdf28 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #linux-sunxi
hlauer has joined #linux-sunxi
lucascastro has joined #linux-sunxi
tlwoerner has quit [Quit: Leaving]
<apritzel> jernej (and whoever cares): this is what I have for H616 Linux support:
<apritzel> contains the pin controller and clock driver for both the "normal" and the carcass of the remaining "R_xxxx" world
<apritzel> plus the H616 .dtsi and the OrangePi Zero 2 .dts
<apritzel> I fixed the most glarious bugs and typos, so those new devices seem to initialise properly, but the SD card isn't happy
<apritzel> even though it works in U-Boot
<jernej> apritzel: can you push TF-A port?
<jernej> and thanks for that work!
tlwoerner has joined #linux-sunxi
<apritzel> jernej: yes, that the next part
<apritzel> jernej: though my brain is still a bit mushy from those clocks and pins ...
tlwoerner has quit [Quit: Leaving]
<jernej> strange that mmc doesn't work
<apritzel> jernej: I think we need to teach some devices to cope without interrupts, foremost the AXP
<apritzel> jernej: surely some stupid typo somewhere
<apritzel> [ 5.439904] sunxi-mmc 4020000.mmc: data error, sending stop command
<apritzel> [ 5.447011] sunxi-mmc 4020000.mmc: send stop command failed
<apritzel> [ 5.452665] mmc0: error -110 whilst initialising SD card
<jernej> I'll check related stuff
<apritzel> or they changed some tiny detail somewhere in the DMA part
<apritzel> (U-Boot does not use DMA)
<jernej> mmc can work without DMA in linux, right?
<jernej> apritzel: you're missing port A, which is used just for second ethernet controller
<apritzel> same as in H6?
<apritzel> isn't mentioned in the manual in both cases
<apritzel> so yeah, I left enough bugs and omissions in there for everyone ;-)
<jernej> no
<jernej> I mean, it's not mentioned
<jernej> because it's completely internal and not visible outside
<apritzel> jernej: DMA for MMC means the internal/embedded DMA controller in the MMC IP, I think Linux relies on it
<jernej> yeah, I just figured that out
<apritzel> jernej: U-Boot reads the FIFO buffer from the register frame, which is surely painfully slow
<apritzel> kind of like PIO hard disk access in the 90s ;-)
<apritzel> "every byte greeted with a personal handshake"
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
jstein has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
yann has quit [Ping timeout: 264 seconds]
<jernej> apritzel: I removed all references to psci and kernel still fails to boot
<jernej> is there anything missing?
<apritzel> jernej: any output?
<jernej> no
<apritzel> let me try ...
yann has joined #linux-sunxi
<apritzel> jernej: do you have "earlycon" on the command line
<apritzel> I see it hanging before it hands over to the real console
<jernej> no, I added earlyprintk
<apritzel> maybe U-Boot does not do everything properly when dropping to EL2, or I missed some PSCI reference
<jernej> ah, earlycon actually prints something
<jernej> and yes, it crashes soon after UART driver is initialized
<jernej> with TF-A goes further?
<apritzel> jernej: earlyprintk doesn't work on arm64, IIRC
<apritzel> yes, until it tries to find the rootfs
<apritzel> jernej: I am trying a new approach on merging the "run in DRAM" changes into the TF-A code, if that works, I will push it
<jernej> ok, great
dev1990 has quit [Quit: Konversation terminated!]
<apritzel> ah: I think U-Boot doesn't set up the GIC for non-secure, that's a config symbol we don't enable for sunxi
<jernej> is this something I can easily toggle?
<apritzel> try CONFIG_GICV2, and you might need to set the GIC base address
<apritzel> it's not in Kconfig, though, legacy symbol (remember to wash hands afterwards)
<jernej> is this Linux or U-Boot?
<jernej> where do I set it?
<apritzel> U-Boot, hack it into include/configs/sunxi-common.h
<apritzel> that symbol is checked by the arm64 start.S
<apritzel> afk for a bit
<jernej> ok, that didn't help
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
jbrown has quit [Ping timeout: 272 seconds]
jbrown has joined #linux-sunxi
freemangordon has quit [Read error: No route to host]
freemangordon has joined #linux-sunxi
night199uk has quit [Ping timeout: 246 seconds]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
<jernej> apritzel: some progress with mmc0 - I made hacks in driver to mimick BSP driver behaviour:
<jernej> SD card is recognized but read data has checksum errors
<jernej> for sure new compatible will be needed
<jernej> apritzel: scratch that, this works:
<jernej> I'm able to boot now to console
<jernej> and ethernet also works nicely
night199uk has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> jernej: wait! Did they put word addresses in the DMA descriptors instead of byte addresses, to cover >4GB of DRAM?
<jernej> idk
<jernej> could be
<jernej> is that bad?
<jernej> you lose granularity, true, but most buffers are aligned anyway
<apritzel> yeah, it's just a hack, pushing the proper solution into next year, when they will need 16GB
<apritzel> they could have put the other bits somewhere else, or at least introduce a bit to switch that behaviour
<jernej> is dma_mask needed? does that assure alignment?
<apritzel> the default dma mask is 32bit, IIRC, so that just allows it to have the buffers between 3GB and 4GB
<apritzel> point is: they could have done nothing, and it would have worked
<jernej> are you sure? you couldn't access upper 1 GiB
<jernej> but I guess that doesn't change anything
<apritzel> but Linux would have just allocated the DMA buffers from addresses below 4GB anyway
<apritzel> so that would have been not a great loss, but would stayed compatible
<apritzel> which Allwinner obviously doesn't care about
<jernej> well, does it matter in this case?
<apritzel> thanks to your findings, it does not, but means we need a new exclusive compatible
<buZz> doesnt PAE help with DMA?
<apritzel> buZz: for 64-bit we don't have any PAE, and DMA is physical addresses, so: no
<buZz> hmhm
<buZz> ok
<apritzel> IOMMUs can remap device addresses
<apritzel> and are used to let 32-bit only devices access memory beyond 4GB (among other reasons)
<jernej> oh, iommus are very useful for gpu/multimedia buffer handling
<apritzel> jernej: yes, that's what I meant with "other reasons"
<jernej> :)
<apritzel> I personally like the isolation properties and the ability to restrict access for VMs
<apritzel> but that's not what the AW IOMMU can do
<apritzel> jernej: you mean scatter/gather, to construct seemingly contiguous buffers from random physical pages?
<jernej> exactly
<apritzel> when I first read "IOMMU" in the H6 datasheet back then, I got really excited, only to be disappointed quite quickly :-(
<jernej> I think this is the only mechanism implemented with AW IOMMU, right?
<apritzel> AFAIK yes
<jernej> we have very different point of view :) I was happy for scatter/gatter functionality
<jernej> which means no more dealing with CMA
<apritzel> probably ;-) But is CMA such a big issue in reality?
<jernej> but I didn't try to use it yet...
<apritzel> I mean it somehow works today, doesn't it?
<apritzel> So now you have *two* solutions to maintain
<jernej> at the very beginning there were some issues, but I didn't yet take time to properly look into it
<jernej> iommu should be transparent in userspace and mostly in drivers too
<jernej> so only difference is that I don't need to tweak CMA size
<apritzel> jernej: is scatter/gather abstracted in the IOMMU framework?
<jernej> consider this: H6 is capable of decoding 4k 10-bit HEVC in P010 format and HEVC can have max. 16 references for each frame
<jernej> you can calculate how much memory it can take
<buZz> is there any h265 hw decoder in a allwinner yet?
<jernej> not sure in which framework but for example for cedrus driver is completely transparent
<jernej> buZz: you mean working implementation?
<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?
<apritzel> smaeul: details ...
<apritzel> I think there is now a SMC transport