Hi Nikolaus, Le samedi 17 juin 2023 à 12:45 +0200, H. Nikolaus Schaller a écrit : > Hi Paul, > > > Am 16.06.2023 um 22:21 schrieb H. Nikolaus Schaller > > <hns@xxxxxxxxxxxxx>: > > > - But renaming the DT nodes (e.g. SUDCDC1 -> DCDC1) (with or > > without regulator_name) makes > > boot hang with strange errors which indicate that the processor > > power supply is not stable. > > Once a while it did even automatically reboot. In most cases there > > are some EXT4 errors > > afterwards. > > I am coming closer, I think. I have now touched only the DCDC1 node > name. > > a) with "SUDCDC1" -> "DCDC1" (bad bood): > > regulator_of_get_init_node() returns the child node > > Then: > [ 0.666962] act8865 0-005a: Looking up vp1-supply from device tree > [ 0.673191] DCDC1: supplied by vcc_33v > [ 0.727070] DCDC1: Bringing 1200000uV into 1100000-1100000uV > [ 0.739398] DCDC1: 1100 mV, enabled > > b) without patch/series or reverted (good boot): > > regulator_of_get_init_node() returns NULL > > Then: > [ 1.016487] DCDC1: at 1200 mV, enabled > [ 1.020578] act8865 0-005a: Looking up vp1-supply from device tree > [ 1.026917] DCDC1: supplied by vcc_33v > > So at least for my board the patched series seems to reduce DCDC1 > voltage > to 1.1V which may trigger the boot and stability problems on my board > while > it is fine for yours. This could explain the hardware dependency. > > Now I have no data sheets or information which voltages are the right > ones > and where the 1200mV come from (most likely some default programmed > into the PMU chip). > > And the issue seems to be that without matching the node names the > voltages in the device tree may have been ignored completely all the > time... Now it sets up voltages, which should happen. But different > ones for my board which breaks boot. So the node names fix caused the driver to actually use the info from DT, which doesn't allow the board to boot. Nice. > Finally I did risk (I have no replacement CI20 board and they are no > longer > on sale... RS part# was 125-3305 Mouser 456-VL-62851) to run a test > with > rename to "DCDC1" but changing the voltage to 1200mV. And this > version boots. Looking at the JZ4780_DS.PDF file, the SoC actually wants 1.1V so the DT is not wrong - in theory. But in practice it does not work, as you experienced yourself. However, if the ACT8600 defaults to 1.2V, or if the bootloader configures it to 1.2V, I would think that this is actually a voltage that the SoC can handle - otherwise the SoC would be overvolted until the kernel starts, and the board design would be flawed. I measured that the old 3.x kernel keeps the SoC voltage at 1.2V, so it sounds like a better default. Therefore the fix here would be to raise the DCDC1 regulator to 1.2V. I'll send a patch later today. Cheers, -Paul > Still without WiFi/Bluetooth but that may be related to missing > rename > of the other regulators. > > So I tried renaming all regulators as by your [PATCH 2/9], and now I > see something from WiFi (haven't installed firmware yet) and the > Bluetooth chip: > > [ 1.977876] mmc1: new high speed SDIO card at address 0001 > > [ 11.341994] Bluetooth: hci0: BCM: chip id 62 > [ 11.348811] Bluetooth: hci0: BCM: features 0x0f > [ 11.376698] Bluetooth: hci0: BCM4330B1 > [ 11.380662] Bluetooth: hci0: BCM4330B1 (002.001.003) build 0000 > [ 11.392053] Bluetooth: hci0: BCM4330B1 'brcm/BCM4330B1.hcd' Patch > > [ 12.145330] brcmfmac mmc1:0001:1: Direct firmware load for > brcm/brcmfmac4330-sdio.img,ci20.bin failed with error -2 > [ 12.208001] brcmfmac mmc1:0001:1: Direct firmware load for > brcm/brcmfmac4330-sdio.clm_blob failed with error -2 > > Unfortunatley systemd bailed out starting Bluetooth service but > failed to provide a login: > > In summary it looks like a potential fix could be to replace the > DCDC1 > min/max range by 1.0 - 1.2V instead of 1.1 - 1.1V but we need deeper > understanding first. Usually this has something to do with dynamic > voltage > scaling depending on processor clock and lower voltages are only > allowed > for lower frequencies but max. clock requires the highest possible > voltage. > AFAIK we have no cpufreq integrated and therefore always run at max. > speed. > > BR, > Nikolaus > > PS: here is what I read back from the regulator voltages (for DCDC1 > min/max = 1.2V): > > root@letux:~# cat /sys/kernel/debug/regulator/regulator_summary > regulator use open bypass opmode voltage > current min max > --------------------------------------------------------------------- > ------------------ > regulator-dummy 1 0 0 unknown 0mV > 0mA 0mV 0mV > eth0_power 1 1 0 unknown 3300mV > 0mA 3300mV 3300mV > 16000000.dm9000-vcc 1 > 0mA 0mV 0mV > otg_power 0 0 0 unknown 5000mV > 0mA 5000mV 5000mV > vcc_33v 4 9 0 unknown 3300mV > 0mA 3300mV 3300mV > 13450000.mmc-vqmmc 1 > 0mA 0mV 0mV > 13450000.mmc-vmmc 1 > 0mA 3300mV 3400mV > DCDC1 1 0 0 standby 1200mV > 0mA 1200mV 1200mV > DCDC2 0 0 0 standby 1500mV > 0mA 0mV 0mV > DCDC3 0 0 0 unknown 3300mV > 0mA 0mV 0mV > LDO5 0 0 0 unknown 2500mV > 0mA 0mV 0mV > LDO6 0 0 0 normal 1800mV > 0mA 1800mV 1800mV > LDO7 0 0 0 unknown 3300mV > 0mA 0mV 0mV > LDO8 0 0 0 unknown 3300mV > 0mA 0mV 0mV > SUDCDC_REG4 0 0 0 normal 5000mV > 0mA 0mV 0mV > LDO_REG9 1 0 0 unknown 3300mV > 0mA 3300mV 3300mV > LDO_REG10 1 0 0 unknown 1200mV > 0mA 1200mV 1200mV > bt_power 0 0 0 unknown 3300mV > 0mA 3300mV 3300mV > root@letux:~# > > This matches device tree except DCDC1, LDO7 and LDO8 (camera). >
