Re: Xen 4.14.1 on RPI4: device tree generation failed

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Sun, Jan 31, 2021 at 9:43 PM Tamas K Lengyel
<tamas.k.lengyel@xxxxxxxxx> wrote:
>
> On Sun, Jan 31, 2021 at 8:59 PM Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
> >
> > On Sun, Jan 31, 2021 at 06:50:36PM -0500, Tamas K Lengyel wrote:
> > > On Sun, Jan 31, 2021 at 6:33 PM Elliott Mitchell <ehem+undef@xxxxxxx> 
> > > wrote:
> > > >
> > > > On Sun, Jan 31, 2021 at 02:06:17PM -0500, Tamas K Lengyel wrote:
> > > > > (XEN) Unable to retrieve address 0 for 
> > > > > /scb/pcie@7d500000/pci@1,0/usb@1,0
> > > > > (XEN) Device tree generation failed (-22).
> > > >
> > > > > Does anyone have an idea what might be going wrong here? I tried
> > > > > building the dtb without using the dtb overlay but it didn't seem to
> > > > > do anything.
> > > >
> > > > If you go to line 1412 of the file xen/arch/arm/domain_build.c and
> > > > replace the "return res;" with "continue;" that will bypass the issue.
> > > > The 3 people I'm copying on this message though may wish to ask 
> > > > questions
> > > > about the state of your build tree.
> > >
> > > I'll try that but it's a pretty hacky work-around ;)
> >
> > Actually no, it simply causes Xen to ignore these entries.  The patch
> > I've got ready to submit to this list also adjusts the error message to
> > avoid misinterpretation, but does pretty well exactly this.
> >
> > My only concern is whether it should ignore the entries only for Domain 0
> > or should always ignore them.
> >
> >
> > > > Presently the rpixen script is grabbing the RPF's 4.19 branch, dates
> > > > point to that last being touched last year.  Their tree is at
> > > > cc39f1c9f82f6fe5a437836811d906c709e0661c.
> > >
> > > I've moved the Linux branch up to 5.10 because there had been a fair
> > > amount of work that went into fixing Xen on RPI4, which got merged
> > > into 5.9 and I would like to be able to build upstream everything
> > > without the custom patches coming with the rpixen script repo.
> >
> > Please keep track of where your kernel source is checked out at since
> > there was a desire to figure out what was going on with the device-trees.
> >
> >
> > Including "console=hvc0 console=AMA0 console=ttyS0 console=tty0" in the
> > kernel command-line should ensure you get output from the kernel if it
> > manages to start (yes, Linux does support having multiple consoles at the
> > same time).
>
> No output from dom0 received even with the added console options
> (+earlyprintk=xen). The kernel build was from rpi-5.10.y
> c9226080e513181ffb3909a905e9c23b8a6e8f62. I'll check if it still boots
> with 4.19 next.

With rpi-4.19.y kernel and dtbs
(cc39f1c9f82f6fe5a437836811d906c709e0661c) Xen boots fine and the
previous error is not present. I get the boot log on the serial with
just console=hvc0 from dom0 but the kernel ends up in a panic down the
line:

