|
Hello all.
Sorry for the top-posting.
> I have also CCed Oleksandr, who IIRC worked on a platform using the same SoC
> (DRA7) in the past.
Yes. I worked with DRA7 sometime ago.
Unfortunately, I don't remember this platform in details, but, there is a Wiki page describing how to run Xen on this platform which *may* help:
Please note, it is related to old Xen and TI GLSDK versions.
Regarding secondary CPU boot.
The special monitor API is used to enable Hyp mode. U-Boot brings secondary CPU up, which, it turn, switches to Hyp mode and enters WFE until Xen wakes it up.
Take a look at the following patch:
OLEKSANDR TYSHCHENKO
Lead Software Engineer
Office: +380
44 390 5457 x 66821 Cell: +380
93 661 6198 Email: oleksandr_tyshchenko@xxxxxxxx
Kyiv, Ukraine (GMT+3) epam.com
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) to which it is addressed and contains information that is legally privileged and confidential. If you are not the intended recipient, or the person responsible for delivering the
message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. All unintended recipients are obliged to delete this message and destroy any printed copies.
From: Julien Grall <julien.grall@xxxxxxx>
Sent: Monday, June 17, 2019 13:09
To: Iain Hunter; Denis Obrezkov
Cc: xen-users@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini; Hunyue Yau; Andre Przywara; Oleksandr Tyshchenko
Subject: Re: Starting to port xen on beagleboard-x15 (GSoC 2019 project)
(+ Andre and Oleksandr)
Hi Denis & lain,
I have discussed with Andre Przywara (in CC) who did some work around
virtualization support in U-boot.
I have also CCed Oleksandr, who IIRC worked on a platform using the same SoC
(DRA7) in the past.
On 17/06/2019 10:03, Iain Hunter wrote:
> I can't remember the history of that patch. What I couldn't figure out
> today was what its effect would be. I could not find any u-boot code
> that used the CONFIG_XXX values added in the patch.
> So, best ignore it.
lain, did you manage to get SMP working back then?
>
> Do you have an emulator available yet?
> If so the easiest way I found to debug this type of issue was to:
>
> 1. Insert an infinite loop just before where I thought I had a problem
> - in a .S file with
> loopHere: b loopHere
>
> - in a C file with
>
> volatile unsigned char loopHere=1;
>
> function()
> { ....
> while(loopHere);
> ....
> }
>
> 2 boot the board
> 3 connect the emulator to the target and then load the symbols for the
> executable (u-boot.img or xen)
> 4 in the emulator set the PC to first instruction after the loop and
> then step over the code. Then you can check the register values to see
> if hypevisor is enabled etc
Both CPUs are Cortex-A15, hence virtualization should be supported. It is a
matter of correctly initializing the secondary CPU.
The platform is not using PSCI but instead a custom SMP bring-up (see
omap5_smp_init in Xen). From my understanding the ROM should bring-up the
secondary CPU to hyp mode if the boot CPU is in hyp mode.
It would be interesting to try Linux on baremetal and see if it brings-up the
secondary CPUs in hyp mode. If it does, then it seems that the problem lies in
Xen. Otherwise it would be in the ROM.
On a side note, I would not spend too much time looking at the SMP now. Instead
you can disable the secondary CPUs.
Cheers,
--
Julien Grall
|
