[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen on beagleboard-x15: fails to access PRCM MPU register
Hi Denis, Agreed. I would continue as you are, just remembering that if you have an issue there might be a patch for it already and have a look at the patches. Iain On Fri, 28 Jun 2019 at 19:31, Denis Obrezkov <denisobrezkov@xxxxxxxxx> wrote: > > Hi Iain, > > On 6/28/19 7:25 PM, Iain Hunter wrote: > > Hi Stefano, > > It was a patchset I'd circulated earlier in the GSoC process. > > Basically the partial port of Xen on X15 I'd done last year. The build > > script is the reference for which patches were actually used. > > Iain > I believe the reason we haven't started from trying your patch was that > I thought that since you hadn't used smp your solution might not work in > our case, since we want to have smp (I was probably wrong). > I think I should reproduce all the issues step-by-step that Iain faced > and apply his patches where they are required (otherwise it would be > hard for me to understand what's happening). > > Stefano, Julien? > > > > On Fri, 28 Jun 2019 at 17:02, Stefano Stabellini <sstabellini@xxxxxxxxxx> > > wrote: > >> > >> Hi Iain, > >> > >> Where is the patch you mentioned? Maybe you forgot to attach it to the > >> email? > >> > >> Cheers, > >> > >> Stefano > >> > >> On Fri, 28 Jun 2019, Iain Hunter wrote: > >>> 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 > >>>>> > >>>>> > >>> > > -- > Regards, Denis Obrezkov > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |