Yes, there is a possibility to use directly the u-boot-imx recipe and the linux-fslc-imx recipe from meta-fsl-arm layer (the only one I kept). I don't know how reliable they are. The best option is to keep good sources in the UDOO team/community repositories like the same branch with different config files for different hardwares. Ther is no reason to make a new branch for specific hardware, neither a hard to maintain fork. The URL of my meta-udoo layer: https://gitlab.com/cyrilfr/meta-udoo
I'm agree with Graugans, it could be great if you can use gitHub and fork your image from graugans repositories (i have just create mine yesterday --> krogoth-modjo) In this way we can go to the same way and share more easily our patch/upgrade ! if you would use the new uBoot branch, we can create a krogoth-next branch for this and in the same way add support for kernel 4.1 (today i'm trying to use an egalax usb touch screen but apparently the kernel 3.14 have a bug with it ...) @cyrilf , i saw that you would use qt5. Did you build the sdk ? because since this week i have an issue with it, see here Did you meet the same ?
I prefer to work with GitLab but I won't maintain my layer so graugans's layer stay the work base. I'll share my progression for my different goals if you're interested in. I moved back to revision 7271b51aeb519414c0de20de077916dac33085e2 until the issue is fixed. If the UDOO U-Boot repository is correctly maintained, it's much easier to work with it. A friend of me was working on mainline kernel to use the last version. Personally I don't care about kernel version for embedded devices but I'll try to get some information. @modjo I'm not far enough to build the Qt5 SDK. I still tweak my image for my needs (with pretty long compile time period...).
I added a Pull Request with a proposal to switch to the fsl (NXP) u-boot with UDOOfication patch applied
@cyrilf ntp related there seems to be a bug in the 3.14 line of kernel which prevents to update time. I am not sure if this is fixed in UDOO kernels. I'll check Details when in the office. At work we decided to switch to chrony instead of ntpd because it fits our needs best https://chrony.tuxfamily.org/ Gesendet von meinem FP2 mit Tapatalk
NFS related with bitbake -e you can list all variables http://www.crashcourse.ca/wiki/index.php/BitBake_Tutorial#Listing_the_environment grep is your friend Gesendet von meinem FP2 mit Tapatalk
dtc is the device tree compiler, this comes handy when debugging device-tree currently loaded. With the option -I fs you can create a dts from the current device tree which is provided in /proc/device-tree mmc-utils was added during Seco A62 eMMC test. I'll move this to A62 or completly remove it i2c-tools comes handy with I2C devices it allows you to peek and poke with i2c screen is a terminal multiplexer and allows you to use it a serial monitor for example for communication with the Arduino core imx-gpu-viv This is the vivante graphic drivers user land part binutils objdump and friends, sometimes useable for debugging. Can be removed imx-gpu-viv-demos demo tools to check functionality of the graphic driver
@graugans What's the bug with NTPd exactly? I know what's the issue with NFS. nfs-utils and rcpbind are part of the "nfs" packagegroup in packagegroup-base and are also in packagegroup-core-full-cmdline-sys-services of packagegroup-core-full-cmdline. Unfortunatelly, I didn't find a solution to remove them. Even Code: IMAGE_INSTALL_remove = "nfs-utils rpcbind" doesn't work. Thanks for the package list, I'll add screen and imx-gpu-viv to the image.
As far as I remember it is a ioctl returning false. In ntpd it is not checked and so time is not adjusted. I have to check patches at the office tomorrow Gesendet von meinem FP2 mit Tapatalk
OK. Here is the commit responsible of the kernel crash with Quad/Dual I guess : https://github.com/UDOOboard/uboot-imx/commit/8d413a0aed66ea8e368cfe13bdee9b22371a5f79 I'll try to build the Qt5 SDK and compile a Qt app for test tomorrow.
@graugans I do use this trick to save disk space. I bought a new 500GB hard drive so this should be OK today. I'm not sure if this bug concerns the NTP package in OpenEmbedded, it seems to be an old bug (2015). @modjo Nice! I'll try to compile a sample app today. PS: meta-ruby is totally useless for Qt5. To look at dependencies: Code: bitbake -u depexp -g udoo-image-qt5 I removed those useless layers from bblayers.conf: meta-fsl-arm-extras meta-fsl-demos meta-multimedia meta-ruby
@cyrilf Yes, the NTP patch was merged into fsl kernel already. When it is save for you you can remove those layers. The ruby layer is not needed anymore. Thanks for pointing this out.
@modjo I tried to compile an app with Qt Creator and I get this error : Code: make: c: Command not found I added this line: Code: source /opt/poky/2.1.1/environment-setup-cortexa9hf-neon-poky-linux-gnueab right before the last line of the script at ~/Qt/Tools/QtCreator/bin/qtcreator.sh Edit: I'm now able to compile using: Code: source /opt/poky/2.1.1/environment-setup-cortexa9hf-neon-poky-linux-gnueabi && ./qtcreator Edit2: I cannot run my example app. Here is what I do: Code: scp build/browser root@<udooneo_ip>:/home/root scp src/main.qml root@<udooneo_ip>:/home/root On the UDOO: Code: # ./browser --platform eglfs QML debugging is enabled. Only use this in a safe environment. QEglFSVivIntegration will set environment variable FB_MULTI_BUFFER=2 to enable double buffering and vsync. If this is not desired, you can override this via: export QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1 Nothing appears on the screen (LVDS7).
