> On 17 Aug 2017, at 09:51, Kever Yang <kever.y...@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.y...@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.y...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
