03:22 <tlwoerner> my bisection lands on: 9b1111fa80df22c8cb6f9f8634693812cb958f4f

03:22 <tlwoerner> "Merge tag 'regulator-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator"

11:42 <tlwoerner> i was hoping to bisect into broonie's tree, but that exact tag ('regulator-fix-v5.13-rc4') in his tree succeeds

12:03 <urja> i was kinda confused about why it'd point out a merge ... but it's that the combination is what fails then (that is, his tree was fine, and the tree before the merge was fine, but combined they fail)

13:13 <urja> i bisected my issue... and it ended up similarly unhelpful (i'm not 100% if this is correct yet either...)

13:13 <urja> 8fb59ce15c43d025dadc2df3d21590bd1e91eff0 is the first bad commit

13:13 <urja> " Merge branches 'clk-nvidia', 'clk-rockchip', 'clk-at91' and 'clk-vc5' into clk-next

13:13 <urja> " ...

13:24 <tlwoerner> urja: exactly. to make it even more fun, in my case linus' merge of broonie's tree is the first bad commit. but when i build the exact tag from broonie's tree it succeeds

13:26 <tlwoerner> therefore the bug must be caused by an interaction between something in broonie's tree interacting badly with something that was added to linus' tree between the time broonie forked off linus' tree and the time broonie's tree was merged to linus'

13:27 <tlwoerner> therefore i'm adding the ~20 or so patches from broonie's tree on top of linus' and bisecting those 20

13:27 <tlwoerner> i should find the culprit soon

13:53 <tlwoerner> this is the patch that is causing my nanopi-m4 to fail to boot: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git/commit/?id=98e48cd9283dbac0e1445ee780889f10b3d1db6a

14:10 <urja> .... that's fun.

14:42 <tlwoerner> interestingly enough, someone else noticed an issue arising from the inclusion of the patch that is causing me issues

14:43 <tlwoerner> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c68ef4ad180e09805fa46965d15e1dfadf09ffa5

14:46 <urja> useless sidenote: i've seen that commit before because i've been following the pyra (=omap5) stuff

16:35 <urja> okay i've got a new first bad ... i guess i messed up something along the first run? anyways this is the result of biasect from v5.14 to 8fb59ce... (above)

16:35 <urja> 69a00fb3d6970681c15a23595ec54233ce10295c is the first bad commit

16:35 <urja> "clk: divider: Implement and wire up .determine_rate by default" ...

16:39 <urja> (i'll re-check this still...)

16:44 <urja> merges melt my brain ...

17:06 <urja> okay confirmed: reverting that (69a...) from 5.15-rc3 (+a couple of patches i'm carrying) gets my C201 to boot all the way to desktop

17:07 <urja> but yeah still need to figure out WTF did it break & how (for it to break eMMC but not µSD..)

20:30 <samueldr> I couldn't find confirmation, but is `7c4e0304550509072d2c7b38170d1711`, the well-known RC4 private key, related to the OTP efuses?

20:31 <samueldr> in other words, while not looking for guides or anything, only a shallow answer, is secure boot with user-controlled keys fused to the SoC possible for an arbitrary SBC?

20:33 <samueldr> I'm not looking for the cop-out answer "you'll brick it", only whether it's possible or not, no more information, and only if you *know*, not suppositions. thanks!

20:34 <samueldr> (I'm thinking it's possible only large volume vendors get the option to customizing the fused-in keys)

21:38 <mmind00> samueldr: secure boot does actually work ... at least on the px30 I've worked on that first-hand ;-)

21:38 <mmind00> samueldr: with a user controlled-key written to fuses/otp memory

21:39 <samueldr> oh, that is excellent news to have actual info :)

21:39 <samueldr> it was hard finding more than tidbits of info to extrapolate from

21:40 <samueldr> so that RC4 signature is totally unrelated I gather?

21:40 <samueldr> and used really as a CRC?

21:40 <samueldr> (or not?)

21:40 <mmind00> samueldr: that's no part of the secureboot but I guess part of a later stage

21:41 <samueldr> good to know I did extrapolate badly from not enough info :)

21:41 <mmind00> samueldr: i.e. on all SoCs the "secureboot" part is the one where bootrom verifies the _initial_ bootcode (u-boot tpl/spl in most cases)

21:41 <samueldr> yep

21:42 <samueldr> otherwise you're gonna have a bad time