[U-Boot] [PATCH] rockchip: rk3288: update the mmc number for fastboot

[Dr. Philipp Tomsich]

> On 17 Aug 2017, at 09:51, Kever Yang <kever.yang at rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 
> On 07/27/2017 09:09 PM, Dr. Philipp Tomsich wrote:
>>> On 27 Jul 2017, at 15:04, Kever Yang <kever.yang at rock-chips.com> wrote:
>>> 
>>> Philipp,
>>> 
>>> 
>>> On 07/27/2017 08:16 PM, Dr. Philipp Tomsich wrote:
>>>> Kever,
>>>> 
>>>>> On 27 Jul 2017, at 13:47, Kever Yang <kever.yang at rock-chips.com> wrote:
>>>>> 
>>>>> The emmc number is 0, correct it for fastboot parameter.
>>>> I provided some code in rk3399-board-spl.c (commit d02d11f8; see
>>>> spl_node_to_boot_device(…) and how 'desc->devnum’ is accessed there)
>>>> to map from a of_node back to a device-number.
>>>> 
>>>> Could you do something similar for the fastboot case, so we can have a DTS
>>>> property (e.g. under /config or /chosen) to map back to the devnum on a
>>>> per-board basis?
>>> I'm not sure if there two are similar the same case, for boot device, we
>>> want to support more then one devices in an order, but for fastboot,
>>> we usually do not support device other than eMMC.
>> Sorry for being a bit unspecific (but had hoped that the reference to the function
>> resolving a single of_node back to a devnum would have clarified what I intended
>> to say)…
>> 
>> I didn’t mean for you to use an ordered list, but rather a single referenced node.
>> E.g.
>> 	u-boot,fastboot-flash-device = <&sdmmc>;
> 
> I try to under stand what you want to do here, but again, I think this is different
> with the boot order. The boot order have much choice, different sequence, so it's
> reasonable for what you have done. But the FLASH_MMC_DEV is only one number,
> not a list, not a node, just like CONFIG_SYS_MMC_ENV_DEV, it's quite easy to do it,
> we do not need to write it in dts and decode the dts, what we need is give the correct
> number to fastboot driver, and that's all.

While eMMC will be the default for most deployments, people may want to
use a different setting for their devices or during testing. In fact the way this
is used in the applications we see can be grouped along the following use
cases:
(a) production deployment
	(1) sometimes fixed to the internal storage (i.e. eMMC) 
	(2) sometimes fixed to external storage (e.g. a eMMC on the baseboard)
	(3) sometimes set to ‘same device the bootloader was loaded from'
(b) device development:
	(4) often fixed to a specific storage device (can bei either ‘internal’ or
		‘external’ storage)
	(5) sometimes set to ‘same devices as the bootloader'

In other words, there’s a lot of variability in what is right for a specific application
and device, but this should not require a new board-configuration in U-Boot (or
a U-Boot rebuild).

Regards,
Philipp.