[U-Boot] [PATCH 3/4] mmc: exynos dwmmc: check boot mode before init dwmmc
Tom Rini
trini at ti.com
Thu Feb 19 17:45:58 CET 2015
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.marczak at 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 <sjg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150219/e00a6242/attachment.sig>
More information about the U-Boot
mailing list