(XEN) traps.c:1983:d0v0 HSR=0x93860046 pc=0xffffff80085ac97c
gva=0xffffff800b096000 gpa=0x0000003e330000
[    1.242863] Unhandled fault at 0xffffff800b096000
[    1.242871] Mem abort info:
[    1.242879]   ESR = 0x96000000
[    1.242893]   Exception class = DABT (current EL), IL = 32 bits
[    1.242922]   SET = 0, FnV = 0
[    1.242928]   EA = 0, S1PTW = 0
[    1.242934] Data abort info:
[    1.242941]   ISV = 0, ISS = 0x00000000
[    1.242948]   CM = 0, WnR = 0
[    1.242958] swapper pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
[    1.242965] [ffffff800b096000] pgd=0000000033ffe003,
pud=0000000033ffe003, pmd=000000003230a003, pte=006800003e33070f
[    1.242989] Internal error: ttbr address size fault: 96000000 [#1]
PREEMPT SMP
[    1.242995] Modules linked in:
[    1.243005] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
[    1.243014] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.127-v8+ #1
[    1.243019] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
[    1.243026] pstate: 20000005 (nzCv daif -PAN -UAO)
[    1.243044] pc : cfb_imageblit+0x58c/0x820
[    1.243054] lr : bcm2708_fb_imageblit+0x2c/0x40
[    1.243059] sp : ffffff800802b4e0
[    1.243063] x29: ffffff800802b4e0 x28: 00000000ffffffff
[    1.243073] x27: 0000000000000010 x26: ffffffc03212c000
[    1.243081] x25: 0000000000000020 x24: ffffffc0322c7d80
[    1.243088] x23: 0000000000000008 x22: ffffffc03212a118
[    1.243095] x21: 0000000000000000 x20: ffffff800b096000
[    1.243102] x19: 0000000000000000 x18: 00000000fffffffc
[    1.243109] x17: 0000000000000000 x16: ffffff800b096000
[    1.243116] x15: 0000000000000001 x14: 0000000000001e00
[    1.243124] x13: 0000000000000010 x12: 0000000000000000
[    1.243131] x11: 0000000000000020 x10: 0000000000000001
[    1.243138] x9 : 0000000000000008 x8 : ffffff800b096020
[    1.243145] x7 : ffffffc03212c001 x6 : 0000000000000000
[    1.243152] x5 : ffffff80089e2f78 x4 : 0000000000000000
[    1.243159] x3 : ffffff800b096000 x2 : ffffffc03212c000
[    1.243166] x1 : 0000000000000000 x0 : 0000000000000000
[    1.243173] Call trace:
[    1.243182]  cfb_imageblit+0x58c/0x820
[    1.243190]  bcm2708_fb_imageblit+0x2c/0x40
[    1.243197]  soft_cursor+0x16c/0x200
[    1.243204]  bit_cursor+0x30c/0x53c
[    1.243211]  fbcon_cursor+0x13c/0x1a0
[    1.243220]  hide_cursor+0x44/0xb0
[    1.243228]  redraw_screen+0x218/0x28c
[    1.243234]  fbcon_prepare_logo+0x380/0x3ec
[    1.243241]  fbcon_init+0x364/0x550
[    1.243248]  visual_init+0xbc/0x110
[    1.243256]  do_bind_con_driver.isra.0+0x1c4/0x3a0
[    1.243264]  do_take_over_console+0x148/0x204
[    1.243270]  do_fbcon_takeover+0x7c/0xe4
[    1.243277]  fbcon_event_notify+0x6d4/0x850
[    1.243288]  blocking_notifier_call_chain+0x90/0xc0
[    1.243297]  fb_notifier_call_chain+0x34/0x40
[    1.243303]  register_framebuffer+0x21c/0x300
[    1.243311]  bcm2708_fb_probe+0x340/0x770
[    1.243319]  platform_drv_probe+0x5c/0xb0
[    1.243325]  really_probe+0x290/0x3a4
[    1.243331]  driver_probe_device+0x60/0xf4
[    1.243337]  __driver_attach+0x118/0x13c
[    1.243347]  bus_for_each_dev+0x84/0xe0
[    1.243352]  driver_attach+0x34/0x40
[    1.243358]  bus_add_driver+0x1a8/0x21c
[    1.243364]  driver_register+0x7c/0x124
[    1.243371]  __platform_driver_register+0x58/0x64
[    1.243382]  bcm2708_fb_init+0x24/0x2c
[    1.243390]  do_one_initcall+0x54/0x248
[    1.243399]  kernel_init_freeable+0x2e4/0x384
[    1.243408]  kernel_init+0x1c/0x118
[    1.243415]  ret_from_fork+0x10/0x18
[    1.243425] Code: 8b0608a6 b94050c6 0a060026 4a0400c6 (b9000066)
[    1.243437] ---[ end trace b74230fc2252e944 ]---
[    1.243452] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[    1.243452]
[    1.243464] SMP: stopping secondary CPUs
[    1.243512] Kernel Offset: disabled
[    1.243519] CPU features: 0x0,61006000
[    1.243523] Memory Limit: none
[    1.590409] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b
[    1.590409]  ]---

This seems to have been caused by a monitor being attached to the HDMI
port, with HDMI unplugged dom0 boots OK.

Tamas