On 06/25/2019 11:50 AM, Jan Kiszka wrote:
On 24.06.19 23:44, 'Vitaly Andrianov' via Jailhouse wrote:
On 06/24/2019 12:27 PM, Jan Kiszka wrote:
On 24.06.19 15:29, Vitaly Andrianov wrote:
On 06/24/2019 09:23 AM, Jan Kiszka wrote:
On 24.06.19 14:27, Vitaly Andrianov wrote:
Hi Jan, Ralf,
On 06/12/2019 03:27 PM, 'Vitaly Andrianov' via Jailhouse wrote:
Hi Ralf,
Thanks you for the quick response.
[skip]
so, I have to implement the corresponding am57xx_init() and
am57xx_cell_exit().
Here is the old mach_cell_exit function, but many of the functions it
uses disappeared in the v0.10 version.
void mach_cell_exit(struct cell *cell)
{
unsigned int cpu;
for_each_cpu(cpu, cell->cpu_set) {
per_cpu(cpu)->cpu_on_entry =
mmio_read32(wkupgen_base + OMAP_AUX_CORE_BOOT_0 +
cpu * 4);
per_cpu(cpu)->cpu_on_context = 0;
arch_suspend_cpu(cpu);
arch_reset_cpu(cpu);
}
}
I have implemented the am57xx unit. At the am57xx_cell_exit() I set cpu_on_entry to
omap5_secondary_hyp_startup() - physical address. That was in the working v0.8 mach_cell_exit().
But I'm not sure what shall I do with the remaining 3 calls:
per_cpu(cpu)->cpu_on_context = 0;
arch_suspend_cpu(cpu);
arch_reset_cpu(cpu);
When I execute "jailhouse cell destroy 1" the kernel cannot bring cpu1 online and it still in
the hypervisor's WFI loop.
Any advise?
Can you share the code?
But, again, we will likely need more redesign anyway because the previous approach was already
hacky. E.g. it was rather fishy to pass through the WakeupGen page and issuing smc calls.
Can you describe the CPU boot flow from OS perspective, or refer to a description? Back then, I
implemented it via Linux reverse engineering.
Jan
I just made suspend_cpu() not static and called from am57xx_exit_cell(). I got cpu_up() working
after that. Now I have the both uart-demo and git-demo working now. Let me clean the code and I
push it to the temporally branch to TI external git repo. After that we can discuss what I need
to do to implement the correct way.
OK, sounds good!
Jan
Jan,
I pushed the sources to my private branch
https://git.ti.com/processor-sdk/jailhouse/commits/am57xx-next-va. I have uart-demo and gic-demo
working, but non of my other inmates works. All accesses to peripheral addresses causes data
aborts. I guess that is because I have not
Check - when in doubt via instrumenting the calls - if the regions at the faulting addresses are
actually mapped -> arch_map_memory_region.
arch_map_memory_region 0x48020000/0x48020000/0x00001000 0x00000093
arch_map_memory_region 0x48424000/0x48424000/0x00001000 0x00000093
arch_map_memory_region 0x48826000/0x48826000/0x00001000 0x00000093
arch_map_memory_region 0x4a000000/0x4a000000/0x00e00000 0x00000093
arch_map_memory_region 0xee000000/0x00000000/0x00800000 0x00000047
arch_map_memory_region 0x00000000/0x80000000/0x00001000 0x00000023
Created cell "AM57XX-EVM-timer8-demo"
Page pool usage after cell creation: mem 62/4073, remap 6/131072
Each region from the am57xx-evm-ti-app.c are mapped.
implemented am57xx_mmio_count_regions(), but I don't understand how I have to implement this
function.
Please can you explain what the function shall do?
This function returns the number of emulated MMIO regions a unit provides (number of
mmio_region_register calls). Yours does not have any so far, thus using the stub is fine.
Regarding the CPU boot. As I understand when the cpu_down() is called, CPU1 is not shutdown, but
go to omap_do_wfi(), where it is waiting for SMC. When we destroy a cell, CPU0 calls cpu_up(1) =>
omap4_boot_secondary() => arch_send_wakeup_ipi_mask() and CPU1 got awaken from wfi. As I
understand the am57xx_cell_exit() shall assign cpu_on_entry address of the omap_do_wfi(). Is that
correct?
I do not recall the details of the OMAP2 wakeup sequence yet. I'm starting to remember that the way
how the guest puts an offline core into shutdown state made it trickier to wake it up again.
We definitely need to understand two things before being able to emulate the
secondary core setup:
- Is it fine to permit direct access to the WakeupGen page, or should
we rather emulated that? Even if the only accessed register is fine,
we need to validate all addresses we expose.
- Is it safe to issue that smc on call 0x109, and what is that call?
Jan
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/f2210cae-3d9d-31e3-d587-6502c5863671%40ti.com.
For more options, visit https://groups.google.com/d/optout.
