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

[Jesse Taube]

On 1/29/22 16:21, Giulio Benetti wrote:
> 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 :-)
Im sorry only by a couple of seconds.
> So happy assembly coding Jesse!
Its very difficult :( I'm not used to how it works yet.
Thanks,
	Jesse Taube
> 
> Best regards