Property mbox get_clock_rate for eMMC returning 0 in recent firmware

[swarren]

As of firmware.git commit de7aa7e "firmware: Rebuild with missing uart and vchiq logging commits", a property mailbox request of get_clock_rate for the eMMC clock returns 0 rather than the expected 250MHz. This causes U-Boot's MMC driver to fail to operate since it doesn't know how to calculate clock dividers (also: the SDHCI controller HW doesn't have any frequency value in its capabilities register, which U-Boot would use as a fallback when the mbox query returns 0).

In the U-Boot code, I put a printf of msg_clk->get_clock_rate.body.resp.rate_hz at http://git.denx.de/?p=u-boot.git;a=blob;f=board/raspberrypi/rpi/rpi.c;h=1d3a4e09cfa3c3f2ca12d253c1c64ea947722908;hb=df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa#l430 and see it's zero. The code that rejects this value is at http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sdhci.c;h=8586d898fdded663fb43a4386b07fd73142568d6;hb=df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa#l497.

[swarren]

I expect this is a duplicate of (and/or the root cause of) #572 and #574.

[TheSin-]

I agree this is likely the exact issue I've been trying to track all day, but I can not figure out how the firmware kernel can get a value, I tried building a kernel and forcing 250 Hz :/

Thank you for being more specific this was making me nuts

[pelwell]

Adding the enable_uart setting changed the dependencies between various parts of the system. In resolving those dependencies, by allowing a more flexible initialisation sequence, one dependency was missed - that of the emmc clock on the core clock. Fortunately it is simple to put that dependency back, and the next firmware will do that. Sorry for the inconvenience.

[pelwell]

The master firmware branch has now been updated.

[swarren]

Verified fixed on at least the B+ in commit 046effa "firmware: arm_loader: emmc clock depends on core clock See: #572".