[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board



Dear Iurii,

Following:
> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.

Is not needed.
The issue does not appear with the current master HEAD.

Sincerely,
Andrii Anisov.


On Wed, Nov 23, 2016 at 4:00 PM, Iurii Mykhalskyi
<iurii.mykhalskyi@xxxxxxxxxxxxxxx> wrote:
> Dear all,
>
> Andrii, thanks for the remark - I'll rework this patch.
>
> Julien, I have updated yocto layer [1] to use the most recent stable Xen
> version - Xen 4.8-rc6
>
> Looks like used patches for Xen should be described more briefly:
> 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
> console introduction for Salvator-X board

> 3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
> compilation issue on arm64 platform. Looks like Andrii faces same problem
> [3] [4].
> 4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
> essential, but xsm might be usefull for some use-cases.
> 5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
> Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
> Dom0 will be allocated at over 4GB space - DMA operation will fail.
>     According to xen-devel list [5], this patch planned to be included in
> Xen 4.9.
> 6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
> but by default Xen traps such calls, so we have to allow such actions.
>
> [1] https://github.com/qbeeukraine/meta-platform-xen
> [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
> [3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
> [4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
> [5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html
>
> In last email you have written:
>> Also, it is not clear to me why you need a specific device tree and hacked
>> DOM0 linux (see [2]) on this board for Xen. This would need some
>> documentation on the wiki.
>
> Yes, this need some explanation. I'll update related wiki page in few hours.
>
> Thanks for all of your comments.
>
> With the best regards,
> Iurii Mykhalskyi
>
>
>
> On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov <andrii.anisov@xxxxxxxxx>
> wrote:
>>
>> Well,
>>
>> > This patch
>> > https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> > Is a total mess.
>> It seems you've lost some code and related history during porting the
>> original patch.
>>
>> Sincerely,
>> Andrii Anisov.
>>
>> On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov <andrii.anisov@xxxxxxxxx>
>> wrote:
>>>
>>> Dear Iurii,
>>>
>>> This patch
>>> https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>>> arch_fixup_fdt() function, which, as per you idea, is not needed to be built
>>> for the XEN boot. You have no patch lines to introduce CONFIG_XEN so the
>>> code works.
>>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>>> to drop whole the function.
>>>
>>> But the problem in that piece of code still exists:
>>>
>>> u-boot updates the first memory node in the dtb with all memory banks it
>>> found in the board code, does not take into consideration other memory nodes
>>> as a result memory banks in device tree are duplicated
>>> unlike the kernel which tolerates that mess from u-boot, XEN does not
>>> accept memory banks are duplicated and crashes.
>>>
>>> Putting all memory banks into one memory node in the device tree is the
>>> simplest workaround.
>>> I'm not really sure where should be a proper fix. Should it be on u-boot
>>> or XEN side?
>>>
>>> Sincerely,
>>> Andrii Anisov.
>>>
>>
>
>
>
> --
>
> Iurii Mykhalskyi | Senior Software Engineer
> GlobalLogic
> P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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