Hi Makumba,
I read your post and your English is excelent..
You can download all pdf's from the product webpage, including linux First Steps document. There on page 10 it mentions if U-boot is missing or corrupt.
Check this post:
flash from zero PicoCore imx8mn ddr3
you can download Recovery.zip for MfgTool2 to put U-boot on the board. Hopefully it is ok for your revision board.
Good luck
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
I've only got one at the moment on my desk, If serial number is equal to MAC address then it ends in 115AC6
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?
Hi,
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?
Is there an update on this? Can you confirm it is a driver problem?
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
Hi,
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
I was trying this already yesterday but I couldn't figure out how to add fsimx6 configs to the main buildroot.
Just copying in the f+s folder isn't enough
Hello,
We use imx6 board and I wonder if WPE can be supprted for Buildroot.
Apparently it is best lean option for running browser frontend.
It is there for other boards so I wanted to see what is needed for fsimx6 support?
Can I see imx differences and see if these can be implemented on the buildroot-WPE sources?
regards
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?
regards
BTW is display on HDMI supported?
I don't have a Linux dev system. Just starting off with migrating from CE to Linux...
Hi,
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
