lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <B3B433F7-08E1-4AF4-8853-C001FEEF9CA2@goldelico.com>
Date:   Fri, 23 Jun 2023 22:21:42 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-mips@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        list@...ndingux.net
Subject: Re: [PATCH] MIPS: DTS: CI20: Raise VDDCORE voltage to 1.125 volts

Hi Paul,

> Am 23.06.2023 um 18:31 schrieb Paul Cercueil <paul@...pouillou.net>:
> 
> 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@...pouillou.net>:
>>> 
>>> 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@...ux:~# 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@...ux:~# 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@...ux:~# 
>> 
>> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