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

[Giulio Benetti]

Hi Jesse, Andre,

On 29/01/22 22: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.

Samuel, are you sure about this? Maybe Jesse can double check what 
happens stepping here:
https://elixir.bootlin.com/u-boot/latest/source/arch/arm/cpu/armv7/start.S#L40

Because Jesse mentioned R2 contains the value, so I expect it to be here.

>> 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.

Are the values in R2 the same as the other sunxi SoCs?
And if yes, you can save it in a global variable here:
https://elixir.bootlin.com/u-boot/latest/source/arch/arm/cpu/armv7/start.S#L40

since that is the very beginning of SPL using a #ifdef SUNIV/#endif

> the sp is also a good idea.

This is also another good option. But if the previous works I would go 
for that IMHO.

Best regards
-- 
Giulio Benetti
Benetti Engineering sas