Re: [Xen-devel] xen on beagleboard-x15: fails to access PRCM MPU register

[Iain Hunter <drhunter95@xxxxxxxxx>]

Stefano, Denis,

I achieved that with patch
patches/xen/0003-add-PRCM_MPU-to-memory-translation-for-AM572x.patch.
This just adds
 .specific_mapping=omap5_specific_mapping
to DRA7 platform.

Iain

On Fri, 28 Jun 2019 at 01:33, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
>
> Writing here a summary of the follow-up discussion on IRC.
>
> This is due to a magic memory region, not described in the device tree,
> being accessed by Linux. The memory region is 0x48243400 - 0x48243400+512.
>
> To fix problems like this one, we have the platform specific files in
> xen: see the files under xen/arch/arm/platforms/. Specifically, omap5.c
> might be a good model for what we need. Look at the
> omap5_specific_mapping function, which does exactly what the name
> suggests: it maps special MMIO regions into the guest.
>
>  /* Additional mappings for dom0 (not in the DTS) */
>  static int omap5_specific_mapping(struct domain *d)
>  {
>      /* Map the PRM module */
>      map_mmio_regions(d, gaddr_to_gfn(OMAP5_PRM_BASE), 2,
>                       maddr_to_mfn(OMAP5_PRM_BASE));
>
>      /* Map the PRM_MPU */
>      map_mmio_regions(d, gaddr_to_gfn(OMAP5_PRCM_MPU_BASE), 1,
>                       maddr_to_mfn(OMAP5_PRCM_MPU_BASE));
>
>      /* Map the Wakeup Gen */
>      map_mmio_regions(d, gaddr_to_gfn(OMAP5_WKUPGEN_BASE), 1,
>                       maddr_to_mfn(OMAP5_WKUPGEN_BASE));
>
>      /* Map the on-chip SRAM */
>      map_mmio_regions(d, gaddr_to_gfn(OMAP5_SRAM_PA), 32,
>                       maddr_to_mfn(OMAP5_SRAM_PA));
>
>      return 0;
>  }
>
> We need something similar for 0x48243400 - 0x48243400+512 on
> Beagleboard.
>
>
> On Thu, 27 Jun 2019, Denis Obrezkov wrote:
> > CC'ed other GSoC mentors
> >
> > On 6/27/19 9:52 PM, Denis Obrezkov wrote:
> > > Hello all,
> > >
> > > I have a failure when I am trying to boot Linux with Xen on bb-x15, here
> > > is the log:
> > > https://pastebin.com/BBAFPkVU
> > >
> > > and, as Julien (cc'ed) suggested here is the DT debug information for xen:
> > > https://drive.google.com/open?id=15YTsCKYUTbG2i-siWezJXKWuG0H1VfQz
> > >
> > > So, what I was able to figure out:
> > > In omap4_prminst_read_inst_reg it tries to read from _prm_bases[part].va
> > > (arch/arm/mach-omap2/prminst44xx.c).
> > > _prm_bases[part].va has a value of prm_base or prcm_mpu_base depending
> > > on part value(arch/arm/mach-omap2/prminst44xx.c:44)
> > > Failure happens when _prm_bases[OMAP4430_PRCM_MPU_PARTITION] is read.
> > > It's value set up in arch/arm/mach-omap2/prcm_mpu44xx.c:54.
> > > The installed value is obtained with OMAP_L4_IO_ADDRESS macro
> > > (mach_omap2/io.c:667). Here is its definition 
> > > (arch/arm/mach_omap2/iomap.h):
> > > #define OMAP2_L4_IO_OFFSET  0xb2000000
> > > #define OMAP2_L4_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_L4_IO_OFFSET) /* L4 */
> > >
> > > and IOMEM (arch/arm/include/asm/io.h):
> > > #define IOMEM(x)    ((void __force __iomem *)(x))
> > >
> > > I don't understand what is happening and how to overcome it.
> > >
> >
> > --
> > Regards, Denis Obrezkov
> >
> >

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