Xen project Mailing List

Hello Andrii,

Thanks again for responding and for clarifying some of the underlying workings of Yocto.

2018年12月27日(木) 20:07 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 am actually very relieved that this is the 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 order to get Xen to compile and to prepare for the boot, I modified the meta-demo layer to include the Xen files that were not already included and the hand modified dts file. I have attempted to attach these to the mail.

I am not sure if there is an easier way to get that information, but I basically did a git show within the tmp/work/aarch64-poky-linux/xen folder and got the hash 7f28661f6a7ce3d82f881b9afedfebca7f2cf116 which points to the current head of the master branch of the xen.git repository, if I am not mistaken.

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?

Via serial console I get the following output for the images created after modifying the dts and applying the patch below:

U-Boot 2015.04 (Jun 22 2018 - 13:36:27)

CPU: Renesas Electronics R8A7795 rev 2.0
Board: H3ULCB
I2C:   ready
DRAM: 3.9 GiB
MMC:   sh-sdhi: 0, sh-sdhi: 1
In:    serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot: 0
=> setenv bootargs
=> setenv serverip 192.168.1.100
=> tftp 0x48080000 xen-h3ulcb.uImage
ravb Waiting for PHY auto negotiation to complete...... done
ravb: 1000Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.40
Filename 'xen-h3ulcb.uImage'.
Load address: 0x48080000
Loading: #############################################################
         171.9 KiB/s
done
Bytes transferred = 886160 (d8590 hex)
=> tftp 0x48000000 Image-r8a7795-h3ulcb-xen-local.dtb
ravb:0 is connected to ravb. Reconnecting to ravb
ravb Waiting for PHY auto negotiation to complete... done
ravb: 1000Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.40
Filename 'Image-r8a7795-h3ulcb-xen-local.dtb'.
Load address: 0x48000000
Loading: #####
         11.7 KiB/s
done
Bytes transferred = 63810 (f942 hex)
=> tftp 0x7a000000 Image
ravb:0 is connected to ravb. Reconnecting to ravb
ravb Waiting for PHY auto negotiation to complete........ done
ravb: 1000Base/Full
Using ravb device
TFTP from server 192.168.1.100; our IP address is 192.168.1.40
Filename 'Image'.
Load address: 0x7a000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ############################################
         2.1 MiB/s
done
Bytes transferred = 15911424 (f2ca00 hex)
=> bootm 0x48080000 - 0x48000000
## Booting kernel from Legacy Image at 48080000 ...
   Image Name:   XEN
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:    886096 Bytes = 865.3 KiB
   Load Address: 78080000
   Entry Point: 78080000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 48000000
   Booting using the fdt blob at 0x48000000
   Loading Kernel Image ... OK
   Using Device Tree in place at 0000000048000000, end 0000000048012941

Starting kernel ...

And that is it.

Please note that although I am getting the images and dtb from tftp, the root filesystem is on the microSD card.

I am guessing I should have seen the console output for Xen. I also am not sure how to test if dom0 is actually running at this stage.

> 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.

Yes, I have been tracking some of the scheduling changes being done to Xen and I would really like to have a relatively newer version up and running. However, just having something, anything, running at this stage would be great.

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.

Thank you very much for all your support.

Best regards,

Jairo

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