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

[Giulio Benetti]

On 29/01/22 22:19, Jesse Taube wrote:
> 
> 
> 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.

I've been too late :-)
So happy assembly coding Jesse!

Best regards
-- 
Giulio Benetti
Benetti Engineering sas