Hello, I am a Computer Engineering student, currently working on building a toolchain to have Xen running on ARM embedded platforms.
I have an Arndale Octa Board (Samsung Exynos 5420 MPSoC) and I am trying to run Xen 4.5 on it. I followed all the steps written in the Wiki ( http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale) as guideline and the following discussions about the Octaboard: [1] - http://xen.markmail.org/thread/3shxyiipnq2ewj2k [2] - http://markmail.org/thread/dhiknm25xfbsrlo6 I have successfully enabled the early_printk feature of Xen for the Exynos 5420 [1], so that I could have the following debug messages on Xen booting: ---------------------------------------------------- Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen must be entered in NS Hyp mode - - Boot failed - ---------------------------------------------------- The problem is that Xen does not match the correct CPU mode for its boot. For this reason I started working on the booting process, trying to deeply understand how it works for this board. The board utilizes a secure multi stages booting process (chain of trust), having 4 different boot levels (BL#): - BL0 runs on iROM, vendor fused. - BL1 runs on iRAM, vendor provided. - BL2 runs on memory, signed. - BL3 is U-Boot and the only one working seems to be a signed 2012.07 version. As far as I know, the booting processor loads Xen while in Non-Secure state and Supervisor mode (NS SVC), failing its boot and generating the above debug messages. To bring the processor in Hypervisor mode (NS HYP), I patched U-Boot by adding all the virtualization modules needed by the ARMv7 U-Boot subtree (u-boot/arch/arm/cpu/armv7) ( http://lists.denx.de/pipermail/u-boot/2013-September/163019.html). The patch executes two functions at the end of the boot_prep_linux( … ) function in bootm.c file (../arch/arm/lib): - armv7_switch_nonsec(), which brings the processor from secure to non-secure state. - armv7_switch_hyp(), which brings the processor from a non-secure mode to the HYP mode. However, CPU does not switch properly to HYP mode as the execution hangs. The problem is that the processor is already in NS SVC mode when the armv7_switch_nonsec() is invoked: the assembly routine _nonsec_init in nonsec_virt.S file fails when it tries to write the MVBAR register, only accessible from a secure mode. Unfortunately the function (or some of its instructions) cannot be simply bypassed, as it holds all the set-up needed to be done in the secure state before actually switching to HYP mode: it sets up vector table and registers needed to enable the hypervisor call (hvc #0) instruction (else, it would hang just as in [2]). Following the discussion ( http://lists.denx.de/pipermail/u-boot/2013-April/150718.html), I patched the start.S file, where the switch to NS SVC mode seems to happen. The patch just tests if the processor is already in HYP mode and does not switch back to SVC mode. Unfortunately neither this attempt was successful, driving me to think that the problem is even before the U-Boot (BL3) stage. The solution would be having the BL2 to set the processor in HYP mode and deliver it to U-Boot already in that mode, so that Xen would boot easily. Changing the BL2 requires the signature of the manufacturer, as it happens for the Odroid-XU3 board (Exynos 5422) ( http://forum.odroid.com/viewtopic.php?f=98&t=6147) but Unfortunately acting on BL2 is not possible for the Arndale Octaboard, as there is no support from the Insignal. Is there a solution to overcome these problems, or anyone still working on it? When Xen 4.5 was released I read in the notes that support for the Exynos 5420 MPSoC was added ( http://wiki.xenproject.org/wiki/Xen_Project_4.5_Feature_List#ARM_Hypervisor-Specific_Updates). Which is the platform where it was implemented? Is it open or is there private software just like in the Arndale Octaboard case? Downline of everything, this experience was needed to understand that I cannot use boards equipped with private software for my work, as overcoming it would be “hacking” more than building a good toolchain. As my goal is to have the full control over the hardware I am going to use, I cannot have private stages that requires intervention of a third part help. Could you suggest me some boards based on ARMv7 (A7 and/or A15) or ARMv8 fully controllable and on which Xen 4.5 works? Any help would be greatly appreciated. Regards, F.C.
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
