| Message ID | 20181128020602.18058-1-kever.yang@rock-chips.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Kever Yang |
| Headers | show |
| Series | [U-Boot,RESENT,v3] rockchip: update emmc/sd index for distro boot order | expand |
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 >
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 >> >
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@lists.denx.de > https://lists.denx.de/listinfo/u-boot
+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@lists.denx.de <mailto:U-Boot@lists.denx.de> >> https://lists.denx.de/listinfo/u-boot <https://lists.denx.de/listinfo/u-boot>
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.
>> 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.
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.
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.
+ 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@lists.denx.de >> https://lists.denx.de/listinfo/u-boot
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.
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@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot >
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
>
>
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@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 >
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 >> >
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
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(-)