ftg has quit [Read error: Connection reset by peer]
<apritzel>
MasterR3C0RD: which makes the NO_REPARENT patch good to go now, I think, I will reply on the list
<apritzel>
MasterR3C0RD: do you still see stability issues with your eMMC, which that patch?
<apritzel>
it could be that the traces are not good enough for HS-200, but maybe DDR50 would work?
<MasterR3C0RD>
After further testing, I think it's likely related more to clocks or voltages; if I reset my device with its little reset pinhole it'll usually pick up HS200 afterwards
<MasterR3C0RD>
And if I rebind the MMC module it'll work as well
<apritzel>
well, it would be a clock issue, since HS-200 is using a faster clock
<apritzel>
MasterR3C0RD: it was 1.8V, right? And you have a mmc-hs200-1_8v property in your DT? If yes, drop that, and have mmc-ddr-1_8v instead
<apritzel>
that limits the bus to 100 MB/s, but I guess the flash chips aren't faster anyway
<MasterR3C0RD>
Huh... there must be some funky power-rail business going on. 4022000.mmc: data error, sending stop command
<MasterR3C0RD>
I guess I should just stick with the original DTB and use 3.3V modes
<apritzel>
there is 3.3V DDR50, so you wouldn't lose much
vagrantc has quit [Quit: leaving]
<MasterR3C0RD>
3.3V doesn't make a difference; still fails on cold reset
<MasterR3C0RD>
... or not? One sec
<apritzel>
it's meant to boot from eMMC, right? Then the right voltage should be the reset value of the PMIC for that rail. You can hack up axp_spl.c to dump PMIC registers, and so learn about that voltage
<apritzel>
(given you know which rail it is)
<MasterR3C0RD>
Nah I think I have an idea of what's going on, and it's 100% power related if so.
<MasterR3C0RD>
Yeah okay that's it
<MasterR3C0RD>
So my stock board runs PL at 3.3V through aldo1, which I figured out through experimentation. I haven't been updating my U-Boot device tree every time I rebuild the device tree for Linux, so it's still probably setting aldo1 to 3.3V. If I constrain PL to min-max 1.8V, it works 100% of the time
<MasterR3C0RD>
*VCC_PC/VCC_PL
montjoie_ has joined #linux-sunxi
<MasterR3C0RD>
(side note: I know it's powering PL as well as PC because if I turn off the regulator, I can't talk to the PMIC anymore, and that's connected to PL)
montjoie has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Running at a lower voltage is fine though, since the AXP806 supports 1.8V logic levels as well as 3.3V
<apritzel>
so VCC_PL and VCC_PC are supplied by the same ALDO1 voltage rail? Do you know what the voltage at reset is? The manual says it's customised...
<MasterR3C0RD>
At reset I believe it's 3.3V
<MasterR3C0RD>
But I have U-Boot configured to set it to 1.8V
<MasterR3C0RD>
Well, not exactly configured; it's just getting set to that because it's trying to initialize the eMMC
<MasterR3C0RD>
Yeah if I don't have dcdcb (which supplies VCC_PG I believe) set to `always-on` and `boot-on`, the WiFi card doesn't initialise correctly, even though `vqmmc-supply` is set to use that, so I think it's probably due to some delay I need to add
<apritzel>
what frequency is the mmc2 clock set to? I think we are missing a "max-frequency = <150000000>;" line in each MMC DT node (mentioned in the manual, and we have that for every other SoC)
<apritzel>
I missed that during review
<MasterR3C0RD>
In my board's DT the MMC2 max frequency is set to 200MHz, but that doesn't seem to cause any problems, nor change anything if I set that on MMC2 and then set aldo1 to be min-microvolts/max-microvolts 1.8V/3.3V
<MasterR3C0RD>
s/set that/set max-frequency to 150MHz/
apritzel has quit [Ping timeout: 480 seconds]
aggi has quit [Quit: connection closed.]
Lightsword_ has left #linux-sunxi [#linux-sunxi]
Lightsword has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
parthiban has quit [Remote host closed the connection]
parthiban has joined #linux-sunxi
<parthiban>
apritzel: MasterR3C0RD: Morning!
<MasterR3C0RD>
parthiban: Hi! Did you get Cc'd on apritzel's bugfix patch for mmc0/1?
<MasterR3C0RD>
Yes you did; that fixes the hang when trying to use SD cards
<parthiban>
Yes, I have custom PCB with AXP717C and Helper board with AXP707.
<parthiban>
Yeah, I got the patch. I can pull and give a try.
<parthiban>
mount works for SD as well.
<parthiban>
Hope this will solve my SDIO WiFi card issue as well IMO together with the RTC clock patches.
<parthiban>
But I doubt I will be able to test those pieces today.
<MasterR3C0RD>
Having any luck with the TCON/DE?
JohnDoe_71Rus has joined #linux-sunxi
<parthiban>
MasterR3C0RD: Am mostly using the D1's implementation for the pipeline. Limiting the mixer to 1 and using the tcon_top as well. But am still figuring the display clock.
<parthiban>
Also LVDS PHY0 is shared between DSI and LVDS, so this got registers in DSI block.
<parthiban>
Had to enable DSI clock to control these registers still.
<MasterR3C0RD>
So far sounds like it's certainly the peskiest task thus far on the kernel side of things
<parthiban>
My knowledge with DRM is limited to i.mx IPU's so far. So this is new land of exploration.
<MasterR3C0RD>
Crypto Engine, on the other hand, appears to match the H616's perfectly; we should be able to use its compatible
<MasterR3C0RD>
parthiban: Yeah, you're braver than I for jumping headfirst into that lake HAHA
<MasterR3C0RD>
Also, I realized something interesting that I apparently missed the first few times I looked at the memory map. The register block that has some of the DRAM gating and such, which in the H616 fits in the "MCTL COMMON" area, is called "DRAM_TOP"
<parthiban>
the whole _TOP IP's are controlling the clock gating and setting up the connections for the flow.
Daanct12 has quit [Read error: Connection reset by peer]
<MasterR3C0RD>
Yep, exactly
<MasterR3C0RD>
The block is also completely different from that used on the H616 in layout
Daanct12 has joined #linux-sunxi
<parthiban>
Which one? DRAM_TOP?
<MasterR3C0RD>
Yeah, DRAM_TOP is not the same as MCTL_COMMON
<MasterR3C0RD>
At all
<parthiban>
Try comparing with D1 or T113. For me the LCD/LVDS controller stuff matched with it.
hexdump01 has joined #linux-sunxi
<MasterR3C0RD>
There's no documentation on the layout of the DRAM blocks, but the registers that are most important are already well known, so it's a non-issue
hexdump0815 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
It's mainly just interesting from a perspective of figuring out the difference between blocks; not an important thing, though the distinction will be useful for the unified driver
aggi has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
Turl has joined #linux-sunxi
Turl_ has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
Turl has quit [Ping timeout: 480 seconds]
Turl has joined #linux-sunxi
Turl has quit [Ping timeout: 480 seconds]
Turl has joined #linux-sunxi
warpme has joined #linux-sunxi
Turl has quit [Ping timeout: 480 seconds]
Turl has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
warpme has quit []
apritzel 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
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
szemzoa has joined #linux-sunxi
mirko has joined #linux-sunxi
<mirko>
and every couple years again: new linux kernel built and no working ethernet on orange-pi-3: "EMAC reset timeout" / "probe with driver dwmac-sun8i failed with error -110". latest uboot/ATF. uboot+kernel patches from latest libreelec/master branch. any idea?
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
warpme has quit []
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
dsimic is now known as Guest8743
dsimic has joined #linux-sunxi
Guest8743 has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
paulk has quit [Quit: WeeChat 3.0]
paulk has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
<apritzel>
mirko: did you compile TF-A with SUNXI_SETUP_REGULATORS=0?
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
Soupborsh has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<Soupborsh>
Hello, using IRC is uncomfortable for me. You need to setup a bouncer, also on Android there are no clients that are good for me.
<Soupborsh>
What do you think of creating matrix bridge? IMO it should have chat history.
<gamiee>
Use Quassel, it's nice.
<gamiee>
It have both desktop and android apps, which are good.
<Soupborsh>
I am trying to port to PB618, it has emmc. I connected to UART successfully, but cannot enter FEL by holding 2 or 1 or by holding buttons. I do not want to soft brick device intentionally to enter FEL because I am not sure if I can unbrick it later at all or in reasonable time.
<apritzel>
Soupborsh: this chat is logged, see the topic, so you won't need a bouncer and won't miss anything
<apritzel>
Soupborsh: I doubt you can enter FEL mode via buttons on those devices. There might be pads on the PCB (one of my tablets has one), some TV boxes have a hidden button inside the headphone jack
<apritzel>
but you should be able to enter FEL via SD card