Yes it should work but you will have to activate it in the device tree too.
in arch/arm/boot/dts/qblissa9r2q.dts set #define CONFIG_QBLISSA9R2_MXCFB to DISPLAY_HDMI
Bit without the GPU, X11 can not start so you only will get the bare framebuffer for now.
Your F&S Support Teeam
Hello,
I am currently not able to reproduce this issue.
Do you have any extra load on the CPU?
Which Display are you using?
Your F&S Support Team
I attached a compiled qblisa9r2q device tree with disabled GPU to this post. (qblissa9r2q.zip)
Please use this for now
Your F&S Support Teeam
Hello,
We can reproduce the issue. The system seems to hang when initializing the GPU.
A quick workaround would be to disable the GPU in the qblissa9r2q device tree:
Add the following lines to the bottom of arch/arm/boot/dts/qblissa9r2q.dts:
Recompile and install the new qblissa9r2q.dtb to the board.
We will further investigate this issue and come back to you.
Your F&S Support Team
Hello,
there seem to be some issues with portaudio and blue-alsa regarding sample rate:
https://github.com/Arkq/bluez-alsa/issues/232
Maybe you could try different sample rates or update to a newer blue-alsa version?
Your F&S Support Team
Hello,
are you using Buildroot or Yocto?
Your F&S Support Team
Hello Michele ,
interesting project.
Did you try to activate Target packages -> Networking applications -> bluez-tools in the menuconfig for bluethoothd ?
It should get installed to /usr/libexec/bluetooth/bluetoothd
Your F&S Support Team
Hello,
the SNVS_HPRTC and the SNVS_LPRTC seem to be two different RTCs. However, chapter
58.4.2 Non-secure real-time counter of the imx6sx reference manual states, that they can be synchronized but does not explain how...
The linux driver at drivers/rtc/snvs-rtc.c seems to read and write directly from/to the LPRTC but the access should be only possible with activated HPRTC, so maybe you could try to read from the LPRTC registers from the Cortex-M4 side.
For more information please read 58.4 SNVS structure of the
i.MX 6SoloX Applications Processor Reference Manual Rev. 4, 05/2020
Your F&S Support Team
Hello,
it is a know issue that some USB memory devices cause problems in Uboot.
Here is a quote from an other discussion:
Display MoreThe USB protocol has a 16 bit value for the count of data blocks that can be transferred in one go. In other words up to 65535 data blocks with 512 bytes each, which is nearly 32MB. From the protocol, there are no restrictions given for this 16 bit value. However in real life, some USB sticks seem to have problems when the maximum value 65535 is used. Then they simply don't answer anymore, which results in USB protocol timeouts. From my point of view these USB sticks do not implement the protocol correctly.
We have fixed this issue partly in the U-Boot that was part of the fsimx6-V3.0, fsimx6sx-V2.0 and fsimx6ul-V2.0 releases, by restricting the value to be used to 65534. This worked fine for a couple of USB sticks that we had by that time and that were showing this issue.
Nonetheless I say partly, because we have observed a new issue with some USB sticks in the meantime. If the USB stick is very very slow, then reading and transferring these many blocks does take so much time that a data timeout happens. The timeout is set to a fix five seconds. So these slow sticks do need longer than 5 seconds to transfer 32MB of data, i.e. they can provide less than 54 MBit/s of data. USB 2.0 should be capable of delivering up to 480 MBit/s, so these sticks are really slow.
So in the meantime, we have reduced the maximum number of blocks to transfer in one go further down to 32768 blocks. Up to now we did not have any problems anymore. However this fix was added after the last Buildroot releases (fsimx6-V3.1, fsimx6sx-V2.1, fsimx6ul-V2.1), but it is already part of the current Yocto releases (fsimx6-Y1.0, fsimx6sx-Y1.0, fsimx6ul-Y1.0). So if you want an U-Boot with this patch, download the Yocto release and extract the U-Boot source package from there.
Of course for boards that are already in the field, you simply should use a stick that is 1) fast enough and that 2) can deliver 65535 blocks of data in one go. But do not ask me how you can decide this by just looking at the device...
Your F&S Support Team
Which release are you using?
Your F&S Support Team
Hello Stefan,
the PicoCOM9X uses an extern RTC connected via I2C by default, as it is more precise.
If you set the RTC time to the system-time with the hwclock -w command, it will set the extern RTC, not the intern RTC.
If both RTCs are activated in your system you should see multiple RTCs at /dev/rtcX.
You can set a specific RTC by using the command hwclock -w --rtc=/dev/rtcX.
Please make sure to protect shared peripherals from simultaneous access by using e.g. Semaphores.
Unfortunately, NXP did not implement RDC_Sema42 in the Linux Kernel, but you can use the normal Sema4.
The driver drivers/char/imx_amp/imx_sema4.c can be used on Linux side, while the example
freertos/examples/fsimx6sx/demo_apps/sema4_demo can be used on Cortex-M4 side.
Your F&S Support Team
Hello,
we have reuploaded the OVA image. Please try to import it again.
We have also uploaded a MD5SUM. You can check if your download was correct by computing your local MD5SUM with the PowerShell commend
certutil.exe -hashfile <PATH\TO\YOUR\OVA> MD5
We have also noticed that the error Result Code: E_INVALIDARG (0x80070057 also can occur, if there is not enough disc space left, so please make sure that you have at least 30GB available.
If it still does not work please send a mail to sales@fs-net.de and you will recive a alternative download link.
Your F&S Support Team
Hello,
There seems to be a problem with our download server.
We will check on that issue and come back to you as soon as possible.
Your F&S Support Team
Hello,
Yes it should be also available in fsimx6-V3.0., but you should update if you can afford it, as the new release offers a lot of bug fixes and performance improvements and is better supported.
Your F&S Support Team
Hello,
Which release are you using?
In fsimx6-B2020.06 the TUN/TAP driver can be activated in the Linux kernel menuconfig at
Device Drivers -> Network device support -> Network core driver support -> Universial TUN/TAP device support
You can either add CONFIG_TUN=y to arch/arm/configs/fsimx6_defconfig to your linux-fsimx6 kernel
or run make linux-menuconfig in your buildroot directory and select it by hand.
Either way, you have to run make linux-reconfigure to rebuild the kernel and use the new kernel on your board. You should get the device /dev/net/tun
Your F&S Support Team
Hello,
did you copy the content of install.scr or install.txt?
Also, did you try to use the install.txt file from the source/ directory of the release directly to create the install.scr?
There might be some special characters in your test.txt that lead to this behavior.
Your F&S Support Team
New document version 0.3
- A chapter about remote debugging with Visual Studios 2019 and the VSRemoteDebugger extention was added.
Your F&S Support Team
Touchscreen Fix for 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22)
The Touchscreen of the 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22) is not working with the following combination:
Boards: PcoreMX8MM-V1-LIN, PcoreMX8MM-V13-LIN [Rev1.3]
Adapter: ADP-MIPI2MIPI1 [Rev 1.2]
Display: 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22)
Releases: Y2021.04, B2021.06
To fix this, you can either apply the attached patch to the Linux Kernel and rebuild the device tree or make the following U-boot settings:
Run the following command in the U-boot console:
Edit the $fdt variable and add the command run fix_EE0350_touch befor the booti command. For example
( The $fdt variable may look different, depending on where the device tree is loaded from)
Boot, the board. The touchscreen should work now.
Your F&S Support Team
Touchscreen Fix for 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22)
The Touchscreen of the 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22) is not working with the following combination:
Boards: PcoreMX8MM-V1-LIN, PcoreMX8MM-V13-LIN [Rev1.3]
Adapter: ADP-MIPI2MIPI1 [Rev 1.2]
Display: 3.5" MIPI-DSI Display mit PCAP Touch ( B.LCD.22)
Releases: Y2021.04, B2021.06
To fix this, you can either apply the attached patch to the Linux Kernel and rebuild the device tree or make the following U-boot settings:
Run the following command in the U-boot console:
Edit the $fdt variable and add the command run fix_EE0350_touch befor the booti command. For example
( The $fdt variable may look different, depending on where the device tree is loaded from)
Boot the board. The touchscreen should work now.
Your F&S Support Team
