Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0

[Julien Grall <julien.grall@xxxxxxx>]

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,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel