Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Collapse
Brand Logo

ModalAI Forum

  1. ModalAI Support Forum
  2. Ask your questions right here!
  3. VOXL2 kernel version

VOXL2 kernel version

Scheduled Pinned Locked Moved Ask your questions right here!
17 Posts 3 Posters 2.8k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Alex KushleyevA Alex Kushleyev

    @jcai , i will try to do the build on native linux machine just in case. Can you confirm you did not make any changes to the kernel source or build scripts before building?

    Alex

    J Offline
    J Offline
    jcai
    Contributor
    wrote on last edited by
    #7

    @Alex-Kushleyev Yeah, no changes

    Alex KushleyevA 1 Reply Last reply
    0
    • J jcai

      @Alex-Kushleyev Yeah, no changes

      Alex KushleyevA Offline
      Alex KushleyevA Offline
      Alex Kushleyev
      ModalAI Team
      wrote on last edited by
      #8

      @jcai , I was able to successfully build the m0054 kernel by following the exact instructions from here : https://docs.modalai.com/voxl2-kernel-build-guide/

      The first time, i did get an error:

      Cloning into bare repository '/home/user/build_mount/lu.um.1.2.1/apps_proc/downloads/git2/github.com.dex4er.fakechroot.git'...
      fatal: unable to access 'https://github.com/dex4er/fakechroot.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
      

      but this must have been a temporary web glitch, as it worked by just re-running the build.

      When you say that you ran the build as root, how exactly did you do that? Did you run as root first then as non-root? if so, it is possible that root user created directories that are not writable by normal user, in which case you may need to clean and build from scratch.

      Alex

      J 1 Reply Last reply
      0
      • Alex KushleyevA Alex Kushleyev

        @jcai , I was able to successfully build the m0054 kernel by following the exact instructions from here : https://docs.modalai.com/voxl2-kernel-build-guide/

        The first time, i did get an error:

        Cloning into bare repository '/home/user/build_mount/lu.um.1.2.1/apps_proc/downloads/git2/github.com.dex4er.fakechroot.git'...
        fatal: unable to access 'https://github.com/dex4er/fakechroot.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
        

        but this must have been a temporary web glitch, as it worked by just re-running the build.

        When you say that you ran the build as root, how exactly did you do that? Did you run as root first then as non-root? if so, it is possible that root user created directories that are not writable by normal user, in which case you may need to clean and build from scratch.

        Alex

        J Offline
        J Offline
        jcai
        Contributor
        wrote on last edited by
        #9

        @Alex-Kushleyev I was only able to follow the guide exactly until I got into the container. From there , all the scripts inside were run with sudo. Otherwise, I would get permission issues like below.

        4c7a03fc-8a11-420f-b199-13cd23bfc368-image.png

        Alex KushleyevA 1 Reply Last reply
        0
        • J jcai

          @Alex-Kushleyev I was only able to follow the guide exactly until I got into the container. From there , all the scripts inside were run with sudo. Otherwise, I would get permission issues like below.

          4c7a03fc-8a11-420f-b199-13cd23bfc368-image.png

          Alex KushleyevA Offline
          Alex KushleyevA Offline
          Alex Kushleyev
          ModalAI Team
          wrote on last edited by
          #10

          @jcai , as this is a permissions issue, can you please check the following:

          inside docker

          ls -lah /home/user/build_mount/lu.um.1.2.1/apps_proc
          

          and outside docker

          ls -lah ~/qrb5165-kernel-build-docker/workspace/lu.um.1.2.1/apps_proc
          

          In my case, all the folders that were created inside the docker container are owned by my actual username on the host machine (and permissions are drwxr-xr-x for the directory apps_proc and others. This means only the owner can write to it. But inside docker, the ownership is shown as user user, so docker is writing as user and on the host machine it is written on my actual username's behalf.

          user@098ef18e8424:~/build_mount/lu.um.1.2.1/apps_proc$ ls -lah
          total 80K
          drwxr-xr-x  10 user user 4.0K Oct  9 15:45 .
          drwxr-xr-x   3 user user 4.0K Oct  9 15:31 ..
          drwxr-xr-x   6 user user 4.0K Oct  9 16:31 build-qti-distro-ubuntu-fullstack-perf
          drwxr-xr-x   2 user user  20K Aug 23  2022 deb_premirror_packages
          drwxr-xr-x   5 user user 4.0K Oct  9 15:37 disregard
          drwxr-xr-x  13 user user  28K Oct  9 16:29 downloads
          drwxr-xr-x  34 user user 4.0K Oct  9 15:38 poky
          drwxr-xr-x   7 user user 4.0K Oct  9 15:37 .repo
          lrwxrwxrwx   1 user user   27 Oct  9 15:38 setup-environment -> poky/qti-conf/set_bb_env.sh
          drwxr-xr-x  25 user user 4.0K Oct  9 15:38 src
          drwxr-xr-x 177 user user 4.0K Oct  9 16:29 sstate-cach
          

          It is possible that in your case something is not working, i am curious what the ownership shows.

          Alex

          1 Reply Last reply
          0
          • J Offline
            J Offline
            jcai
            Contributor
            wrote on last edited by
            #11

            On the host:

            jcai@jcai-VirtualBox:~/qrb5165-kernel-build-docker/workspace/lu.um.1.2.1/apps_proc$ ls -lah
            total 48K
            drwxr-xr-x  8 root root 4.0K Oct  9 15:42 .
            drwxr-xr-x  3 root root 4.0K Oct  8 13:03 ..
            drwxrwxr-x  2 1001 1001  20K Aug 23  2022 deb_premirror_packages
            drwxr-xr-x  5 root root 4.0K Oct  8 17:27 disregard
            drwxr-xr-x  2 root root 4.0K Oct  9 09:49 downloads
            drwxr-xr-x 34 root root 4.0K Oct  9 15:25 poky
            drwxr-xr-x  7 root root 4.0K Oct  9 15:23 .repo
            lrwxrwxrwx  1 root root   27 Oct  8 17:33 setup-environment -> poky/qti-conf/set_bb_env.sh
            drwxr-xr-x 25 root root 4.0K Oct  8 17:31 src
            
            

            In Docker:

            user@8de0065c2813:~/build_mount/lu.um.1.2.1/apps_proc$ ls -lah
            total 48K
            drwxr-xr-x  8 root root 4.0K Oct  9 19:42 .
            drwxr-xr-x  3 root root 4.0K Oct  8 17:03 ..
            drwxrwxr-x  2 1001 1001  20K Aug 23  2022 deb_premirror_packages
            drwxr-xr-x  5 root root 4.0K Oct  8 21:27 disregard
            drwxr-xr-x  2 root root 4.0K Oct  9 13:49 downloads
            drwxr-xr-x 34 root root 4.0K Oct  9 19:25 poky
            drwxr-xr-x  7 root root 4.0K Oct  9 19:23 .repo
            lrwxrwxrwx  1 root root   27 Oct  8 21:33 setup-environment -> poky/qti-conf/set_bb_env.sh
            drwxr-xr-x 25 root root 4.0K Oct  8 21:31 src
            
            

            Yeah, ownership looks like an issue here

            Alex KushleyevA 1 Reply Last reply
            0
            • J jcai

              On the host:

              jcai@jcai-VirtualBox:~/qrb5165-kernel-build-docker/workspace/lu.um.1.2.1/apps_proc$ ls -lah
              total 48K
              drwxr-xr-x  8 root root 4.0K Oct  9 15:42 .
              drwxr-xr-x  3 root root 4.0K Oct  8 13:03 ..
              drwxrwxr-x  2 1001 1001  20K Aug 23  2022 deb_premirror_packages
              drwxr-xr-x  5 root root 4.0K Oct  8 17:27 disregard
              drwxr-xr-x  2 root root 4.0K Oct  9 09:49 downloads
              drwxr-xr-x 34 root root 4.0K Oct  9 15:25 poky
              drwxr-xr-x  7 root root 4.0K Oct  9 15:23 .repo
              lrwxrwxrwx  1 root root   27 Oct  8 17:33 setup-environment -> poky/qti-conf/set_bb_env.sh
              drwxr-xr-x 25 root root 4.0K Oct  8 17:31 src
              
              

              In Docker:

              user@8de0065c2813:~/build_mount/lu.um.1.2.1/apps_proc$ ls -lah
              total 48K
              drwxr-xr-x  8 root root 4.0K Oct  9 19:42 .
              drwxr-xr-x  3 root root 4.0K Oct  8 17:03 ..
              drwxrwxr-x  2 1001 1001  20K Aug 23  2022 deb_premirror_packages
              drwxr-xr-x  5 root root 4.0K Oct  8 21:27 disregard
              drwxr-xr-x  2 root root 4.0K Oct  9 13:49 downloads
              drwxr-xr-x 34 root root 4.0K Oct  9 19:25 poky
              drwxr-xr-x  7 root root 4.0K Oct  9 19:23 .repo
              lrwxrwxrwx  1 root root   27 Oct  8 21:33 setup-environment -> poky/qti-conf/set_bb_env.sh
              drwxr-xr-x 25 root root 4.0K Oct  8 21:31 src
              
              

              Yeah, ownership looks like an issue here

              Alex KushleyevA Offline
              Alex KushleyevA Offline
              Alex Kushleyev
              ModalAI Team
              wrote on last edited by
              #12

              @jcai , yes it looks like all the folders have root ownership, and the build script does not like being run as root, however non-root cannot write to those folders.

              Please try to run the build from scratch, removing the workspace folder and running the sync, patch, build scripts as non-root. After you sync, please check the ownership of the folders, if root is the owner, the same issue will happen.

              If after build and sync, the folders are owned by root, you can try to do the following from your docker container after running sync and patch (which seem to work fine, right?):

              • sudo chown -R user:user ~/build_mount/

              This will make user the owner of those files and folders (recursively)

              Alternatively you can assign all permissions to all users for this build folder

              • sudo chmod -R 777 ~/build_mount/

              And then run the actual build as user

              Alex

              J 1 Reply Last reply
              0
              • Alex KushleyevA Alex Kushleyev

                @jcai , yes it looks like all the folders have root ownership, and the build script does not like being run as root, however non-root cannot write to those folders.

                Please try to run the build from scratch, removing the workspace folder and running the sync, patch, build scripts as non-root. After you sync, please check the ownership of the folders, if root is the owner, the same issue will happen.

                If after build and sync, the folders are owned by root, you can try to do the following from your docker container after running sync and patch (which seem to work fine, right?):

                • sudo chown -R user:user ~/build_mount/

                This will make user the owner of those files and folders (recursively)

                Alternatively you can assign all permissions to all users for this build folder

                • sudo chmod -R 777 ~/build_mount/

                And then run the actual build as user

                Alex

                J Offline
                J Offline
                jcai
                Contributor
                wrote on last edited by
                #13

                @Alex-Kushleyev I've managed to get the build working, thanks! I think the problems started because my initial docker image was built with sudo. Removing the workspace folder and starting from scratch got everything set up as user.

                I'm now attempting to test the build using:

                adb reboot bootloader
                fastboot boot your_new_kernel.img
                

                Are there specific drivers I need to download? Once I put the voxl into bootloader, VirtualBox can't detect the device anymore. The same is true on my Windows host. As a result, running fastboot boot new_kernel.img gives me a constant <waiting for any device> message. As reference, here's my device manager during normal and bootloader modes. The "Android" device also comes and goes. It usually exists for a couple seconds before disappearing.
                dee9ae26-c869-4473-8cbb-9bdb7fd12157-image.png 39832796-de23-4d67-a4fd-ef134b554d55-image.png

                Alex KushleyevA 1 Reply Last reply
                0
                • J jcai

                  @Alex-Kushleyev I've managed to get the build working, thanks! I think the problems started because my initial docker image was built with sudo. Removing the workspace folder and starting from scratch got everything set up as user.

                  I'm now attempting to test the build using:

                  adb reboot bootloader
                  fastboot boot your_new_kernel.img
                  

                  Are there specific drivers I need to download? Once I put the voxl into bootloader, VirtualBox can't detect the device anymore. The same is true on my Windows host. As a result, running fastboot boot new_kernel.img gives me a constant <waiting for any device> message. As reference, here's my device manager during normal and bootloader modes. The "Android" device also comes and goes. It usually exists for a couple seconds before disappearing.
                  dee9ae26-c869-4473-8cbb-9bdb7fd12157-image.png 39832796-de23-4d67-a4fd-ef134b554d55-image.png

                  Alex KushleyevA Offline
                  Alex KushleyevA Offline
                  Alex Kushleyev
                  ModalAI Team
                  wrote on last edited by
                  #14

                  @jcai , sometimes fastboot requires running at it as root, so please try

                  sudo fastboot boot your_new_kernel.img
                  
                  J 1 Reply Last reply
                  0
                  • Alex KushleyevA Alex Kushleyev

                    @jcai , sometimes fastboot requires running at it as root, so please try

                    sudo fastboot boot your_new_kernel.img
                    
                    J Offline
                    J Offline
                    jcai
                    Contributor
                    wrote on last edited by
                    #15

                    @Alex-Kushleyev I think this is just an issue with Windows drivers. I ended up switching over to OSX to use adb and fastboot, no issues there. I'm just using a USB drive to get the .img file from the VM to the Mac. Boot tests look good.

                    One more thing, I'm looking at the kernel build guide and there's a section that says I can enable in tree drivers by editing:

                    apps_proc/poky/meta-voxl2-bsp/recipes-kernel/linux-msm/files/m005x.cfg
                    

                    I don't have this file in my system. the closest I found is ../linux-msm/files/configs/m0054. In this directory, there's kona_defconfig and kona-perf_defconfig. What's the difference between these two files? Are these the correct files to be editing to enable, for example, CONFIG_MACVLAN?

                    Alex KushleyevA 1 Reply Last reply
                    0
                    • J jcai

                      @Alex-Kushleyev I think this is just an issue with Windows drivers. I ended up switching over to OSX to use adb and fastboot, no issues there. I'm just using a USB drive to get the .img file from the VM to the Mac. Boot tests look good.

                      One more thing, I'm looking at the kernel build guide and there's a section that says I can enable in tree drivers by editing:

                      apps_proc/poky/meta-voxl2-bsp/recipes-kernel/linux-msm/files/m005x.cfg
                      

                      I don't have this file in my system. the closest I found is ../linux-msm/files/configs/m0054. In this directory, there's kona_defconfig and kona-perf_defconfig. What's the difference between these two files? Are these the correct files to be editing to enable, for example, CONFIG_MACVLAN?

                      Alex KushleyevA Offline
                      Alex KushleyevA Offline
                      Alex Kushleyev
                      ModalAI Team
                      wrote on last edited by Alex Kushleyev
                      #16

                      @jcai ,

                      In my kernel build, the config file exists:

                      workspace$ find . -name m005x.cfg
                      ./lu.um.1.2.1/apps_proc/build-qti-distro-ubuntu-fullstack-perf/tmp-glibc/work/m0054-oe-linux/linux-msm/4.19-r0/fragments/m005x.cfg
                      ./lu.um.1.2.1/apps_proc/poky/meta-voxl2-bsp/recipes-kernel/linux-msm/files/fragments/m005x.cfg
                      

                      kona-perf_defconfig is the "performance" kernel, which is what you should be using
                      kona_defconfig is the debug version of the kernel configuration

                      I believe you can edit either the m005x.cfg config fragment or kona-perf_defconfig , since linux-msm_4.19.bbappend has the following:

                      do_configure_prepend() {
                         # We merge the config changes with the default config for the board
                         # using merge-config.sh kernel tool
                      
                         mergeTool=${S}/scripts/kconfig/merge_config.sh
                         confDir=${S}/arch/${ARCH}/configs
                         defconf=${confDir}/${KERNEL_CONFIG}
                      
                         ${mergeTool} -m -O ${confDir} ${defconf} ${CFG_FRAGMENTS}
                      
                         # The output will be named .config. We rename it back to ${defconf} because
                         # that's what the rest of do_configure expects
                         mv ${confDir}/.config ${defconf}
                         bbnote "Writing back the merged config: ${confDir}/.config to ${defconf}"
                      }
                      

                      which is merging the config fragment with the defconfig.

                      I hope this helps!

                      Alex

                      J 1 Reply Last reply
                      0
                      • Alex KushleyevA Alex Kushleyev

                        @jcai ,

                        In my kernel build, the config file exists:

                        workspace$ find . -name m005x.cfg
                        ./lu.um.1.2.1/apps_proc/build-qti-distro-ubuntu-fullstack-perf/tmp-glibc/work/m0054-oe-linux/linux-msm/4.19-r0/fragments/m005x.cfg
                        ./lu.um.1.2.1/apps_proc/poky/meta-voxl2-bsp/recipes-kernel/linux-msm/files/fragments/m005x.cfg
                        

                        kona-perf_defconfig is the "performance" kernel, which is what you should be using
                        kona_defconfig is the debug version of the kernel configuration

                        I believe you can edit either the m005x.cfg config fragment or kona-perf_defconfig , since linux-msm_4.19.bbappend has the following:

                        do_configure_prepend() {
                           # We merge the config changes with the default config for the board
                           # using merge-config.sh kernel tool
                        
                           mergeTool=${S}/scripts/kconfig/merge_config.sh
                           confDir=${S}/arch/${ARCH}/configs
                           defconf=${confDir}/${KERNEL_CONFIG}
                        
                           ${mergeTool} -m -O ${confDir} ${defconf} ${CFG_FRAGMENTS}
                        
                           # The output will be named .config. We rename it back to ${defconf} because
                           # that's what the rest of do_configure expects
                           mv ${confDir}/.config ${defconf}
                           bbnote "Writing back the merged config: ${confDir}/.config to ${defconf}"
                        }
                        

                        which is merging the config fragment with the defconfig.

                        I hope this helps!

                        Alex

                        J Offline
                        J Offline
                        jcai
                        Contributor
                        wrote on last edited by
                        #17

                        @Alex-Kushleyev Yup, editing kona-perf_defconfig looks to have worked, thanks!

                        1 Reply Last reply
                        0
                        • Alex KushleyevA Alex Kushleyev referenced this topic on

                        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                        With your input, this post could be even better 💗

                        Register Login
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        ModalAI
                        Categories Recent Tags ModalAI.com Docs
                        © 2026 ModalAI® · Accelerating autonomy for smaller, smarter, safer drones · Powered by NodeBB
                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups