←back to thread

242 points denysvitali | 1 comments | | HN request time: 0.462s | source
Show context
tripdout ◴[] No.44427076[source]
It will be really interesting to see what production devices this is enabled on - It mentions the OnePlus 6 at least which has it fused out but is still accessible.

Edit: How are they reading the eFuses on a production OnePlus 6? Do they have a Qualcomm-signed EL3 EDL loader?

It seems to exist as qcom,msm-eud in the device tree of a (unfortunately production) SM4350 device I have along with an eud_enable_reg. Time to recompile the kernel with `/dev/mem`.

replies(4): >>44427931 #>>44428623 #>>44450259 #>>44455350 #
1. tripdout ◴[] No.44428623[source]
Well, no luck.

In the device tree I see (snippet):

  qcom,msm-eud@1628000 {
   compatible = "qcom,msm-eud";
   interrupt-names = "eud_irq";
   interrupts = <0x00 0xbd 0x04>;
   reg = <0x1628000 0x2000 0x162a000 0x1000 0x3e5018 0x04>;
   reg-names = "eud_base", "eud_mode_mgr2", "eud_tcsr_check_reg";
   qcom,secure-eud-en;
   qcom,eud-tcsr-check-enable;
   status = "ok";
  };

  qusb@162b000 {
   compatible = "qcom,qusb2phy-v2";
   reg = <0x162b000 0x400 0x1b40268 0x04 0x162f014 0x04 0x162a000 0x04>;
   reg-names = "qusb_phy_base", "efuse_addr", "refgen_north_bg_reg_addr", "eud_enable_reg";
   qcom,efuse-bit-pos = <0x19>;
   qcom,efuse-num-bits = <0x03>;
but `devmem 0x162A000 4 0x1` causes the system to lock up and I see the following in ramoops:

    [  433.720232] msm_watchdog f410000.qcom,wdt: Causing a QCOM Apps Watchdog bite!
    [  433.727381] msm_watchdog f410000.qcom,wdt: Wdog - STS: 0xb01a6, CTL: 0x3, BARK TIME: 0x57fdf, BITE TIME: 0x6ffd6

I'm not at all sure on the interpretation of this, but the reading at the efuse_addr (so I guess certain ones can be read from EL0?) is 0x0e000000 which has bits 25-27 set and QFPROM fuses seem to have a blown value of 1 according to Qualcomm docs, so it might be fused out?