+Vagrant Let’s also hear the opinion of the Debian project on this...
> On 29.11.2018, at 10:54, Wadim Egorov <w.ego...@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.y...@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.y...@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> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
