Hi, On 7/6/19 12:56 PM, Julien Grall wrote: > Hi Denis, > > On 7/6/19 11:19 AM, Denis Obrezkov wrote: >> On 7/5/19 11:47 PM, Denis Obrezkov wrote: >>> So, >>> >>> >>>> I am going to try to expose the whole crossbar to the dom0 by >>>> mapping it >>>> into dom0 and after that to unmap it and restrict the use of the >>>> control >>>> register via register_mmio_handler. Don't know whether this will work. >>>> >>> >>> I tried and write now now visible progress: >>> --- a/xen/arch/arm/platforms/omap5.c >>> +++ b/xen/arch/arm/platforms/omap5.c >>> @@ -23,6 +23,8 @@ >>> #include <xen/vmap.h> >>> #include <asm/io.h> >>> >>> +#define OMAP5_CTRL_CORE_MPU_IRQ 0x00000A48 >>> + >>> void omap5_init_secondary(void); >>> asm ( >>> ".text \n\t" >>> @@ -124,6 +126,8 @@ static int omap5_specific_mapping(struct domain *d) >>> map_mmio_regions(d, gaddr_to_gfn(OMAP5_SRAM_PA), 32, >>> maddr_to_mfn(OMAP5_SRAM_PA)); >>> >>> + map_mmio_regions(d, gaddr_to_gfn(OMAP5_CTRL_CORE_MPU_IRQ), 300, >>> + maddr_to_mfn(OMAP5_CTRL_CORE_MPU_IRQ)); >>> return 0; >>> } >>> >>> >> I can see there is a mistake in OMAP5_CTRL_CORE_MPU_IRQ address, so, I >> tried the right address for the MPU crossbar cotrol registers and I also >> tried to expose the whole control CTRL register but unsurprisingly >> haven't succeeded. >> > > The crossbar is described in the Device-Tree, Xen should already map the > crossbar in Dom0. > > I wasn't able to find any clue in the log (from your first e-mail) that > the crossbar is not mapped to Dom0. Actually, per the log, the mapping > should have been done: > > (XEN) handle /ocp/crossbar@4a002a48 > (XEN) dt_irq_number: dev=/ocp/crossbar@4a002a48 > (XEN) /ocp/crossbar@4a002a48 passthrough = 1 nirq = 0 naddr = 1 > (XEN) DT: ** translation for device /ocp/crossbar@4a002a48 ** > (XEN) DT: bus is default (na=1, ns=1) on /ocp > (XEN) DT: translating address:<3> 4a002a48<3> > (XEN) DT: parent bus is default (na=2, ns=2) on / > (XEN) DT: walking ranges... > (XEN) DT: default map, cp=0, s=c0000000, da=4a002a48 > (XEN) DT: parent translation for:<3> 00000000<3> 00000000<3> > (XEN) DT: with offset: 4a002a48 > (XEN) DT: one level translation:<3> 00000000<3> 4a002a48<3> > (XEN) DT: reached root node > (XEN) - MMIO: 004a002a48 - 004a002b78 P2MType=5 > (XEN) handle /ocp/dss@58000000 > (XEN) dt_irq_number: dev=/ocp/dss@58000000 > (XEN) /ocp/dss@58000000 passthrough = 1 nirq = 0 naddr = 5 > (XEN) DT: ** translation for device /ocp/dss@58000000 ** > > Looking towards the end of the log: > > (XEN) traps.c:1998:d0v0 HSR=0x93800007 pc=0xc012bd5c gva=0xfa243404 > gpa=0x00000048243404 > > This means Linux is trying to access the address 0x00000048243404 which > was not mapped in the stage-2. This does not seem to belong to the > crossbar but PRCM_MPU. The function omap5_specific_mapping() should do > the mapping for you. Is it called for your platform? > > On a side note, I am not convinced exposing directly (i.e without > emulation) the crossbar to dom0 will help us. Per the log, the UART will > also use the crossbar: > > (XEN) omap-uart: Unable to retrieve the IRQ > (XEN) Unable to initialize dtuart: -22 > (XEN) Bad console= option 'dtuart' > > So Xen needs to be able to control it. To make things easier, it would > probably better to first focus on getting a small crossbar driver in Xen > and verify you can use the UART in Xen (such as receiving characters). > > Cheers, > sorry for confusing you, I share a bit outdated log but only to show the output of xen about device tree. We already overcome that error about omap specific mapping (applied one of Iain's patches).
I tried to replicate the tegra version of legacy irq controller support you mentioned in the irq: https://github.com/embeddedden/xen/commit/180af7ffc8abbbc3ed41dcbc9abc6e8b12daa57a Now, I have an error: (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading d0 kernel from boot module @ 0000000082000000 (XEN) Loading ramdisk from boot module @ 0000000084000000 (XEN) Allocating 1:1 mappings totalling 512MB for dom0: (XEN) BANK[0] 0x000000a0000000-0x000000c0000000 (512MB) (XEN) Grant table range: 0x00000085000000-0x00000085040000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from 0000000082000000 to 00000000a7c00000-00000000a7fdea20 (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Unable to copy the kernel in the hwdom memory (XEN) **************************************** Probably, I messed something with remapping. -- Regards, Denis Obrezkov _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
