[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 at 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 at 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.