Hi Paul,
> Am 23.06.2023 um 18:31 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>:
>
> Hi Nikolaus,
>
> Le vendredi 23 juin 2023 à 18:13 +0200, H. Nikolaus Schaller a écrit :
>> Hi Paul, Thomas,
>> here are my test results.
>>
>>> Am 22.06.2023 um 19:59 schrieb Paul Cercueil
>>> <paul@xxxxxxxxxxxxxxx>:
>>>
>>> Commit 08384e80a70f ("MIPS: DTS: CI20: Fix ACT8600 regulator node
>>> names") caused the VDDCORE power supply (regulated by the ACT8600's
>>> DCDC1 output) to drop from a voltage of 1.2V configured by the
>>> bootloader, to the 1.1V set in the Device Tree.
>>>
>>> According to the documentation, the VDDCORE supply should be
>>> between
>>> 0.99V and 1.21V; both values are therefore within the supported
>>> range.
>>>
>>> However, VDDCORE being 1.1V results in the CI20 being very
>>> unstable,
>>> with corrupted memory, failures to boot, or reboots at random.
>>
>> ... and damaging the file system on SD card.
>>
>>> The
>>> reason might be succint drops of the voltage below the minimum
>>> required.
>>
>> 1. with your patches (except this one) on top of upstream v6.4-rc7
>> and
>> ci20_defconfig I can still not boot with 1.100V.
>>
>> 2. but also not at 1.125V as by this patch.
>> [ 0.647637] DCDC1: Bringing 1200000uV into 1125000-1125000uV
>>
>> 3. my board needs 1.150V as minimum, reporting:
>> [ 0.647627] DCDC1: Bringing 1200000uV into 1150000-1150000uV
>
> Heh. I was fearing this would be the case.
>
>>
>> That is good news that it does not need 1.200V at the upper limit.
>>
>> 4. next, with this setup I can see the bluetooth chip (with default
>> MAC
>> address 43:30:B1:00:00:00), but it is not useable (maybe my user
>> space).
>>
>> And there no WiFi. Rather, I have to disable the brcmfmac driver or
>> otherwise I can't even complete boot (hangs in a later stage) at all.
>
> Most likely it's because of an invalid firmware file. It happened to me
> with every single firmware file (including the one in the linux-
> firmware repository at that time) except the one found on the CI20's
> Debian image.
>
> Since then Broadcom guys updated the firmware in linux-firmware to the
> newest one they had, which works fine.
Well, I have used exactly the same /lib/firmware directory in both cases.
Even the same SD card... Nothing removed, replaced or changed with the
firmware file.
I.e. I have just swapped kernel, dtb and modules on the same SD card.
So the difference is inside one of these, not the firmware but I have not
yet searched for the detail...
>
>> 5. finally the mysterious result:
>>
>> With all this merged with the letux-os kernel (and manually fixing
>> minor
>> merge conflicts) and using letux_defconfig I can boot. Even with
>> 1.100V
>> in the device tree, checked with /sys/kernel/debug):
>>
>> root@letux:~# cat /sys/kernel/debug/regulator/regulator_summary
>> regulator use open bypass opmode voltage
>> current min max
>> ---------------------------------------------------------------------
>> ------------------
>> regulator-dummy 3 2 0 unknown 0mV
>> 0mA 0mV 0mV
>> 13500000.usb-vusb_a 1
>> 0mA 0mV 0mV
>> 13500000.usb-vusb_d 1
>> 0mA 0mV 0mV
>> eth0_power 1 1 0 unknown 3300mV
>> 0mA 3300mV 3300mV
>> 16000000.dm9000-vcc 1
>> 0mA 0mV 0mV
>> otg_power 1 2 0 unknown 5000mV
>> 0mA 5000mV 5000mV
>> 1000003c.usb-phy-vcc 1
>> 0mA 0mV 0mV
>> usb_phy-vcc 0
>> 0mA 0mV 0mV
>> vcc_33v 8 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 1100mV
>> 0mA 1100mV 1100mV
>> DCDC2 1 0 0 standby 1500mV
>> 0mA 1500mV 1500mV
>> DCDC3 1 0 0 unknown 3300mV
>> 0mA 3300mV 3300mV
>> LDO5 1 0 0 unknown 2500mV
>> 0mA 2500mV 2500mV
>> LDO6 1 1 0 normal 1800mV
>> 0mA 1800mV 1800mV
>> 13460000.mmc-vqmmc 1
>> 0mA 0mV 0mV
>> LDO7 0 0 0 unknown 2800mV
>> 0mA 2800mV 2800mV
>> LDO8 0 0 0 unknown 1500mV
>> 0mA 1500mV 1500mV
>> SUDCDC_REG4 2 1 0 normal 5000mV
>> 0mA 5000mV 5000mV
>> bt_power 2 1 0 unknown 3300mV
>> 0mA 3300mV 3300mV
>> wifi_power 2 1 0 unknown 3300mV
>> 0mA 3300mV 3300mV
>> 13460000.mmc-vmmc 1
>> 0mA 3300mV 3400mV
>> LDO_REG9 1 0 0 unknown 3300mV
>> 0mA 3300mV 3300mV
>> LDO_REG10 1 0 0 unknown 1200mV
>> 0mA 1200mV 1200mV
>> root@letux:~# uname -a
>> Linux letux 6.4.0-rc7-letux-ci20+ #13881 SMP PREEMPT Fri Jun 23
>> 17:23:42 CEST 2023 mips GNU/Linux
>> root@letux:~#
>>
>> And I there have WiFi working fine.
>>
>> But no Bluetooth interface at all (although driver is compiled).
>>
>> A potential hint could be that DCDC1 is enabled a little later during
>> boot than with ci20_defconfig:
>>
>> [ 1.077926] DCDC1: Bringing 1200000uV into 1100000-1100000uV
>> [ 1.096997] DCDC1: 1100 mV, enabled
>>
>> And another test with trying 1.000V hangs immediately after this:
>>
>> [ 1.032846] DCDC1: Bringing 1200000uV into 1000000-1000000uV
>>
>> Maybe it is a too big step during operation.
>
> 1.0V is about as low as you can get with theorically perfect power
> supply, I doubt that you can use this voltage in the real world.
Indeed. There may be some more mV drop. I haven't tried 1.050V (yet).
>
> It's strange that your letux kernel can set 1.1V and be stable, while
> you need 1.15V with the upstream kernel. I wonder what could be the
> cause.
Yes, that is a mysterium...
>
>>
>> For the records:
>>
>> - I just swapped the clean compiled uImage, kernel modules and
>> ci20.dtb
>> between all these tests (and fsck the SD card before).
>>
>> - we have some experimental SMP patches by Yanjie Zhou (and other
>> nice
>> stuff not pushed upstream) in the Letux kernel so that any of thes
>> may have an influence.
>>
>> So I'd say let's postpone this 1.125V patch until your other patches
>> arrive upstream. Then I will rebase our Letux kernel anyways and then
>> I can analyse a little easier what makes all these differences
>> (because
>> then no merge and manual conflict resolution is involved any more and
>> there are better chances for a bisect to be helpful).
>
> Thomas already merged it, so I guess we have 1.125V now.
>
> Which is better than nothing; instead of not working on both our
> boards, at least now v6.4 will work on one of them ;)
And it will not break LetuxOS if rebased. That is what we need for further
analysis.
>
> Note that I was testing my patches on top of the vanilla kernel,
> without any local patches.
I do the same but have a better result with adding my local patches.
So they must improve something even more (except than making Bluetooth worse)...
But I don't know what it is.
Something for future analysis.
BR and thanks for building a basis,
Nikolaus
