On Thu, Feb 19, 2015 at 03:36:57PM +0100, Przemyslaw Marczak wrote: > Hello Tom, > > On 02/19/2015 03:03 PM, Tom Rini wrote: > >On Wed, Feb 18, 2015 at 11:50:41AM +0100, Przemyslaw Marczak wrote: > >>Hello Simon, > >> > >>On 02/18/2015 06:02 AM, Simon Glass wrote: > >>>Hi Przemyslaw, > >>> > >>>On 17 February 2015 at 06:09, Przemyslaw Marczak <p.marc...@samsung.com> > >>>wrote: > >>>>Before this commit, the mmc devices were always registered > >>>>in the same order. So dwmmc channel 0 was registered as mmc 0, > >>>>channel 1 as mmc 1, etc. > >>>>In case of possibility to boot from more then one device, > >>>>the CONFIG_SYS_MMC_ENV_DEV should always point to right mmc device. > >>>> > >>>>This can be achieved by init boot device as first, so it will be > >>>>always registered as mmc 0. Thanks to this, the 'saveenv' command > >>>>will work fine for all mmc boot devices. > >>>> > >>>>Exynos based boards usually uses mmc host channels configuration: > >>>>- 0, or 0+1 for 8 bit - as a default boot device (usually eMMC) > >>>>- 2 for 4bit - as an optional boot device (usually SD card slot) > >>>> > >>>>And usually the boot order is defined by OM pin configuration, > >>>>which can be changed in a few ways, eg. > >>>>- Odroid U3 - eMMC card insertion -> first boot from eMMC > >>>>- Odroid X2/XU3 - boot priority jumper > >>>> > >>>>By this commit, Exynos dwmmc driver will check the OM pin configuration, > >>>>and then try to init the boot device and register it as mmc 0. > >>> > >>>I think a better way to do this would be to make > >>>CONFIG_SYS_MMC_ENV_DEV support an option where the device can be > >>>selected at run-time. > >>> > >>>However that would probably be better done when the drive rmodel > >>>conversion is complete. > >>> > >>>So this seems a reasonable patch given where we are. > >>> > >>>Reviewed-by: Simon Glass <s...@chromium.org> > >>> > >> > >>This was just a quick solution to solve the issue on XU3, when the > >>same binary can boot from sd or eMMC slots. > > > >XU3 isn't unique in this regard. "am335x_evm" binaries runs on 4 very > >different boards and we still just have to say that sometimes we default > >to ENV in a place that isn't workable. > > Yes, I saw this issue on bb black. But it seems to be not a big > problem to fix it. > When I finish the pmic and finally start work on adding it to the bb > black, then maybe I will try to fix it somehow.
It's not hard (extending some of the concepts we have already) but I want to hold that off until we have driver model support instead as part of a "carrot and stick" approach ;) -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
