Hi,

On 02/19/2015 05:45 PM, Tom Rini wrote:
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 ;)


Ok, that's fine.

Regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to