Thanks for the link, I hadn’t seen that thread before!
In the meantime, I found another thread about the DevTerm that offers a similar solution: Extremely Slow Battery Charging
Its battery tech is similar enough to the uConsole’s that it should still be relevant.
The values for constant_charge_current and constant_charge_current_max in the message you linked seem to be too high for the batteries I have. The datasheet for my Panasonic NCR18650B batteries give a value of 1625 mA as the max charge current, so a value of 1625000 seems more appropriate. (the kernel driver expects these to be microamperes for some reason)
I don’t know if the kernel driver expects you to multiply this value by the number of batteries in use, but I’m gonna play it safe and go with no.
Earlier, I found this: [PATCH 0/4] set battery info on AXP20X and AXP22X from DT which appears to be a kernel list discussion about the code that outputs the couldn't set constant charge current from DT message that appears in dmesg output.
In it, you can also see how it defaults to a safe charging current of 300 mA. (which is probably why the uConsole charges so slowly)
Also, this bit:
(the default constant current charge will still be 1500mA from powering
up the board to the driver probing unless the bootloader takes care of
it beforehand)
seems to imply that if the OS isn’t running, it defaults to 1500 mA instead. I have no idea if this is true and can’t test it because I don’t own a power meter.
I’m gonna wait for my uConsole’s battery to finish charging the slow way before I fiddle with kernel parameters because I want to see if doing so helps with calibration.