[PATCH 09/11] sunxi: Add support for SUNIV architecture

[Jesse Taube]

On 1/29/22 15:59, Samuel Holland wrote:
> On 1/29/22 5:51 AM, Andre Przywara wrote:
>> On Fri, 28 Jan 2022 22:21:28 -0500
>> Jesse Taube <mr.bossman075 at gmail.com> wrote:
>>> On 1/26/22 09:38, Jesse Taube wrote:
>>>> On 1/26/22 09:13, Andre Przywara wrote:
>>>>> On Tue,  4 Jan 2022 19:35:06 -0500
>>>>> Jesse Taube <mr.bossman075 at gmail.com> wrote:
>>>>>   
>>>>>>     u32 spl_boot_device(void)
>>>>>>     {
>>>>>>     	return sunxi_get_boot_device();
>>>>>>     }
>>>>>> +#else
>>>>>> +/*
>>>>>> + * suniv BROM do not pass the boot media type to SPL, so we try with the
>>>>>> + * boot sequence in BROM: mmc0->spinor->fail.
>>>>>> + */
>>>>>> +void board_boot_order(u32 *spl_boot_list)
>>>>>> +{
>>>>>> +	/*
>>>>>> +	 * See the comments above in sunxi_get_boot_device() for information
>>>>>> +	 * about FEL boot.
>>>>>> +	 */
>>>>>> +	if (!is_boot0_magic(SPL_ADDR + 4)) {
>>>>>> +		spl_boot_list[0] = BOOT_DEVICE_BOARD;
>>>>>> +		return;
>>>>>> +	}
>>>>>> +
>>>>>> +	spl_boot_list[0] = BOOT_DEVICE_MMC1;
>>>>>
>>>>> So does that mean that it tries MMC first, even when booted via SPI? So if
>>>>> there is a *non*-bootable microSD card in, it will read something from
>>>>> sector 80, and will execute that if this is a FIT or legacy image?
>>>> yes
>>> Uh sorry to bother you again but I cant seem to find a way to find where
>>> the bootrom got the spl. I could check other periphirals like pinmux. I
>>> could also just have it configured at build. Are both these options
>>> okay? I will try to find a way to find the boot device at runtime first.
>>
>> Don't bother for this version, it's fine as it is now, we can refine
>> this later. It's only a problem if there is a non-valid SPL, but a
>> valid U-Boot proper legacy image on the SD card.
>> I don't want to have a build time option, we try to keep a single image
>> for all boot sources.
>> So eventually I'd prefer the pinmux/clock check, since that's cheaper.
>> The alternative would be to read the SPL (again), check for a valid
>> header and verify the checksum. You can look at this for inspiration:
>> https://patchwork.ozlabs.org/project/uboot/patch/20210712100651.6912-3-andre.przywara@arm.com/
> 
> I checked the boot ROM code (thanks Jesse!), and indeed it does not report where
> it loaded SPL from, or make any other changes to the loaded eGON image. The boot
> ROM also completely cleans up its clock and pinctrl changes, regardless of the
> success/failure of a specific boot device.
> 
> There's a function which loads some value to r2, but that gets called before the
> "load eGON from storage" functions, so r2 will be clobbered.
> 
> So as far as I can tell, the only way to determine the boot device, other than
> reimplementing the BROM in SPL, is to look at the return address on the top of
> the BROM's stack. These are the possible values (in order of execution):
> 
> 0xffff40f8: mmc0
> 0xffff4114: spi0 NAND
> 0xffff4130: spi0 NOR
> 0xffff4150: mmc1

If i save it in save_boot_params it does change when in a different boot 
device. Ill look into it more.
the sp is also a good idea.
> Regards,
> Samuel