Hi Suneel, On 27 July 2017 at 23:03, Suneel Garapati <suneelgli...@gmail.com> wrote: > Hi Simon, > > I have similar requirement of Cavium boards using two card slots on > one host and currently trying to figure out to support it using > DM_MMC. > Would like to know if you have quick thoughts or seen similar use case > with some other boards too?
It should work correctly - what sort of problem do you have? > > Please correct me if I miss something obvious. > Regards, Simon > Regards, > Suneel > > > On Thu, Jul 27, 2017 at 9:19 PM, Simon Glass <s...@chromium.org> wrote: >> Hi Maxime, >> >> On 17 July 2017 at 03:26, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >>> Hi Simon, >>> >>> On Fri, Jul 14, 2017 at 07:47:45AM -0600, Simon Glass wrote: >>>> 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? >>> >>> I guess we should just drop the hack. We'll have to at some point >>> anyway. But I guess we should also find a way to tweak the distro >>> bootcmd at boot time to search for the medium that we booted on first. >>> >>> I'm not really sure how to do this though. >> >> Well in that case let's drop the hack and someone will pick it up when >> it hits them. >> >> Regards, >> Simon >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
