[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


  • To: Iain Hunter <drhunter95@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Denis Obrezkov <denisobrezkov@xxxxxxxxx>
  • Date: Fri, 28 Jun 2019 20:31:25 +0200
  • Autocrypt: addr=denisobrezkov@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQMuBFrAxPQRCAD59CJNd5LF1VmojUBpdr/bJ2TaKC7SW4ln7+PWn+QyAJfFOVFlTRIDsAlP 65y7CacXFCXmLTACo4a7HEhRb5787kPm6rc30zpL+04uXCeTruYZi0ZnQVXOiab/qy3aMsk0 6n9hMY28TSbM9nynnlrbg9pGkb1EiFVNsowJjFSKXa3Rpogte9qxfXmLf2eV0MZNnrmq6Kb2 8ri5/Ffh5DG1CsN/dkv8n1kw2QqMM2RT+ZS57D+yCehtw355EXSVh2r+GsXAqMinOexcdYI4 skvvP84OovRMnlJhmRdnbjO+QFiOVeLUj7WHMT3AbClaBlUuHkbFi9HLBHAiu6uMrNtzAQD9 KoM6SXbuvlhCq2v78dGkex9EgaA7CSnBcNXuUdrjYQf+MsZgI7oDihT6TUBO0IDQL+qSrozs /hHV+HhWtc5+SYTsHXxnTkcVe12vR0uPw3fFUuncWnMRzHivKZC2ZF/w3LJL/nGzguAoPa9e VghM38EP49yO6ESthD4WvELMy2+zPkMiUqilMfxOl370RXxEBUIzFSpP6oqvNq7fvThGTQah mrFhflGSyMHXk75VkCiY+cbrMeB9xG7H3nlbQ9fYVCOPejnt8gImeazdIghQh1tjbNpjQhy8 50klCowN5H+gaSZsy4K7jlJ1UNFz/vWCvlr3W8o4tA6EoJ4tjJV2HXcrUBPYLwkruKnv8QJM vyVj5an6Sfuwt/AmFEOKo1QJnAf+Oi47RrOmec8lXS/06TMn7z6krmuRul03HXayCtREqMyY VCf87oMpPYYnFJolDrSB8kCSZRn2aixzHl4IIGa9RVuywChzUvgZJbFGPFR+Qz1BK9Ltl7FC rQcuAqg3A2RJ7uoTNiZDfI0tKWm8BEUe5LqZqgFTkTkuV9D6UveYnDk2zUFGlDTguagW2XWI wiGaA9Ud7UBBlQGTZUwNGahAErUHI5gDSNfWEUaRBEccWKgddK3a/NhkxOveqDWWFcAt4K/g JOqBs+7Bm0RjQa+4EAP6gFx4098XBZP9ff6pPuFWRN6fvfdBDUMHqb3i2SGDWVPrRR/x+Iz/ yfjdWlC/87QoRGVuaXMgT2JyZXprb3YgPGRlbmlzb2JyZXprb3ZAZ21haWwuY29tPoiWBBMR CAA+FiEExuZY9Y+VSLigQ/5M+4kLEySe7PkFAlrAxPQCGyMFCQWjmoAFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AACgkQ+4kLEySe7PleSQEAktULi71pVGKh0vykq0wrn6IyqXx1SLFNwLcr PnZ2N5gA/3Ipzf3vXWXWCwRR07BB/H+9XgqWRl3jsu5EL9TzmyFAuQINBFrAxPQQCADaIOKd +PPUX4GvjdLikKxHsFRRpk75LiFZJcFU8cCA0M4Dg/Q0LcSX82TfgrfU34y7/rrF4ig/Dj81 H8MB2u01lYA2QpQ/XdHfwFMxkj5FCB4Cq6EqGxsXsaRhw4Qu3ouiJiHCEeoMoloBLOlqpXBf qnJSnBXYJDnlyvxoFIVpX4l+q2xJk/877otbPK5TBYdeHQv/f7cWNxIUT5Feth9DVq4B9OG1 BgOA1gH13KUmWhMaO+k/rYCJd9UiRoGm7FihyWrsRnG5K6VNnLjwjMjxDukNxdlITVbeK5/E QaiKRGRcTp3OwfHy6HlQH/JXGGyfmEx0rKVjoW/DD76MPpk/AAMFB/0SBNOW9asG5HeRKhJm QOPJDwNQik4t8uuZb7mw6+QoQuyzMBkXvhL7Aud0OluPeSYL2jZPw2IB26gvlUVva+FJRW9X 7cInI5mnuB4HBGdNpzR+ngRzFyf+qsd6cUrrioQUQozQKCgKG/J2LimV1fC4hQW0n5Q0qM9I KX3PtRCgxItQbn/HdqkTXqv8oxDB9cQILJvIYDZnVLojB4rJFUNb397ao3qaXdXj3iaX6wwJ 2Oo3cSxMGdY/8grRTDGYjItpWEM2noIRzdWSybzavtLHu/LmG4rbgy2aNm/TiVp28G5KvWW/ fCLomZhN0JscRgSkYjSaxmMgEdks1h9DWTHkiH4EGBEIACYWIQTG5lj1j5VIuKBD/kz7iQsT JJ7s+QUCWsDE9AIbDAUJBaOagAAKCRD7iQsTJJ7s+UF2AQDqHEO2tekVMTWJa3SakIM5FJjk sao+JkzbKe0vDy4ecwEAukGaHvmKxMZsUOOjDWjDe4eV+aRTVjUjY7LAl3OJkiU=
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Hunyue Yau <hy-gsoc@xxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 28 Jun 2019 18:31:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

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

Attachment: signature.asc
Description: OpenPGP digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.