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]
<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
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]
<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..