Re: [Xen-devel] [PATCH v2] xen/arm: Switch OMAP5 secondary cores into hyp mode
Hi, > > Well, Xen has been supported the omap5 for quite a while. So there are > two possibilities regarding the current SMP code: > 1) It is totally broken and therefore never worked on any omap5 > platform. > 2) It works but with maybe modification in U-boot. > > Looking at the mailing list archive and wiki, I believe 2) is closer to > the current reality. So this raise the question whether your patch will > break any existing setup. > > Don't get me wrong, the code is perfectly fine as, to the best of my > knowledge, it matches what Linux does. However, I would like to see an > analysis written in the commit message regarding what's going to happen > for any existing setup. > > Cheers, > I hoped to hear more opinions because I don't really understand where to start - I don't know much about how xen and Linux worked with omap5. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: Switch OMAP5 secondary cores into hyp mode
Hi Julien, > > I am trying to understand how this ever worked. omap5_smp_init is called > by two sets of platforms (based on compatible): > - ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am > right, then I would not bother to support hacked U-boot. > - ti,omap5: [1] suggest that U-boot do the switch for us but it is > not clear whether this is upstreamed. @Chen, I know you did the port a > long time ago. Do you recall how this worked? > > Linux seems to use the smc on any dra7 and omap54xx. So maybe we can use > safely here. > I don't understand your concerns to the full extent. What should be investigated? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSoC-2019] About the crossbar and xen
Hi, On 7/11/19 7:32 PM, Julien Grall wrote: >> >> What do you think? > > Have you looked at the series I pointed out earlier on? It extends Xen > to support other interrupt controller parent. > Yes, but you said once that these patch series wasn't accepted because maintainers didn't like something. So, I wanted to understand whether this approach is acceptable. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSoC-2019] About the crossbar and xen
Hi, >> >> I am interested whether we should do something with omap5-wugen-mpu. I >> found that crossbar is connected to GIC. And on some schemes in trm it >> is connected via omap5-wugen-mpu. So, it is not clear for me whether it >> should be handled in xen. > Also, I am interested in how to add the crossbar. I can see two options as we discussed earlier. The first option is to remove the crossbar but for me it might cause some problems since a guest might want to use it. The second option is to expose the crossbar and intercept all the calls to it. But the problem is that now xen supports only one interrupt-controller. And at the same time most of the SPI IRQs are mapped to the crossbar. So, when xen checks whether the main interrupt-controller is the same as the one to who external interrupts are mapped it fails. (xen/common/device_tree.c:dt_irq_translate()). And I don't think that I should change interrupt-parent option of devices to map them to the GIC because it is essentially the first option mentioned above. So, it seems that probably interrupt-parent finding decision logic should be changed a bit? Like to find a GIC node not in a direct interrupt-parent but transitively in one of ancestors: UART -> crossbar -> wugen -> GIC What do you think? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSoC-2019] About the crossbar and xen
Hi,
On 7/10/19 10:17 PM, Stefano Stabellini wrote:
> On Wed, 10 Jul 2019, Denis Obrezkov wrote:
>> Hi,
>>
>> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>>
>>>
>>> phandle = <0x0002>;
>>>
>>> I think that means that interrupts go to the GIC via Crossbar; i.e. the
>>> parent interrupt controller of Crossbar is the GIC.
>>>
>> But the crossbar's interrupt-parent node is 0x0008 and phandle value
>> 0x0008 belongs to
>> interrupt-controller@48281000 {
>> compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
>>
>> For me it looks like interrupts from crossbar goes to wugen and the from
>> wugen to GIC. But I don't quite understand it.
>
> Hi Denis,
>
> I only read your email and got a partial picture. I read the full device
> tree now and the hierarchy is as follow:
>
> - crossbar routes to phandle 8
> - phandle 8 is omap5-wugen-mpu and routes to phandle 2
> - phandle 2 is the GIC
>
> So:
>
> crossbar -> omap5-wugen-mpu -> GIC
>
I am interested whether we should do something with omap5-wugen-mpu. I
found that crossbar is connected to GIC. And on some schemes in trm it
is connected via omap5-wugen-mpu. So, it is not clear for me whether it
should be handled in xen.
--
Regards, Denis Obrezkov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSoC-2019] About the crossbar and xen
Hi,
On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>
> phandle = <0x0002>;
>
> I think that means that interrupts go to the GIC via Crossbar; i.e. the
> parent interrupt controller of Crossbar is the GIC.
>
But the crossbar's interrupt-parent node is 0x0008 and phandle value
0x0008 belongs to
interrupt-controller@48281000 {
compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
For me it looks like interrupts from crossbar goes to wugen and the from
wugen to GIC. But I don't quite understand it.
--
Regards, Denis Obrezkov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [GSoC-2019] About the crossbar and xen
Hello,
so, I think I understood why uart doesn't work, that's because all the
irqs are routed to the crossbar not to GIC, so, xen can't deal with them.
One thing I am concerned of is the:
interrupt-controller@48281000 {
compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
interrupt-controller;
#interrupt-cells = <0x0003>;
reg = <0x 0x48281000 0x 0x1000>;
interrupt-parent = <0x0002>;
phandle = <0x0008>;
};
And this is an interrupt-parent for the crossbar. So, it is not clear
for me how it participates in interrupt processing. Any thoughts?
Here is my device tree: https://pastebin.com/Xec57Jcr
--
Regards, Denis Obrezkov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hi, On 7/6/19 7:37 PM, Julien Grall wrote: > > Yes it would be sensible to try to implement a crossbar driver in Xen > and test with the UART. Looking at the driver in Linux, this should not > be too difficult. I don't understand why xen doesn't react on triple Ctrl+a. It probably means that UART's interrupts doesn't work. But I was able to type in u-boot so the uart should be already configured. Or not? Should I set up it in a crossbar first? > >>> > > I don't think I ever suggested to not expose the crossbar to Dom0. > Instead, I suggested to virtualize for Dom0, so it can be used by Xen as > well. > >>> >>>> Also, the tegra >>>> implementation blacklist only a uart. >>> >>> I don't understand this. >> In here [1] you can find that only uart is blacklisted (in >> tegra_blacklist_dev[]). So, in tegra they didn't blacklist their version >> of the crossbar. > > This series has not been merged. In other word, the code is not yet > matching the expectations of the maintainers. > > I pointed you to this series, because I think some of the idea could be > re-used for implementing the crossbar. > > In this particular case, it has been suggested to use blacklist_dev > rather than unmapping (see [2]). > Hm, I thought that idea behind the patch was that they unmap the control register and intercept the calls from Linux to that control register. At the same time they preserved the crossbar in the device tree. And, I thought that you wanted to demonstrate this exact thing. Could you describe how in general the approach with blacklisting should work? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
>> Ok, I changed it and was able to boot to the previous error. I think a >> logical next step would be to set up the uart somehow? > > Do you mean the UART used by Xen? Yes, to be able to switch between xen and dom0, to download a produced dt for dom0 for example. > >>> >>> But this feels weird to map then unmap the mmio. Instead, you should >>> blacklist the crossbar device. Have a look at the field blacklist_dev in >>> platform_desc. >> Hm, I can see that in the device tree the crossbar has a phandle >> property <0x0008> and the main node has an interrupt-parent property >> 0x0008. So, all the interrupts seems to be mapped to the crossbar. >> Wouldn't be that a problem if we blacklist the device? > > > The Device is owned by Xen, so technically Dom0 does not see the > hardware one. Instead it sees a virtual and therefore the node should be > created to reflect it. > > The purpose of recreating the node is you can alter it to match what we > actually exposed to the domain (property values may differ). It may > happen that a lot of information are exactly the same as the hardware > and can just be copied. > > This is, for instance, what we do for the GIC and timer. I mean if we expose only GIC to the dom0 then we need to change the interrupt-parent property to make all nodes have GIC's phandle as their interrupt-parent. And when dom0 tries to modify irq connections then xen should modify the crossbar. It seems to be a bit error prone approach. > >> Also, the tegra >> implementation blacklist only a uart. > > I don't understand this. In here [1] you can find that only uart is blacklisted (in tegra_blacklist_dev[]). So, in tegra they didn't blacklist their version of the crossbar. [1] https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00993.html -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hi, On 7/6/19 5:57 PM, Julien Grall wrote: > > > rc = unmap_mmio_regions(d, _gfn(pfn_start), > pfn_end + pfn_start + 1, > _mfn(pfn_start)); > > You are not computing correctly the number of pages. I think you want > "pfn_end - pfn_start + 1". Ok, I changed it and was able to boot to the previous error. I think a logical next step would be to set up the uart somehow? > > But this feels weird to map then unmap the mmio. Instead, you should > blacklist the crossbar device. Have a look at the field blacklist_dev in > platform_desc. Hm, I can see that in the device tree the crossbar has a phandle property <0x0008> and the main node has an interrupt-parent property 0x0008. So, all the interrupts seems to be mapped to the crossbar. Wouldn't be that a problem if we blacklist the device? Also, the tegra implementation blacklist only a uart. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hi, On 7/6/19 12:56 PM, Julien Grall wrote: > 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 >>> #include >>> >>> +#define OMAP5_CTRL_CORE_MPU_IRQ 0x0A48 >>> + >>> 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=c000, da=4a002a48 > (XEN) DT: parent translation for:<3> <3> <3> > (XEN) DT: with offset: 4a002a48 > (XEN) DT: one level translation:<3> <3> 4a002a48<3> > (XEN) DT: reached root node > (XEN) - MMIO: 004a002a48 - 004a002b78 P2MType=5 > (XEN) handle /ocp/dss@5800 > (XEN) dt_irq_number: dev=/ocp/dss@5800 > (XEN) /ocp/dss@5800 passthrough = 1 nirq = 0 naddr = 5 > (XEN) DT: ** translation for device /ocp/dss@5800 ** > > Looking towards the end of the log: > > (XEN) traps.c:1998:d0v0 HSR=0x9387 pc=0xc012bd5c gva=0xfa243404 > gpa=0x0048243404 > > This means Linux is trying to access the address 0x0048243404 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, > sorry for confusing you, I share a bit outdated log but only to show the output of xen about device tree. We already overcome that error about omap specific mapping (applied one of Iain's patches). I tried to replicate the tegra version of legacy irq controller support you mentioned in the irq: https://github.com/embeddedden/xen/commit/180af7ffc8abbbc3ed41dcbc9abc6e8b12daa57a Now, I have an error: (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading d0 kernel from boot module @ 8200 (XEN) Loading ramdisk from boot module @ 8400 (XEN) Allocating 1:1 mappings totalling 512MB for dom0: (XEN) BANK[0] 0x00a000-0x00c000 (512MB) (XEN) Grant table range: 0x008500-0x008504 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from 8200 to a7c0-a7fdea20 (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Unable to copy the kernel in the hwdom memory (XEN) Probably, I messed something with remapping. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hi, 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 > #include > > +#define OMAP5_CTRL_CORE_MPU_IRQ 0x0A48 > + > 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. -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
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 #include +#define OMAP5_CTRL_CORE_MPU_IRQ 0x0A48 + 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; } -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hi Iain, On 7/5/19 10:31 AM, Iain Hunter wrote: > Hi Denis, > That is about as far as I got > > The driver to handle crossbar is > https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-crossbar.c > The documentation is > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/arm/omap/crossbar.txt Julien recommended me to look at the tegra example: https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00991.html And I believe that Stefano proposed to implement a virtualized crossbar control register. 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. -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0
Hello, I am trying to run xen and I have a problem: https://pastebin.com/U0gch9us on line 190-193 So, it seems that Linux can't discover the irq domaing for crossbar interrupt controller when running in dom0, but it has no problem when running baremetal. Here is the DT log with xen: https://drive.google.com/open?id=15YTsCKYUTbG2i-siWezJXKWuG0H1VfQz (an older version with another mistake) It can be seen that external interrupts are connected to the crossbar interrupt controller. I found some information about irq domains and crossbars: https://www.kernel.org/doc/Documentation/IRQ-domain.txt it seems to me that it is possible to give control on the crossbar to dom0, though, I don't really understand what's happening. -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ 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
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
> 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
>>> 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 0xb200
>>>>>> #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
signature.asc
Description: OpenPGP digital signature
___
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
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 0xb200 > #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 signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] xen on beagleboard-x15: fails to access PRCM MPU register
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 0xb200 #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 signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/arm: Switch OMAP5 secondary cores into hyp mode
This function allows xen to bring secondary CPU cores into non-secure
HYP mode. This is done by using a Secure Monitor call.
Signed-off-by: Denis Obrezkov
---
xen/arch/arm/arm32/head.S | 11 ++-
xen/arch/arm/platforms/omap5.c| 5 +++--
xen/include/asm-arm/platforms/omap5.h | 3 +++
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5f817d473e..120e034934 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -36,6 +36,10 @@
#include EARLY_PRINTK_INC
#endif
+
+#define API_HYP_ENTRY 0x102
+#define AUX_CORE_BOOT0_PA 0x48281800
+
/*
* Common register usage in this file:
* r0 -
@@ -113,6 +117,12 @@ past_zImage:
b common_start
+GLOBAL(omap5_init_secondary)
+ldr r12, =API_HYP_ENTRY
+adr r0, init_secondary
+ dsb
+smc #0
+
GLOBAL(init_secondary)
cpsid aif/* Disable all interrupts */
@@ -159,7 +169,6 @@ common_start:
PRINT("- CPU doesn't support the virtualization extensions -\r\n")
b fail
1:
-
/* Check that we're already in Hyp mode */
mrs r0, cpsr
and r0, r0, #0x1f /* Mode is in the low 5 bits of CPSR */
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index aee24e4d28..6b5cc15af3 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -128,8 +128,9 @@ static int __init omap5_smp_init(void)
}
printk("Set AuxCoreBoot1 to %"PRIpaddr" (%p)\n",
- __pa(init_secondary), init_secondary);
-writel(__pa(init_secondary), wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
+ __pa(omap5_init_secondary), omap5_init_secondary);
+writel(__pa(omap5_init_secondary),
+wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
printk("Set AuxCoreBoot0 to 0x20\n");
writel(0x20, wugen_base + OMAP_AUX_CORE_BOOT_0_OFFSET);
diff --git a/xen/include/asm-arm/platforms/omap5.h
b/xen/include/asm-arm/platforms/omap5.h
index c559c84b61..732b27f403 100644
--- a/xen/include/asm-arm/platforms/omap5.h
+++ b/xen/include/asm-arm/platforms/omap5.h
@@ -22,6 +22,9 @@
#endif /* __ASM_ARM_PLATFORMS_OMAP5_H */
+/* Secondary cpu omap5 specific init routine */
+extern void omap5_init_secondary(void);
+
/*
* Local variables:
* mode: C
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Starting to port xen on beagleboard-x15 (GSoC 2019 project)
Hi, On 6/19/19 5:06 PM, Julien Grall wrote: > > > On 19/06/2019 15:33, Denis Obrezkov wrote: >> Hi, > > Hi Denis, > >> ср, 19 июн. 2019 г. в 14:01, Andrii Anisov : >>> >>> >>> >>> On 18.06.19 19:19, Julien Grall wrote: >>>> Denis (the author of the thread) is doing a GSOC to port Xen on the >>>> BeagleBoard X15. You ended up CCed because you can provide feedback >>>> how to proceed. Not because we wanted you to implement it... >>> >>> OK then. >>> >>> Denis, >>> >>> Feel free to contact me in case you need clarifications about the stuff. >> thank you >>> >>> -- >>> Sincerely, >>> Andrii Anisov. > > Don't forget to strip unnecessary bits of the e-mail you quote :). > >> >> So, right now I get a bit further and it seems that CPU1 was switched >> to hyp mode: >> https://github.com/embeddedden/xen/commit/2d76ae7aacb7c0ea7312eaddb91c3eb1e1963cc9 >> > > Nice to see some progress here! :) > > Just to keep record of the discussion on IRC: > > - omap5_init_secondary is the entry point to Xen and SMC #0 is > called right after. There are nothing in r2-r12 that we care about, so > there are no need to save/restore them. On a side note, you could not > use sp because we don't know the value stored in it. So you may rewrite > Xen (or any other modules). > > - From the pastebin "(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > Freq: 0 KHz". It looks like the register CNTFREQ is not configured > correctly on the CPU. Looking at Linux, they have code to setup CNTFRQ > (set_cntfrq) for all the CPUs (see realtime_counter_init in > arch/arm/mach-omap2/timer.c and omap4_secondary_init in > arch/arm/mach-omap2/omap-smp.c). > In the case of Xen, I think we want to call set_cntfreq in > omap5_init_time() for the boot CPU. For the secondary CPUs, we may need > to introduce a callback in struct platform_desc to be called during > secondary startup. > > Lastly, please clean-up the code and send the patch on xen-devel. I will > have a closer look at that time. Feel free to ping me on IRC if you have > any doubt how to proceed. Ok, I will read xen code guideline and send the patch. > >> and the output: >> https://pastebin.com/3JBw6S4K > > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Missing kernel boot module? > (XEN) > (XEN) **** > (XEN) Panic on CPU 0: > (XEN) Could not set up DOM0 guest OS > (XEN) > > You probably haven't set up the Dom0 kernel here. Check you u-boot runes > for this. So, I configured dtb and got: https://pastebin.com/uDYiGsHL So, it seems that timer interrupts don't work for now. -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Starting to port xen on beagleboard-x15 (GSoC 2019 project)
Hi, On 6/19/19 5:32 PM, Julien Grall wrote: > Hi, > > On 19/06/2019 16:27, Andrii Anisov wrote: >> >> >> On 19.06.19 18:06, Julien Grall wrote: >>> Lastly, please clean-up the code and send the patch on xen-devel. I >>> will have a closer look at that time. Feel free to ping me on IRC if >>> you have any doubt how to proceed. >> >> About the code: I think omap5_init_secondary() must be moved to the >> platform code (omap5.c). > > Well omap5.c is C code... You can't call C in the boot process at least > until the MMU is on and we fully setup the processor. I don't understand this since init_secondary is installed in C code, isn't it? (in omap5.c:omap5_smp_init()) -- Regards, Denis Obrezkov signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree
> Good! Please compile Xen for ARM64 and try to boot Xen and Dom0 with it. > Once you have Xen and Dom0 up and running, you can try to create a small > guest and start that as well. It will help you setup your build and test > environments. > > To build Xen for ARM64, you can use native compilation inside the > qemu-system-aarch64 emulation, but it is slow. Otherwise you can use > chroot and qemu-aarch64-static (the qemu-user aarch64 target, statically > compiled). For example give a look at: > > https://wiki.debian.org/Arm64Qemu > > > The end goal of the project is to be able to boot two domains directly > from Xen. Typically, Xen boots Dom0, then only once Dom0 is fully up and > running, a second domain can be created and that is done via the Xen > tools (xl). However, it is not always necessary to wait until Dom0 is > fully booted before starting a second guest. In many embedded > environments, you only have two or three guests in total to deal with. > It would be better to create them all in parallel directly from Xen. It > would drastically shorten the boot time. > > Device tree is used to describe the hardware available on the platform. > It comes into play in this project because it is the best way to pass > the required information to Xen, so that Xen knows it needs to boot a > second guest in addition to Dom0. > > Before we start the main project though, we usually ask candidates to > send a patch to fix a small issue just to show that they managed to > setup a dev and test environment correctly. We'll come back with a list > of potential small issues to fix shortly. > > >> I have also proposed to make a port of xen for qemu-system-riscv (it >> should be ready in Q2.2018) to people from riscv but I haven't >> received any answer.Anyway, I would like to work with xen on embedded >> platforms. > > That would be awesome, but I don't think that a project like porting Xen > to riscv would fit in a GSoC project :-) Thanks, I will try to do it this weekend. Though, I want to note, that I probably won't participate in GSoC if Google continue their discrimination payment policy. For example, last year I've made a port of RTEMS for RISC-V and received $3600. At the same time one of the RTEMS project participants did almost nothing and was expelled from the program before the final evaluation and received...$3600. That was unfair! Could you imagine what my fellow from India felt who made an excellent project and received only $2400. P.S. Is xen-project going to participate in Outreachy? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree
> Hello Denis, > Hello Stefano, > it is great to see interest in Xen on ARM and this project! > > Unfortunately RPi3 can't run Xen as far as I know due to their non-ARM > interrupt controller without virtualization support. Otherwise it would > have been a good dev board. The BeagleBoard doesn't have processors with > virtualization support so it cannot run Xen either (it needs an Cortex > A7 or A15). I have RPi2 and it has Cortex A7 AFAIK. > > But that's not a problem, because the latest QEMU (2.11) can run Xen > just fine. Build QEMU with --target-list=aarch64-softmmu, then you can > run it with: > > qemu-system-aarch64 -machine virt,gic_version=3 \ > -machine virtualization=true \ > -cpu cortex-a57 -machine type=virt \ > -smp 4 -m 2048 \ > -serial stdio -monitor none \ > -bios /path/QEMU_EFI.fd \ > -netdev user,id=hostnet0 -device virtio-net-device,netdev=hostnet0 \ > -drive if=none,file=$DISK1,id=hd0 -device virtio-blk-device,drive=hd0 > > Where DISK1 is your EFI ready disk image and QEMU_EFI.fd can be > downloaded from: > > http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-AARCH64/RELEASE_GCC5/QEMU_EFI.fd > > See the following for more detailed information: > > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64 > > Give it a try and let me know if you have any issues. > > Cheers, > > Stefano I was able to boot to uefi shell. What can I do further? What is my overall goal? To build and run several instances of Linux? Make a patch? I have also proposed to make a port of xen for qemu-system-riscv (it should be ready in Q2.2018) to people from riscv but I haven't received any answer.Anyway, I would like to work with xen on embedded platforms. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree
2018-02-04 9:53 GMT+03:00 Denis Obrezkov <denisobrez...@gmail.com>: > Hello all, > > I would like to participate in GSoC 2018 with the project Xen on ARM > related project. I have some previous experience with GSoC: > https://summerofcode.withgoogle.com/archive/2017/projects/4780624749527040/ > > Could you give me more details on the project? > > I have RPi3 and BBB boards, or should this work be done in emulator? > > -- > Regards, Denis Obrezkov I am also very interested in GPU virtualization on ARM devices. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree
Hello all, I would like to participate in GSoC 2018 with the project Xen on ARM related project. I have some previous experience with GSoC: https://summerofcode.withgoogle.com/archive/2017/projects/4780624749527040/ Could you give me more details on the project? I have RPi3 and BBB boards, or should this work be done in emulator? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
