Re: [Bug] Bring up Dom0 on Arm board

[Julien Grall <julien@xxxxxxx>]

(+ Bertrand and Stefano)

Hello,

On 06/01/2023 06:41, 蔡力刚 wrote:
>   I try to run Xen on a Rockchip RK3588 board and encountered some problems.
>   The command I used:
>   load mmc 1:1 0xC400000 dom0-Image;
>   load mmc 1:1 0x47C00000 xen4.14.5;
We have made a lot of improvement since Xen 4.14. This is also out of 
support since January 2022. It is still security supported but not for 
long (July 2023).
Would you be able to try Xen 4.17 (this was released a month ago)?

>   load mmc 1:1 0x47E00000 rk3588-evb7-lp4-v10-linux.dtb
>   fdt addr 0x47E00000
>   fdt resize 1024
>   fdt set /chosen \#address-cells <0x2>
>   fdt set /chosen \#size-cells <0x2>
>   fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial2 dom0_mem=4G 
> dom0_max_vcpus=4 vwfi=native sched=null"
>   fdt mknod /chosen dom0
>   fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module" 
> "multiboot,module"
>   fdt set /chosen/dom0 reg <0x0 0xC400000 0x0 0x2000000>
>   fdt set /chosen xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen 
> clk_ignore_unused root=/dev/mmcblk0p6 rw rootwait"
>   setenv fdt_high 0xffffffffffffffff
>   booti 0x47C00000 - 0x47E00000
>   1. Device tree generation failed errors.
>   when I used the default dtb to run xen, Painc occured on xen.
>   log:
>   (XEN) Unable to get irq 0 for /pcie@fe180000/legacy-interrupt-controller
>   (XEN) Device tree generation failed (-1).
>   (XEN)
>   (XEN) ****************************************
>   (XEN) Panic on CPU 0:
>   (XEN) Could not set up DOM0 guest OS
>   (XEN) ****************************************
>   (XEN)
>   (XEN) Reboot in five seconds...
>   the dtb:
>   pcie2x1l1_intc: legacy-interrupt-controller {
>   interrupt-controller;
>   #address-cells = <0>;
>   #interrupt-cells = <1>;
>   interrupt-parent = <&gic>;
>   interrupts = <GIC_SPI 245 IRQ_TYPE_EDGE_RISING>;
>   }; >   I modified the legacy-interrupt-controller of interrupts from 
IRQ_TYPE_EDGE_RISING to IRQ_TYPE_LEVEL_HIGH.

Based on this change, I would say the call to irq_set_spi_type() (called 
from platform_get_irq()) will return -1. The function will validate the 
type and will throw an error if there is a problem.
Can you confirm whether the interrupt is shared with another device? Is 
it described twice in the DT?
If yes to one of the two questions. Is the type different?

You could also print the old and new type in irq_set_spi_type() to 
confirm the difference.
>   And bring up Xen successed, through I not sure the modification is correct.
>   2. After boot up, I tried to input in the console but failed.
>   I added some log in api do_trap_guest_sync, try_handle_mmio as below:
>   In function do_trap_guest_sync:
>   static unsigned long ec = 0;
>   if(hsr.ec != ec)
>   {
>   gprintk(XENLOG_INFO, "do_trap_guest_sync hsr.ec=%x \n", hsr.ec);
>   ec = hsr.ec;
>   }
>   In function try_handle_mmio:
>   gprintk(XENLOG_INFO, "handler->addr: %lx\n", handler->addr);
>   Then everytime I type enter in the console, console show the log below:
>   (XEN) d0v0 do_trap_guest_sync hsr.ec=24
>   (XEN) d0v0 handler->addr: fe600000
>   (XEN) d0v0 handler->addr: fe600000
>   (XEN) d0v0 do_trap_guest_sync hsr.ec=18
>   Is that something wrong with the GIC interrupt ?
A few questions:
  * What is the corresponding device in the host physical address space 
for 0xfe600000?
  * What is the UART on your board? Is there any specific workaround 
required?
>   3. In Dom0, the dev mali0 and mmcblk2 is missing, and weston running failed.
Do you have any log in the kernel indicating why the mali and/or the mmc 
driver didn't load?
Also, can you confirm that the same kernel image works without Xen?

>   While I can't input in the console, I tried use console via ssh.
>   In the /dev list, I can't find mali0 and mmcblk2(sdcard),
>   In u-boot mode, mmcblk2 can be recognized, I loaded dom0-Image, xen, and dtb 
> from mmcblk2.
>   While booting without xen, the mali0 and mmcblk2 can be recognized,
>   Is that something wrong with xen while Initialize the driver?
>   4. xl command can not executed, and seems to be suspended.
xl requires the initscript (or systemd service) to be executed. The fact 
it hangs usually means this didn't happen.
Just in case, can you also check that your kernel has been build with 
Xen support?
>   Type the xl list or xl create command via ssh console, the command not 
> responding until type ctrl+c.
>   Type xl info command succeed, and show some info in the console.
Cheers,

--
Julien Grall