Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2 3/3] linux-xlnx.inc: Support simpleImage.mb support for MB

[Manjukumar Harthikote Matha]

Hi Nathan,

> -Original Message-
> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> Sent: Sunday, January 28, 2018 5:29 AM
> To: Manjukumar Harthikote Matha 
> Cc: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2 3/3] linux-xlnx.inc: 
> Support
> simpleImage.mb support for MB
> 
> On 23 January 2018 at 10:55, Manjukumar Matha  ma...@xilinx.com> wrote:
> > Support simpleImage.mb for MB machines. simpleImage.mb depends on dts
> > to be included while kernel is being compiled. This patch enables
> > copying the dts from device-tree recipe to kernel work area so that
> > simpleImage.mb can be built
> >
> > Signed-off-by: Manjukumar Matha
> > 
> > ---
> >  meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc | 18
> > ++
> 
> This should be implemented in a kernel-simpleimage.bbclass, so that is can be 
> also
> used for linux-yocto and even contributed upstream (since powerpc also 
> supports
> simpleimage).
> 
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc
> > b/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc
> > index 7b4f9ac..e05890c 100644
> > --- a/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc
> > +++ b/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc
> > @@ -23,6 +23,24 @@ do_kernel_metadata_prepend () {
> > [ -n "${KBUILD_DEFCONFIG}" ] && [ -e ${WORKDIR}/defconfig ] &&
> > rm ${WORKDIR}/defconfig  }
> >
> > +python __anonymous () {
> > +   kerneltypes = d.getVar('KERNEL_IMAGETYPES') or ""
> 
> This should take KERNEL_IMAGETYPE into account as well, in case a user only 
> wants
> simpleImage and is using the KERNEL_IMAGETYPE variable which should work.
> 
> Something like this gets a unique list to check against:
> 
> kerneltypes = set((d.getVar("KERNEL_IMAGETYPE") or "").strip()) kerneltypes |=
> set((d.getVar("KERNEL_IMAGETYPES") or "").split())
> 

Ok thanks,

> > +   if 'simpleImage.mb' in kerneltypes.split():
> 
> The simpleImage. targets can work for any dtb, this check can instead
> something like:
> 
> if any(t.startswith("simpleImage.") for t in kerneltypes):
> ...
> 
> Though you will need to update the copying steps below to handle multiple 
> dtbs.
> 
> > +  providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb") or ""
> > +  if providerdtb:
> 
> Its not worth doing this check, since "" is a valid provider which is used to
> automatically select based on available providers. And this will force 
> bitbake to fail if
> it cant find a provider which will list possible options/etc, and most 
> usefully why
> they were skipped.
> 
> > + d.appendVarFlag('do_compile', 'depends', '
> virtual/dtb:do_populate_sysroot')
> > +  else:
> > + bb.error("For MB dts/dtb provider needs to be set") }
> > +
> > +do_compile_prepend_microblaze () {
> > +   if (echo "${KERNEL_IMAGETYPES}" | grep -wq "simpleImage.mb");
> > +then
> 
> I would suggest doing this as a separate task that do_compile becomes 
> dependent
> on if simpleImage is enabled. That also means you can make the separate task
> dependent on the virtual/dtb instead of do_compile.
> Which might likely speed up some parallelism of tasks.
>

Ok agreed
 
> > +   install -d ${B}/arch/microblaze/boot/dts
> > +   cp ${RECIPE_SYSROOT}/boot/devicetree/*.dts
> > + ${B}/arch/microblaze/boot/dts/mb.dts
> 
> It is possible to build the simpleImage targets without needing the dts, 
> populating
> the .dtb into the build/..boot/dts/ directory and then calling the make
> simpleImage. target works as intended.
> 

I have to check this, every time I compiled using kernel Makefile it was 
checking for dts file to be present


> That also means you wont need the disassembled version of the dtb from device-
> tree.bb (thus making that patch unnecessary). And prevents any issues caused 
> by
> rebuilding the dtb (e.g. differing pad size).
> 

Thanks for the review!

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Ethernet functionality of QEMU (zcu102-zynqmp)

[Martin Siegumfeldt]

Hi,

Are there any limitations regarding the ethernet capabilities of the QEMU 
instance of the zcu102-zynqmp machine? runqemu seems to allocate IP address to 
the tap interface, no obvious errors are present from the kernel log, however 
no IP address is assigned to eth0. I have manually tried to assign address, 
gateway etc., however I am not able to gain ssh access. The qemux86 seems to 
automatically gain the 'runqemu' allocated IP address.

Similar observations seem reported for Zynq 
(https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Zynq-QEMU-Network-Issues/td-p/797050)
 however no definite conclusion seems drawn.

Thanks,
Martin

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] qemuboot.conf

[Nathan Rossi]

On 29 January 2018 at 05:51, Martin Siegumfeldt  wrote:
>
>
>
> 
> From: Nathan Rossi 
> Sent: Sunday, January 28, 2018 13:44
> To: Alistair Francis
> Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] qemuboot.conf
>
> On 24 January 2018 at 09:04, Alistair Francis  wrote:
>> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt 
>> wrote:
>>> Hi,
>>>
>>> We are rendering a custom piece of HW based on Ultrascale+, and have the
>>> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to
>>> the application developers and to close the loop we would like to be capable
>>> of delivering also the QEMU instance. The machine image- and qemuboot.conf
>>> is not part of the eSDK and is thus delivered next to the eSDK.
>>> Unfortunately, the Xilinx conf file describes a few absolute path variables
>>> (caused by e.g.
>>> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55
>>> I believe) prohibiting this conf file to be shared between the application
>>> developers. AFACICS, this is in contrast to the generic QEMU machine configs
>>> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/)
>>> which only describes relative path variables - I assume this is related to
>>> the "custom" Xilinx PMU.
>
> These are not directly related to the PMU part of QEMU execute, since
> that part is executed by runqemu. It is simply that runqemu does not
> make generic find/replace with all args, only specific ones.
>
>>>
>>> Do you see any way around these absolute paths, which thus enables
>>> directly sharing the QEMU instance with eSDK developers?
>>
>> All of these files should be in the deploy directory, I don't see any
>> reason why they need to be absolute. How do the other configs point to
>> the images?
>
> They need to be absolute because the runqemu script does not rewrite
> the paths for those arguments, and in turn with runqemu not executing
> with the cwd being the deploy directory it is not known where the
> intended path to these files are.
>
> Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings
> that are substituted during runqemu execution.
>
> http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030
>
> Unfortunately I don't think there is a good solution to remove these
> fields without improving runqemu itself. Since the paths are only
> known by runqemu and cannot be relative to an unknown execution
> working directory.
>
> Thanks Nathan, I was kind of expecting this answer - it can fairly easy
> worked around with a sed command. However, for the "staging_bindir_native"
> variable, is there a reason this is absolute as apposed to the other
> "staging_dir_..." variables? AFAICS, other machines describe this variable
> in a relative manner?
>

That is simply a case of qemuboot.bbclass getting changes that are not
reflected in the qemuboot-xilinx.bbclass in meta-xilinx.

This change in oe-core added relative pathing,
http://git.openembedded.org/openembedded-core/commit/?id=55a0028a961c0ad3c2e5729a9e3919cbbf256fe1

But qemuboot-xilinx.bbclass modifies staging_bindir_native to put in
the qemu-xilinx-helper-native specific path. Which doesn't do the
relative path logic, since it was created before the oe-core change.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/classes/qemuboot-xilinx.bbclass#n20

Please send a patch to fix it if you need the relative paths.

Regards,
Nathan
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx