Skip to content

Conversation

setotau
Copy link

@setotau setotau commented Jan 12, 2025

With vmmc-supply set as vreg_l5b_2p95 system cannot boot from sdcard with following error:

mmc2: error -110 whilst initialising SD card

With vmmc-supply unset system can boot from sdcard, so comment out a vmmc-supply to allow system to boot from sdcard

@setotau setotau changed the title HACK: comment out vmmc-supply from sdhc_2 to allow to boot from SD card HACK: comment out vmmc-supply from sdhc_2 to allow to boot from SD card on clover Jan 12, 2025
@minlexx minlexx force-pushed the qcom-sdm660-6.11.y branch from 474f79f to 096f7ac Compare January 13, 2025 13:52
Signed-off-by: Nickolay Goppen <killubuntoid@yandex.ru>
@minlexx minlexx force-pushed the kubntd/qcom-sdm660-6.11.y-clover-sdcard-hack branch from 319deae to aa04b4a Compare January 13, 2025 14:08
@minlexx
Copy link
Member

minlexx commented Mar 12, 2025

Currently on mainline l5b (aka pm660l_l5, aka vreg_l5b_2p95) seems to be set to 3.3V

l5                         0    1      0 unknown  3300mV     0mA  1800mV  3328mV 
          c084000.mmc-vmmc        0                                 0mA  3300mV  3328mV

but downstream requests strictly 2.95 (dumped from dowsntream)
maximum seems to be limited by driver on both l2b & l5b to 2.95 actually

		pm660l_l2                        0    2      0   350mV     0mA    350mV  3100mV 
			c084000.sdhci                                                 350mV  2950mV
			deviceless                                                      0mV     0mV
		pm660l_l5                        0    2      0  1721mV     0mA   1721mV  3600mV 
			c084000.sdhci                                                1721mV  2950mV
			deviceless                                                      0mV     0mV

It's described in DT as

&sdhc_2 {
    /* device core power supply */
    vdd-supply = <&pm660l_l5>;                         // range: 1.721 V .. 3.6 V
    qcom,vdd-voltage-level = <2950000 2950000>;
    qcom,vdd-current-level = <15000 800000>;  // not a range, but lpm_uA, hpm_uA

    /* device communication power supply */
    vdd-io-supply = <&pm660l_l2>;                     // range: 0.35 V .. 3.1 V
    qcom,vdd-io-voltage-level = <1800000 2950000>;
    qcom,vdd-io-current-level = <200 22000>;   // not a range, but lpm_uA, hpm_uA

    pinctrl-names = "active", "sleep";
    pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
    pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off &sdc2_cd_off>;
...
    cd-gpios = <&tlmm 54 0x0>;
...
};

🤔

@minlexx
Copy link
Member

minlexx commented Mar 14, 2025

The issue with SD cards is hopefuuly fixed with #59 , so this can be closed I think, thanks for all the testing and ideas.

@minlexx minlexx closed this Mar 14, 2025
@minlexx minlexx deleted the kubntd/qcom-sdm660-6.11.y-clover-sdcard-hack branch March 26, 2025 02:22
minlexx pushed a commit that referenced this pull request May 11, 2025
… prevent wrong idmap generation

The PTE_MAYBE_NG macro sets the nG page table bit according to the value
of "arm64_use_ng_mappings". This variable is currently placed in the
.bss section. create_init_idmap() is called before the .bss section
initialisation which is done in early_map_kernel(). Therefore,
data/test_prot in create_init_idmap() could be set incorrectly through
the PAGE_KERNEL -> PROT_DEFAULT -> PTE_MAYBE_NG macros.

   # llvm-objdump-21 --syms vmlinux-gcc | grep arm64_use_ng_mappings
     ffff800082f242a8 g     O .bss    0000000000000001 arm64_use_ng_mappings

The create_init_idmap() function disassembly compiled with llvm-21:

  // create_init_idmap()
  ffff80008255c058: d10103f     	sub	sp, sp, #0x40
  ffff80008255c05c: a9017bfd     	stp	x29, x30, [sp, #0x10]
  ffff80008255c060: a90257f6     	stp	x22, x21, [sp, #0x20]
  ffff80008255c064: a9034ff4     	stp	x20, x19, [sp, #0x30]
  ffff80008255c068: 910043fd     	add	x29, sp, #0x10
  ffff80008255c06c: 90003fc8     	adrp	x8, 0xffff800082d54000
  ffff80008255c070: d280e06a     	mov	x10, #0x703     // =1795
  ffff80008255c074: 91400409     	add	x9, x0, #0x1, lsl #12 // =0x1000
  ffff80008255c078: 394a4108     	ldrb	w8, [x8, #0x290] ------------- (1)
  ffff80008255c07c: f2e00d0a     	movk	x10, #0x68, lsl #48
  ffff80008255c080: f90007e9     	str	x9, [sp, #0x8]
  ffff80008255c084: aa0103f3     	mov	x19, x1
  ffff80008255c088: aa0003f4     	mov	x20, x0
  ffff80008255c08c: 14000000     	b	0xffff80008255c08c <__pi_create_init_idmap+0x34>
  ffff80008255c090: aa082d56     	orr	x22, x10, x8, lsl #11 -------- (2)

Note (1) is loading the arm64_use_ng_mappings value in w8 and (2) is set
the text or data prot with the w8 value to set PTE_NG bit. If the .bss
section isn't initialized, x8 could include a garbage value and generate
an incorrect mapping.

Annotate arm64_use_ng_mappings as __read_mostly so that it is placed in
the .data section.

Fixes: 84b04d3 ("arm64: kernel: Create initial ID map from C code")
Cc: stable@vger.kernel.org # 6.9.x
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Link: https://lore.kernel.org/r/20250502180412.3774883-1-yeoreum.yun@arm.com
[catalin.marinas@arm.com: use __read_mostly instead of __ro_after_init]
[catalin.marinas@arm.com: slight tweaking of the code comment]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants