[U-Boot] RK3399/RK3288 same-as-spl Option

[Philipp Tomsich]

> On 30.01.2019, at 15:06, Wadim Egorov <w.egorov at phytec.de> wrote:
> 
> Hi Philipp,
> Am 30.01.19 um 13:56 schrieb Philipp Tomsich:
>> Wadim,
>> 
>>> On 30.01.2019, at 13:50, Wadim Egorov <w.egorov at phytec.de <mailto:w.egorov at phytec.de>> wrote:
>>> I want to know if there is a reason why the same-as-spl boot order option [1] was not added for the RK3288. Do the chromebooks or other RK3288 based boards don't want/need this option?
>> For starters I don’t have a RK3288-based board or a Chromebook.
>> The code was designed to be generic enough to easily retarget to new boards.
>> 
>> It’s good to see that it’s not just our modules that face the challenge of requiring a configurable boot-order ;-) 
> Yes, this popped up again for me after the "eMMC/sd index distro boot order" discussion.
> 
>>> It seems the RK3288 has the same Register that marks the boot source device:
>>>   RK3399_BROM_BOOTSOURCE_ID_ADDR: 0xff8c0010
>>>   For RK3288 it is 0xff700010. I know it is not documented in the TRM. But it works.
>> I had asked Kever for the address (back in the day), as it was not documented neither for the RK3368 nor for the RK3399.
>>> Any opinions in reworking the RK3288 code to use this Register for "same-as-spl" boot?
>> There’s a task in my to-do list to move most of the configuration in the GRF (e.g. selecting RGMII vs. GMII) to an ioctl-based scheme.
>> This resulted as the “best available choice” from a prior discussion between me an Simon.
>> 
>> If you want to tackle this, I would advise a DM-based solution for interfacing with our BootROM.
> Thanks, I will keep this in mind. Right know it is not that important for us. And I just wanted to know why nobody else had the idea to use the same-as-spl process before. Maybe because this Register was not known for a long time.
For us it was a critical issue, as we have to support the Qseven form-factor on top of the
Rockchip BootROM: i.e. BIOS_DISABLE should force an external boot.  The hardware
does this by keeping the eMMC and SPI-NOR in reset (or powered-off, as we model it
as a regulator) and early-on in SPL during the regulator set-up, we re-enable these two
devices.

As we probe for a bootable FIT payload, we thus need to know what order to probe in.
Yet, the same bootloader should work from eMMC and SD-card … so we needed to have
some token to say “same device the SPL stage was booted from” that we could insert
early on in the search sequence (and yes: the SRAM location—this is not even a register—
is not publicly documented, but it took only one mail to Kever to get the info…)

That’s the complete historical record on this feature, now documented for eternity on the
mailing list archive. ;-)
I hope this provides the needed context…

Cheers,
Phil.