On 1/29/22 5:51 AM, Andre Przywara wrote:
> On Fri, 28 Jan 2022 22:21:28 -0500
> Jesse Taube <mr.bossman...@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.bossman...@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.przyw...@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
Regards,
Samuel
