On 2016-10-10 18:38, Dan Zach wrote:
> On Monday, 10 October 2016 09:57:20 UTC+3, Dan Zach  wrote:
>> On Monday, 10 October 2016 09:47:51 UTC+3, Jan Kiszka  wrote:
>>> On 2016-10-10 08:22, Dan Zach wrote:
>>>> On Sunday, 9 October 2016 20:34:59 UTC+3, Jan Kiszka  wrote:
>>>>> On 2016-10-09 19:29, Dan Zach wrote:
>>>>>> On Sunday, 9 October 2016 20:22:28 UTC+3, Jan Kiszka  wrote:
>>>>>>> On 2016-10-09 19:18, Dan Zach wrote:
>>>>>>>> Thanks, Jan.
>>>>>>>>
>>>>>>>> With u-boot 2016.07 and commenting out the "/cpus" check, at
>>>>>>>> arch/arm/cpu/armv7/virt-dt.c
>>>>>>>
>>>>>>> Where is your device tree from that causes this? Taken from a recent
>>>>>>> kernel or from that old one?
>>>>>>>
>>>>>>>> I get the following
>>>>>>>>
>>>>>>>> [    3.096285] CPU3: failed to come online
>>>>>>>> [    3.096360] Brought up 1 CPUs
>>>>>>>> [    3.096375] SMP: Total of 1 processors activated.
>>>>>>>> [    3.096391] CPU: All CPU(s) started in HYP mode.
>>>>>>>> [    3.096407] CPU: Virtualization extensions available.
>>>>>>>>
>>>>>>>>
>>>>>>>> CPU0 comes up at HYP, but other CPUs are dead.
>>>>>>>>
>>>>>>>> - is it because incompatibility between kernel 3.10.40 and PSCI?
>>>>>>>> - Is there way to hack PSCI source to make it work?
>>>>>>>
>>>>>>> Are CONFIG_ARM_PSCI and CONFIG_ARM_PSCI_FW set in your 3.10?
>>>>>>>
>>>>>>> Jan
>>>>>>
>>>>>> - This is the original L4T device tree. It just doesnt have /cpus entry
>>>>>> - CONFIG_ARM_PSCI is not set and CONFIG_ARM_PSCI_FW doesn't exist
>>>>>>
>>>>>
>>>>> CONFIG_ARM_PSCI must be turned on, CONFIG_ARM_PSCI_FW was indeed
>>>>> introduced only in 4.3.
>>>>>
>>>>> Jan
>>>>
>>>> With CONFIG_ARM_PSCI, the kernel will boot *only* if bootm_boot_mode is 
>>>> set to nonsec, which shows it took some effect at least.
>>>> Unfortunately the result is the same:
>>>> CPU0 - HYP mode
>>>> CPUs 1,2,3 - failed to come online...
>>>>
>>>> 1. My assumption is - if CPU0 could boot to HYP, there is no fundamental 
>>>> barrier for other CPUs to do so, makes sense? Appreciate any hint how to 
>>>> dig it further
>>>
>>> HYP-wise, no. But the challenge is now getting PSCI / CPU powering to work.
>>>
>>>>
>>>> 2. Whet it boots all the way to graphical IDE, it gets stuck , can it be 
>>>> because CPU_IDLE is still on?
>>>
>>> Try it out.
>>>
>>> But, before possibly wasting too much time on this path: Also try to
>>> reach out to the NVIDIA folks doing the TK1 and TX1 upstreaming. Maybe
>>> they can tell you more about if you actually need that old kernel and/or
>>> why it is not working in combination with virtualization.
>>>
>>> Jan
>>
>> - My friend checked on NVIDIA DevTalk forum, they said not to hold our 
>> breath for kernel update to 4.x
>> - Is there any POC @NVIDIA you can point us to, please?

Back then, I was in contact with Tom Warren, Thierry Reding and Stephen
Warren.

>> - If it comes to this, the u-boot files 
>> :./arch/arm/mach-tegra/psci.S;./arch/arm/cpu/armv7/psci.S; are the actual 
>> implementation of the secure monitor that bootstraps cores 1-3?
> 
> Jan,
> I will try to follow the logic as below:
> As I said, I have kernel 4.6 booting fine in HYP. If I trace down the smc 
> calls it does:
> [    0.101384]  psci_boot_secondary: cpu=1
> [    0.101412]  __invoke_psci_fn_smc: Function smc  95c1ba60
> [    0.101435]  __invoke_psci_fn_smc: Function arg0 1
> [    0.101457]  __invoke_psci_fn_smc: Function arg1 802013e0
> [    0.101479]  __invoke_psci_fn_smc: Function arg2 0
> 
> The secure monitor is exactly the same, so if I make sure my 3.10 kernel does 
> identical SMC calls - it should work...
> 
> Sounds reasonable?

May work - at least if the difference in 3.10 is that simple. You may
still study the related commits on PSCI files since then to find out the
differences.

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 jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to