Hi Philipp,
On 08/17/2017 04:27 PM, Dr. Philipp Tomsich wrote:
On 17 Aug 2017, at 09:51, Kever Yang kever.yang@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@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@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).
Make the fastboot dev number select into dts instead of MACRO in header file can not resolve the issue without bootloader update, but need to update fastboot cmd driver, like the ums driver works good for the issue with the correct parameter: 'ums 0 mmc 0' vs 'fastboot usb0'
Thanks, - Kever
Regards, Philipp.