[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug] Bring up Dom0 on Arm board
Hi,
On 12/01/2023 02:11, 蔡力刚 wrote:
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.
Ok. I would suggest to speak with them then.
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]
...
IIRC, this is expected as you specify a boot console and a runtime console.
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.
Cheers,
--
Julien Grall
|
