[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

According to the emmc/sdcard index in dts alias, emmc is always 0 and
sdcard index is 1, let's update to using correct mmc number for distro
boot order in common header.

SD card suppost to have higher priority so that people can boot into
the firmware in SD card, this is very convenient for developer try with
distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
Distro image(which id download from OS vendor release) into SD card without
any modify and then we can boot it up directly.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

Changes in v3:
- update the commit message
Series-changes: 2
- update the commit message

 include/configs/rockchip-common.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
index 68e1105a4b..8a72613e52 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,11 +11,11 @@
 
 #ifndef CONFIG_SPL_BUILD
 
-/* First try to boot from SD (index 0), then eMMC (index 1) */
+/* First try to boot from SD (index 1), then eMMC (index 0) */
 #if CONFIG_IS_ENABLED(CMD_MMC)
 	#define BOOT_TARGET_MMC(func) \
-		func(MMC, mmc, 0) \
-		func(MMC, mmc, 1)
+		func(MMC, mmc, 1) \
+		func(MMC, mmc, 0)
 #else
 	#define BOOT_TARGET_MMC(func)
 #endif
-- 
2.18.0

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Philipp Tomsich]

Kever,

> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
> 
> According to the emmc/sdcard index in dts alias, emmc is always 0 and
> sdcard index is 1, let's update to using correct mmc number for distro
> boot order in common header.
> 
> SD card suppost to have higher priority so that people can boot into
> the firmware in SD card, this is very convenient for developer try with
> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
> Distro image(which id download from OS vendor release) into SD card without
> any modify and then we can boot it up directly.

You never addressed the review comment from Klaus (from the review in May):

> Also prioritising SD card over eMMC does not make any sense to me. At least on
> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
> right for me. 

This will change default behaviour and may break things for users in the field.
Before we can move forward, we really need to establish a consensus on this
and how users will be affected.

While this doesn’t matter much for our boards, as we have logic to rewrite the
default boot during boot-up anyway, I expect a lot of trouble for mainline users
with their own boards...

> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
> 
> Changes in v3:
> - update the commit message
> Series-changes: 2
> - update the commit message
> 
> include/configs/rockchip-common.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
> index 68e1105a4b..8a72613e52 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,11 +11,11 @@
> 
> #ifndef CONFIG_SPL_BUILD
> 
> -/* First try to boot from SD (index 0), then eMMC (index 1) */
> +/* First try to boot from SD (index 1), then eMMC (index 0) */
> #if CONFIG_IS_ENABLED(CMD_MMC)
> 	#define BOOT_TARGET_MMC(func) \
> -		func(MMC, mmc, 0) \
> -		func(MMC, mmc, 1)
> +		func(MMC, mmc, 1) \
> +		func(MMC, mmc, 0)
> #else
> 	#define BOOT_TARGET_MMC(func)
> #endif
> -- 
> 2.18.0
> 

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
> Kever,
>
>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>> sdcard index is 1, let's update to using correct mmc number for distro
>> boot order in common header.
>>
>> SD card suppost to have higher priority so that people can boot into
>> the firmware in SD card, this is very convenient for developer try with
>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>> Distro image(which id download from OS vendor release) into SD card without
>> any modify and then we can boot it up directly.
> You never addressed the review comment from Klaus (from the review in May):
I do address the review comment and that's why this patch has been V3
but not a RESEND for V1. The source code does not change, while the commit
message has update to make it more clear why this patch is needed.

I'm sorry to Klaus for not sure if I have reply to him directly, but I
do this
because I always not get response after I send out my comments in this
channel,
then I thought send a new patch with necessary update may be more fast to
make patch merged.

>
>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>> right for me. 
> This will change default behaviour and may break things for users in the field.
> Before we can move forward, we really need to establish a consensus on this
> and how users will be affected.
>
> While this doesn’t matter much for our boards, as we have logic to rewrite the
> default boot during boot-up anyway, I expect a lot of trouble for mainline users
> with their own boards...
First we have to understand what we want and what we should do, I think the
origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
what we want, but the index is wrong, so we have to correct it, and my first
commit message is about "index fix".
And I do explain in latest commit message about why we need boot SD first,
but I'm not sure if you have read it.

Rockchip private loaders always make SD as higher priority then eMMC,
because
we may need use SD to update the firmware for eMMC or just a temporary test
only image to check if the PCB is good or not.
I think most of SBC developers prefer to use SD card instead of eMMC,
because
write a SD is easier then update eMMC firmware with vendor tools, and we can
use SD card just like we try a Ubuntu in a Udisk without install it in
hard disk for PC,
just like I write in the commit message.

If we keep eMMC as higher priority, then people have no chance to use
firmware
in SD card if there already have firmware in eMMC.

Then let's check if this "break things for users in the field ", this
patch only affect the
case both eMMC and SD have available firmware(boot.img), right?
I think people only write firmware to SD when they want to boot from it,
or else
people would never do it, the SD will be a normal external storage if
they want to use
the firmware in eMMC. I don't think  there will be "a lot of trouble for
mainline users ".

