Hi Igor, On Thu, Aug 16, 2018 at 2:13 PM, Igor Opaniuk <[email protected]> wrote: > As I didn't have any available Hikey board, tested this on Poplar: > > Tested-by: Igor Opaniuk <[email protected]> > > BTW, we've had it up for discussion already, but just to clarify and > summarize: > As ID of eMMC is hardcoded in the OP-TEE OS core (CFG_RPMB_FS_DEV_ID), > we will probably have issues on some platforms, where there is a > difference in the probe order of MMC controllers (for example, on > Poplar eMMC is 0 in U-boot, but in Linux it's 1, as SD is enumerated > as 0). > I guess it's unlikely that people will introduce changes to > U-boot/Linux to make this order conform to each other, so instead, we > should let the Normal World-part to decide what eMMC id to use from > these RPMB frames.
Both U-boot and Linux are part of Normal World. I guess you're suggesting to move the logic of selecting RPMB device based on the ID from Secure World to tee-supplicant. For Linux that's a user space daemon and in U-boot that's part of the OP-TEE driver. I think it would be unfortunate to have this logic in user space, upgrades can make a mess of this. This is in one aspect a board specific problem which can be addressed by defining the sequence number (what's indicated by CFG_RPMB_FS_DEV_ID above) of relevant RPMB partitions on a specific board. This is what we have been relying on indirectly so far. Another way to deal with this problem is to let Secure World probe all available RPMB partitions and use the one using the expected shared secret for MACing. A drawback is that it's more complicated in Secure World and will take a while before it's implemented. Thanks, Jens _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
