Posts by Hans Kessels

    Even in Startintf they don't work. On this carrier board there is also a power button and with this button the processor starts (not always) but not with the reset button.

    After a reset on the Startintf the processor board does not react immediately. Only after a while (~10-60sec) it performs the reset.

    I think the best is to send the 2 boards I have back to you as it seems the Boot fail of the IMX6 is still prevalent.

    In the past there were boot fail problems on the imx6: IMX6 Solo intermittent boot-up failures - NXP Community

    But some of the solutions were workarounds and later corrected in the silicon (these 2 boards are on AC revision)

    Some workarounds, e.g. an external watchdog might not have worked.

    115AC6: Intermittent boot fail

    115AFE: Constant boot fail

    We did some more analysing as the boards seem to work normal in the F&S Startintf (demo carrier board). We cannot get it in the Boot fail state using the Startintf.

    On our carrier board we noticed a reset can lead to boot start of the WEC board only after several seconds delay. A reset on the Startintf immediately starts the boot.

    So after checking once more the power requirements (5Vcc and 5V_STB) the difference in carrier boards is that Startintf is equipped with alot more peripheral. The question arises if there are any signals on the Goldfinger connector which can't be left dangling?

    For eaxmple there are PWRBTN, LIDBTN and SLP_BTN. Then there are several SUS_ lines.

    Any idea?


    We have a several of these boards coming back from customers with an intermittent problem (screen stays black, not running software). After investigating, the boards sometimes start up ok but mostly no bootloader kicks in. There is no output on debug serial port.

    We run with F3S file system. I've noticed with these boards (even ok boards) sometimes they take ~7 seconds before debug output is produced from bootloader.

    LED on the board is lit (orange) which is normal.

    In this vegetative state nothing helps, no reset, no powercycle. Only after been powered off for a while they come back to normal when powered.

    I read in the documentation about Boot Fail on HW rev 1.1 till 1.3.

    We have rev 1.31.

    What can we measure on the boards to confirm it is still Boot Fail?

    ok, this works and I see improvement in the serial comms of the application. The application gets sent 16x 4k chunks without any Ack/Nak of individual packets.
    Previously it occasionally missed packets and either the retry was correct or I got an overrun reported in the .net stack.
    I guess we reached some critical point with the packet size of 4k. With the driver having a buffer of 2k it meant the application at 460kBaud had to clear this buffer in about 40ms. The application uses the OpenNet serial port which is not highly efficient but at least it uses a dedicated receive thread. I guess the differences (QBliss vs QBlissR2) in observed behavior in this can be explained because of time spent in thread context switch (which might be different in both versions).

    With the 10k buffer it has more time taking in the data sent in quick succession. I would be happy to run with this.

    Can you replace the original csp_serial.dll in our custom OS image with this 10k version?

    Thanks for the csp file with the increased buffer, however we don't make the OS image ourselves. Can I somehow use this file and load it on the system? Or can you build the image with the increased buffer so I can test it?

    'Overrun' error is sporadically shown on the r1 board that we use. On r2 error is always thrown.

    This overrun has to do with the HW buffer or OS driver buffer. Not the application SW buffer.

    Have you done these test?

    Forgot to mention we're not using RTS/CTS

    Using COM2 which I believe is mapped to UART2 on A9 and UART3 on A9r2 (if this wasn't the case it wouldn't work at all)

    And just had an Overrun on the r1 also at first (second time running it was not produced)

    We're on QBlissA9.

    I've used both UseDMA and RXDMAEnable so we can disregard it.

    Yes it the normal Windows API. CLearCommError and WaitCommEvent. It is actually the code from OpenNETCF.IO.Serial.Port

    ok, regardless of these settings (I tried them in every way) I have still Overrun errors on the r2 board.

    Under which conditions does the r2 produce this Overrun error? The r1 board does not produce it, I have never seen it when I run the exact same software.

    We are not using this r2 in production but I am curious about this error and why it happens on r2 and not on r1. Have we hit a limitation?

    According documentation I can't do anything about such an error. It comes from the UART driver itself.

    BTW is the DMA setting 'RXDMAEnable' or 'UseDMA' ?

    This is the custom kernel.

    I tried again this but still overruns on the second 4k datablock received with DMA and prio set.

    The OpenNetCF library serial port is used. It sets threadpriority.Highest.

    Seems that r2 has problem, but I really like to know if DMA is enabled on the non-r2 we use in production. Do I check by seeing till which baud rate I can go?

    Like to get r2 board working


    On the QBlissA9r2 (quad core) I get Overruns while on the QBlissA9 I have no problems using the same software.

    So I enabled DMA as in your post about UART performance.

    Is there an indication in the log to check if it is enabled? The overruns persists even with DMA registry setting and I know on the r2 there is a different UART numbering (so I tried both UART settings in registry)

    At startup the device reads several 4k messages from serial port at 460k baud

    Ok, I set up dev environment which was easy thanks to your VirtualBox image. So now I can build with above settings. Unfortunately not a glimp on the HDMI output.

    I've also checked your other sticky post of setting up specific displays.

    In the tty console output I get : (relevant hdmi lines only)


    mxc_vpu 2040000.vpu_fsl: VPU initialized

    mxc_vdoa 21e4000.vdoa: i.MX Video Data Order Adapter(VDOA) driver probed

    mxc_hdmi_cec soc:hdmi_cec@00120000: can't get/select CEC pinctrl


    imx-audio-hdmi sound-hdmi: hdmi-hifi.0 <-> soc:hdmi_audio@00120000 mapping ok


    No state is present for card imxhdmisoc

    Found hardware: "imx-hdmi-soc" "" "" "" ""

    Hardware is initialized using a generic method

    No state is present for card imxhdmisoc


    I wonder if I need to tell kernel to use hdmi using the bootargs (video=mxcfb0:dev=hdmi). Please advice how to do this, or is something else wrong?



    I am just starting with Linux on QBliss9r2 with SKIT baseboard. I've put SDCard contents from fsimx6-B2020.04 onto USB stick and it installs linux. However after reset I don't get the login prompt.

    No display on the HDMI output, is there something special you have to do?

    log.txt attached


    • log.txt

      (13.32 kB, downloaded 316 times, last: )