Vmware workstation version: 11.1.4.
Host system: x-64 based processor, windows 8.1 64-bit.
1. install Ubuntu as a virtual machine.
2. Download some 32-bit libraries: sudo apt-get install libgtk2.0-0:i386 libXtst6:i386 libcanberra-gtk-module:i386
3. run qnx660 linux binary: ./qnx-sdp-6.6-20141234567.bin. Note: don’t use “sudo”. when using “sudo”, it will be installed in /opt/. then you will get “permission denied” when you try to install your headers to qnx6/target/usr/include/
4. set up qnx660 environment: . ~/qnx660/qnx660-env.sh
5. install the patches: sudo -E $QNX_HOST/usr/bin/applypatch patch-660-3851-RS5495_headers.tar
6. activate the product as described in QNX6.6.0 installation notes, if you need use Momentics IDE.
7. share folders with the host:
(1) power off the Ubuntu;
(2) right click “Ubuntu” in the library page — “settings” — “options” — “shared folders”.
(3) choose the folders to share.
(4) power on Ubuntu.
(5) the shared folders will appear under /mnt/hgfs/.
8. install svn: sudo apt-get install subversion.
9. install qnx mainline toolchain:
(1) mkdir qnx7; cd qnx7.
(2) tar -xvzf software/mainline_toolchain_2016-10-12.tar.gz .
(3) remove host/darwin; remove host/win64; remove target_sym folder;
(4) modify /opt/qnx660/qnx660-env.sh for mainline use, and run it.
10. set up environment variables: edit ~/.bashrc, add “export XXX=/mnt/hgfs/…”.
************** use SD card in Linux ——————–
(1) power down Ubundu;
(2) add SD card as a physical drive: “settings” — “hardware” — add — “hardware Disk” …. IDE type or SCSI type, it doesn’t matter
note: need check the disk number of SD card in windows first: computer management — disk managment.
See this link: https://www.htpcguides.com/how-to-use-sd-card-reader-in-vmplayer-and-vmworkstation/
volatile is mostly used in low-level C programming, when the code deals with peripheral devices, IO ports, ISRs.
With “volatile”, compiler will not do any optimisation (e.g. store the value in a register and read it back from the register) on this variable , but read the variable from the memory every time.
a few examples:
Below are two snapshots from videos. the left is the bad case, where the green line is blurred; the right is the good case. The bad case gets reproduced when switching from Android auto to RVC mode.
the screen reflection confirmed this too. below is the images in 0/win-0.
Screen combined a few windows together. this is the top window. Its transparency is SOURCE_OVER.
Open it via GIMP, the alpha of questionable area is not 255, although the majority of the image is with alpha 255. With SOURCE_OVER transparency, the pixels will blend over the pixels underneath them.
These are the bottom windows for the bad case:
This is the bottom window for the good case:
For the good case, the alpha values of the bottom window (white) are all 1s (GIMP shows 1, not 0). As it is fully transparent, there is no blending occurring.
For the bad case, the alpha values of the bottom window (blue) are 255s. so the pixels on the top window (with a non-255 alpha value) will blend over with the bottom.
change the top (RVC) window to “TRANSPARENCY_NONE”, and use alpha 255.
** alpha = opaqueness: 1 means fully opaque while 0 means fully transparent.
** Alpha blending allows pixel blending based on the alpha channel of the source pixel.
** In order to use transparency, you must use a pixel format with an alpha channel, like RGBA. Applications that want to disregard the alpha channel can choose a pixel format with an X.
Transparency can be a property of a window, or a display.
1. Window transparency
Note: the follow definitions are used by BLIT too, specified by SCREEN_BLIT_TRANSPARENCY.
2. display/pipeline transparency, defines how the graphics image from one pipeline will be combined with the graphics image of those pipelines layered below it.
3. passing window transparency to pipeline transparency
With 2 headache issues being solved, now I am relaxed. At the same time, a few things need to be learnt from.
summary of 2 issues:
#1 Kernel crash or system hang, if capture is started 5 ~ 10s after bootup. the crash point is in VPE isr handler most times. and the kernel developer’s analysis indicates that there is memory corruption.
— I have narrowed down to the VPE operation, as the issue disappeared if there is no VPE operation.
#2 Display shows stripes then system resets, if there is capture activity involved right after bootup.
— EMIF registers were corrupted (JTAG debug), most of time 32 bytes. By setting up a firewall against EMIF registers, the analysis showed that it is VIP or VPE hit the exception a few times.
I tried the VPE max_size to restrict VPDMA to write over boundry, and it doesn’t help. then, I have no idea.
There is an idea from some else: VIP initialisation might bring some issues here. so most people focused on the VIP instantiation sequence, delay, ..coordination.. If that’s the reason, it looks that nothing I can do…
Correct way to continue:
if VIP intialization doesn’t solve the problem, we need focus on the VPE driver — It is a memory corruption, where are we writing during an VPE VPDMA operation? My first idea is the VPE output buffer, and didn’t check the code clearly. .. Actually, there is another write: write descriptor, which is provided to VPDMA to write into during a VPDMA transaction.
Also, register dump and dma configuration (extremely important! as it might be initialised on the stack before being passed the the hardware) are essential if the system is still reachable (via JTAG), as they will give some clue about what might be wrong.
the dma configuration printed in issue #2 showed that a write descriptor address is a random value (as it is defined on the stack and not gets initialised to 0), which leads to VPDMA writing to EMIF registers.
We met one lockup issue recently, which was quite confusing from the symptom. There were a few facts based on the testing:
so my first impression is that the nightmare came back — when we worked on this platform a few years ago, we had a few lockups due to the un-sturdy DMA hardware and the interaction of DMA operations between capture and display — Another developer said it should have been fixed by two changes before (don’t disable DMA, don’t disable DMA channel during the capturing) and the lockup did not happen for quite a long time. However, I think he didn’t convince me as I don’t trust the hardware…
I did tried to not touch DMA channel, or touch it at a different time point, but they didn’t help. I also asked to use separate IPUs for display and capture, and got confirmed that no issues were seen in this configuration. Then, I signed: oh, the nightmare, it is the interaction of IDMaC channels..my instinct was: it is not fixable.. we probably can only try to avoid it.. it’s timing related…
OK…so the problem is here. Since separate IPUs don’t have the issue, I should not focus on the nightmare before, but think bout the issue using logical thinking: with single IPU being used, there are both hardware interaction and software interaction. we need think about the issue from both aspects.
one more thing, through the perplexing test result, there is another fact: we recently changed the code on capture side (and some shared control in display driver), it is possible the new change introduced this issue since the lockup had not seen for long time.
Eventually, with the help of JTAG, the root cause is that a kernel call between InterruptLock() and InterruptUnlock() leads to early enabling of interrupts, so a deadlock is formed. As the piece of code only gets executed when the hardware fails to clear the ready flag so(software clears it) and the deadlock is only formed when display interrupt is raised right after InterruptLock() is called. So it is rare to see..