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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebf776a8fb8dee045e7661daaca4564fe39917a6.camel@crapouillou.net>
Date:   Sun, 18 Jun 2023 13:51:01 +0200
From:   Paul Cercueil <paul@...pouillou.net>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     list@...ndingux.net, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Conor Dooley <conor+dt@...nel.org>, linux-mips@...r.kernel.org,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Paul Boddie <paul@...die.org.uk>,
        Paul Burton <paulburton@...nel.org>
Subject: Re: [PATCH 0/9] MIPS: CI20: Add WiFi / Bluetooth support

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@...delico.com>:
> 
> > - 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@...ux:~# 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@...ux:~# 
> 
> This matches device tree except DCDC1, LDO7 and LDO8 (camera).
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