ftg has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
junari has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
jjjjjjjjjjjjjjjj has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
jjjjjjjjjjjjjjjj has quit []
junari has quit [Ping timeout: 480 seconds]
triskit is now known as triskit|away
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
<jernej>
apritzel: rtl8822 is already supported by mainline for some time (BS and CS versions)
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
KREYREN__ has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
KREYREN__ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
junari has joined #linux-sunxi
apritzel has joined #linux-sunxi
inf has quit [Ping timeout: 480 seconds]
inf has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
edwardnorton has joined #linux-sunxi
edwardnorton has quit []
norton has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
Halamix2 has quit [Quit: Gone (and/or ZNC is doing something stupid)]
Halamix2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
KREYREN__ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
dsimic is now known as Guest8207
dsimic has joined #linux-sunxi
Guest8207 has quit [Ping timeout: 480 seconds]
JohnDoe6 has joined #linux-sunxi
<apritzel>
jernej: ah, true, just see it. I don't think it's a Realtek, though, the vendor kernel reports a SDIO for a Broadcom BCM4335
<apritzel>
02d0:4335 "BCM4335/BCM4339 WLAN card"
<jernej>
that should also be supported
<apritzel>
yeah, there is something missing with the platform setup, the kernel says: mmc2: Failed to initialize a non-removable card
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
<apritzel>
I used all the GPIOs I could find in the vendor DT, but I think the semantics are typically different between vendor and mainline DT
<apritzel>
(reset vs enable, for instance)
<apritzel>
also I saw PG10 configured to X32KFOUT, so I guess it also needs the LOSC fanout
kuba2k2 has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
<jernej>
BCM wifi always need LOSC out
<apritzel>
and this is done via a clock reference in the pwrseq DT node?
<jkm>
edpt
<jkm>
sorry, wrong window, carry on :P
<apritzel>
jkm: that's a very short password ;-)
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<jernej>
apritzel: yes
apritzel has quit [Ping timeout: 480 seconds]
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
warpme has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
electricworry has joined #linux-sunxi
ftg has joined #linux-sunxi
electricworry has quit [Quit: Leaving]
electricworry has joined #linux-sunxi
norton has quit []
norton has joined #linux-sunxi
electricworry has quit []
electricworry has joined #linux-sunxi
<electricworry>
Is anyone here working on the Orange Pi Zero 3? I've been chatting with some people on the u-boot and linux-sunxi mailing lists, and some of them might be here.
KREYREN__ has quit [Remote host closed the connection]
kuba2k2 has joined #linux-sunxi
KREYREN__ has joined #linux-sunxi
<junari>
electricworry: yep
<electricworry>
I'm trying to decide what to do next. Andre Przywara and others appear to have u-boot largely tackled and working. It looks like there's a lot of work still to be done on the kernel however. Some work has gone into 6.7 but it's far from complete. And I've got a pretty complete 6.1.31 modified kernel which I'm trying to get opengl working in.
<electricworry>
When I attempt to boot with 6.7-rc2 I don't even get output on the serial console; it just stops outputting anything after the "Starting kenel ..." line.
kuba2k2 has quit [Ping timeout: 480 seconds]
<gamiee>
this reminds me, did anyone played with H616 RISC-V SCP core? Or it doesn't have one?
<jernej>
gamiee: afaik it doesn't
<gamiee>
:/ well, that's downgrade from H3/H5/H6 (also hi jernej :) )
<jernej>
electricworry: I have enough patches to run LibreELEC distro on H616 and I soon plan to run it on Orange Pi Zero 3 too
<jernej>
in other words, I have graphics part sorted (in hackish way)
<jernej>
gamiee: hi! :)
<electricworry>
jernej: That's cool. I've not looked at LibreELEC, I'm doing all of my work with the meta-sunxi layer for yocto. Will you be attempting to submit your patches to kernel mainline? Do you need help testing them?
<jernej>
electricworry: First I need to finish them
<jernej>
DE3.3 has two big new features which need a lot of work
<gamiee>
jernej: how is shut-down performed on H616 boards? Is there some PMIC?
<jernej>
one is planes independent of output (you can assign all 7 planes or just 1 to one output)
<electricworry>
jernej: No problem. Do get in touch on the mailing list if you need any testers at some point. I'll keep an eye on it.
<jernej>
I have only hackish solution for that one
<jernej>
and another one is register copying DMA like, so registers get applied at exactly right time
<jernej>
no implementation for that one yet
warpme has quit []
<junari>
electricworry: I have manjaro arm based on jernej's kernel, that can load DE
<jernej>
gamiee: same as on other boards. if there is PMIC, it used, yes.
<jernej>
electricworry: I'm not sure when I'll have time to continue the work. If you need it now, I suggest you test patches from my github. Note that for GPU you also need U-Boot hack for power domain (this too needs better solution).
<electricworry>
jernej: I'm low on time at the moment too, but I'll take a link to your repo if you don't mind sharing.
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<electricworry>
I'm sure I'm not as experienced as others here with this work. What's the main method or approach for getting this done? It feels like shooting at a rapidly moving target. xunlong have provided the source for OrangePiOS, so building something with a full DE is kind of trivial, but getting things published upstream is the big challenge. At best I'll be happy to have a set of patches that work even if it takes
<electricworry>
months/years to get them improved and upstreamed. Obviously one can take xunlong's kernel repo, diff against 6.1.x and cherry pick changes. (And that's what I've done for my setup.) But none of them will merge nicely into the mainline kernel of the day because things change so much with each release. How do you all remain sane working on this? :)
<jernej>
first thing, Xunlong makes BSP kernel source drop, which is usually useless for mainline purposes
kuba2k2 has joined #linux-sunxi
<jernej>
so we take that just as documentation and write our own drivers
<jernej>
which usually don't have much common with BSP ones
<jernej>
so yeah, you'll have hard time forward porting BSP drivers, while rebasing "to be upstreamed" drivers usually isn't a big deal
<electricworry>
That's very helpful to understand the process thanks. So you do refer to the BSP, but you write cleaner patches against mainline (in your case against 6.6-rc2) and then once you're done it should be easier to rebase them to master at the time?
<jernej>
cleaner drivers, but yes
<jernej>
often BSP drivers don't follow mainline practices, so they would be rejected
<jernej>
for example, BSP display driver is still implemented as fbdev, while mainline accepts only DRM based drivers
<jernej>
not to mention various multimedia related cores - they have custom interfaces, while upstream accepts only V4L2 based drivers
<electricworry>
good to know. there's a whole world of standards here that I'm not aware of yet.
<gamiee>
jernej: yeah, I know, just I miss the additional features of SCP, as it let us to do wake by IR, CEC, etc..
<electricworry>
jernej: Can I just sanity check something? I built your kernel and replaced my build and there's no output to the serial port. Is that something still to be done?
<jernej>
gamiee: CEC might work, because interrupt can be set for specific messages
<jernej>
so wfi sleep + CEC interrupt
<gamiee>
hmm, I totally forgot about WFI sleep. It is probably not that good as how it would be with SCP, but also OK option. Is this implemented in.... TF-A? (idk what part should manage suspend and shutdown)
<jernej>
electricworry: UART works just fine for me, although on other boards. I haven't test OrangePi Zero 3 yet
<jernej>
gamiee: you have to ask apritzel or smaeul
<electricworry>
jernej: Ok, that's maybe something easy for me to start with to learn the process. Thanks!
<jernej>
gamiee: with IR and other peripherals active, even SCP can't go in deep sleep
<gamiee>
jernej: yeah, that's understandable. I just want to be able to "power off" device (no need for RAM retention), and have ability to turn it on through CEC, IR or button.
<gamiee>
Having this, I might could migrate to H616 someday
<jernej>
I plan to research H616 based TV box how IR power on/off is done
<jernej>
since there it depends on protocol and simple interrupt doesn't suffice (IR interrupt can be triggered by turning lights on in the room)
<jernej>
(sometimes)
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
electricworry: do you have "console=ttyS0,115200n8 earlycon" on your kernel command line?
<apritzel>
gamiee: on arm64 poweroff goes via PSCI, so it's TF-A in charge
<apritzel>
and TF-A has code to talk to the PMIC, and turns the system off this way
<apritzel>
only that the current H616 TF-A code is married to the AXP305 via RSB, so it doesn't work on devices using the AXP313 (which are also using I2C only)
<apritzel>
if anyone wants to have a look at fixing this: be my guest, it's not very high on my priority list
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
warpme has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<electricworry>
apritzel: Thanks, I was missing earlycon.
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
norton has quit [Quit: WeeChat 4.1.1]
<gamiee>
apritzel: thanks for explanation. What if there is no PMIC, or what if I want to listen to interrupts (HDMI-CEC / IR wake up)? I guess it needs to be done in TF-A?
<smaeul>
gamiee: yes, WFI sleep / s2idle would be implemented in TF-A. for "fake" poweroff, that could be implemented in TF-A like we do for H5, but that wouldn't be able to wake up afterward.
<smaeul>
if you want to poweroff and still listen for wakeup, you need some firmware running in SRAM, but still on the ARM CPU. This could be something you kexec() into.
<gamiee>
Hmm. And how to then start the boot process again? Or just trigger watchdog which will reboot it?
<smaeul>
right, just trigger a reboot to wakeup. this is what crust does already
<gamiee>
Hmm. How difficult is to develop such firmware? Since it will be executed after Linux and it will live in SRAM, everything should be set up? (maybe turn off DRAM and some not used stuff to save power?)
apritzel has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
electricworry has quit [Quit: Leaving]
norton has joined #linux-sunxi
macromorgan_ has joined #linux-sunxi
norton has quit [Quit: WeeChat 4.1.1]
macromorgan has quit [Ping timeout: 480 seconds]
kuba2k2 has quit []
<apritzel>
gamiee: so just want the box to power on / boot up again after an IR event?
<apritzel>
I think you wouldn't need something like a complete "firmware" part, you could just put that in TF-A
<apritzel>
so we just need to figure out how to communicate this soft-power-off event to PSCI
<apritzel>
the descriptions for SYSTEM_RESET2 says: "Values in the range 0x80000000-0xFFFFFFFF of the reset_type parameter can be used to request vendor-specific resets or shutdowns."
<smaeul>
apritzel: the only problem with putting it in TF-A is that TF-A runs in DRAM on H616, so you couldn't turn off DRAM.
<apritzel>
yes, but on poweroff we own the system, so could put some code into SRAM A1
<smaeul>
Yes, it could be embedded in TF-A, like the AR100 thunk or U-Boot's secure monitor, but it would still need to be some standalone firmware
<apritzel>
understood, but I guess in case of just IR that could be pretty small? We could do the set up in DRAM code still, then just have a "wfi; check IR for power key; go back to sleep or reset" in SRAM?
<apritzel>
don't know anything about CEC though
<smaeul>
right, the SRAM part doesn't need to be very big, just enough to finish turning off DRAM and check the desired wakeup sources
KREYREN__ has quit []
norton has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]