<apritzel>
and is that really the same power rail? typically PortC and the PHY are on separate rails
tokyovigilante has quit [Remote host closed the connection]
tokyovigilante has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<MasterR3C0RD>
It seems like ALDO1 powers PortC and PortL at minimum; there is a separate rail supposedly for the PHY, but the Ethernet LED seems to be statically powered by something
<apritzel>
can you dump /sys/kernel/debug/regulators/regulators_summary from the running vendor system?
<MasterR3C0RD>
Will do in about 30m
<apritzel>
that's in my experience the most reliable way to figure out the rail assignment
<MasterR3C0RD>
I figured most of the critical ones out by killing regulators in U-Boot and seeing what results I got, then comparing ones that made the system hang to important voltages in the datasheet, while non-important ones I tried to see what broke
<MasterR3C0RD>
ALDO1 on my board definitely controls PortL; if it's turned off I start getting garbage back from the regulator and can't turn it back on
<MasterR3C0RD>
s/regulator/PMIC/
<apritzel>
ah, very good! What is your PMIC? AXP803/707? Or something else?
<apritzel>
for me PortL is ALDO3, apparently at 3.3V, and PortC is powered by ELDO1
<apritzel>
and the tablet detected that I changed the boot partition with an image patched by Magisk, and refused to boot :-(
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
apritzel: Bootloader bit's a frustrating point; sounds like they have it locked down quite hard. Usually you'd be able to "unlock the bootloader"; not sure if that's possible on your device though
<MasterR3C0RD>
Also PMIC is AXP806, thus why I have the AXP305 SPL driver enabled for A133 on my branch
<apritzel>
ah, right, I now remember. So that means different rails are used, which explains the differences between our devices in this regard
<MasterR3C0RD>
Yeah, the rails are all a bit weird. Actually one of the weird bits is that in boot0, DCDCA is set in a "pll_set_voltage" routine, while in the device tree it's the CPU power supply
<MasterR3C0RD>
Considering DVFS works the latter seems like the correct interpretation
<apritzel>
I think it must be DCDCA, polyphased with DCDCB, there is virtually no other choice which satisfies the CPU's needs
<MasterR3C0RD>
Well, if I disable DCDCB nothing changes
<MasterR3C0RD>
When checking regulators, DCDCB is set to 1.8V, whereas DCDCA starts at 1.1V
<apritzel>
please don't do this ;-) DCDCB is most likely "married" to DCDCA (polyphased), because one DCDC is not enough for all the cores
<apritzel>
this is typically customised, we don't touch that setting, the Linux driver just reads it and skips DCDCB
<apritzel>
check axp20x_is_polyphase_slave(), maybe put a printf in there to check that (or read 0x1b and see for yourself)
<MasterR3C0RD>
Reading 0x1B returns 0
<apritzel>
ah, interesting, then you indeed don't have a polyphase. Though that sounds sketchy, I'd think the A133 is in the same ballpark as the other quad-A53 SoCs when it comes to power consumption
<MasterR3C0RD>
Well, it doesn't exactly appear this thing is the definition of "good design", so I'm not entirely surprised LOL
<MasterR3C0RD>
parthiban: Thanks for the Tested-bys! If you get a chance, can you test gadgets again after disabling ohci0 and ehci0 in your device tree?
<MasterR3C0RD>
Do so after switching back to an a33 compatible, of course
hentai has joined #linux-sunxi
<MoeIcenowy>
MasterR3C0RD: Yangtao Li is Yangtao/Frank Lee
<MasterR3C0RD>
MoeIcenowy: Cool, good to know! I was curious since I had him in my patch series CCs as a maintainer with his tiny.windzz email, while his allwinnertech email doesn't seem to exist anymore
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
parthiban has quit [Quit: Leaving]
parthiban has joined #linux-sunxi
<MasterR3C0RD>
Neat; if SyterKit is to be believed, if we fix up base addresses and get a CCU config, the A133 DRAM driver should theoretically work on the A523/A527 and other sun55iw3 chips
parthiban has quit []
parthiban has joined #linux-sunxi
parthiban has quit [Remote host closed the connection]
parthiban has joined #linux-sunxi
<MasterR3C0RD>
Actually it matches the H616 better with how the COM registers are used
<parthiban>
MasterR3C0RD: Disabling hci in DT works.
<parthiban>
Morning!
<parthiban>
PHY was claimed by the HCI?
<MasterR3C0RD>
Morning! Happy to hear it works
<MasterR3C0RD>
That's what we believe yes; apparent the musb drivers can be a bit of a mess sometimes
<MasterR3C0RD>
But that's not something to be fixed in this patch series; if it's working when the HCIs are disabled then it's working period, just means OTG won't work at the moment
<MasterR3C0RD>
Apparently on most boards this isn't an issue because MUSB claims the PHY before HCI does, but sounds like it's running into a bit of a race condition
<parthiban>
I have a complex hub in the PCB.
<parthiban>
HUB facing the host side. UART0 and USB0 is connected from the SoC.
<MasterR3C0RD>
In that case I presume you'll want to keep the HCI0 nodes disabled anyways then
<parthiban>
Otherwise, mmc0 and mmc1 is the only part which I can't test yet in your series.
<MasterR3C0RD>
I've confirmed HCI0 works on my board when in host mode. The MMC patches may get held back if things get applied from this series though; there's not much rationale for vs against the clock fix at the moment
hipboi has joined #linux-sunxi
<parthiban>
eMMC works. You can atleast keep them?
<MasterR3C0RD>
eMMC only works with the reparenting patch; I don't have enough time before the window of opportunity to get this in for 6.13 closes to figure out why the NO_REPARENT was set on the nodes to begin with (even though I've been spending a lot of time on this, it's all on the side and unrelated to my job)
<parthiban>
MasterR3C0RD: eMMC works in my end without removing reparent
<parthiban>
Not sure what's the difference between the hardware we have.
<parthiban>
So I would like to keep the eMMC in the patch series
<parthiban>
One other question, "reboot" command hangs too. Is this related to BL31 as well?
hipboi has quit [Quit: hipboi]
<MasterR3C0RD>
I'm afraid I don't have time to resubmit and drop the reparenting patch, as my many extremely late nights lately are catching up to me. I would need to replace the MMC patch with a different one that only adds the eMMC node, and I'd need to resubmit the series. I don't think they'll accept the MMC patches if they aren't functioning without a
<MasterR3C0RD>
dubious patch. However, the fact that eMMC worked correctly on your device but not mine seems interesting; hopefully we'll be able to track down the root cause for the next patch window.
<MasterR3C0RD>
Also yes, reboot failing is due to BL31
<MasterR3C0RD>
It throws a stack trace from TF-A when a reboot is attempted
<parthiban>
MasterR3C0RD: Ok then. Did I miss anything else in the series to test?
<MasterR3C0RD>
The PMU node is the only new node without known issues and without a tested-by
<MasterR3C0RD>
I don't really know how that would be tested though, so I think we're probably good on testing
<parthiban>
Great.
<parthiban>
btw, did you had time to check the LPDDR4 in the u-boot? Let me know how can I help.
<MasterR3C0RD>
I didn't yet get a chance to figure out why the Helperboard wasn't working if that's what you mean; I'm still thinking it's related to the RAM size/configuration, but I'll dig into it further in a few days
<parthiban>
Helperboard comes with 1GB RAM, which works fine. That's how am able to test your series.
<MasterR3C0RD>
Oh right it was your other board
<parthiban>
I have a custom PCB with 4GB LPDDR4, which didn't work.
<MasterR3C0RD>
I'm having a bit of code fatigue on the DRAM front, so I'm going to leave it sit for a few more days. In the meantime I plan to see if I can get more progress on bringing up more peripherals on my device
<parthiban>
"gpioget: unable to request lines: Unknown error 517" AFAIK, this is the main reason other problems when using pio. r_pio works fine.
<apritzel>
parthiban: 517 is EPROBE_DEFER, which means there is some dependency missing for probing the driver, like a clock or a regulator
<apritzel>
please note that you cannot announce the vcc-pl-supply in the DT, since that creates a circular dependency (PMIC is on R_I2C, R_I2C uses PortL pins, PMIC provides PortL power rail)
<apritzel>
error -517 is not fatal, it's tried later again, and might have succeeded. Check in /sys/kernel/debug/devices_deferred, it should be empty
<apritzel>
and ideally whatever outputs that error should be silenced because of this, in the kernel there are error wrappers that take care of that automatically
<apritzel>
MasterR3C0RD: for testing the PMU: run some "perf record" command, and check that it works and the interrupt counter in /proc/interrupts increases
<apritzel>
but we don't need Tested-by: for every patch, reviews or ACKs are more important. Tested-by: is also to give maintainers some clue who to ask when something needs testing in the future
warpme has quit []
warpme has joined #linux-sunxi
dsimic is now known as Guest8136
dsimic has joined #linux-sunxi
Guest8136 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<parthiban>
PA bank doesn't exist, but the pinctrl considers this bank and 32 pins for it. I was assuming <&pio 0> -> refers to PB, which was wrong the whole time.
<MasterR3C0RD>
If you compile U-Boot with the gpio command, does it work there?
<MasterR3C0RD>
Can't test on my device right now, but I know that basic GPIO should work correctly
<MasterR3C0RD>
I was able to turn on/off PH19 without any issue, and created an LED device for it in my device tree that I was also able to turn on, off, and assign to a trigger
<parthiban>
It works from devicetree if claimed by the Kernel.
<parthiban>
but not from the userspace using gpioset
<parthiban>
MasterR3C0RD: from u-boot it works
<MasterR3C0RD>
No clue what could be the issue then I'm afraid, it could be an issue with libgpiod or something
<parthiban>
I can live with claiming in the kernel from dts for now
KREYREN_oftc has joined #linux-sunxi
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
ity1 has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity1 has quit []
ity has joined #linux-sunxi
vagrantc has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<parthiban>
"armv8-pmu pmu: probe with driver armv8-pmu failed with error -22"
<parthiban>
"armv8-pmu pmu: hw perfevents: failed to parse interrupt-affinity[1]
<parthiban>
this means PMU is not loaded?
<parthiban>
not sure if this is because I commented the secondary CPU's
<apritzel>
did you change the PMU node accordingly, since it references the CPUs?
digetx is now known as Guest8150
apritzel has quit [Ping timeout: 480 seconds]
digetx has joined #linux-sunxi
Guest8150 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
<MasterR3C0RD>
parthiban: Instead of commenting out the additional CPUs, it might make more sense to add "nosmp" to your kernel command line
parthiban has quit [Remote host closed the connection]
dliviu has quit [Ping timeout: 480 seconds]
parthiban has joined #linux-sunxi
dliviu has joined #linux-sunxi
<MasterR3C0RD>
Randomly thinking about the A133 DRAM code, and realized one thing is less of a mystery than I thought; there's 3 additional sets of "shadow registers" in the uMCTL2 DRAM register block, which normally have the same values being written to as those on the main registers, but I wasn't sure why. However, I think it's likely for configuring settings
<MasterR3C0RD>
specific to different DFS (Dynamic Frequency Scaling) modes. Not exactly critical functionality, but it would explain what they're being used for
<apritzel>
so you mean there is a register which selects one of those banks then?