With this patch, people can use firmware in SD card if they want;
Without this patch, people never able to use firmware in SD card if eMMC
firmware exist
(even if it's broken).
 

Hi Klaus,
    How do you think?

Thanks,
- Kever
>
>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>> ---
>>
>> Changes in v3:
>> - update the commit message
>> Series-changes: 2
>> - update the commit message
>>
>> include/configs/rockchip-common.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
>> index 68e1105a4b..8a72613e52 100644
>> --- a/include/configs/rockchip-common.h
>> +++ b/include/configs/rockchip-common.h
>> @@ -11,11 +11,11 @@
>>
>> #ifndef CONFIG_SPL_BUILD
>>
>> -/* First try to boot from SD (index 0), then eMMC (index 1) */
>> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>> #if CONFIG_IS_ENABLED(CMD_MMC)
>> 	#define BOOT_TARGET_MMC(func) \
>> -		func(MMC, mmc, 0) \
>> -		func(MMC, mmc, 1)
>> +		func(MMC, mmc, 1) \
>> +		func(MMC, mmc, 0)
>> #else
>> 	#define BOOT_TARGET_MMC(func)
>> #endif
>> -- 
>> 2.18.0
>>
>

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Wadim Egorov]

Hi,

Am 29.11.18 um 02:48 schrieb Kever Yang:
>
> On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
>> Kever,
>>
>>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>
>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>> sdcard index is 1, let's update to using correct mmc number for distro
>>> boot order in common header.
>>>
>>> SD card suppost to have higher priority so that people can boot into
>>> the firmware in SD card, this is very convenient for developer try with
>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>> Distro image(which id download from OS vendor release) into SD card without
>>> any modify and then we can boot it up directly.
>> You never addressed the review comment from Klaus (from the review in May):
> I do address the review comment and that's why this patch has been V3
> but not a RESEND for V1. The source code does not change, while the commit
> message has update to make it more clear why this patch is needed.
>
> I'm sorry to Klaus for not sure if I have reply to him directly, but I
> do this
> because I always not get response after I send out my comments in this
> channel,
> then I thought send a new patch with necessary update may be more fast to
> make patch merged.
>
>>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>>> right for me. 

+1 for keeping the ROM boot order also for u-boot.


>> This will change default behaviour and may break things for users in the field.
>> Before we can move forward, we really need to establish a consensus on this
>> and how users will be affected.
>>
>> While this doesn’t matter much for our boards, as we have logic to rewrite the
>> default boot during boot-up anyway, I expect a lot of trouble for mainline users
>> with their own boards...
> First we have to understand what we want and what we should do, I think the
> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
> what we want, but the index is wrong, so we have to correct it, and my first
> commit message is about "index fix".
> And I do explain in latest commit message about why we need boot SD first,
> but I'm not sure if you have read it.
>
> Rockchip private loaders always make SD as higher priority then eMMC,
> because
> we may need use SD to update the firmware for eMMC or just a temporary test
> only image to check if the PCB is good or not.
> I think most of SBC developers prefer to use SD card instead of eMMC,
> because
> write a SD is easier then update eMMC firmware with vendor tools, and we can
> use SD card just like we try a Ubuntu in a Udisk without install it in
> hard disk for PC,
> just like I write in the commit message.

If that is the case, then the SBC developers can override
BOOT_TARGET_DEVICES to their needs in the specific board include file.


>
> If we keep eMMC as higher priority, then people have no chance to use
> firmware
> in SD card if there already have firmware in eMMC.

AFAIK most of the rockchip boards provide a jumper to somehow cut the
eMMC clock and bypass the fixed ROM boot order.

Regards,
Wadim

>
> Then let's check if this "break things for users in the field ", this
> patch only affect the
> case both eMMC and SD have available firmware(boot.img), right?
> I think people only write firmware to SD when they want to boot from it,
> or else
> people would never do it, the SD will be a normal external storage if
> they want to use
> the firmware in eMMC. I don't think  there will be "a lot of trouble for
> mainline users ".
>
> With this patch, people can use firmware in SD card if they want;
> Without this patch, people never able to use firmware in SD card if eMMC
> firmware exist
> (even if it's broken).
>  
>
> Hi Klaus,
>     How do you think?
>
> Thanks,
> - Kever
>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>> ---
>>>
>>> Changes in v3:
>>> - update the commit message
>>> Series-changes: 2
>>> - update the commit message
>>>
>>> include/configs/rockchip-common.h | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
>>> index 68e1105a4b..8a72613e52 100644
>>> --- a/include/configs/rockchip-common.h
>>> +++ b/include/configs/rockchip-common.h
>>> @@ -11,11 +11,11 @@
>>>
>>> #ifndef CONFIG_SPL_BUILD
>>>
>>> -/* First try to boot from SD (index 0), then eMMC (index 1) */
>>> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>>> #if CONFIG_IS_ENABLED(CMD_MMC)
>>> 	#define BOOT_TARGET_MMC(func) \
>>> -		func(MMC, mmc, 0) \
>>> -		func(MMC, mmc, 1)
>>> +		func(MMC, mmc, 1) \
>>> +		func(MMC, mmc, 0)
>>> #else
>>> 	#define BOOT_TARGET_MMC(func)
>>> #endif
>>> -- 
>>> 2.18.0
>>>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Philipp Tomsich]

+Vagrant

Let’s also hear the opinion of the Debian project on this...

