Re: [Bug] Bring up Dom0 on Arm board

["蔡力刚" <cai_ligang@xxxxxxxxxxxxxxx>]

Hi,

>>>>>> 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)?
>>>> I also tried the Xen4.17.0, But failed to run xl command in dom0, the error like below:
>>>> root@RK3588:~# xl list
>>>> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve the maximum number of cpus
>>>> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve the maximum number of cpus
>>>> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve the maximum number of cpus
>>>> libxl: error: libxl_domain.c:334:libxl_list_domain: getting domain info list: Permission denied
>>>> libxl_list_domain failed.
>>>> In Rootfs, Xen tool version is 4.14.3,
>>>> I suspect that Xen tool and Xen hypervisor version conflict cause this problem, is that right?
>>>
>>> Part of the ABI used between the tools and the hypervisor is not stable.
>>> So you will need to rebuild the tools for every new major releases (for
>>> minor releases it is usually not necessary).
>>>
>>>> And although I used Xen4.17.0, The problems I mentioned are still there,
>>>> The Device tree generation failed error, the dev mali0 and mmcblk2 still failed to run.
>>>
>>> I will reply to this below.
>>>
>>>>>> 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.
>>>> It may cause by the interrupt interrupt-controller@fe600000,
>>>> set the interrupt IRQ_TYPE_LEVEL_HIGH first according to interrupt-controller@fe600000 ,
>>>> then irq_set_spi_type() try to set the interrupt IRQ_TYPE_EDGE_RISING according to
>>>> pcie2x1l1_intc: legacy-interrupt-controller, but return -1.
>>>> the gic: interrupt-controller@fe600000 like below:
>>>> gic: interrupt-controller@fe600000 {
>>>> compatible = "arm,gic-v3";
>>>> #interrupt-cells = <3>;
>>>> #address-cells = <2>;
>>>> #size-cells = <2>;
>>>> ranges;
>>>> interrupt-controller;
>>>> reg = <0x0 0xfe600000 0 0x10000>, /* GICD */
>>>> <0x0 0xfe680000 0 0x100000>; /* GICR */
>>>> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>>>> its0: msi-controller@fe640000 {
>>>> compatible = "arm,gic-v3-its";
>>>> msi-controller;
>>>> #msi-cells = <1>;
>>>> reg = <0x0 0xfe640000 0x0 0x20000>;
>>>> };
>>>> its1: msi-controller@fe660000 {
>>>> compatible = "arm,gic-v3-its";
>>>> msi-controller;
>>>> #msi-cells = <1>;
>>>> reg = <0x0 0xfe660000 0x0 0x20000>;
>>>> };
>>>> };
>>>
>>> I am a bit confused. Reading the binding, it looks like the GIC and PCI
>>> interrupt controller don't share an interrupt. Can you confirm the IRQ
>>> number you saw in Xen?
>> My mistake, my analysis was wrong.
>> I added the log in the platform_get_irq(), and get the log as below:
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 280, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 279, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 278, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 277, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 276, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 280, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 279, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 278, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 277, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000, irq: 276, irq.type: 4
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000/legacy-interrupt-controller, irq: 277, irq.type: 1
>> (XEN) d[IDLE]v0 -----fullname: /pcie@fe180000/legacy-interrupt-controller, irq: 277, irq.type: 1
>> (XEN) Unable to get irq 0 for /pcie@fe180000/legacy-interrupt-controller
>> (XEN) Device tree generation failed (-1).
>> The Node pcie@fe180000:
>> pcie2x1l1: pcie@fe180000 {
>>   compatible = "rockchip,rk3588-pcie", "snps,dw-pcie";
>>   #address-cells = <3>;
>>   #size-cells = <2>;
>>   bus-range = <0x30 0x3f>;
>>   clocks = <&cru ACLK_PCIE_1L1_MSTR>, <&cru ACLK_PCIE_1L1_SLV>,
>>   <&cru ACLK_PCIE_1L1_DBI>, <&cru PCLK_PCIE_1L1>,
>>   <&cru CLK_PCIE_AUX3>, <&cru CLK_PCIE1L1_PIPE>;
>>   clock-names = "aclk_mst", "aclk_slv",
>>   "aclk_dbi", "pclk",
>>   "aux", "pipe";
>>   device_type = "pci";
>>   interrupts = <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>,
>>   <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>,
>>   <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>,
>>   <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>,
>>   <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>;
>>   interrupt-names = "sys", "pmc", "msg", "legacy", "err";
>>   #interrupt-cells = <1>;
>>   interrupt-map-mask = <0 0 0 7>;
>>   interrupt-map = <0 0 0 1 &pcie2x1l1_intc 0>,
>>   <0 0 0 2 &pcie2x1l1_intc 1>,
>>   <0 0 0 3 &pcie2x1l1_intc 2>,
>>   <0 0 0 4 &pcie2x1l1_intc 3>;
>>   linux,pci-domain = <3>;
>>   num-ib-windows = <8>;
>>   num-ob-windows = <8>;
>>   num-viewport = <4>;
>>   max-link-speed = <2>;
>>   msi-map = <0x3000 &its0 0x3000 0x1000>;
>>   num-lanes = <1>;
>>   phys = <&combphy2_psu PHY_TYPE_PCIE>;
>>   phy-names = "pcie-phy";
>>   ranges = <0x00000800 0x0 0xf3000000 0x0 0xf3000000 0x0 0x100000
>>   0x81000000 0x0 0xf3100000 0x0 0xf3100000 0x0 0x100000
>>   0x82000000 0x0 0xf3200000 0x0 0xf3200000 0x0 0xe00000
>>   0xc3000000 0x9 0xc0000000 0x9 0xc0000000 0x0 0x40000000>;
>>   reg = <0x0 0xfe180000 0x0 0x10000>,
>>   <0xa 0x40c00000 0x0 0x400000>;
>>   reg-names = "pcie-apb", "pcie-dbi";
>>   resets = <&cru SRST_PCIE3_POWER_UP>, <&cru SRST_P_PCIE3>;
>>   reset-names = "pcie", "periph";
>>   rockchip,pipe-grf = <&php_grf>;
>>   status = "disabled";
>>   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 did not find IRQ number equal 277 in node pcie@fe180000, but found in node gpio@fd8a0000.
>> The Node gpio@fd8a0000:
>> gpio0: gpio@fd8a0000 {
>>   compatible = "rockchip,gpio-bank";
>>   reg = <0x0 0xfd8a0000 0x0 0x100>;
>>   interrupts = <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>;
>>   clocks = <&cru PCLK_GPIO0>, <&cru DBCLK_GPIO0>;
>>   gpio-controller;
>>   #gpio-cells = <2>;
>>   gpio-ranges = <&pinctrl 0 0 32>;
>>   interrupt-controller;
>>   #interrupt-cells = <2>;
>> };
>> I'm confused, can you explain it?
> 
> The irq type is used to configure GICD_ICFGR. Here the Device-Tree seems 
> to provide conflicting information (one interrupt is edge and the other 
> level).

> Where did you take your device-tree from?

I take the device-tree from rockchip offical source code.

>>>>>> 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?
>>>> 0xfe600000 is: gic: interrupt-controller@fe600000, full content above.
>>>
>>> Thanks. So the trap is expected because the GICD exposed to the domains
>>> is emulated.
>> So this is not an error? How can I investigate the console can't input problem?
> 
> See below.
> 
>>>> The UART is 8250, I set menuconfig in Debugging Options, the config like below:
>>>> [*] Early printk (Early printk via 8250 UART) --->
>>>> (0Xfeb50000) Early printk, physical base address of debug UART
>>>> (2) Early printk, left-shift to apply to the register offsets within the 8250 UART
>>>> I found that if I config the early printk in xen, I don't need the xen,dom0-bootargs=
>>>> "console=hvc0 earlycon=xen earlyprintk=xen" anymore, is that right?
>>>
>>> I don't know the exact configuration of the 8250. So I can't tell
>>> whether this is correct.
>>>
>>> That said, as you see some ouput, it would indicate that the
>>> configuration might be right.
>> If xen,dom0-bootargs contains the  "console=hvc0 earlycon=xen earlyprintk=xen"
>> The boot up log would print twitce in console.
> 
> I am not sure I understand your point.

 

The menuconfig setting is according to :

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD

After set this config and also set xen,dom0-bootargs="console=hvc0 earlycon=xen earlyprintk=xen",

Boot Dom0 with xen, the Dom0 kernel log print twice, like below:

[   60.783809] Booting Linux on physical CPU 0x0000000000 [0x412fd050]

...

[   60.783809] Booting Linux on physical CPU 0x0000000000 [0x412fd050]

...

>>> This could indicate that Xen is still using early printk and therefore
>>> it would not be able to read character. From your previous email, I see
>>> that you are requesting serial2. I am assuming this is an alias to the
>>> same UART as the one you configure for the early printk?
>>>
>>> Can you paste the content of the related Device-Tree node? Also, I would
>>> suggest to check if there are any errors in the Xen logs.
>> Serial2 is the alias of the UART, some Xen logs as below:
>> (XEN) adding DT alias:serial2: stem=serial id=2 node=/serial@feb50000
>> ...
>> (XEN) Looking for dtuart at "serial2", options ""
>> (XEN) Unable to initialize dtuart: -19
>> (XEN) Bad console= option 'dtuart'
>> The node /serial@feb50000:
>> uart2: serial@feb50000 {
>>   compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
>>   reg = <0x0 0xfeb50000 0x0 0x100>;
>>   interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
>>   clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
>>   clock-names = "baudclk", "apb_pclk";
>>   reg-shift = <2>;
>>   reg-io-width = <4>;
>>   dmas = <&dmac0 10>, <&dmac0 11>;
>>   pinctrl-names = "default";
>>   pinctrl-0 = <&uart2m1_xfer>;
>>   status = "disabled";
>>   };
>> There did an error when parse the xen command line, the command line I input is not correct ?
>> fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial2 dom0_mem=4G dom0_max_vcpus=4 vwfi=native sched=null"
> 
> I can't find the compatible rockchip,rk3588-uart in Linux drivers. Is 
> the UART meant to be similar to snps,dw-apb-uart with some quirks?

The uart2 with compatible "snps,dw-apb-uart",  is not a standard UART driver?

The UART node:

uart2: serial@feb50000 {
    compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
    reg = <0x0 0xfeb50000 0x0 0x100>;
    interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
    clock-names = "baudclk", "apb_pclk";
    reg-shift = <2>;
    reg-io-width = <4>;
    dmas = <&dmac0 10>, <&dmac0 11>;
    pinctrl-names = "default";
    pinctrl-0 = <&uart2m1_xfer>;
    status = "disabled";
};

Do you have any suggestions on how to investigate the console can't input problem?

About Mali and sdmmc drivers initialize problems, I will read Linux code to understand why 
the driver is not initializing Mali and sdmmc.
Thanks for your answer. 

Best regards
Cailigang