00:06 <apritzel> isn't macromorgan's plan to ditch RSB for all devices completely?

00:07 <apritzel> this would not only simplify the shared DTs, but also make this procedure much easier?

00:10 <tokyovigilante> it is, but IMO not actually required, if we just do the detection over I2C in SPL we are free to use RSB elsewhere, and reboot is currently broken anyway, because the SPL is unconditionally trying to use I2C to configure the chip when it is set to RSB signalling

00:12 <apritzel> ... which would all be nicely solved by not using RSB at all

00:13 <apritzel> this rebooting issue is much more severe with those battery powered devices, as both you have learned quite painfully, I believe ;-)

00:13 <tokyovigilante> true, if we are all happy to use I2C, I had an idea that RSB had some technical advantages, and if we can do detection at boot in SPL where we are unconditionally using I2C, then that would be a win-win

00:14 <tokyovigilante> yup it has been annoying. I am just patching u-boot to reset the 0x3c bus select register for I2C in SPL, then macromorgan can still write the detection code, and reboot will work either way

00:15 <apritzel> put you would need to do this reset in RSB mode ...

00:15 <tokyovigilante> I think they are orthogonal and it makes sense to check/positively set the bus to I2C signalling before trying it, given that the AXP can potentially still be configured from a previous boot

00:15 <tokyovigilante> no, it's just a direct register write, that setting is not done over the bus

00:15 <tokyovigilante> at least that is my interpretation of the datasheet

00:16 <apritzel> you mean to the RSB controller? for that this must be set up (clocks, reset, pin mux)

00:16 <tokyovigilante> 0x68 is the I2C bus, 0x3a3 is RSB, but 0x3e is a separate register to select which is active

00:16 <apritzel> and it *will* be transmitted over the bus, to an AXP register

00:17 <tokyovigilante> Ah right, so there is no way to reset the device out of RSB mode without using RSB?

00:17 <tokyovigilante> Annoying

00:18 <apritzel> yeah, that's the point: you *can* pull it off, but it's quite involved

00:18 <apritzel> and given that I don't think the advantages of RSB are really a win

00:19 <tokyovigilante> in that case better to just use I2C everywhere, agreed

00:19 <tokyovigilante> that seems like a real design flaw.

00:19 <apritzel> IIRC RSB is faster (3 MHz instead of 100 or 400 KHz), which doesn't strike me as a big advantage, though you can do power transitions faster

00:22 <apritzel> the other advantage is that it's easier to program ("fire-and-forget"), but that doesn't really count if we have a driver already

00:23 <apritzel> regardless we probably should have code in Linux to reset the PMIC back to I2C, in sunxi_rsb_remove(), but that would assume we always go through that, with an orderly reset

00:23 <tokyovigilante> is there value in using RSB after boot, then resetting to I2C on shutdown? Wouldn't be robust to a kernel panic or other unclean shutdown (but cutting power does reset)

00:24 <apritzel> yeah, my thoughts exactly, we would still have cases where it doesn't work, although much less frequent

00:24 <apritzel> but it feels like the right thing to do, in general, so we should go for it regardless, I think

00:26 <apritzel> but given that the Anbernic devices are more problematic due to the battery, and some need I2C-only anyway, and there are more "casual" users of those devices, I'd say we go all I2C there

00:27 <tokyovigilante> Yeah I think that's sensible. Practically do you you think there will be much impact on DVFS?

00:28 <apritzel> I have no idea, really. I heard arguments that RSB would enable faster switching, but have no idea if that really matters

00:30 <tokyovigilante> Sounds good. Shall I just bite the bullet and submit a DT patch to change the devices over to I2C?

00:31 <tokyovigilante> The datasheet does suggest that the serial selection register is reset on POR (power-on reset) but that clearly isn't happening in practice

00:32 <apritzel> which register? in the AXP, you mean? A watchdog reset/reboot does not affect the AXP ...

00:32 <tokyovigilante> oh no, macromorgan has already submitted the DT changes

00:32 <apritzel> yeah, exactly

00:33 <tokyovigilante> Yeah in the AXP, it suggests on power cycle all the registers labelled POR are reset, but this clearly isn't happening

00:33 <apritzel> I think it is, but when do you really power cycle, on a battery powered device?

00:34 <tokyovigilante> Quite, in fact it says it's only triggered by holding the power button for >16s, which is a bit user-unfriendly

00:35 <apritzel> we could trigger a reset via the AXP instead of the watchdog, in TF-A, maybe that solves that problem?

00:37 <tokyovigilante> well, if I understand this correctly, all the registers noted "system reset" are reset by an AXP power cycle, which we *could* do but aren't currently (I think) but the POR registers are only reset by the POR cycle, which is only triggered by holding the power button for 16s. Seems a bit pointless in that case

00:38 <tokyovigilante> And that also resets all the battery capacity registers

00:38 <tokyovigilante> No I really think you and macromorgan are right, that we should just use I2C

00:49 <apritzel> POR is also when the power "comes up", which is the normal way of starting things on dev boards. Any battery really spoils this

00:58 <tokyovigilante> Have just tested macromorgan's series briefly, does indeed fix reboot

02:27 <macromorgan> so from my perspective if reset doesn't completely reset the device do we need to make sure certain regulators are kept on at shutdown? I'm wondering why reset sends it straight into FEL mode (possibly because the MMC regulator isn't staying on maybe?)

02:28 <macromorgan> doesn't writing a 1 to 0x27 cause a reset? Because that's how I can both reset the device and trigger the FEL "glitch" (where it boots straight into FEL mode)

02:29 <macromorgan> or 2 to 0x27, one of those two values

07:56 <Jookia> my friend has a h616 board (a btt pi using a btt cb1) whose rtc runs at 40% of real time D: D: D:

09:36 <apritzel> Jookia: I think that's a known issue with the RC calibration? There was a thread on the list ...

09:36 <Jookia> hmm, wasn't there a patch to calibrate it

09:37 <apritzel> well, there was some patch, but it was a against some Armbian branch, and had other issues, IIRC

09:37 <Jookia> ah

09:37 <apritzel> does the BTT Pi not have a 32KHz crystal oscillator?

09:38 <apritzel> because that is actually the root cause: board vendors being too stingy and omitting this part

09:39 <Jookia> i don't know

09:39 <Jookia> how would you check

09:42 <Jookia> i guess without a scope i can't

09:44 <apritzel> it should be on the schematics, and you should be able to find the physical part on the board

09:45 <Jookia> i would guess the board has one

09:45 <Jookia> oh, that might ben an 24mhz one

09:53 <tokyovigilante> Jookia: AFAICT that patch was against H6 code, but the H616 clk-ng code sets that register anyway

09:54 <tokyovigilante> I think the calibration is not an absolute panacea for a crystal

09:55 <Jookia> in this case we're using ntp

09:55 <Jookia> to paper over the issue