Hi Maxime, On 5 July 2017 at 14:14, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Wed, Jul 05, 2017 at 04:57:40PM +0200, Maxime Ripard wrote: >> On Tue, Jul 04, 2017 at 01:33:25PM -0600, Simon Glass wrote: >> > Hi Maxime, >> > >> > On 21 June 2017 at 01:31, Maxime Ripard >> > <maxime.rip...@free-electrons.com> wrote: >> > > Hi Simon, >> > > >> > > On Mon, Jun 19, 2017 at 11:11:27AM -0600, Simon Glass wrote: >> > >> Add a driver-model version of this driver which mostly uses the existing >> > >> code. The old code can be removed once all boards are switched over. >> > >> >> > >> Signed-off-by: Simon Glass <s...@chromium.org> >> > > >> > > I'm not sure if you tested that, but we have some code that switches >> > > the MMC indices when using both an eMMC and an external MMC. >> > > >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c#l494 >> > > >> > > This predates my time, but it seems that it was done to have a >> > > consistent boot MMC device ID. >> > > >> > > I'm not really sure we can get rid of it (even if it creates some >> > > issues of it's own), but what would be the impact of a switch to the >> > > device model on that logic? >> > >> > That is a pretty terrible hack. >> >> Yes, I know. This is especially bad when used together with other >> tools that rely on one MMC index for example (such as fastboot). >> >> I wanted to kill it for quite some time, but I'm a bit reluctant due >> to the possible side effects. >> >> > I'm not sure whether it will continue to work with DM. It does still >> > use the device number in the block device, so maybe... Do you have >> > a board would use this? >> >> I guess I do. I'll give it a try or tonight and let you know. > > I just tested. Even with an eMMC (which was the first use case for > that hack), it works, even things that are not mainline yet (fastboot, > etc). > > It obviously break the old scripts relying on the mmc index, but I > guess that's ok. > > There's one regression though. Our eMMC will always be the second one, > which means that the distro bootargs will always boot on the external > SD first (which is always going to be mmc0). > > That's due to the fact that the eMMC controller is the third one, and > is thus probed last. We obviously want something deterministic for > fastboot for example, but booting partitions of the media you started > from make sense I guess. And this is what this hack was trying to > address.
OK...so what should we do here? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
