Date: Sun, 11 Oct 2020 21:55:34 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, Oleksandr Tymoshenko <gonzo@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Patches from ~gonzo/arm/rpi3-smp/u-boot-patches/ missing from u-boot upstream and from relevant sysutils/u-boot-* ports? Message-ID: <5A695B2A-8E46-449F-B9DF-2807B6A64C63@yahoo.com> In-Reply-To: <9DE1EAA1-40DB-4614-843B-73A8861098E7@yahoo.com> References: <9DE1EAA1-40DB-4614-843B-73A8861098E7@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-11, at 19:23, Mark Millard <marklmi at yahoo.com> wrote: >=20 > There are u-boot patches (from 2015-Nov-25) listed at: >=20 > https://people.freebsd.org/~gonzo/arm/rpi3-smp/u-boot-patches/ >=20 > that are not in u-boot and are not in the sysutils/u-boot-master > or sysutils/u-boot-rpi[34] ports tree via patch-* files. >=20 > arm/rpi3-smp/u-boot-patches/patch-board_raspberrypi_rpi_rpi.c > looks to be what was expected to handle the values from the: >=20 > https://github.com/gonzoua/rpi3-psci-monitor/blob/master/pscimon.S >=20 > code (w0 and x1 before boot_kernel). That calling code (to u-boot > as kernel) looks like: >=20 > primary_cpu: > mov sp, #RESERVE_SIZE > sub sp, sp, #16 > ldr w0, dtb_ptr32 > bl fixup_dt_blob > ldr w4, kernel_entry32 > ldr w0, dtb_ptr32 > mov x1, #RESERVE_SIZE >=20 > boot_kernel: > mov x2, #0 > mov x3, #0 > br x4 >=20 > The matching rpi.c patch code was (in part): >=20 > +static u64 fw_fdt_address __attribute__ ((section(".data"))); > +static u64 reserve_memory __attribute__ ((section(".data"))); > + > +void save_boot_params(u64 x0, u64 x1, u64 x2, u64 x3) > +{ > + fw_fdt_address =3D x0; > + reserve_memory =3D x1; > + save_boot_params_ret(); > +} > + > +void dram_init_banksize(void) > +{ > + gd->bd->bi_dram[0].start =3D CONFIG_SYS_SDRAM_BASE + = reserve_memory; > + gd->bd->bi_dram[0].size =3D get_effective_memsize() - = reserve_memory; > +} > . . . > +#ifdef CONFIG_ARM64 > + if (fw_fdt_address) > + setenv_hex("fdt_addr_r", (ulong)fw_fdt_address); > +#endif >=20 > The only "set_env.*fdt_addr_r" that I find is: >=20 > # grep -r "set_env.*fdt_addr_r" ./ | more > ./arch/arm/mach-uniphier/board_late_init.c: = uniphier_set_env_addr("fdt_addr_r", "fdt_addr_r_offset"); >=20 > As for the line with CONFIG_SYS_SDRAM_BASE, only one match > seems to be for armv8 cotnexts: >=20 > # grep -r "\<bi_dram\[0\].start.*CONFIG_SYS_SDRAM_BASE" ./ | more > ./arch/arm/cpu/armv8/fsl-layerscape/cpu.c: = gd->bd->bi_dram[0].start =3D CONFIG_SYS_SDRAM_BASE; > . . . >=20 > If there is other, more modern u-boot code that covers handling > the x0 and x1 from pscimon.S I have yet to notice. (But, the > code is not familiar so that might not be surprising.) Looks like I got only one part of the the above correct. There is material for fdt_addr via x0: board/raspberrypi/rpi/lowlevel_init.S does have: /* * Routine: save_boot_params (called after reset from start.S) * Description: save ATAG/FDT address provided by the firmware at boot = time */ .global save_boot_params save_boot_params: /* The firmware provided ATAG/FDT address can be found in r2/x0 = */ #ifdef CONFIG_ARM64 adr x8, fw_dtb_pointer str x0, [x8] #else ldr r8, =3Dfw_dtb_pointer str r2, [r8] #endif /* Returns */ b save_boot_params_ret and board/raspberrypi/rpi/rpi.c does have: /* * If the firmware provided a valid FDT at boot time, let's expose it in * ${fdt_addr} so it may be passed unmodified to the kernel. */ static void set_fdt_addr(void) { if (env_get("fdt_addr")) return; if (fdt_magic(fw_dtb_pointer) !=3D FDT_MAGIC) return; =20 env_set_hex("fdt_addr", fw_dtb_pointer); } =20 /* * Prevent relocation from stomping on a firmware provided FDT blob. */ unsigned long board_get_usable_ram_top(unsigned long total_size) { if ((gd->ram_top - fw_dtb_pointer) > SZ_64M) return gd->ram_top; return fw_dtb_pointer & ~0xffff; } . . . /* * If the firmware passed a device tree use it for U-Boot. */ void *board_fdt_blob_setup(void) { if (fdt_magic(fw_dtb_pointer) !=3D FDT_MAGIC) return NULL; return (void *)fw_dtb_pointer; } (So, somewhat different naming for what is involved.) That covers x0. But x1 seems to be ignored. May be its value proved to be unimportant or what it was for is now handled another way? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A695B2A-8E46-449F-B9DF-2807B6A64C63>