This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM62: DRM issue about am62

Part Number: SK-AM62
Other Parts Discussed in Thread: IWR6843AOP, IWR6843

Hello Ti,

I follow the steps to build demo https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.0&node=A__AC5iPpi4BISWp3fFC9R3Iw__linux_academy_am62x__XaWts8R__LATEST.

Here is my log:

cd [SDK_PATH]/arago
source ./environment-setup
git clone git.ti.com/.../edgeai-building-access-refdesign
qmake -config release
make

When I started the demo, I use the command "./build/release/mmwavegesture_hmi -platform eglfs -s /dev/ttyUSB1"

The terminal appears the error message as follow:

could not queue drm page flip on screen HDMI1 (permission denied)

How to solve the problem?

Thanks.

  • Hello James,

    This happens when the window manager (Weston) is running. You can turn that off with a systemctl command:

    systemctl stop weston

    Please let me know if you have issues here.

    Regards,

    Reese

  • Hello Reese,

    I think the weston may not stop after the command used.

    There are other error messages as follow:

    Could not set DRM mode for screen HDMI (Permission denied)

    Could not queue DRM page flip on screen HDMI1 (Permission denied)
    *Failed to open port /dev/ttyusBO, error: Permission error while locking the device"

    BR

  • Hi James,

    Could you tell me what is displayed on the screen? If it is the HMI demo (looks like a control panel), then we will need to disable that demo from running so Weston can stop gracefully.

    You can also run the demo (the binary under /build/release of the repo you cloned for this) without the "-platform eglfs" tag and it will run within weston, though probably with less performance. The error you're seeing is because this application uses QT, and using that EGLFS tag tries to use the entirety of the GPU for this application.

    As to you USB error, I assume you have a mmwave radar sensor attached through USB to the AM62X, yes? Based on that error, it seems like there is another application currently holding a lock on that device. Please make sure there is not another instance of this application running. Note that you can change the port to use when running the demo with "-s /dev/DEVICE_NAME" included in command line arguments

    Best,

    Reese

  • Hi Reese,

    The HMI Demo is terminated and I tried the two ways that you have suggested:

    1. without the "-platform eglfs" tag 

    2. with the "-platform eglfs" tag 

    After the terminal shows "Creating filter", the screen dosen't show any information

    BR

  • Hi James,

    Let's back up a bit so I can get a better understanding of what you have. At this stage, you should have:

    1) an AM62x SK EVM with the default Linux image installed

    2) a camera (USB is simplest) plugged in and accessible at /dev/video0

    3) a mmWave radar device, specifically an 6843AOP EVM with the gesture recognition binary downloaded (You can find the most recent version in their industrial toolbox here: https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.1&node=A__AB3P8Iq.cVgCtrFYFhvt7Q__com.ti.mmwave_industrial_toolbox__VLyFKFf__LATEST

    - Based on the log, this is available at /dev/ttyUSB3. These devices have 2 ports and you should be using the second one (so if you have /dev/ttyUSB2 and /dev/ttyUSB3, use the latter)

    4) A monitor plugged in through HDMI, which shows either A) a black screen with "Please wait" text, which indicates no process using the GPU is running or B) a mostly blank grey screen, which indicates weston is running.

    Let's keep the "-platform eglfs" tag from now on.

    Are any of the above not true? My guess is that the default out-of-box demo (and HMI interface) is showing and is preventing you from shutting down the window manager Weston.

    Best,

    Reese

  • Hi Reese,

    The demo is follow the official document, so 1) ~ 3) absolutely match.

    If you want to comprehend further, you can refer the link that I previously provided. (https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.0&node=A__AC5iPpi4BISWp3fFC9R3Iw__linux_academy_am62x__XaWts8R__LATEST)

    Besides, the term 4) you list, both the situation do not corrospond to your description.

    The realistic situation I also said previously, the screen didn't show any information and the HMI demo was also closed by the command "systemctl stop weston".

    BTW, the USB camera has successfully detected because of the warning light itself and the screen that the HDMI connectd didn't show anything (black screen)

  • Hello,

    Before you run the mmwave demo, could you reboot the EVM and share your monitor output? Also, try running the following commands:

    1. /etc/init.d/weston stop
    2. kmstest

    Regards,
    Krunal

  • Hi Krunal,

    1. After I reboot the  EVM, the monitor output is as follow

    1. /etc/init.d/weston stop
    2. kmstest

    2. When I use th above command, the monitor output is as follow

    3.  Before I execute the mmwave demo, I use the command "systemctl stop weston" to stop the weston and then run the mmwave demo by the command  "./build/release/mmwavegesture_hmi -platform eglfs -s /dev/MMWAVE_DEVICE_NAME" .

     The monitor still shows

    BR

  • The kmstest application should have closed if you pressed "CTR+C" or pressed Enter. I do not understand why it's still running in the background and are you running the application with "&"? Also, in the earlier commands, I see you running apps with sudo and that is not necessary. 

    Regards,
    Krunal 

  • Hi Krunal,

    The method you provided is invalid  and I don't run any application before executing the mmwave demo.

    I also tried the demo wtih IWR6843ODS, it still got failure.

    BR

  • Hi James,

    Changing the device for radar will not alter the issue that you're seeing. This is an issue with a process preventing another from taking over the display interface.

    Is the 'kmstest' process running in the background? You can see what's running in real time with 'htop' or the full printout with 'ps -aux'

    For the demo to run, it should be on a black screen with small white text saying "Please Wait..."

    I would also echo what Krunal said about not running with sudo -- you're already logged in as root, and running as sudo can change some of the linux environment variables and produce unexpected behavior in this context.

    Best,
    Reese

  • Hi Reese,

    I have checked the 'kmstest' and it was terminated.

    The black screen with small white text saying "Please Wait..." will occur after the command "systemctl stop weston".

    Now, there are two situation as follow:

    1. 

    2.

    As 1 and 2, after "Creating filter", there are two situations show above.

    BTW , the monitor displays the black screen after the demo running.

    BR

  • Hi James,

    I haven't seen these two printouts before -- what you're seeing are kernel log messages (printk). The one with 'XFRM netlink socket' is ordinary, but I'm less familiar with the cp210x (serial-USB driver), but it seems like the driver is reporting errors when trying to read through this port. I'm not familiar with the EXT4-fs one either, or the mmcblk1p2 mount point it mentions  -- there is one for mmcblk1p1, but that's built into the EVM.  I'm not sure if either of those errors are relevant here.

    Before going on with any debug I'll recommend, I'd suggest swiping your hand in front of the mmWave radar part (up, down, left, right) -- give this several tries as the ML model on the radar device is quite selective in what it detects - there's human readable output through /dev/ttyUSB0 (see below for configuring this in CLI). The demo starts off with a black screen until it is woken up by a recognized gesture, so what you're seeing isn't abnormal yet.

    If the device isn't responding, let's look at USB -- I'll ask how you have the devices plugged into the EVM. This EVM unfortunately has only 1 USB port, but a USB-C to USB-A adapter can be used for the USB-c port next to the power input - this is what I did while developing this demo, but I sometimes found the adapters did not tolerate being unplugged or plugged in while the device was powered on. How are you connecting the mmWave radar's USB-cable and the camera's USB?

    One way to debug is to configure the serial port and attempt to read from it. Before doing that, you may try swapping the USB-micro cable you're using when the radar device and the EVM

    Set serial settings with:

    stty -F /dev/ttyUSB1 921600 cs8 -cstopb -parenb

    and read with:

    tail -f /dev/ttyUSB1

    You can also do the same for /dev/ttyUSB0, but use a baud of 115200 when running 'stty' instead of 921600

    Best,
    Reese

  • Hi Reese,

    I have tried to swipe my hand in front of the mmWave radar part (up, down, left, right) and the serial console has the output.

    The output I refer the mmWave demo guide are several types(such as R or U).

    Although the serial has appeared the gesture output, the monitor still maintains the balck screen.

    Is there any method to solve the issue?

    BR

  • Hi James,

    Can you send a log/screenshot of this serial output? I believe you mean they only show R or U - this is an older version of the gesture recognition software that used conventional methods. The demo that we're running on the AM62 expects a newer version that uses machine learning for up to 9 gestures. From what you say, I assume you're verified that those R or U values come through serial by reading from the /dev/ttyUSB1 interface but do not print anything in the full building-access demo.

    When this demo was created, the mmWave demo with Machine Learning for 9 gestures wasn't fully public, so we linked to the one you're referring to for setup instructions. That demo can be found here: https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.1&node=A__AB3P8Iq.cVgCtrFYFhvt7Q__com.ti.mmwave_industrial_toolbox__VLyFKFf__LATEST.You will need to download the mmWave Industrial toolkit (scroll up and click the 3 dots next to that name) - the compiled binary for this demo is under "mmwave_industrial_toolbox_4_12_1\labs\Gesture_Recognition\Gesture_with_Machine_Learning\prebuilt_binaries" - Be sure to use the 6443AOP version.

    Apologies, the instructions here have slightly changed since the original release and now. In general, the most up-to-date instructions are in the README for the git repo for the sk-am62 building access demo.

    Best,
    Reese

  • Hi Reese,

    You mean that IWR6843AOP or ODS is not compatible with the demo? 

  • Hi James,

    The IWR6843AOP is compatible with the 6443AOP image. This configuration was used when developing and testing the demo, including what we took to tradeshows. The same should be be true of ODS, but that hardware was not used in the original testing. I can confirm the IWR6843 IS compatible with this demo

    Are you still seeing issues when you flash with the code (gesture recognition with Machine Learning) that says 6443AOP? I believe the only difference between those two devices is the presence of a DSP in 6843 - that gesture recognition demo doesn't use the DSP, so it will be compatible with both devices

    Best,

    Reese.

  • Hi Reese,

    I only have IWR6843ODS now, because my IWR6843AOP got damage and I don't have 6443AOP.

    I tried to reproduce the demo and I don't receive the same resault.

    In this time, the console didn't print any log and I use the mmWave toolbox version is 4.12.0.

    BR

  • Hi James,

    I understand. I believe at this point we've gotten past the original issue with the "DRM" error. My recommendation at this point is to make a separate e2e thread with mmwave radar (Sensors forum) if you cannot see any data coming over the interface when you flash the ODS device with the image meant for that device.

    I would mention again that to check the device is giving some output over either one of the serial ports. The ttyUSB0 should be 115200 baud and ttyUSB1 should be 921600. The one at lower baud should be human readable, but please refer to that demo's documentation to confirm

    Best,
    Reese