<apritzel>
prefixcactus: yeah, I think I have seen this before
<apritzel>
as libv mentioned, this should resolve itself (and I need to send those patches that silence those -517 warnings)
<apritzel>
but indeed the mmc driver doesn't probe eventually
<libv>
there seems to be a more general pinctrl/regulator issue
ldevulder_ has joined #linux-sunxi
ldevulder_ has quit [Remote host closed the connection]
<apritzel>
prefixcactus: can you check /sys/kernel/debug/regulators/regulator_summary, does that list a bunch of them or just a few?
<prefixcactus>
/sys/kernel/debug is empty right now
ldevulder has quit [Ping timeout: 272 seconds]
<apritzel>
prefixcactus: yeah, please mount it first: mount -t debugfs debugfs /sys/kernel/debug
<prefixcactus>
apritzel: appended to the same paste
<apritzel>
prefixcactus: ah, the PMIC doesn't probe, that would explain it
<prefixcactus>
apritzel: is there something I can enable to make the kernel print everything that didn
<prefixcactus>
't load/loaded unsuccessfully?
<prefixcactus>
I imagine unsuccessful attempts at probing modules would be registered on the kernel side
<apritzel>
ah, it actually says so in the logs: [ 3.913275] axp20x-regulator axp20x-regulator: Failed to register dc1sw
<apritzel>
prefixcactus: try to chase this one down
<apritzel>
uis: thanks for trying this driver, and sorry for making this not clear: this won't fix your problem either, it's just a port of the existing driver to the "new" framework
<apritzel>
uis: it would be interesting to see what actually happens: I guess the driver tries to program the PLL too high: it does the maths and wants to setup ~300(?) MHz for 4K@60p
<apritzel>
uis: but it doesn't know that this is not possible on the A10
<apritzel>
uis: yeah, even worse, as jernej mentioned, the A10 can only do 165 MHz
ldevulder has joined #linux-sunxi
<apritzel>
uis: maybe you can chase down how the clocks are setup (in the new version)?
<uis>
So A10 can't run at 4k?
<apritzel>
uis: not at 60Hz, at least
<apritzel>
the A10 is quite old
<uis>
That's sad. Ok. Thank you.
<apritzel>
uis: can you test that it works on 1080p?
<uis>
Ok. Original one works at 1920x1080@60
<apritzel>
uis: ideally we would add some code to impose limits, I think the issue is more general: if the monitor is more capable than the display engine
<libv>
without having looked at the code, it smells like there could be a fundamental failure in modevalidation, as it perhaps should reject modes with dotclocks above 165MHz
<apritzel>
libv: I wouldn't say failure, I guess there are simply no checks?
<libv>
but as said yesterday, it is not unlikely that there's also display engine clocking issues in the uboot code
<libv>
which is a fundamental failure in my book ;)
<libv>
could be that i was the origin of that issue as well, as i wrote the first version of that code
<libv>
even though i should know better
<apritzel>
the U-Boot code is rather simple, by design, and if no one reports issues ...
<apritzel>
libv: do you know how the Linux code knows about the 165 MHz limit?
<libv>
not sure without looking
<libv>
apritzel: the way it works is like it used to work in xfree86 4.0
<apritzel>
prefixcactus: your dcdc1 is at 3.3V, but the dc1sw is at 3.0V
<libv>
gather modes, validate them for your setup (adjust or reject them), then choose the best candidate, and set it (at which point it should not fail anymore)
<libv>
at least in theory
<apritzel>
libv: that sounds like the way to go, but I don't think U-Boot does this?
<libv>
let me dig in
<apritzel>
libv: at least it probably doesn't even know that >165MHz pixel clock isn't possible
<prefixcactus>
apritzel: the previous 12 lines state that all the other regulators are "supplied by regulator-dummy".
<prefixcactus>
that smells funky
<apritzel>
no, that's another red herring
<apritzel>
prefixcactus: check the lines immediately before the warning
<prefixcactus>
(and dc1sw is the same as vcc-lcd)
<prefixcactus>
which is mentioned in the lines immediately before, yes
<libv>
apritzel: hdmi_mode_get is where some sembleance of validation is done, and there indeed is no such check
<apritzel>
prefixcactus: point is: dc1sw is just a switch, as the name implies, so it must the same voltage as the parent regulator, which is DCDC1
mmarc___ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
ldevulder has quit [Quit: Leaving]
<prefixcactus>
yep, and DCDC1 supplies the MMCs, at least according to the DT
<libv>
sunxi_hdmi_edid_get_mode even
<prefixcactus>
I see no mention of dcdc1 anywhere, however
<prefixcactus>
I'm mostly poking around the peripherals in order to determine whether they work or not
<prefixcactus>
amusingly, wifi went up right off the bat. I expected it to throw all kinds of tantrums at me,
elros1 has joined #linux-sunxi
<prefixcactus>
apritzel: so, just split it up into a dtsi and dts?
<prefixcactus>
also, how good is good enough?
<karlp>
start with simple bits that let people boot
<karlp>
you don't have to submit everything right away.
lkcl has joined #linux-sunxi
random_yanek has quit [Ping timeout: 260 seconds]
uis has joined #linux-sunxi
<uis>
apritzel: 1920x1080-24@60 works
<apritzel>
prefixcactus: as karlp said: nobody expects a perfect submission, but we need to start the discussion and review somewhere
random_yanek has joined #linux-sunxi
<apritzel>
uis: great, thanks! We will have a look at limiting the modes, maybe you can help out with testing then?
mmarc__ has quit [Remote host closed the connection]
netlynx has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 260 seconds]
macc24 has joined #linux-sunxi
<apritzel>
Hey libv, I guess you can answer this: what does "sunxi" refer to exactly, when used in (older parts of?) the wiki?
<apritzel>
I find things like "Sunxi/Legacy Kernel" vs. "Mainline kernel", but then also statements like: "... some other linux image which uses linux-sunxi code. Do not put non-sunxi images here ..."
<apritzel>
so does sunxi refer to the purgatory between BSP code and mainline? Or to community changes on top of BSP code, before mainlining becomes feasible?
matthias_bgg has joined #linux-sunxi
<prefixcactus>
apritzel: sure, will do then.
<prefixcactus>
I'll do all my work in the repo listed on the device page
<apritzel>
prefixcactus: yeah, I peeked in there already for checking your DT
<apritzel>
prefixcactus: let me know if you need help or advice with the mainlining process
<prefixcactus>
Aye
reinforce has quit [Quit: Leaving.]
<mripard>
apritzel: linux-sunxi (and uboot-sunxi) used to refer to the initial AW BSP then maintained and improved by the community here
<mripard>
it's only really been relevant for the A10 to A20, later SoCs never got any support from linux-sunxi
elros1 has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
mripard: thanks, that comes close to what I thought, as nowadays it seems to be either the "read-only" BSP vs. mainline (merged or WIP)
<mripard>
apritzel: yeah, pretty much
<mripard>
even more so since cedrus and lima have been merged, there's no features really unique to linux-sunxi (aside from the PM)
cnxsoft1 has quit [Quit: cnxsoft1]
kaspter has joined #linux-sunxi
Ecco has quit [Ping timeout: 256 seconds]
<prefixcactus>
Is there anything I need to change in u-boot if change the boot source, e.g. booting from emmc vs sd?
<apritzel>
prefixcactus: no, this is automatically detected
<prefixcactus>
and how does it determine where to get the boot script?
<apritzel>
not sure (I don't use boot scripts), but I think it uses the same mechanism, check "printenv bootcmd_mmc_auto" in U-Boot
<prefixcactus>
apritzel: what do you use then?
<apritzel>
UEFI boot (but this will look at the same places, I think)
<prefixcactus>
ah.
<apritzel>
so yeah, the BootROM writes some boot source ID into one byte in SRAM, where SPL code picks it up, to find the device where it needs to load the rest of U-Boot from
<prefixcactus>
So if I just move my whole SD image to emmc now it should boot out of the box theoretically?
<apritzel>
prefixcactus: and then this info is also used to populate the environment variable, check board/sunxi/board.c:misc_init_r()
<apritzel>
prefixcactus: yes, that is the idea
<prefixcactus>
aha, good
<apritzel>
prefixcactus: with some recent patches you can even move that whole thing to the eMMC *boot* partition (that extra 4MB one)
<prefixcactus>
there's two extra ones here, both 16M
<prefixcactus>
mmcblk1boot0 and mmcblk1boot1
<apritzel>
prefixcactus: SPI flash booting should work the same, btw, minus the bootscript part
<apritzel>
prefixcactus: yes, those ones
<prefixcactus>
which one of those should I move it to?
<apritzel>
the one you activate ;-)
<prefixcactus>
er, now I'm lost
<prefixcactus>
how is it supposed to work with allwinner's stuff and how does it work with mainline?
<apritzel>
prefixcactus: patches for the automatic boot partition support are not mainline yet, I am waiting for comments and tests - that's why I am telling you about it :-P
<prefixcactus>
(and if I choose not to go that way, I can always burn to mmcblk1 and forget about it, right?)
<apritzel>
prefixcactus: yes, you can always use the normal user storage on eMMC, at offset 8K
<prefixcactus>
ok, nice
<apritzel>
but that is slightly fragile, as some other software might overwrite this
<prefixcactus>
But I'll test out your patches too if you give me the link
<apritzel>
and it spoils GPT partition support
uis has quit [Ping timeout: 264 seconds]
<prefixcactus>
I don't think I care about having GPT partitions to be frank, but a separate hardware-guaranteed(?) partition just for the bootloader seems like something nice to have
<prefixcactus>
Why is there two of them, though?
<apritzel>
prefixcactus: it's in the eMMC standard, I guess for backup, failover or switching purposes
<apritzel>
prefixcactus: so you use the other one for your new firmware version, and roll back if that fails
<apritzel>
prefixcactus: I haven't checked if that is automatic, also the BROM has a very low bar for "fails to boot", as long as the magic and checksum are correct, it's fine from the BROM point of view
iyzsong has joined #linux-sunxi
ldevulder has quit [Read error: Connection reset by peer]
<apritzel>
prefixcactus: the more common failure though is when this code then crashes for some reason
ldevulder has joined #linux-sunxi
<apritzel>
prefixcactus: the workaround would be to boot from SD, into U-Boot or Linux, then switch the active boot partition back
<prefixcactus>
uh-huh
matthias_bgg has quit [Ping timeout: 256 seconds]
MangyDog has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 260 seconds]
MangyDog has quit [Remote host closed the connection]
Mangy_Dog has joined #linux-sunxi
cmeerw has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
rzerres has quit [Ping timeout: 272 seconds]
prefixcactus has quit [Ping timeout: 264 seconds]
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
lurchi_ is now known as lurchi__
pCactus_ has joined #linux-sunxi
pCactus_ has quit [Read error: Connection reset by peer]
pCactus has quit [Read error: Connection reset by peer]
pCactus_ has joined #linux-sunxi
vagrantc has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
rzerres has joined #linux-sunxi
rzerres has quit [Ping timeout: 260 seconds]
elros1 has joined #linux-sunxi
fl__0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 264 seconds]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
rzerres has joined #linux-sunxi
Peetz0r has joined #linux-sunxi
ldevulder has quit [Ping timeout: 240 seconds]
rzerres has quit [Ping timeout: 264 seconds]
ldevulder has joined #linux-sunxi
<Peetz0r>
Hi! Pinephone user here. I'm trying to figure out how crust works, and if I get get WL-WAKE-AP aka wowlan working.
<Peetz0r>
So, how do I get debug output from crust? And has anyone gotten wake from wlan working before?
fl__0 is now known as fl_0
uis has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
pCactus has joined #linux-sunxi
pCactus_ has quit [Ping timeout: 240 seconds]
gaston1980 has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]