On Wed, Jun 15, 2016 at 7:25 AM, Nathan Rossi <[email protected]> wrote:
> On Wed, Jun 15, 2016 at 7:45 AM, Alistair Francis
> <[email protected]> wrote:
>> On Tue, Jun 14, 2016 at 7:11 AM, Nathan Rossi <[email protected]> wrote:
>>> On Tue, Jun 14, 2016 at 2:25 AM, Alistair Francis
>>> <[email protected]> wrote:
>>>> On Tue, May 17, 2016 at 9:40 AM, Alistair Francis
>>>> <[email protected]> wrote:
>>>>> On Tue, May 17, 2016 at 6:27 AM, Nathan Rossi <[email protected]>
>>>>> wrote:
>>>>>> On Tue, May 17, 2016 at 8:20 AM, Alistair Francis
>>>>>> <[email protected]> wrote:
>>>>>>> On Mon, May 16, 2016 at 9:39 AM, Alistair Francis
>>>>>>> <[email protected]> wrote:
>>>>>>>> On Sun, May 15, 2016 at 10:10 AM, Peter Crosthwaite
>>>>>>>> <[email protected]> wrote:
>>>>>>>>> On Sun, May 15, 2016 at 1:17 AM, Nathan Rossi
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>> On Sat, May 14, 2016 at 2:54 AM, Alistair Francis
>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>> On Fri, May 13, 2016 at 2:35 AM, Nathan Rossi
>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>> On Fri, May 13, 2016 at 6:11 AM, Alistair Francis
>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>> Add the qemuzynqmp machine based on the physical ZCU02 revB board.
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Alistair,
>>>>>>>>>>>>
>>>>>>>>>>>> So I am a little confused, is this machine supposed to emulate the
>>>>>>>>>>>> ep108 (the args to QEMU appear to be for the ep108) or the zcu102?
>>>>>>>>>>>> or
>>>>>>>>>>>> are both able to be emulated?
>>>>>>>>>>>
>>>>>>>>>>> Hey Nathan,
>>>>>>>>>>>
>>>>>>>>>>> This machine is supposed to be emulating the ZCU102.
>>>>>>>>>>>
>>>>>>>>>>> At the moment we only have the EP108 in upstream QEMU. It isn't
>>>>>>>>>>> worth
>>>>>>>>>>> adding a ZCU102 model upstream yet as at the moment we don't have
>>>>>>>>>>> enough modeled upstream to notice any differences between the
>>>>>>>>>>> boards.
>>>>>>>>>>
>>>>>>>>>> Ah ok, so in the future QEMU will have models for both the EP108 and
>>>>>>>>>> the ZCU102 boards. In that case I don't actually see a need for a
>>>>>>>>>> 'qemuzynqmp' machine, since the ep108-zynqmp already provides the
>>>>>>>>>> setup for QEMU. The same can be done for the zcu102-zynqmp board,
>>>>>>>>>> this
>>>>>>>>>> would also make it easier to maintain consistency (aka changes only
>>>>>>>>>> need to be made to the zcu102-zynqmp machine).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1, qemuzynq as well as the "zynq" machine model in upstream QEMU are
>>>>>>>>> legacy convention that we should replace with concrete boards going
>>>>>>>>> forward.
>>>>>>>>
>>>>>>>> Ok, I'll look into adding a ZCU102 machine similar to what we do for
>>>>>>>> the EP108.
>>>>>>>
>>>>>>> How can I run the EP108 on QEMU? I can't find how I can start QEMU with
>>>>>>> Yocto.
>>>>>>
>>>>>> There is no runqemu support though the ep108 machine is setup to build
>>>>>> qemu-native for use. But there was a guide created back when first
>>>>>> adding zynqmp, essentially it is manually running QEMU with the
>>>>>> correct args. http://www.wiki.xilinx.com/Yocto+for+zynqmp
>>>>>
>>>>> Ok, but I'm looking for adding runqemu support to Yocto. The way that
>>>>> everyone else seems to do it is by architecture and not by board so I
>>>>> think that is my only option.
>>>>>
>>>>> Do you have a better idea of adding runqemu support?
>>>>
>>>> This has been accepted in poky master branch with this commit:
>>>> commit ff3bc6c61f5946aa5e91a77442d828ec1a03387d
>>>> Author: Alistair Francis <[email protected]>
>>>> Date: Thu May 12 14:37:39 2016 -0700
>>>>
>>>> runqemu: Add suport for qemuzynqmp
>>>>
>>>> (From OE-Core rev: d2a7c1db9bff6ae3844e3d017e94f29d1501bf57)
>>>>
>>>> Signed-off-by: Alistair Francis <[email protected]>
>>>> Signed-off-by: Ross Burton <[email protected]>
>>>> Signed-off-by: Richard Purdie <[email protected]>
>>>>
>>>>
>>>> Can we work on merging this in meta-xilinx now?
>>>
>>> I will accept the addition of this machine given that it will only
>>> exist for the purposes of runqemu, and it will be removed in the
>>> future once runqemu is able to handle using the actual machine
>>> targets. But there should be no specific configuration/overrides for
>>> this machine, it should be equivalent to the target QEMU model, in
>>> this case ep108-zynqmp.
>>
>> Agreed! I would much rather have EP108 and ZCU102 machines which can
>> boot on QEMU, but that doesn't seem to be how the rest of Yocto works.
>>
>>>
>>> But between this patch, your patch to runqemu and that with qemu 2.6.0
>>> zynqmp does not boot correctly. I don't see a point in merging this
>>> addition until all parts are working as expected. This means that
>>> runqemu should be setup to direct boot the kernel, as this works fine
>>> with qemu 2.5 (and should also work fine with 2.6 once the cpu bring
>>> up issue is resolved).
>>
>> How are you testing with QEMU 2.6? I am unable to build images with
>> meta-xilinx and poky both at master.
>
> Some of the components in meta-xilinx still don't support gcc 6 yet.
> So make sure you specify GCCVERSION = "5.%" in your local.conf.
>
> If you get a task hash mismatch error on the core-image-* task, just
> re-run bitbake. I believe there is a patch for oe-core to fix it on
> the oe-core list (it relates to having cpio and cpio.gz.u-boot in the
> IMAGE_FSTYPES).
Thanks, that was my problem.
It looks like QEMU Linux boot is working for EP108 on Krogoth and only
u-boot works on master.
As the qmeuzynqmp machine won't be applied to Krogoth can I re-send it
with the fixes you mentioned before targeting u-boot?
Then we need to figure out the Linux boot issue and update the runqemu
script to swap over to Linux boot.
Thanks,
Alistair
>
> Regards,
> Nathan
>
>>
>> Thanks,
>>
>> Alistair
>>
>>>
>>> ---
>>>
>>> With regards to this patch, please change it so that it is just
>>> including the ep108 machine. Something like the following in
>>> qemuzynqmp.conf.
>>>
>>> MACHINEOVERRIDES =. "ep108-zynqmp:"
>>> require conf/machine/ep108-zynqmp.conf
>>>
>>> As for setting the "QEMU_DTB", this can be set in the ep108 conf. I
>>> would also suggest using the kernel_devicetree/imagetype to set it.
>>>
>>> QEMU_DTB =
>>> "${KERNEL_IMAGETYPE}-${@os.path.splitext(os.path.basename(d.getVar("KERNEL_DEVICETREE",
>>> True)))[0]}"
>>>
>>> As for the kernel changes, that kernel config is broken for QEMU.
>>>
>>> Regards,
>>> Nathan
>>> --
>>> _______________________________________________
>>> meta-xilinx mailing list
>>> [email protected]
>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
> --
> _______________________________________________
> meta-xilinx mailing list
> [email protected]
> https://lists.yoctoproject.org/listinfo/meta-xilinx
--
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx
