Re: [Bug] Bring up Dom0 on Arm board

[Julien Grall <julien@xxxxxxx>]

Hi,

On 13/01/2023 01:24, 蔡力刚 wrote:
> > > > > > 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?
> > snps,dw-apb-uart is based on the 8250 but there are some quirks. We do
> > have support in Xen, but the fact you have an extra compatible makes me
> > wonder whether there are extra setup for your UART.
> >
> > > 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?
> > I would suggest to look at the Linux driver and check if there are any
> > different with the Xen one.
> I see, I will check UART driver.
> About the mali and sdmmc drivers problem, I compare the log between boot with 
> xen and boot without xen.
> And found an error log as below:
> [ 65.517345] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
> (XEN) d0v2 Unhandled SMC/HVC: 0x82000010
> [ 66.559382] arm-scmi firmware:scmi: unable to communicate with SCMI
> [ 66.559516] arm-scmi: probe of firmware:scmi failed with error -95
> It seems SCMI driver probe failed.
> So I did an experiment, disable SCMI driver and rebuild the Linux kernel,
> boot up in normal way without xen, and reproduces the problem that mali and 
> sdmmc did not bring up.
> It looks like a high probability SCMI cause the problem.
> I read the Linux code and targeting located the error -95,
> It seems SCMI probe failed cause by SMCCC not supported, code as below:
> static int smc_send_message(struct scmi_chan_info *cinfo,
>   struct scmi_xfer *xfer)
> {
>   struct scmi_smc *scmi_info = cinfo->transport_info;
>   struct arm_smccc_res res;
>   mutex_lock(&scmi_info->shmem_lock);
>   shmem_tx_prepare(scmi_info->shmem, xfer);
>   if (scmi_info->irq)
>   reinit_completion(&scmi_info->tx_complete);
>   arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
>   if (scmi_info->irq)
>   wait_for_completion(&scmi_info->tx_complete);
>   scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
>   mutex_unlock(&scmi_info->shmem_lock);
>   /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */
>   if (res.a0)
>   return -EOPNOTSUPP;
>   return 0;
> }
> #define EOPNOTSUPP 95 /* Operation not supported on transport endpoint */
> I also check the code where Unhandled SMC/HVC print in xen,
> and found the log cause by unhandled SMCCC call in function 
> vsmccc_handle_call().
> Could it be xen unhandle SMCCC call cause SCMI driver probe failed ?
Yes. The domain would need to talk to the host SCMI. This is not yet 
supported because Xen doesn't provide a mediator (this is necessary to 
ensure the safety of the call).
If you are *only* looking to use the Mali driver in dom0. So you could 
add some code in Xen to forward simply forward the request to the host 
and check if it helps you.
Cheers,

--
Julien Grall