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

[Jesse Taube]

On 1/29/22 16:05, Jesse Taube wrote:
> 
> 
> 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.
Sry Im just dumb. it does change but it is because it doesn't clean the 
registers.
Thanks sam, looking at the stack is the best option.

Sorry,
	Jesse Taube
>> Regards,
>> Samuel