09:18 <warpme> guys: i have board with 8822cs sdio wifi on m2 key. Hw desgin not provides vqmmc to m2 module and instead m2 module has onboard 1v8 requlator for io. So module operates always on 1v8 io. Issue i have is kernel (6.16 mainline) at init checks 1v8 modes and fails with "dwmmc_rockchip 2a320000.mmc: Unexpected CMD11 timeout". Imho this is because kernel has no control on sdio vqmmc level. As module uses always 1v8 (on board regulator)

09:18 <warpme> but kernel starts with 3v3 then tries 1v8 then fails with 1v8 level - all fails like here: https://termbin.com/2q66 Is there way to ask kernel to skip 3v3->1v8 switching and directly go with 1v8 modes? I tried mmc-hs200-1_8v and mmc-hs400-1_8v and this removes "Unexpected CMD11 timeout" but still gives very low wifi speeds (so i suspect still issues with sdio bus) Maybe somebody has any ideas here?

11:03 <wens> warpme: which soc is this?

11:04 <warpme> rk3576

11:07 <wens> doesn't seem to have an I/O domain driver (Documentation/devicetree/bindings/power/rockchip-io-domain.yaml)

11:07 <warpme> i played a bit with hacking reusing openrtw hacks: https://github.com/warpme/minimyth2/commit/49b43be98b946deed74a04e8187ffc54995b87da This code works ok for them on 6.12 kernel but on mine 6.16 wifi speeds is still very low....

11:08 <wens> IIRC you specify I/O voltage supplies for each pin group here, so that the pin controller gets configured with the correct I/O voltage levels

11:08 <wens> because 1.8V signalling is below the logic threshold of 3.3V signalling, this is definitely needed

11:08 <CounterPillow> wens: just because it doesn't have its own compatible doesn't mean it doesn't have a driver.

11:10 <wens> I don't see anything like it in the dts files either

11:11 <CounterPillow> yeah but neither does the rk3588, doesn't mean something is missing here.

11:20 <CounterPillow> fwiw, the downstream vendor kernel rk3576 dts doesn't have any io domain voltage node either, whereas the rk356x.dtsi in the vendor kernel does. So it's not a thing missing from mainline, the hardware just works differently.

11:20 <wens> I'm just extrapolating

11:20 <wens> those are emmc modes, so I suspect they don't really have any effect for an SDIO card

11:20 <wens> warpme: you might want to check /sys/kernel/debug/mmc/*/ios and see what mode it is running when you add mmc-hs*

11:20 <wens> I guess rockchip might have just did away with the configurable stuff, and it just follows the pingroup's voltage supply

11:20 <wens> ok

11:21 <wens> so they changed their design, fair enough

11:30 <warpme> hmm: per https://wiki.friendlyelec.com/wiki/images/6/60/NanoPi_R76S_LP4X_2411_SCH.pdf is wifi sdio is on vccio3 (page10). supply is VCC_1V8_S3. is it wired to vcc8/buck8. then in my dts it is conencted to dcdc_reg8 (https://github.com/warpme/minimyth2/blob/f29623145727ebeca9073e5bc5d09318f3990147/script/kernel/linux-6.16/files/1282-arm64-dts-add-rk3576-nanopi-r76s-dt.patch#L547) Regulator summary on running bard shows:

11:30 <warpme> https://gist.github.com/warpme/e2a0eb5c8cd70bfa8e1943cdded56c54 But mmc1 ios shows https://gist.github.com/warpme/129e0ad5a5867ede033730b6aabdb90f hmm - why this?

11:33 <wens> what do you have for vqmmc in the sdio node?

11:34 <wens> the only other thing I can think of is that the drive strength on the pins isn't enough for the rate the signals are running at

11:41 <robmur01> there is no vqmmc-supply, so the driver presumably believes the voltage stays at the default (3.3V) in the absence of any way to change it

11:48 <warpme> robmur01 : sdio node: https://github.com/warpme/minimyth2/blob/f29623145727ebeca9073e5bc5d09318f3990147/script/kernel/linux-6.16/files/1282-arm64-dts-add-rk3576-nanopi-r76s-dt.patch#L849

11:49 <robmur01> warpme: exactly, you're not specifying any supply regulators there, so how do you expect the MMC layer to know what the voltage is?

12:30 <warpme> robmur01 : ah indeed - forgot to add vqmmc-supply = <&vcc_1v8_s3>; now ios looks good i think https://gist.github.com/warpme/1f607482b666713f4ffd5b477106085b But speeds are still 20-40MBps max. Still don't understand why....

12:33 <warpme> maybe time to get osciloscope and see what happens on io lanes....

14:45 <golledge> Hi, I am working on rk3566, I have got yocto scathgap using the yoctos meta-rockchip running. I want to enable secure boot, i have built rockchips uboot to flash the keys and the keys are flash so now i can only flash signed loaders, i have built and signed mainline uboot spl which works by manually signing the idbloader.img. my next step is the

14:45 <golledge> get the idbloader signed inside of yocto. then work on signing the uboot fit image. has any one else tried this or know of anyone doing the same. Any help would be appreciated. This is very slow going for me at the moment

15:04 <qschulz> typ

15:04 <qschulz> ically you do not want to sign with Yocto

15:05 <qschulz> usually you want air-gapped systems to sign artifacts

15:12 <qschulz> for signing U-Boot FIT probably look into https://docs.yoctoproject.org/ref-manual/classes.html#uboot-sign ?

15:15 <golledge> not a bad shout, I think with keys stored in online and build VM ran on in house server. It should be enough.

15:15 <golledge> I looked at the docs and struggled to find a simple way include the rk_sign_tool. I was hoping someone else has got this far

15:16 <qschulz> For signing idbloader.img, probably not as I would assume this to be part of meta-rockchip from the YP git repo

15:16 <qschulz> and I am not aware of that

15:16 <qschulz> so you'd likely need to add something for that

15:16 <qschulz> if you do, please send patches to meta-rockchip, I'm sure Trevor would be happy to see contributions like that :)

15:17 <qschulz> and contributions to U-Boot docs to explain how to sign idbloader.img would also be very nice :)

15:21 <golledge> Yeah, it looks like i need to create a native recipe to add the rk_sign_tool binary to the SDK, then just figure a way to check if spl is required to be signed then run the sign tool if required. simple :S

15:21 <golledge> I am hoping to get some time to create some upstream patches.

15:23 <qschulz> do we have the sources for rk_sign_tool?

15:24 <golledge> no released as a binary

15:25 <qschulz> yeah that's a bit of an issue for Yocto, don't really like running prebuilt binaries on the host, especially since it could be running on another architecture than the one this binary was built for

15:25 <qschulz> I guess maybe fex could be used to run it on incompatible architectures /me shrugs

15:27 <qschulz> https://github-wiki-see.page/m/madisongh/meta-rk3588/wiki/Secure-boot-on-RK3566-68-88 maybe take inspiration from that?

15:27 <qschulz> there seems to be a meta-rk3588 layer you could take inspiration from

15:28 <qschulz> https://github.com/madisongh/meta-rk3588/blob/kirkstone/recipes-bsp/u-boot/u-boot-rockchip-downstream.inc is likely the file you want to steal code from

15:33 <Kwiboo> golledge: I played around with adding idblock v2 signing to mkimage at https://github.com/Kwiboo/u-boot-rockchip/commit/cb2827f096975a4aa255c3c6915b4fe6f58824af some time ago, the generated signature can be validated with rk_sign_tool, see https://gist.github.com/Kwiboo/6847d4c83ad768bacf47a162f99a24e2 for very limted docs

15:37 <wens> warpme: limitations of the card or access point?