2014-09-04 11:37 GMT+02:00 Jean-Michel Hautbois <jean-michel.hautbois@xxxxxxxxxxx>: > Hi Ulf, > >> I am not sure adding a DT binding for non access to rpmb would be >> needed. At least until we heard of a similar case as Adrian describes >> but for rpmb. >> >> BTW, I just posted a patch which disabled partition scan of the boot >> area, what to you think about that? >> http://marc.info/?l=linux-mmc&m=140973496402028&w=2 >> >> Finally I am also wondering whether we could and thus should, handle >> these situations entirely without using a host cap. In principle what >> we need is a more sophisticated error handling when the switch errors >> occurs, while trying to switch to the boot area/rpmb partitions. Could >> you maybe investigate that option, before we decide to add a new DT >> binding? > > According to me and what Hsin-Hsiang Tseng wrote, it seems that we > should be able to have access to boot partitions if we want to give a > possibility of writing u-boot in one (or both) of them. This is the > way the i.MX6 will boot on a eMMC if I read the reference manual > correctly, but I didn't tested it yet. > But there is no need to scan those partitions at boot, as there will > probably never be a partition table inside, as you said. > All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1 > and a way to tell which one is used as default boot partition. > > This is my point of view, but I didn't read JESD84-A441 so I don't > know if this is the good way. > > Regards, > JM BTW, here is an interesting commit from Freescale tree : http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.0_ga&id=28774b788ae0de5d88045dd60cac3656c305821d JM -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
