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