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
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.
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.ani...@gmail.com>
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.ani...@gmail.com>
> wrote:
>
>> Dear Iurii,
>>
>> This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/m
>> inimal/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/>
http://www.globallogic.com/email_disclaimer.txt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
