Hi Julien, On Thu, Oct 21, 2021 at 2:52 PM Julien Massot <julien.massot@xxxxxxx> wrote: > >> +/* > >> + * Most of the R-Car Gen3 SoCs have an ARM Realtime Core. > >> + * Firmware boot address has to be set in CR7BAR before > >> + * starting the realtime core. > >> + * Boot address must be aligned on a 256k boundary. > >> + */ > >> +static int rcar_rst_set_gen3_rproc_boot_addr(u32 boot_addr) > > > > phys_addr_t? > Not sure, in the remoteproc subsystem the boot address is in the > remote processor address space, which can be a different mapping than the host > processor. On Gen3 both the realtime and the application cores share the same address > map. (excepted for 64 bits address) > So a physical address from the CA5x processors is the same on the CR7 > processor. > My feeling is that it's better to keep u32. > > Do you have a public user of this code, too? > I have one that I plan to submit to the remoteproc subsystem once > it will be possible to set the CR7 boot address. OK. > Please have a look there > https://github.com/iotbzh/linux/blob/iot/for-upstream/rproc/drivers/remoteproc/rcar_rproc.c#L114 > > In this function the remoteproc subsystem already fetched a firmware and parsed the elf file. > The firmware entry point is stored in a u64 variable > https://github.com/iotbzh/linux/blob/iot/for-upstream/rproc/include/linux/remoteproc.h#L550 > > Then we can start the processor by deasserting the reset. Given rproc defines this as u64, I think using u64 would be even better than phys_addr_t. I'd like to keep this as generic as possible, as someone may want to do the reverse too (boot the CA5x from the CR7). And of course there's also the SH-4A core on R-Car Gen2 ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
