<div dir="ltr"><div dir="ltr">Hi Marek,<div><br></div><div>one of the issues I saw was that both kernel.bbclass and kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ subfolder.</div><div><br></div><div>My fix was to make the kernel.bbclass ignore "fitImage" during deployment. This is also the fix I saw from Xilinx.</div><div><br></div><div>(Another fix I have pending is that bundled initramfs images (i.e that go inside the kernel binary) where also seperately packed inside the FIT image.)<br></div><div><br></div><div>In general, I am trying to fix all bugs and issues that match "kernel-fitimage.bbclass" on the mailing list.</div><div><br></div><div>Regards,</div><div><br></div><div>Leon.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut <<a href="mailto:marex@denx.de" target="_blank">marex@denx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/18/2018 11:40 AM, Leon Woestenberg wrote:<br>
> Hi Alex,<br>
<br>
Hi,<br>
<br>
> Adding Marek Vasut, original author of kernel-fitimage.bbclass.<br>
> <br>
>> I guess the reason that the deployment happens in kernel.bbclass is so<br>
>> you only have all the symlinking logic in one place<br>
> <br>
> The deployment happens in both kernel.bbclass and<br>
> kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to<br>
> solve. I am not sure what the intention was, though.<br>
> <br>
> Marek: can you comment of the exact purpose of the deploy task in<br>
> kernel-fitimage.bbclass?<br>
> Which class should deploy the FIT images themselves?<br>
<br>
It seems to have to do with deploying of the ITS files and the symlinks<br>
for then .<br>
<br>
It's hard to make any sense from the discussion below due to the<br>
constant top-posting and mixing of email history, so I'll just not do<br>
that, sorry.<br>
<br>
What bug is it that you're seeing ?<br>
<br>
> Whilst cleaning things up, my understanding was that<br>
> kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the<br>
> fitImages, along with the .its file etc.<br>
> Maybe I was mistaken.<br>
<br>
That's the case, yes.<br>
<br>
> I have several other fixed piled up; for example initramfs's supposed to<br>
> get bundled inside the kernel get also packed into the FIT; this takes<br>
> double the amount of space in the FIT image...<br>
> <br>
> Regards,<br>
> <br>
> Leon.<br>
> <br>
> <br>
> <br>
> <br>
> On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan <<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a><br>
> <mailto:<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a>>> wrote:<br>
> <br>
> Thanks Leon<br>
> <br>
> I guess the reason that the deployment happens in kernel.bbclass is so<br>
> you only have all the symlinking logic in one place.<br>
> <br>
> Are in agreement that this change should be reverted and the<br>
> "fitImage" deployed here:<br>
> <br>
> <a href="http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495</a><br>
> <br>
> is the one which we should remove?<br>
> On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg<br>
> <<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a> <mailto:<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a>>> wrote:<br>
> ><br>
> > Hi Alex,<br>
> ><br>
> > I expected it to be kernel-fitimage.bbclass’s responsibility to<br>
> deploy the fitImage.<br>
> ><br>
> > Regards, Leon<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On 16 Sep 2018, at 16:22, Alex Kiernan <<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a><br>
> <mailto:<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a>>> wrote:<br>
> ><br>
> > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan<br>
> <<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a> <mailto:<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> > Hi Leon<br>
> ><br>
> ><br>
> > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg<br>
> <<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a> <mailto:<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a>>> wrote:<br>
> ><br>
> ><br>
> > Hi Alex,<br>
> ><br>
> ><br>
> > On 15 Sep 2018, at 19:45, Alex Kiernan <<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a><br>
> <mailto:<a href="mailto:alex.kiernan@gmail.com" target="_blank">alex.kiernan@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg<br>
> <<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a> <mailto:<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a>>> wrote:<br>
> ><br>
> ><br>
> > kernel-fitimage.bbclass replaces an occurance of "fitImage" in<br>
> ><br>
> > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the<br>
> ><br>
> > architecture (such as zImage). The kernel-fitimage.bbclass packs that<br>
> ><br>
> > image as sub-image in a flattened image tree image (fitImage) and<br>
> ><br>
> > deploys this fitImage along with the image tree source file (.its).<br>
> ><br>
> ><br>
> > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus<br>
> ><br>
> > also contains "fitImage", which kernel.bbclass will also deploy<br>
> ><br>
> > redundantly with different naming.<br>
> ><br>
> ><br>
> > The result is a dual deployment with slightly different naming,<br>
> ><br>
> > each with a set of symlinks.<br>
> ><br>
> ><br>
> > The solution chosen is to have fitImage deployment be handled by<br>
> ><br>
> > kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage<br>
> ><br>
> > types during deployment.<br>
> ><br>
> ><br>
> > Signed-off-by: Leon Woestenberg <<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a><br>
> <mailto:<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a>>><br>
> ><br>
> ><br>
> > This looks completely plausible, but the two "FIT" images that are<br>
> ><br>
> > installed aren't identical... after this I end up with no FIT image<br>
> ><br>
> > and only a bare image in the deploy dir.<br>
> ><br>
> ><br>
> > What was in your KERNEL_IMAGETYPES? Did it at least contain<br>
> “fitImage”??<br>
> ><br>
> ><br>
> ><br>
> > Yes, in fact only fitImage (and no initramfs).<br>
> ><br>
> ><br>
> > Digging into it, the logic between the two classes is a bit odd... in<br>
> ><br>
> > the case of a non initramfs build, the fitImage is actually installed<br>
> ><br>
> > here.<br>
> ><br>
> ><br>
> > If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a<br>
> FIT image containing AT LEAST a Linux kernel are installed by<br>
> kernel-fitimage.<br>
> ><br>
> ><br>
> > The one that's installed in kernel-fitimage is the bare<br>
> ><br>
> > linux.bin, but named fitImage-...<br>
> ><br>
> ><br>
> > which is totally broken. If you want the bare kernel binary (which<br>
> naming depends on architecture, so it should NOT be hard-coded to<br>
> linux.bin anyway), you would need to specify that type *also* in<br>
> KERNEL_IMAGETYPES, next to “fitImage”.<br>
> ><br>
> ><br>
> > Totally agree...<br>
> ><br>
> ><br>
> ><br>
> > I'll send a patch reverting this and removing the other one as I'd<br>
> ><br>
> > agree that it appears to have no purpose (and if you did want it, I<br>
> ><br>
> > guess you could list it in KERNEL_IMAGETYPES).<br>
> ><br>
> ><br>
> > I’m sorry I cannot follow what this and the other one is, and it.<br>
> Let’s first understand all cases correctly.<br>
> ><br>
> ><br>
> ><br>
> > Sorry I've not described it well... the code in<br>
> ><br>
> > kernel-fitimage.bbclass that inserts the kernel into the its happens<br>
> ><br>
> > here<br>
> <a href="http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371</a><br>
> ><br>
> ><br>
> > fitimage_emit_section_kernel ${1} "${kernelcount}" linux.bin<br>
> "${linux_comp}"<br>
> ><br>
> ><br>
> > inside fitimage_emit_section_kernel we create a kernel section which<br>
> ><br>
> > has `data = /incbin/("${3}");` so linux.bin is our bare image.<br>
> ><br>
> ><br>
> > Then we have the installation of fitImage-linux-bin that happens here<br>
> ><br>
> ><br>
> <a href="http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495</a><br>
> ><br>
> ><br>
> > echo "Copying linux.bin file..."<br>
> ><br>
> > install -m 0644 ${B}/linux.bin<br>
> ><br>
> > ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_NAME}.bin<br>
> ><br>
> > ln -snf fitImage-linux.bin-${KERNEL_FIT_NAME}.bin<br>
> ><br>
> > ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_LINK_NAME}<br>
> ><br>
> ><br>
> > i.e. the bare linux.bin file which we used to pack into the FIT image,<br>
> ><br>
> > not a fitImage.<br>
> ><br>
> ><br>
> > The output FIT image from kernel-fitimage.bbclass is created here<br>
> ><br>
> ><br>
> <a href="http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n450" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n450</a><br>
> ><br>
> ><br>
> > uboot-mkimage \<br>
> ><br>
> > ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if<br>
> len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \<br>
> ><br>
> > -f ${1} \<br>
> ><br>
> > arch/${ARCH}/boot/${2}<br>
> ><br>
> ><br>
> > i.e. in arch/${ARCH}/boot/${2}<br>
> ><br>
> ><br>
> > It's that image which is then picked up by kernel.bbclass to install<br>
> ><br>
> > into deploydir (because KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"):<br>
> ><br>
> ><br>
> > for imageType in ${KERNEL_IMAGETYPES} ; do<br>
> ><br>
> > # kernel-fitimage class deploys fitImages, skip here<br>
> ><br>
> > if [ "$imageType" != "fitImage" ]; then<br>
> ><br>
> > base_name=${imageType}-${KERNEL_IMAGE_NAME}<br>
> ><br>
> > install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}<br>
> ><br>
> > $deployDir/${base_name}.bin<br>
> ><br>
> > fi<br>
> ><br>
> > done<br>
> ><br>
> ><br>
> > Only it's doesn't because of the filter against fitImage.<br>
> ><br>
> ><br>
> ><br>
> > To check I'm not seeing some strange artefact of our BSP or<br>
> > linux-ti-staging (or any other layer we're using):<br>
> ><br>
> > $ git clone git://<a href="http://git.yoctoproject.org/poky" rel="noreferrer" target="_blank">git.yoctoproject.org/poky</a><br>
> <<a href="http://git.yoctoproject.org/poky" rel="noreferrer" target="_blank">http://git.yoctoproject.org/poky</a>><br>
> > $ cd poky<br>
> > $ . oe-init-build-env<br>
> > $ cat << EOF >> conf/local.conf<br>
> > MACHINE = "beaglebone-yocto"<br>
> > KERNEL_CLASSES += " kernel-fitimage"<br>
> > KERNEL_IMAGETYPES = "fitImage"<br>
> > EOF<br>
> > $ bitbake linux-yocto<br>
> ><br>
> > The FIT images we then have:<br>
> ><br>
> > $ find tmp/deploy/images/beaglebone-yocto -name 'fit*.bin' -type f<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916134100.bin<br>
> ><br>
> > And what is:<br>
> ><br>
> > $ bitbake u-boot-mkimage-native -caddto_recipe_sysroot<br>
> > $ oe-run-native u-boot-mkimage-native mkimage -l<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916134100.bin<br>
> > Running bitbake -e u-boot-mkimage-native<br>
> > GP Header: Size a0e1 LoadAddr a0e1<br>
> ><br>
> > Revert c2d00e2f83cdf3d2923660448756ed29296a06a6 and try again:<br>
> ><br>
> > $ git revert c2d00e2f83cdf3d2923660448756ed29296a06a6<br>
> > $ bitbake linux-yocto<br>
> ><br>
> > This time there's two images:<br>
> ><br>
> > $ find tmp/deploy/images/beaglebone-yocto -name 'fit*.bin' -type f<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin<br>
> ><br>
> > And what they are:<br>
> ><br>
> > $ oe-run-native u-boot-mkimage-native mkimage -l<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin<br>
> > Running bitbake -e u-boot-mkimage-native<br>
> > FIT description: U-Boot fitImage for Poky (Yocto Project Reference<br>
> > Distro)/4.18.3+gitAUTOINC+7341720391_eba03655e8/beaglebone-yocto<br>
> > Created: Sun Sep 16 14:14:47 2018<br>
> > Image 0 (kernel@1)<br>
> > Description: Linux kernel<br>
> > Created: Sun Sep 16 14:14:47 2018<br>
> > Type: Kernel Image<br>
> > Compression: uncompressed<br>
> > Data Size: 6381368 Bytes = 6231.80 KiB = 6.09 MiB<br>
> > Architecture: ARM<br>
> > OS: Linux<br>
> > Load Address: 0x80008000<br>
> > Entry Point: 0x80008000<br>
> > Hash algo: sha1<br>
> > Hash value: 909137524ffd28b5b0ac51ea39c648b09902dc18<br>
> > Image 1 (fdt@am335x-bone.dtb)<br>
> > Description: Flattened Device Tree blob<br>
> > Created: Sun Sep 16 14:14:47 2018<br>
> > Type: Flat Device Tree<br>
> > Compression: uncompressed<br>
> > Data Size: 33030 Bytes = 32.26 KiB = 0.03 MiB<br>
> > Architecture: ARM<br>
> > Hash algo: sha1<br>
> > Hash value: 0fece12f15fc5ac6c452d9308cd374c2c0cfea47<br>
> > Image 2 (fdt@am335x-boneblack.dtb)<br>
> > Description: Flattened Device Tree blob<br>
> > Created: Sun Sep 16 14:14:47 2018<br>
> > Type: Flat Device Tree<br>
> > Compression: uncompressed<br>
> > Data Size: 34782 Bytes = 33.97 KiB = 0.03 MiB<br>
> > Architecture: ARM<br>
> > Hash algo: sha1<br>
> > Hash value: 337f6843020cb8fbaf119b43fd748222d32e72df<br>
> > Image 3 (fdt@am335x-bonegreen.dtb)<br>
> > Description: Flattened Device Tree blob<br>
> > Created: Sun Sep 16 14:14:47 2018<br>
> > Type: Flat Device Tree<br>
> > Compression: uncompressed<br>
> > Data Size: 33286 Bytes = 32.51 KiB = 0.03 MiB<br>
> > Architecture: ARM<br>
> > Hash algo: sha1<br>
> > Hash value: 4974e8b1656cd7f52829ac3c01f6747bece87cbc<br>
> > Default Configuration: 'conf@am335x-bone.dtb'<br>
> > Configuration 0 (conf@am335x-bone.dtb)<br>
> > Description: 1 Linux kernel, FDT blob<br>
> > Kernel: kernel@1<br>
> > FDT: fdt@am335x-bone.dtb<br>
> > Hash algo: sha1<br>
> > Hash value: unavailable<br>
> > Configuration 1 (conf@am335x-boneblack.dtb)<br>
> > Description: 0 Linux kernel, FDT blob<br>
> > Kernel: kernel@1<br>
> > FDT: fdt@am335x-boneblack.dtb<br>
> > Hash algo: sha1<br>
> > Hash value: unavailable<br>
> > Configuration 2 (conf@am335x-bonegreen.dtb)<br>
> > Description: 0 Linux kernel, FDT blob<br>
> > Kernel: kernel@1<br>
> > FDT: fdt@am335x-bonegreen.dtb<br>
> > Hash algo: sha1<br>
> > Hash value: unavailable<br>
> > $ oe-run-native u-boot-mkimage-native mkimage -l<br>
> ><br>
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin<br>
> > Running bitbake -e u-boot-mkimage-native<br>
> > GP Header: Size a0e1 LoadAddr a0e1<br>
> ><br>
> > --<br>
> > Alex Kiernan<br>
> <br>
> <br>
> <br>
> -- <br>
> Alex Kiernan<br>
> <br>
> <br>
> <br>
> -- <br>
> Leon Woestenberg<br>
> <a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a> <mailto:<a href="mailto:leon@sidebranch.com" target="_blank">leon@sidebranch.com</a>><br>
> T: +31 40 711 42 76<br>
> M: +31 6 472 30 372<br>
> <br>
> Sidebranch<br>
> Embedded Systems<br>
> Eindhoven, The Netherlands<br>
> <a href="http://www.sidebranch.com" rel="noreferrer" target="_blank">http://www.sidebranch.com</a> <<a href="http://www.sidebranch.com/" rel="noreferrer" target="_blank">http://www.sidebranch.com/</a>><br>
> <br>
> <br>
> <br>
> <br>
<br>
<br>
-- <br>
Best regards,<br>
Marek Vasut<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-7318857044726254343gmail_signature"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Helvetica">Leon Woestenberg</div><div style="color:rgb(0,0,0);font-family:Helvetica"><a href="mailto:leon@sidebranch.com" style="color:rgb(17,85,204)" target="_blank">leon@sidebranch.com</a></div><div style="color:rgb(0,0,0);font-family:Helvetica"><div>T: +31 40 711 42 76</div><div>M: +31 6 472 30 372</div></div><div style="color:rgb(0,0,0);font-family:Helvetica"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica">Sidebranch</div><div style="color:rgb(0,0,0);font-family:Helvetica">Embedded Systems</div><div style="color:rgb(0,0,0);font-family:Helvetica">Eindhoven, The Netherlands</div><a href="http://www.sidebranch.com/" style="color:rgb(17,85,204);font-family:Helvetica" target="_blank">http://www.sidebranch.com</a><div><br></div><div><img src="http://www.sidebranch.nl/sites/default/files/images/unnamed.png" style="color: rgb(0, 0, 0); font-family: Helvetica;"><br></div><div><br><div><br></div></div></div></div></div></div>