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
ftg has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
KREYREN_ has joined #linux-sunxi
gsz has joined #linux-sunxi
KREYREN_ has quit [Ping timeout: 480 seconds]
pmp-p has quit [Remote host closed the connection]
pmp-p has joined #linux-sunxi
Daaanct12 has quit [Quit: WeeChat 4.2.1]
jelly has quit []
Daanct12 has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
jelly has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
jelly has quit []
hexdump0815 has quit [Remote host closed the connection]
ynezz has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
wingrime-ww has quit [Remote host closed the connection]
wingrime-ww has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
jelly has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
ynezz has joined #linux-sunxi
ynezz is now known as Guest4156
<KREYREN_oftc> Does anyone have any idea what's happening here? https://github.com/NixOS/nixpkgs/pull/299116
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest4167
ungeskriptet has joined #linux-sunxi
Guest4167 has quit [Ping timeout: 480 seconds]
warpme has quit []
machinehum has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
apritzel has joined #linux-sunxi
pmp-p has quit [Ping timeout: 480 seconds]
pmp-p has joined #linux-sunxi
<apritzel> KREYREN: so some source you linked somewhere describes some touchy enablement sequence, with certain delays and a certain order in enabling the regulators
<apritzel> and the Linux kernel driver seems to implement exactly that
<apritzel> but the U-Boot bridge driver seems ignorant of the regulators altogether
<apritzel> so I guess TF-A just blindly enabling them might spoil that sequence?
<apritzel> I think the proper solution is to add explicit regulator support to the U-Boot driver, and implement this very sequence there
<apritzel> and disable the regulator setup in TF-A
<apritzel> we have a similar problem with some Ethernet PHYs on some Orange Pi H6 boards, and that's the reason I introduced SUNXI_SETUP_REGULATORS=0
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest4182
dsimic has joined #linux-sunxi
Guest4182 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: ZNC 1.9.0 - https://znc.in]
Danct12 has joined #linux-sunxi
<KREYREN_oftc> apritzel, the source is from teres's schematics
<KREYREN_oftc> apritzel, i didn't find relevant source code in the uboot for this but it sounds plausibl
<KREYREN_oftc> e
<KREYREN_oftc> apritzel, so you say that the SUNXI_SETUP_REGULATORS=0 might help, but that this is a uboot issue?
<KREYREN_oftc> also might be relevant that teres seems to get it's battery power cut off on high load with no msgs in the kernel so it might be related.. my hypothesis was that it's trying to draw beyond the battey cut off bcs it has an internal circutry for safety things
<KREYREN_oftc> also the display doesn't get turned on if it fails to initialize during uboot
<apritzel> yes, that would be the symptom: TF-A enables both regulators, and *later* the ANX U-Boot driver enables the bridge, but this is not the right sequence
<apritzel> so the bridge is messed up
<apritzel> so my suggestion would be to add both regulator code to the U-Boot bridge driver, and then implement the right sequence there. Then use SUNXI_SETUP_REGULATORS=0 for the TF-A build
<apritzel> KREYREN_oftc: this is one example of how to add DT regulator support to a U-Boot driver: https://source.denx.de/u-boot/u-boot/-/commit/5ad98c57b?page=2#31f8557d39e32258de682843f7252341e404edc5
<KREYREN_oftc> ity, wanna implement this?
<KREYREN_oftc> > https://source.denx.de/u-boot/u-boot/-/commit/5ad98c57b?page=2#31f8557d39e32258de682843f7252341e404edc5 that seems to implement that for the H64 from pine does that mean that all i have to do is set CONFIG_MACPWR="PC16" ?
<KREYREN_oftc> oh that has H6
<apritzel> ??? that's code for the sun8i-emac driver, that's the Ethernet IP in the H3, A64, H5, H6, H616 ....
<apritzel> It's technically unrelated to your problem, but an example of how to add proper regulator support to a U-Boot driver
<KREYREN_oftc> oh i see
warpme has quit []
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<apritzel> so is there anyone double checking the AXP717 regulator patch(es)?
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
warpme has joined #linux-sunxi
Daaanct12 has quit [Quit: WeeChat 4.2.1]
sunshavi has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<macromorgan> apritzel: I've been busy testing my own stuff, but so far I've had no issues with the regulator patches thus far
<macromorgan> I have been trying to teach myself USB-C because I both want to get a driver out the door for the bq25703 as well as see if I can contribute any USB-C stuff for the 717
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<apritzel> macromorgan: oh great, any help there would be warmly welcomed!
Schimsalabim has quit [Read error: No route to host]
KREYREN_oftc has quit [Remote host closed the connection]
Schimsalabim has joined #linux-sunxi
<apritzel> also have you seen what I wrote yesterday, about the H616 family BROM using 256KB, not 128KB as the alternative SPL/boot0 location on an SD card?
KREYREN_oftc has joined #linux-sunxi
<Jookia> yeah i saw it. not sure what to do with it
<apritzel> Jookia: it's just a small detail, and a two-liner U-Boot patch to support it, but macromorgan was wondering about why putting the SPL at 128K didn't work on his board
<Jookia> ah
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]
machinehum has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
warpme has quit []
<Jookia> is uboot master broken for the t113?
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel> Jookia: in how far? boots into the U-Boot prompt via FEL for me
KREYREN_ has quit [Remote host closed the connection]
<Jookia> i rebased my NAND branch on it and it isn't booting. going to do some more troubleshooting
<apritzel> what is not booting, exactly? no sign from the SPL? U-Boot proper not loading? kernel not booting?
Schimsalabim has quit [Read error: Connection reset by peer]
<Jookia> no sign from SPL
Schimsalabim has joined #linux-sunxi
<Jookia> i'm going to strip my changes out and just try direct master builds
<apritzel> Jookia: booting from SD card?
<Jookia> haven't tried that yet
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
<Jookia> ... i was using the wrong config
<Jookia> it works
Schimsalabim has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<Jookia> lesson learned: test with FEL first
alikates has quit [Quit: ZNC - https://znc.in]
alikates has joined #linux-sunxi
<apritzel> amazing how OrangePi managed to sneak in "mainline" support for the A527, without us even noticing it :-D
vagrantc has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
alikates has quit [Quit: ZNC - https://znc.in]
alikates has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
<alikates> apritzel: Got a UART output!
gsz has quit [Ping timeout: 480 seconds]
<alikates> it has the PIO v2, but the mux function value of UART is 0x2, like on H616
<alikates> And it also works with the SPL command
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
vagrantc has quit [Quit: leaving]
<ity> KREYREN_oftc: H64? But *why*
vagrantc has joined #linux-sunxi
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> ity: there is nothing H64 related in there, not the Pine H64 nor the Allwinner H64
<ity> Oh
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
f_ has quit [Remote host closed the connection]
f_ has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
f_ has quit [Remote host closed the connection]
timsu has joined #linux-sunxi
<apritzel> timsu: depends on which I2C port and on which pins you need
<apritzel> I guess it's on the header pins?
<timsu> it should be the twi4 port
<apritzel> for that you need to add the pins first to sun50i-h616.dtsi
<apritzel> and then enable i2c4 in your board .dts, and reference those pins
<apritzel> (and the term "twi" is not used in the mainline kernel)
<apritzel> PG16 & PG15, on the header pins 3 and 5?
<timsu> exactly, this should match the raspbrry pi pinout
vagrantc has quit [Quit: leaving]
<timsu> so i can use a hat
<apritzel> look at the other i2c pins in sun50i-h616.dtsi, and copy that for your two pins
colinsane has quit []
timsu has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
timsu has joined #linux-sunxi
<alikates> apritzel: now that i got an uart output with uart0-helloworld, i'm trying to build u-boot and at least get the SPL running. I'm trying to understand the code u-boot's boot0.h and I see a WFI loop at the end of the init RVBAR setup code. I guess that loop assumes a trap is going to be triggered somehow right?
<timsu> apritzel: great, steadily making progress, thank you!
<apritzel> alikates: yes, that "msr RMR" will reset the core into AArch64 EL3, with the code execution continuing at where RVBAR points to
<apritzel> RMR is architectural, but the location of the writable RVBAR copy is not, so this depends on the SoC
<alikates> Okay, so then i will have to do some guessing
<alikates> Ive already defined a base dts, early uart params and stuff based on what i got by trying with the helloworld
<alikates> So i expected at least a uart output, i will recheck the rvbar address
<apritzel> please note that the SPL does not use the DT, so you have to find all the hardcoded addresses in the source and adjust them :-(
<alikates> I know i know, i already modified the .h with all the defines
<alikates> So you say there are hardcoded addreses not controlled by defines?
<apritzel> ah, good. And no, it should be all in headers or in Kconfig
<alikates> Ah okay, all good then haha
<apritzel> if you look at U-Boot commit 95168d77d391b146 and its parents, that should give you some guidance. Those are the T113s support patches, the last SoC we added
<apritzel> a lot of those you won't need, and you can probably lean on a lot of SUNXI_GEN_NCAT2 definitions that series introduced
<apritzel> the clocks can get quite hairy without a manual (even with one!), but you might find something in those github code hits?
<alikates> Okay, ty
<alikates> Yeah i remember stuggling to understand some qcom SoC clock mux and gate registers..