[U-Boot] [PATCH] rockchip: rk3288: update the mmc number for fastboot
Dr. Philipp Tomsich
philipp.tomsich at theobroma-systems.com
Thu Aug 17 08:27:10 UTC 2017
> 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:
>>> On 07/27/2017 08:16 PM, Dr. Philipp Tomsich wrote:
>>>>> 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.
>> 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
(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
(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).
More information about the U-Boot