> On 29.11.2018, at 10:54, Wadim Egorov <w.egorov@phytec.de> wrote:
> 
> Hi,
> 
> Am 29.11.18 um 02:48 schrieb Kever Yang:
>> 
>> On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
>>> Kever,
>>> 
>>>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> 
>>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>>> sdcard index is 1, let's update to using correct mmc number for distro
>>>> boot order in common header.
>>>> 
>>>> SD card suppost to have higher priority so that people can boot into
>>>> the firmware in SD card, this is very convenient for developer try with
>>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>>> Distro image(which id download from OS vendor release) into SD card without
>>>> any modify and then we can boot it up directly.
>>> You never addressed the review comment from Klaus (from the review in May):
>> I do address the review comment and that's why this patch has been V3
>> but not a RESEND for V1. The source code does not change, while the commit
>> message has update to make it more clear why this patch is needed.
>> 
>> I'm sorry to Klaus for not sure if I have reply to him directly, but I
>> do this
>> because I always not get response after I send out my comments in this
>> channel,
>> then I thought send a new patch with necessary update may be more fast to
>> make patch merged.
>> 
>>>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>>>> right for me. 
> 
> +1 for keeping the ROM boot order also for u-boot.
> 
> 
>>> This will change default behaviour and may break things for users in the field.
>>> Before we can move forward, we really need to establish a consensus on this
>>> and how users will be affected.
>>> 
>>> While this doesn’t matter much for our boards, as we have logic to rewrite the
>>> default boot during boot-up anyway, I expect a lot of trouble for mainline users
>>> with their own boards...
>> First we have to understand what we want and what we should do, I think the
>> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
>> what we want, but the index is wrong, so we have to correct it, and my first
>> commit message is about "index fix".
>> And I do explain in latest commit message about why we need boot SD first,
>> but I'm not sure if you have read it.
>> 
>> Rockchip private loaders always make SD as higher priority then eMMC,
>> because
>> we may need use SD to update the firmware for eMMC or just a temporary test
>> only image to check if the PCB is good or not.
>> I think most of SBC developers prefer to use SD card instead of eMMC,
>> because
>> write a SD is easier then update eMMC firmware with vendor tools, and we can
>> use SD card just like we try a Ubuntu in a Udisk without install it in
>> hard disk for PC,
>> just like I write in the commit message.
> 
> If that is the case, then the SBC developers can override
> BOOT_TARGET_DEVICES to their needs in the specific board include file.
> 
> 
>> 
>> If we keep eMMC as higher priority, then people have no chance to use
>> firmware
>> in SD card if there already have firmware in eMMC.
> 
> AFAIK most of the rockchip boards provide a jumper to somehow cut the
> eMMC clock and bypass the fixed ROM boot order.
> 
> Regards,
> Wadim
> 
>> 
>> Then let's check if this "break things for users in the field ", this
>> patch only affect the
>> case both eMMC and SD have available firmware(boot.img), right?
>> I think people only write firmware to SD when they want to boot from it,
>> or else
>> people would never do it, the SD will be a normal external storage if
>> they want to use
>> the firmware in eMMC. I don't think  there will be "a lot of trouble for
>> mainline users ".
>> 
>> With this patch, people can use firmware in SD card if they want;
>> Without this patch, people never able to use firmware in SD card if eMMC
>> firmware exist
>> (even if it's broken).
>>  
>> 
>> Hi Klaus,
>>     How do you think?
>> 
>> Thanks,
>> - Kever
>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>>> ---
>>>> 
>>>> Changes in v3:
>>>> - update the commit message
>>>> Series-changes: 2
>>>> - update the commit message
>>>> 
>>>> include/configs/rockchip-common.h | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
>>>> index 68e1105a4b..8a72613e52 100644
>>>> --- a/include/configs/rockchip-common.h
>>>> +++ b/include/configs/rockchip-common.h
>>>> @@ -11,11 +11,11 @@
>>>> 
>>>> #ifndef CONFIG_SPL_BUILD
>>>> 
>>>> -/* First try to boot from SD (index 0), then eMMC (index 1) */
>>>> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>>>> #if CONFIG_IS_ENABLED(CMD_MMC)
>>>> 	#define BOOT_TARGET_MMC(func) \
>>>> -		func(MMC, mmc, 0) \
>>>> -		func(MMC, mmc, 1)
>>>> +		func(MMC, mmc, 1) \
>>>> +		func(MMC, mmc, 0)
>>>> #else
>>>> 	#define BOOT_TARGET_MMC(func)
>>>> #endif
>>>> -- 
>>>> 2.18.0
>>>> 
>> 
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>> https://lists.denx.de/listinfo/u-boot <https://lists.denx.de/listinfo/u-boot>

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

+ Andreas from SUSE and Thomas from Armbian

Hi Wadim,


On 11/29/2018 05:54 PM, Wadim Egorov wrote:
> Hi,
>
> Am 29.11.18 um 02:48 schrieb Kever Yang:
>> On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
>>> Kever,
>>>
>>>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>
>>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>>> sdcard index is 1, let's update to using correct mmc number for distro
>>>> boot order in common header.
>>>>
>>>> SD card suppost to have higher priority so that people can boot into
>>>> the firmware in SD card, this is very convenient for developer try with
>>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>>> Distro image(which id download from OS vendor release) into SD card without
>>>> any modify and then we can boot it up directly.
>>> You never addressed the review comment from Klaus (from the review in May):
>> I do address the review comment and that's why this patch has been V3
>> but not a RESEND for V1. The source code does not change, while the commit
>> message has update to make it more clear why this patch is needed.
>>
>> I'm sorry to Klaus for not sure if I have reply to him directly, but I
>> do this
>> because I always not get response after I send out my comments in this
>> channel,
>> then I thought send a new patch with necessary update may be more fast to
>> make patch merged.
>>
>>>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>>>> right for me. 
> +1 for keeping the ROM boot order also for u-boot.
>
>
>>> This will change default behaviour and may break things for users in the field.
>>> Before we can move forward, we really need to establish a consensus on this
>>> and how users will be affected.
>>>
>>> While this doesn’t matter much for our boards, as we have logic to rewrite the
>>> default boot during boot-up anyway, I expect a lot of trouble for mainline users
>>> with their own boards...
>> First we have to understand what we want and what we should do, I think the
>> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
>> what we want, but the index is wrong, so we have to correct it, and my first
>> commit message is about "index fix".
>> And I do explain in latest commit message about why we need boot SD first,
>> but I'm not sure if you have read it.
>>
>> Rockchip private loaders always make SD as higher priority then eMMC,
>> because
>> we may need use SD to update the firmware for eMMC or just a temporary test
>> only image to check if the PCB is good or not.
>> I think most of SBC developers prefer to use SD card instead of eMMC,
>> because
>> write a SD is easier then update eMMC firmware with vendor tools, and we can
>> use SD card just like we try a Ubuntu in a Udisk without install it in
>> hard disk for PC,
>> just like I write in the commit message.
> If that is the case, then the SBC developers can override
> BOOT_TARGET_DEVICES to their needs in the specific board include file.

This need a updated of U-Boot into there eMMC, right?
Most of boards with Rockchip SoC will ship with rockchip default U-Boot,
what I want to do
is the default behavior, developers can boot the system from SD card by
default.
But, please note that every one wants to play with U-Boot.
>
>
>> If we keep eMMC as higher priority, then people have no chance to use
>> firmware
>> in SD card if there already have firmware in eMMC.
> AFAIK most of the rockchip boards provide a jumper to somehow cut the
> eMMC clock and bypass the fixed ROM boot order.

No, not for all the products like box and tablet, and many SBC only have
test point instead of jumper which is not easy to do it without hardware
workaround.
And any kind of software or hardware workaround is not what I want.

Thanks,
- Kever
>
> Regards,
> Wadim
>
>> Then let's check if this "break things for users in the field ", this
>> patch only affect the
>> case both eMMC and SD have available firmware(boot.img), right?
>> I think people only write firmware to SD when they want to boot from it,
>> or else
>> people would never do it, the SD will be a normal external storage if
>> they want to use
>> the firmware in eMMC. I don't think  there will be "a lot of trouble for
>> mainline users ".
>>
>> With this patch, people can use firmware in SD card if they want;
>> Without this patch, people never able to use firmware in SD card if eMMC
>> firmware exist
>> (even if it's broken).
>>  
>>
>> Hi Klaus,
>>     How do you think?
>>
>> Thanks,
>> - Kever
>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - update the commit message
>>>> Series-changes: 2
>>>> - update the commit message
>>>>
>>>> include/configs/rockchip-common.h | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
>>>> index 68e1105a4b..8a72613e52 100644
>>>> --- a/include/configs/rockchip-common.h
>>>> +++ b/include/configs/rockchip-common.h
>>>> @@ -11,11 +11,11 @@
>>>>
>>>> #ifndef CONFIG_SPL_BUILD
>>>>
>>>> -/* First try to boot from SD (index 0), then eMMC (index 1) */
>>>> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>>>> #if CONFIG_IS_ENABLED(CMD_MMC)
>>>> 	#define BOOT_TARGET_MMC(func) \
>>>> -		func(MMC, mmc, 0) \
>>>> -		func(MMC, mmc, 1)
>>>> +		func(MMC, mmc, 1) \
>>>> +		func(MMC, mmc, 0)
>>>> #else
>>>> 	#define BOOT_TARGET_MMC(func)
>>>> #endif
>>>> -- 
>>>> 2.18.0
>>>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Wadim Egorov]

Hi Kever,

Am 30.11.18 um 02:27 schrieb Kever Yang:
> + Andreas from SUSE and Thomas from Armbian
>
> Hi Wadim,
>
>
> On 11/29/2018 05:54 PM, Wadim Egorov wrote:
>> Hi,
>>
>> Am 29.11.18 um 02:48 schrieb Kever Yang:
>>> On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
>>>> Kever,
>>>>
>>>>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>>
>>>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>>>> sdcard index is 1, let's update to using correct mmc number for distro
>>>>> boot order in common header.
>>>>>
>>>>> SD card suppost to have higher priority so that people can boot into
>>>>> the firmware in SD card, this is very convenient for developer try with
>>>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>>>> Distro image(which id download from OS vendor release) into SD card without
>>>>> any modify and then we can boot it up directly.
>>>> You never addressed the review comment from Klaus (from the review in May):
>>> I do address the review comment and that's why this patch has been V3
>>> but not a RESEND for V1. The source code does not change, while the commit
>>> message has update to make it more clear why this patch is needed.
>>>
>>> I'm sorry to Klaus for not sure if I have reply to him directly, but I
>>> do this
>>> because I always not get response after I send out my comments in this
>>> channel,
>>> then I thought send a new patch with necessary update may be more fast to
>>> make patch merged.
>>>
>>>>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>>>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>>>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>>>>> right for me. 
>> +1 for keeping the ROM boot order also for u-boot.
>>
>>
>>>> This will change default behaviour and may break things for users in the field.
>>>> Before we can move forward, we really need to establish a consensus on this
>>>> and how users will be affected.
>>>>
>>>> While this doesn’t matter much for our boards, as we have logic to rewrite the
>>>> default boot during boot-up anyway, I expect a lot of trouble for mainline users
>>>> with their own boards...
>>> First we have to understand what we want and what we should do, I think the
>>> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
>>> what we want, but the index is wrong, so we have to correct it, and my first
>>> commit message is about "index fix".
>>> And I do explain in latest commit message about why we need boot SD first,
>>> but I'm not sure if you have read it.
>>>
>>> Rockchip private loaders always make SD as higher priority then eMMC,
>>> because
>>> we may need use SD to update the firmware for eMMC or just a temporary test
>>> only image to check if the PCB is good or not.
>>> I think most of SBC developers prefer to use SD card instead of eMMC,
>>> because
>>> write a SD is easier then update eMMC firmware with vendor tools, and we can
>>> use SD card just like we try a Ubuntu in a Udisk without install it in
>>> hard disk for PC,
>>> just like I write in the commit message.
>> If that is the case, then the SBC developers can override
>> BOOT_TARGET_DEVICES to their needs in the specific board include file.
> This need a updated of U-Boot into there eMMC, right?

yes, you are right. But this should not be an issue for SBCs shipped
with rockchip private loaders since - as you mentioned before - they
already prioritize the SD card.


> Most of boards with Rockchip SoC will ship with rockchip default U-Boot,
> what I want to do
> is the default behavior, developers can boot the system from SD card by
> default.
> But, please note that every one wants to play with U-Boot.
>>
>>> If we keep eMMC as higher priority, then people have no chance to use
>>> firmware
>>> in SD card if there already have firmware in eMMC.
>> AFAIK most of the rockchip boards provide a jumper to somehow cut the
>> eMMC clock and bypass the fixed ROM boot order.
> No, not for all the products like box and tablet, and many SBC only have
> test point instead of jumper which is not easy to do it without hardware
> workaround.
> And any kind of software or hardware workaround is not what I want.

I understand why you want to change the default boot order. It makes
things much more easier for people who want to try new distros without
ever touching the eMMC content.

Our SoM is not really affected by the change because we redefine the
boot order in the board includes.
Anyway, if you are going to pick this commit I would like to see a note
in the documentation. The bootrom order was default since forever.

Regards,
Wadim


>
> Thanks,
> - Kever
>> Regards,
>> Wadim
>>
>>> Then let's check if this "break things for users in the field ", this
>>> patch only affect the
>>> case both eMMC and SD have available firmware(boot.img), right?
>>> I think people only write firmware to SD when they want to boot from it,
>>> or else
>>> people would never do it, the SD will be a normal external storage if
>>> they want to use
>>> the firmware in eMMC. I don't think  there will be "a lot of trouble for
>>> mainline users ".
>>>
>>> With this patch, people can use firmware in SD card if they want;
>>> Without this patch, people never able to use firmware in SD card if eMMC
>>> firmware exist
>>> (even if it's broken).
>>>  
>>>
>>> Hi Klaus,
>>>     How do you think?
>>>
>>> Thanks,
>>> - Kever
>>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>>>> ---
>>>>>
>>>>> Changes in v3:
>>>>> - update the commit message
>>>>> Series-changes: 2
>>>>> - update the commit message
>>>>>
>>>>> include/configs/rockchip-common.h | 6 +++---
>>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
>>>>> index 68e1105a4b..8a72613e52 100644
>>>>> --- a/include/configs/rockchip-common.h
>>>>> +++ b/include/configs/rockchip-common.h
>>>>> @@ -11,11 +11,11 @@
>>>>>
>>>>> #ifndef CONFIG_SPL_BUILD
>>>>>
>>>>> -/* First try to boot from SD (index 0), then eMMC (index 1) */
>>>>> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>>>>> #if CONFIG_IS_ENABLED(CMD_MMC)
>>>>> 	#define BOOT_TARGET_MMC(func) \
>>>>> -		func(MMC, mmc, 0) \
>>>>> -		func(MMC, mmc, 1)
>>>>> +		func(MMC, mmc, 1) \
>>>>> +		func(MMC, mmc, 0)
>>>>> #else
>>>>> 	#define BOOT_TARGET_MMC(func)
>>>>> #endif
>>>>> -- 
>>>>> 2.18.0
>>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Philipp Tomsich]

Kever,

> On 29.11.2018, at 02:48, Kever Yang <kever.yang@rock-chips.com> wrote:
> 
> On 11/28/2018 05:15 PM, Philipp Tomsich wrote:
>> Kever,
>> 
>>> On 28.11.2018, at 03:06, Kever Yang <kever.yang@rock-chips.com> wrote:
>>> 
>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>> sdcard index is 1, let's update to using correct mmc number for distro
>>> boot order in common header.
>>> 
>>> SD card suppost to have higher priority so that people can boot into
>>> the firmware in SD card, this is very convenient for developer try with
>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>> Distro image(which id download from OS vendor release) into SD card without
>>> any modify and then we can boot it up directly.
>> You never addressed the review comment from Klaus (from the review in May):
> I do address the review comment and that's why this patch has been V3
> but not a RESEND for V1. The source code does not change, while the commit
> message has update to make it more clear why this patch is needed.
> 
> I'm sorry to Klaus for not sure if I have reply to him directly, but I
> do this
> because I always not get response after I send out my comments in this
> channel,
> then I thought send a new patch with necessary update may be more fast to
> make patch merged.
> 
>> 
>>> Also prioritising SD card over eMMC does not make any sense to me. At least on
>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
>>> right for me. 
>> This will change default behaviour and may break things for users in the field.
>> Before we can move forward, we really need to establish a consensus on this
>> and how users will be affected.
>> 
>> While this doesn’t matter much for our boards, as we have logic to rewrite the
>> default boot during boot-up anyway, I expect a lot of trouble for mainline users
>> with their own boards...
> First we have to understand what we want and what we should do, I think the
> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is
> what we want, but the index is wrong, so we have to correct it, and my first
> commit message is about "index fix”.

Your patch clearly changes both the comment _and_ the boot order.
So we need to find a consensus on the boot order as part of this discussion.

> And I do explain in latest commit message about why we need boot SD first,
> but I'm not sure if you have read it.

I have read the message, but just because there is one use-case for this we
shouldn't change the boot order for everyone.

That said, I didn’t find the rationale from the commit message very compelling:
(1) if there isn’t any firmware in the MMC, then the SD card will be booted anyway;
(2) if there is firmware in the MMC, then U-Boot can be instructed to continue booting from SD (i.e. the user breaks onto the commandline and overrides the boottarget for distroboot)
(3) if the firmware in the MMC is broken, then a USB-recovery can be attempted.

Furthermore, if we always boot from SD, there’s issues for people that have
another fixed storage connected to the SD controller (e.g. a second eMMC) or 
if a user inserts a SD card that inadvertently has a loadable image.

> Rockchip private loaders always make SD as higher priority then eMMC,
> because
> we may need use SD to update the firmware for eMMC or just a temporary test
> only image to check if the PCB is good or not.
> I think most of SBC developers prefer to use SD card instead of eMMC,
> because
> write a SD is easier then update eMMC firmware with vendor tools, and we can
> use SD card just like we try a Ubuntu in a Udisk without install it in
> hard disk for PC,
> just like I write in the commit message.

There’s some interesting information here, as I had not been aware that your
bootloader prioritised SD cards over eMMC.  This may be an issue for most
industrial embedded applications, as these frequently don’t want surprising
changes to the boot order … however, I’d expect that most of these have the
boot-order fixed in their board-files anyway.

You might be surprised to hear that our RK3399 module has the eMMC on
the SDHCI controller and the SD/SDIO on the DWMMC.
As I said: my team doesn’t really have any skin in the game, as we have a
'u-boot,spl-boot-order’ to select where and how SPL searches for its FIT
images… and we have a board-specific setup_boottargets() function to
perform appropriate reordering of the boottargets before distroboot.

> If we keep eMMC as higher priority, then people have no chance to use
> firmware
> in SD card if there already have firmware in eMMC.
> 
> Then let's check if this "break things for users in the field ", this
> patch only affect the
> case both eMMC and SD have available firmware(boot.img), right?
> I think people only write firmware to SD when they want to boot from it,
> or else
> people would never do it, the SD will be a normal external storage if
> they want to use
> the firmware in eMMC. I don't think  there will be "a lot of trouble for
> mainline users “.

The unexpected behaviour (a.k.a. “a lot of trouble”) would occur for users that
have firmware on their SD card (and may not even be aware of this).
Again: we need to establish a consensus here, as we are changing something
that has always been like this in our tree.

> With this patch, people can use firmware in SD card if they want;
> Without this patch, people never able to use firmware in SD card if eMMC
> firmware exist (even if it's broken).

Most boards I know have the ability to bypass the internal eMMC.

Thanks,
Philipp.

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Philipp Tomsich]

>> With this patch, people can use firmware in SD card if they want;
>> Without this patch, people never able to use firmware in SD card if eMMC
>> firmware exist (even if it's broken).
> 
> Most boards I know have the ability to bypass the internal eMMC.

One last thing: I know a number of projects developing devices using our
modules that have a SD card slot for data exchange (e.g. config data, log
files, data acquisition and export) but that don’t want endusers to boot the
device from the SD card (possibly using unauthorized firmware).

For factory use, there’s a signal on the mainboard to disable (until turned
back on by software) the on-module eMMC and (if available) SPI to allow
booting from the external SD card.  For field use, this signal is unaccessible
and can not be asserted…

Hope this provides one example to how different use cases can play out...

Thanks,
Philipp.

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Klaus Goger]

Adding Wadim as he will most likely has something to add to the discussion too.

Kever,

I understand your SBC viewpoint especially in terms of developer. But as Philipp already laid out the usage in the SoM and enduser products might be different and changing defaults may have a big impact. So while I don’t have a problem in changing the behaviour we should have a consense for all usecases and define if we want to have it global or a board basis for backwarts compatibility.

Thanks,
Klaus

> On 29.11.2018, at 22:44, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
> 
> 
> 
>>> With this patch, people can use firmware in SD card if they want;
>>> Without this patch, people never able to use firmware in SD card if eMMC
>>> firmware exist (even if it's broken).
>> 
>> Most boards I know have the ability to bypass the internal eMMC.
> 
> One last thing: I know a number of projects developing devices using our
> modules that have a SD card slot for data exchange (e.g. config data, log
> files, data acquisition and export) but that don’t want endusers to boot the
> device from the SD card (possibly using unauthorized firmware).
> 
> For factory use, there’s a signal on the mainboard to disable (until turned
> back on by software) the on-module eMMC and (if available) SPI to allow
> booting from the external SD card.  For field use, this signal is unaccessible
> and can not be asserted…
> 
> Hope this provides one example to how different use cases can play out...
> 
> Thanks,
> Philipp.

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Klaus Goger]

Wadim, sorry for missing that you already commented in the thread. Threading doesn’t work that well on mobile if I’m not CC’ed.

So it looks like we want to keep the BootROM behaviour for at least the Rockchip based SoMs. Let’s see if Simon has an opinion regarding the Chromebooks.

> On 29.11.2018, at 23:01, Klaus Goger <klaus.goger@theobroma-systems.com> wrote:
> 
> Adding Wadim as he will most likely has something to add to the discussion too.
> 
> Kever,
> 
> I understand your SBC viewpoint especially in terms of developer. But as Philipp already laid out the usage in the SoM and enduser products might be different and changing defaults may have a big impact. So while I don’t have a problem in changing the behaviour we should have a consense for all usecases and define if we want to have it global or a board basis for backwarts compatibility.
> 
> Thanks,
> Klaus
> 
>> On 29.11.2018, at 22:44, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>> 
>> 
>> 
>>>> With this patch, people can use firmware in SD card if they want;
>>>> Without this patch, people never able to use firmware in SD card if eMMC
>>>> firmware exist (even if it's broken).
>>> 
>>> Most boards I know have the ability to bypass the internal eMMC.
>> 
>> One last thing: I know a number of projects developing devices using our
>> modules that have a SD card slot for data exchange (e.g. config data, log
>> files, data acquisition and export) but that don’t want endusers to boot the
>> device from the SD card (possibly using unauthorized firmware).
>> 
>> For factory use, there’s a signal on the mainboard to disable (until turned
>> back on by software) the on-module eMMC and (if available) SPI to allow
>> booting from the external SD card.  For field use, this signal is unaccessible
>> and can not be asserted…
>> 
>> Hope this provides one example to how different use cases can play out...
>> 
>> Thanks,
>> Philipp.

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

Hi Philipp,


On 11/30/2018 05:44 AM, Philipp Tomsich wrote:
>
>
>>> With this patch, people can use firmware in SD card if they want;
>>> Without this patch, people never able to use firmware in SD card if eMMC
>>> firmware exist (even if it's broken).
>>
>> Most boards I know have the ability to bypass the internal eMMC.
>
> One last thing: I know a number of projects developing devices using our
> modules that have a SD card slot for data exchange (e.g. config data, log
> files, data acquisition and export) but that don’t want endusers to
> boot the
> device from the SD card (possibly using unauthorized firmware).

Here have few points:
1. people can use SD card as normal storage, I have mentioned about this
in my previous mail;
    We don't affect this feature because SD with firmware need special
format.
2. If vendor don't want end users to using unauthorized firmware, they
need add
    verify boot in U-Boot, or else user can override firmware no matter
is eMMC or SD;
3. If vendor don't want to boot from SD, then they do need update the
source code and delete
    the SD option, because people can still boot from SD only with broke
eMMC boot partition
We are talking about the default boot order of bootable partition, not
about if we can boot
from SD card or if we can use unauthorized firmware.

>
> For factory use, there’s a signal on the mainboard to disable (until
> turned
> back on by software) the on-module eMMC and (if available) SPI to allow
> booting from the external SD card.  For field use, this signal is
> unaccessible
> and can not be asserted…

Thanks for your information, and you are doing very well for your are so
experienced,
and you have consider this case in both software and hardware, but I
know most of the
product vendor does not consider so much like you, and they will depends
on what Rockchip
provide to them.

Like I have said in another mail, I don't want any kind of software or
hardware workaround
after it have been in product type, because not all people want to play
with U-Boot,
and product usually pack with case.

For some product, it still need update or fix with SD/USB for those not
support OTA.

BTW, this feature does not affect products which use Rockchip SDK
directly, because
we are using AOSP image instead of distro image.

I hope those SBC developers can play with different distro based OS
easier without
study bootloader or study Rockchip tools to update eMMC or any kind of
hardware workaround.

Thanks,
- Kever

>
> Hope this provides one example to how different use cases can play out...
>
> Thanks,
> Philipp.

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

Hi Philipp, Simon,

   Is it possible for this patch to be merged?
   Right now, two board owner does not  like this patch but both of you
says this patch do not affect your board, and most of other boards are
maintained by me, and I have share why I need this patch and why this patch
not affect so much very clearly in previous mail.
    Please evaluate it again and close this topic, at least the original
code comment "First try to boot from SD (index 0), then eMMC (index 1) " is
not correct, something must be fixed.

Thanks,
- Kever

Kever Yang <kever.yang@rock-chips.com> 于2018年11月28日周三 上午10:06写道：

> According to the emmc/sdcard index in dts alias, emmc is always 0 and
> sdcard index is 1, let's update to using correct mmc number for distro
> boot order in common header.
>
> SD card suppost to have higher priority so that people can boot into
> the firmware in SD card, this is very convenient for developer try with
> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
> Distro image(which id download from OS vendor release) into SD card without
> any modify and then we can boot it up directly.
>
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
> Changes in v3:
> - update the commit message
> Series-changes: 2
> - update the commit message
>
>  include/configs/rockchip-common.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/rockchip-common.h
> b/include/configs/rockchip-common.h
> index 68e1105a4b..8a72613e52 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,11 +11,11 @@
>
>  #ifndef CONFIG_SPL_BUILD
>
> -/* First try to boot from SD (index 0), then eMMC (index 1) */
> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>  #if CONFIG_IS_ENABLED(CMD_MMC)
>         #define BOOT_TARGET_MMC(func) \
> -               func(MMC, mmc, 0) \
> -               func(MMC, mmc, 1)
> +               func(MMC, mmc, 1) \
> +               func(MMC, mmc, 0)
>  #else
>         #define BOOT_TARGET_MMC(func)
>  #endif
> --
> 2.18.0
>
>

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Philipp Tomsich]

My gut feeling would be to fix the comment only.

> On 23.01.2019, at 03:14, Kever Yang <kever.yang@rock-chips.com> wrote:
> 
> Hi Philipp, Simon,
> 
>    Is it possible for this patch to be merged?
>    Right now, two board owner does not  like this patch but both of you says this patch do not affect your board, and most of other boards are maintained by me, and I have share why I need this patch and why this patch not affect so much very clearly in previous mail.
>     Please evaluate it again and close this topic, at least the original code comment "First try to boot from SD (index 0), then eMMC (index 1) " is not correct, something must be fixed.
> 
> Thanks,
> - Kever
> 
> Kever Yang <kever.yang at rock-chips.com <mailto:kever.yang@rock-chips.com>> 于2018年11月28日周三 上午10:06写道：
> According to the emmc/sdcard index in dts alias, emmc is always 0 and
> sdcard index is 1, let's update to using correct mmc number for distro
> boot order in common header.
> 
> SD card suppost to have higher priority so that people can boot into
> the firmware in SD card, this is very convenient for developer try with
> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
> Distro image(which id download from OS vendor release) into SD card without
> any modify and then we can boot it up directly.
> 
> Signed-off-by: Kever Yang <kever.yang at rock-chips.com <mailto:kever.yang@rock-chips.com>>
> ---
> 
> Changes in v3:
> - update the commit message
> Series-changes: 2
> - update the commit message
> 
>  include/configs/rockchip-common.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
> index 68e1105a4b..8a72613e52 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,11 +11,11 @@
> 
>  #ifndef CONFIG_SPL_BUILD
> 
> -/* First try to boot from SD (index 0), then eMMC (index 1) */
> +/* First try to boot from SD (index 1), then eMMC (index 0) */
>  #if CONFIG_IS_ENABLED(CMD_MMC)
>         #define BOOT_TARGET_MMC(func) \
> -               func(MMC, mmc, 0) \
> -               func(MMC, mmc, 1)
> +               func(MMC, mmc, 1) \
> +               func(MMC, mmc, 0)
>  #else
>         #define BOOT_TARGET_MMC(func)
>  #endif
> -- 
> 2.18.0
> 

[U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

[Kever Yang]

The comment is what we want to do, so it's not correct to fix the
comment only.

    "First try to boot from SD() , then eMMC()"


Thanks,
- Kever
On 01/23/2019 07:00 PM, Philipp Tomsich wrote:
> My gut feeling would be to fix the comment only.
>
>> On 23.01.2019, at 03:14, Kever Yang <kever.yang@rock-chips.com
>> <mailto:kever.yang@rock-chips.com>> wrote:
>>
>> Hi Philipp, Simon,
>>
>>    Is it possible for this patch to be merged?
>>    Right now, two board owner does not  like this patch but both of
>> you says this patch do not affect your board, and most of other
>> boards are maintained by me, and I have share why I need this patch
>> and why this patch not affect so much very clearly in previous mail.
>>     Please evaluate it again and close this topic, at least the
>> original code comment "First try to boot from SD (index 0), then eMMC
>> (index 1) " is not correct, something must be fixed.
>>
>> Thanks,
>> - Kever
>>
>> Kever Yang <kever.yang@rock-chips.com
>> <mailto:kever.yang@rock-chips.com>> 于2018年11月28日周三 上午10:06写道：
>>
>>     According to the emmc/sdcard index in dts alias, emmc is always 0 and
>>     sdcard index is 1, let's update to using correct mmc number for
>>     distro
>>     boot order in common header.
>>
>>     SD card suppost to have higher priority so that people can boot into
>>     the firmware in SD card, this is very convenient for developer
>>     try with
>>     distro img from SUSE, Fedora and etc. Developer only need to 'dd' the
>>     Distro image(which id download from OS vendor release) into SD
>>     card without
>>     any modify and then we can boot it up directly.
>>
>>     Signed-off-by: Kever Yang <kever.yang@rock-chips.com
>>     <mailto:kever.yang@rock-chips.com>>
>>     ---
>>
>>     Changes in v3:
>>     - update the commit message
>>     Series-changes: 2
>>     - update the commit message
>>
>>      include/configs/rockchip-common.h | 6 +++---
>>      1 file changed, 3 insertions(+), 3 deletions(-)
>>
>>     diff --git a/include/configs/rockchip-common.h
>>     b/include/configs/rockchip-common.h
>>     index 68e1105a4b..8a72613e52 100644
>>     --- a/include/configs/rockchip-common.h
>>     +++ b/include/configs/rockchip-common.h
>>     @@ -11,11 +11,11 @@
>>
>>      #ifndef CONFIG_SPL_BUILD
>>
>>     -/* First try to boot from SD (index 0), then eMMC (index 1) */
>>     +/* First try to boot from SD (index 1), then eMMC (index 0) */
>>      #if CONFIG_IS_ENABLED(CMD_MMC)
>>             #define BOOT_TARGET_MMC(func) \
>>     -               func(MMC, mmc, 0) \
>>     -               func(MMC, mmc, 1)
>>     +               func(MMC, mmc, 1) \
>>     +               func(MMC, mmc, 0)
>>      #else
>>             #define BOOT_TARGET_MMC(func)
>>      #endif
>>     -- 
>>     2.18.0
>>
>