* Tony Lindgren <tony@xxxxxxxxxxx> [170315 10:24]: > * Tony Lindgren <tony@xxxxxxxxxxx> [170314 11:16]: > > * Andrew F. Davis <afd@xxxxxx> [170314 10:59]: > > Then onto the other related patches.. > > > > > We re-park cpu1 in bootROM in U-Boot already, in the U-Boot tree: > > > arch/arm/mach-omap2/omap5/sec_entry_cpu1.S > > > > OK good to hear. > > > > > omap_smc_sec_cpu1() wakes up cpu1 into the function cpu1_entry(), this > > > makes an SMC call to setup the core, then re-parks itself back in bootROM. > > > Relevant code to run on cpu1: > > > > > > > #define AUX_CORE_BOOT_0 0x48281800 > > > > #define AUX_CORE_BOOT_1 0x48281804 > > > > /* DRA7xx ROM code function "startup_BootSlave". This function is where CPU1 > > > > * waits on WFE, polling on AUX_CORE_BOOT_x registers. > > > > * This address is same for J6 and J6 Eco. > > > > */ > > > > #define ROM_FXN_STARTUP_BOOTSLAVE 0x00038a64 > > > > > > > > ldr r4, =AUX_CORE_BOOT_0 > > > > mov r5, #0x0 > > > > str r5, [r4] > > > > ldr r4, =ROM_FXN_STARTUP_BOOTSLAVE > > > > bx r4 @ Jump back to ROM > > > > > > We would have to do this in kernel. The issue I'm thinking we are going > > > to hit is that the parking function in bootROM expects the MMU to be > > > off. Although we don't really need to turn it off as long as we can > > > identity map the bootROM area, the AUX_CORE_BOOT_0/1 space, and wherever > > > we plan to exit the parking loop. > > > > Would be good to hear what Russell thinks we should do here to park > > CPU1. > > How about we introduce smp_park_secondary()? > > Then soft_restart() can call it between setup_mm_for_reboot() > and cpu_proc_fin()? Hmm that probably won't help as we'd have to still have a 1:1 mapping in cpu_die() to put CPU1 into WFI and release it in smp_park_secondary() to the bootrom. Anyways, I think in your use case it's the suspend/resume that needs the state preserved for CPU1. Do you need kexec working in your use case? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
