Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

Hello Jairo,

On 25.12.18 18:07, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
> I believe this is the SoC information. If there is any other method of 
> extracting the information, please let me know so I can transmit it.
That output gives a full set of required information. Actually, I worried you
might have an obsolete SoC revision. But it is not your case.

> I took a look at [1] and decided to start from scratch to attempt to get the 
> minimum workspace functioning.
I mainly mentioned point 1 from those limitations. But you have H3 ES2.0 so
ready for the latest BSP as well.

> In previous attempts, I had to modify some recipes to get the compilation 
> working, but this time I would like to confirm with everyone the initial steps 
> before I take them.
> ERROR: xen-unstable+gitAUTOINC+9d357cbaf7-r0 do_package: QA Issue: xen: 
> Files/directories were installed but not shipped in any package:
>    /usr/lib/libxenfsimage.so
>    /usr/lib/libxenfsimage.so.4.12
>    /usr/lib/libxenfsimage.so.4.12.0
>    /usr/lib/xenfsimage/ext2fs-lib/fsimage.so
>    /usr/lib/xenfsimage/ufs/fsimage.so
>    /usr/lib/xenfsimage/fat/fsimage.so
>    /usr/lib/xenfsimage/iso9660/fsimage.so
>    /usr/lib/xenfsimage/reiserfs/fsimage.so
>    /usr/lib/xenfsimage/zfs/fsimage.so
>    /usr/lib/xen/bin/depriv-fd-checker
>    /usr/sbin/xenmon
> Please set FILES such that these items are packaged. Alternatively if they are 
> unneeded, avoid installing them or delete them within do_install.
> xen: 11 installed and not shipped files. [installed-vs-shipped]
> ERROR: xen-unstable+gitAUTOINC+9d357cbaf7-r0 do_package: Fatal QA errors found, 
> failing task.
> ERROR: xen-unstable+gitAUTOINC+9d357cbaf7-r0 do_package: Function failed: 
> do_package
> ERROR: Logfile of failure stored in: 
> /home/yocto/r-car/build/tmp/work/aarch64-poky-linux/xen/unstable+gitAUTOINC+9d357cbaf7-r0/temp/log.do_package.8954
> ERROR: Task 329 
> (/home/yocto/r-car/meta-virtualization/recipes-extended/xen/xen_git.bb 
> <http://xen_git.bb>, do_package) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3642 tasks of which 3641 didn't need to be rerun 
> and 1 failed.
> No currently running tasks (2517 of 3653)
>
> Summary: 1 task failed:
>    /home/yocto/r-car/meta-virtualization/recipes-extended/xen/xen_git.bb 
> <http://xen_git.bb>, do_package
> Summary: There were 3 WARNING messages shown.
> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
It's a known issue. Let's say Yocto's specifics. XEN does evolve so its tools
set of libs and apps is being changed. But Yocto tracks all products of
compilation and eager to know what to do with each of those files.

> I am aware I am using a very old BSP. If there is a slightly better version 
> with which to start with, I would greatly like everyone's opinion.
It is mainly not because of BSP, but the meta-virtualization layer version, it
describes how to build and install XEN. As you can see in the last patch to
xen_git.bbappend [1] it is adjusted for 4.10-rc1. I suppose you already did
required changes for the current 4.12-unstable version when saying:

> In previous attempts, I had to modify some recipes to get the compilation 
> working
Good, you have the BSP with XEN built. Could you please reveal your changes to
let me know which XEN you actually built? In the previous email you said, you
tried running freshly built BSP with XEN, and it does not show anything to
display. But what about the console output for that case?

>  From the log it would seem that the xen_git.bb <http://xen_git.bb> in the 
> meta-virtualization layer is being called and thus the recipe is attempting to 
> compile the newest version of Xen.
Right you are. That is the idea. But Yocto's way of BSP compilation makes it
tending to break up. You can edit XEN recipe to build it from a specific
revision, e.g. 4.10.0-rc1. You should replace `${AUTOREV}` in this line [2]
with the correspondent commit-id `24fb44e971a62b345c7b6ca3c03b454a1e150abe` to
do so.
But I suppose it is not what you really need. Since 4.10.0-rc1 there are a
number of changes to scheduling. You might need have those bits up to date for
your work.

> So my second question would be, what version of Xen should I point towards for 
> the board I am using?I guess it is better to use the latest and greatest for 
> your work, so XEN 4.12 unstable should suit you.
Also I do understand that we have our meta-demo layer quite outdated both from
XEN and BSP sides. Renesas's 2.x BSPs are baked with Linux kernel 4.9.x, it is
really old. Even with LK 4.14, we are using from BSP 3.9, I faced an issue [3]
while playing with the latest and greatest XEN.

[1] 
https://github.com/xen-troops/meta-demo/commit/a4178158ca3ebb739c9bc71c517ec7b65f563218
[2] 
https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-extended/xen/xen_git.bbappend#L9
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg01373.html

--
Sincerely,
Andrii Anisov.

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