On 30.01.2019, at 15:06, Wadim Egorov w.egorov@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@phytec.de mailto:w.egorov@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.