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

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

[Denis Obrezkov]

[-- Attachment #1.1.1: Type: text/plain, Size: 1132 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Denis Obrezkov]

[-- Attachment #1.1.1: Type: text/plain, Size: 1257 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Stefano Stabellini]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Iain Hunter]

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@kernel.org> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Stefano Stabellini]

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@kernel.org> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Iain Hunter]

[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]

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

On Fri, 28 Jun 2019 at 17:02, Stefano Stabellini <sstabellini@kernel.org> 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@kernel.org> 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
> > > >
> > > >
> >

[-- Attachment #2: gsoc-xen-v0.1.tar.gz --]
[-- Type: application/x-gzip, Size: 43979 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

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

[Denis Obrezkov]

[-- Attachment #1.1.1: Type: text/plain, Size: 4343 bytes --]

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@kernel.org> 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@kernel.org> 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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Iain Hunter]

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@gmail.com> 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@kernel.org> 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@kernel.org> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Stefano Stabellini]

On Fri, 28 Jun 2019, Denis Obrezkov 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?

Yes, I think you should reproduce all the issues step by step to know
for sure what is required and why. In this case, it is very likely that
we'll need Iain's patch.

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