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.
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
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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/dae8aa98-f7cd-d25f-b8d7-cb0006d08ff0%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
