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

Giulio Benetti
2022-01-29T21:18:48Z

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