|
Re: MTD UBI undefined reference failed to build OE gatesgarth branch
JH
Thanks for your response.
I am sorry, I thought that is what meta-freescale for, right? NXP might involve the coding, but is it integrated and released by Yocto / OE https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/, right? I cloned meta-freescale from Yocto project: git://git.yoctoproject.org/meta-freescale, I am sorry, I really lost. |
|
|
|
Re: MTD UBI undefined reference failed to build OE gatesgarth branch
Andrey Zhizhikin
Hello Jupiter,
On Fri, Jan 15, 2021 at 8:32 PM JH <jupiter.hce@...> wrote: From all the build logs you have, it look to me that you're trying to build the U-Boot delivered by NXP as a part of their BSP release. In this case, I suggest you'd rather contact NXP support in order to address this failure, since it is a vendor BSP you're trying to upgrade. In addition, I do not think that all mailing lists you've cross-posted your question to would be able to help you here: - linux-mtd list is not really appropriate to solve U-Boot build issues; - u-boot list is for upstream U-Boot patches and discussions, which is way past over 2020.04 version (not even considering that you're building U-Boot from NXP fork); - oe-core is not a proper list to post questions specific to one SOC vendor; - meta-freescale 'gatesgarth' branch does not have any U-Boot build configuration for mx6ull_14x14_evk_nand_config, the only available build config provided is for sd card; Having all those points above, I'd suggest you contact NXP support at first to see if they can solve those build errors for you. If you would find a solution, you can send a PR to meta-freescale to address it - this would be much appreciated.
-- Regards, Andrey. |
|
|
|
Re: MTD UBI undefined reference failed to build OE gatesgarth branch
JH
Hello,
The mtd build was fine, what could be missing not to link mtd? $ ls 2020.04-r0/build/mx6ull_14x14_evk_nand_config/drivers/mtd built-in.o mtdcore.su mtdpart.o mtd_uboot.o mtd-uclass.o nand spi mtdcore.o mtd.o mtdpart.su mtd_uboot.su mtd-uclass.su onenand ubi On 1/15/21, Jupiter <jupiter.hce@...> wrote: Hello, -- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs |
|
|
|
MTD UBI undefined reference failed to build OE gatesgarth branch
JH
Hello,
I was able to build MTD, UBI and u-boot on OE version Zeus branch, but failed in gatesgarth branch. Here are errors, what could I be missing? u-boot-imx/2020.04-r0/git/cmd/ubi.c:478: undefined reference to `mtd_probe_devices' u-boot-imx/2020.04-r0/git/cmd/ubi.c:484: undefined reference to `put_mtd_device' u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1161: undefined reference to `put_mtd_device' u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1229: undefined reference to `get_mtd_device_nm' u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:1407: undefined reference to `mtd_read' u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:279: undefined reference to `mtd_write' u-boot-imx/2020.04-r0/git/drivers/video/cfb_console.c:2025: undefined reference to `video_hw_init' u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51: undefined reference to `dm_spi_claim_bus' u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55: undefined reference to `dm_spi_xfer' u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58: undefined reference to `dm_spi_release_bus' u-boot-imx/2020.04-r0/git/Makefile:1701: recipe for target 'u-boot' failed make[1]: *** [u-boot] Error 1 WARNING: exit code 1 from a shell command. There are a couple of warning messages I am not sure if they are important or just nonsense, like CONFIG_DEFAULT_DEVICE_TREE has already been defined but it complained: Device Tree Source is not correctly specified. Please define 'CONFIG_DEFAULT_DEVICE_TREE' or build with 'DEVICE_TREE=<device_tree>' argument u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51:8: warning: implicit declaration of function 'dm_spi_claim_bus'; did you mean 'spi_claim_bus'? [-Wimplicit-function-declaration] 51 | ret = dm_spi_claim_bus(dev); | ^~~~~~~~~~~~~~~~ | spi_claim_bus @ u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55:8: warning: implicit declaration of function 'dm_spi_xfer'; did you mean 'spi_xfer'? [-Wimplicit-function-declaration] 55 | ret = dm_spi_xfer(dev, priv->nregs * 8, priv->buffer, NULL, | ^~~~~~~~~~~ | spi_xfer u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58:2: warning: implicit declaration of function 'dm_spi_release_bus'; did you mean 'spi_release_bus'? [-Wimplicit-function-declaration] 58 | dm_spi_release_bus(dev); | ^~~~~~~~~~~~~~~~~~ | spi_release_bus Appreciate your advice. Thank you very much. Kind regards, - jupiter |
|
|
|
Enable Etnaviv driver for IMX8MQ
Dylan Laduranty
Hello, I would like to know if it is possible to use Etnaviv driver
instead of IMX-GPU-VIV on the IMX8MQEVK for hardware acceleration
? Did someone already manage to setup such configuration in a
Yocto build ? Best regards --
Dylan Laduranty |
|
|
|
Re: i.mx8mm desktop environment
Otavio Salvador
Hello, Em qua., 9 de dez. de 2020 às 12:21, Erhan via lists.yoctoproject.org <erhan14=yahoo.com@...> escreveu:
Yes, this is technically viable but I strongly advise you use at least dunfell for this. Zeus release is not being actively maintained anymore. On meta-openembedded there are some packagroup and a lot of recipes for this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|
|
|
i.mx8mm desktop environment
Erhan
Sorry if this is the wrong mailing list. We want to build a desktop environment for i.mx8m mini EVK. As only wayland is supported with GPU acceleration which desktop environments we can build out of the box from the BSP (Gnome, LXDE etc.)? Is there a documentation or defined package-group to build a full desktop environment with GPU support. We are using zeus release. Regards Erhan |
|
|
|
Re: Using a .dtb built with kernel from Yocto 3.1.1 with u-boot from Yocto 3.1.2 results in "base fdt does did not have a /__symbols__ node ..."
Brian Hutchinson
I made an error in my original post. It was when I moved from Yocto 3.1.2 to 3.1.3 that I noticed this whole:
"failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND base fdt does did not have a /__symbols__ node make sure you've compiled with -@ No Space for dtb ERROR: system-specific fdt fixup failed: FDT_ERR_NOTFOUND - must RESET the board to recover. FDT creation failed! hanging...### ERROR ### Please RESET the board ###" ... business, which appears to be associated with u-boot because I can dd if=imx-boot-imx8mmevk-sd.bin of=/dev/mmcblk2 bs=1k seek=33 using u-boot image from Yocto 3.1.2 and the issue goes away. dd=if . So nobody has seen this before??? Regards, Brian |
|
|
|
Using a .dtb built with kernel from Yocto 3.1.1 with u-boot from Yocto 3.1.2 results in "base fdt does did not have a /__symbols__ node ..."
Brian Hutchinson
I have no clue what my problem is here.
I built imx8mm-evk.dtb (kernel version 5.4.51) in Yocto meta-freescale environment from Dunfell/Yocto 3.1.1, and then moved on to Dunfell/Yocto 3.1.2. Looks like u-boot version changed during that time. Small bump in kernel version too. When I copy imx8mm-evk.dtb from previous Yocto release into my sdcard image built with Dunfell/Yocto 3.1.2 I get the following on boot: BuildInfo: - ATF b0a00f2 - U-Boot 2020.04-imx_v2020.04_5.4.24_2.1.0+g4979a99482 switch to partitions #0, OK mmc2(part 0) is current device flash target is MMC:2 Net: eth0: ethernet@30be0000 Fastboot: Normal Normal Boot Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc2(part 0) is current device 21621248 bytes read in 87 ms (237 MiB/s) Booting from mmc ... 43774 bytes read in 10 ms (4.2 MiB/s) ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Using Device Tree in place at 0000000043000000, end 000000004300dafd failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND base fdt does did not have a /__symbols__ node make sure you've compiled with -@ No Space for dtb ERROR: system-specific fdt fixup failed: FDT_ERR_NOTFOUND - must RESET the board to recover. It appears to be something with u-boot because if I flash sdcard with u-boot from previous Yocto release the issue goes away. I'd like to understand what is going on and why this is happening. Regards, Brian |
|
|
|
Re: #yocto #meta-java
#yocto
#meta-java
Andrey Zhizhikin
On Tue, Nov 10, 2020 at 8:30 PM Richard Leitner
<richard.leitner@...> wrote: I believe the reason is NXP provides their vendor BSP based on zeus, hence the author opted to checkout corresponding branch in meta-java. Therefore I would recommend to switch to dunfell or gatesgarth ifThis is a good suggestion that I would follow! There was a blog post [1] on how to build a "poky" upstream distro and not using NXP-specific BSP. This should assist in switching from NXP BSP to community one. It already provides dunfell compatibility, and has NXP release 5.4.24-2.1.0 integrated. [1]: https://yoctoproject.blogspot.com/2020/09/how-to-build-core-image-minimal-with.html -- Regards, Andrey. |
|
|
|
Re: #yocto #meta-java
#yocto
#meta-java
Richard Leitner
Hi,
On Tue, Nov 10, 2020 at 08:47:46AM -0800, feki.ayman94@... wrote: [Edited Message Follows]I guess that should read "origin/zeus"? 😉 Is there a specific reason why you're using zeus? I'm asking because I'm currently not maintaining the zeus branch of meta-java (as it's EOL). Therefore I would recommend to switch to dunfell or gatesgarth if possible. regards;rl I did modify bblayers.conf and local.conf as per the guide. |
|
|
|
#yocto #meta-java
#yocto
#meta-java
Hello;
I'm working on a Ubuntu 18.04 machine. and NXP release L5.4.24 for IMX8M Mini. I did successfully "bitbake" my custom image. Then I am trying to add support for openjdk-8. Referred "How to add openjdk to Yocto Layers " I did "git checkout -b zeus origin/zueus" I did modify bblayers.conf and local.conf as per the guide. But when I tried to do "bitbake openjdk-8", got following error: Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:01 Sstate summary: Wanted 122 Found 87 Missed 35 Current 368 (71% match, 92% complete) NOTE: Executing Tasks NOTE: Setscene tasks completed ERROR: ecj-bootstrap-native-1.0-r1 do_prepare_recipe_sysroot: The file /usr/include/gc.h is installed by both bdwgc-native and cacao-native, aborting ERROR: Logfile of failure stored in: /home/ayman/YOCTO/imx_repo/menzu/tmp/work/x86_64-linux/ecj-bootstrap-native/1.0-r1/temp/log.do_prepare_recipe_sysroot.14496 ERROR: Task (/home/ayman/YOCTO/imx_repo/sources/meta-java/recipes-core/ecj/ecj-bootstrap-native.bb:do_prepare_recipe_sysroot) failed with exit code '1' NOTE: Tasks Summary: Attempted 1032 tasks of which 1029 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/ayman/YOCTO/imx_repo/sources/meta-java/recipes-core/ecj/ecj-bootstrap-native.bb:do_prepare_recipe_sysroot Summary: There was 1 ERROR message shown, returning a non-zero exit code. Would you please provide some pointers to resolve this issue? Thanks and regards.
|
|
|
|
Re: Cannot run "devtool mofidy linux-fslc" in Dunfell branch
bartvanderlaan
Hi, I'm facing the exact same issue. This is the ("same") message after updating to 5.4.72 on poky 3.2 to see if that would resolve the issue.
ERROR: Execution of '/home/user/project/build/tmp/work/imx7d_pico-poky-linux-gnueabi/linux-fslc/5.4.72+gitAUTOINC+3bd0fd4e0f-r0/devtooltmp-l63mos0r/temp/run.do_preconfigure.32540' failed with exit code 2: /home/user/project/build/tmp/work/imx7d_pico-poky-linux-gnueabi/linux-fslc/5.4.72+gitAUTOINC+3bd0fd4e0f-r0/devtooltmp-l63mos0r/temp/run.do_preconfigure.32540: 160: /home/user/project/build/tmp/work/imx7d_pico-poky-linux-gnueabi/linux-fslc/5.4.72+gitAUTOINC+3bd0fd4e0f-r0/devtooltmp-l63mos0r/temp/run.do_preconfigure.32540: cannot open /home/user/project/build/tmp/work/imx7d_pico-poky-linux-gnueabi/linux-fslc/5.4.72+gitAUTOINC+3bd0fd4e0f-r0/devtooltmp-l63mos0r/workdir/defconfig: No such file WARNING: exit code 2 from a shell command. Would one of you be so kind to give me some pointers where to start resolving this? Thanks! |
|
|
|
Re: Cannot run "devtool mofidy linux-fslc" in Dunfell branch
Ks89 <stefano.cappa.ks89@...>
I'm still having the same issue. I cannot run devtool modify linux-fslc. I'm using dunfell with imx6ullevk. Il mar 4 ago 2020, 16:27 Ks89 via lists.yoctoproject.org <stefano.cappa.ks89=gmail.com@...> ha scritto:
|
|
|
|
Re: [IMX6Q][Dunfell] Problem using imxeglvivsink on top of X11
Otavio Salvador
https://github.com/Freescale/meta-freescale
toggle quoted message
Show quoted text
Em ter., 20 de out. de 2020 às 14:28, Wouter Vanhauwaert <w.vanhauwaert@...> escreveu:
--
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|
|
|
Re: [IMX6Q][Dunfell] Problem using imxeglvivsink on top of X11
Wouter Vanhauwaert
Ehm, which github?
And would anyone be able to reproduce it at his side? (so I know it's not just me ;-)) |
|
|
|
Re: Enabling ION with CMA heap on imx6
Carlos Rafael Giani
Yes, this happened in the past. However, the benefits of DMA-BUF outweigh this IMO. I also have the libimxdmabuffer library to encapsulate such details.
toggle quoted message
Show quoted text
The alternative is to rely on IPU/VPU/etc. specific allocators, which come with more significant downsides. On 20.10.20 13:38, Andrey Zhizhikin wrote:
On Tue, Oct 20, 2020 at 10:19 AM Carlos Rafael Giani via |
|
|
|
Re: Enabling ION with CMA heap on imx6
Carlos Rafael Giani
For i.MX8 it is enabled already. On 20.10.20 13:31, Otavio Salvador
wrote:
Hello Carlos, Em ter., 20 de out. de 2020 às 05:19, Carlos Rafael Giani via lists.yoctoproject.org <crg7475=mailbox.org@...> escreveu:On i.MX6 machines, it is currently not possible to use the ION allocator. However, there is no hardware limitation that requires ION to be disabled. If ION were enabled, with a CMA heap, then it would be possible for userspace to allocate DMA-BUF buffers. I could then enable the ion packageconfig in the libimxdmabuffer recipe. The defconfig only needs these additions: CONFIG_ION=y CONFIG_ION_SYSTEM_HEAP=y CONFIG_ION_CMA_HEAP=y I tried it out, worked fine. Using DMA-BUF for allocating physically contiguous memory (via CMA) is preferable over using other allocators (like the ones from the VPU, IPU etc.) since it allows for proper buffer sharing, ownership transfer, is based on FDs (though physical address are accessible via an NXP extension), and there are extensions in OpenCL, OpenGL etc. for importing DMA-BUF. V4L2 also has DMA-BUF support. Opinions?Please prepare the PR for it; also see if i.MX8 couldn't also benefit from it. |
|
|
|
Re: [IMX6Q][Dunfell] Problem using imxeglvivsink on top of X11
Otavio Salvador
Em ter., 20 de out. de 2020 às 05:28, Wouter Vanhauwaert
<w.vanhauwaert@...> escreveu: Ok, so I did the same with distro fsl-x11 distro (same local.conf as above, only changed distro) and issue prevails.Please open an issue on github so we can hook NXP people on it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|
|
|
Re: Enabling ION with CMA heap on imx6
Andrey Zhizhikin
On Tue, Oct 20, 2020 at 10:19 AM Carlos Rafael Giani via
lists.yoctoproject.org <crg7475=mailbox.org@...> wrote: From the past experience I had with ION allocators in the past, I would try to refrain from using it. It is still residing in staging folder, which means that the API compatibility is not guaranteed. I had an experience where Application used ION in 4.4.y kernel, and should be re-written when 4.9.y kernel has been released due to significant changes in the ION UAPI. I would personally not recommend using it until it would be moved from staging to drivers. If one plans to base development on ION API - this should be taken into consideration. -- Regards, Andrey. |
|
|