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-TDA4VM: Query regarding TI-PSDK QNX

Part Number: SK-TDA4VM
Other Parts Discussed in Thread: TDA4VM

We are using the QNX SDP version 7. 1 with TI PSDK versionf or our project development

RTOS - ti-processor-sdk-rtos-j721e-evm-09_00_01_01.tar.gz

QNX - ti-processor-sdk-qnx_j721e_09_00_00_03.tar.gz

Hardware - TDA4VM SK Board

And currently we are working for OTA solutions with the above components.

With the TI provided SDK, Three partitions (BOOT, QNXFS, ROOTFS) are creared with the mkcard_qnx.sh

Let summarize our understanding with the TI-SDK and QNX

1. QNX-IFS placed in the BOOT partition is mounted at '/'.

2. qnxfs partition contains the QNX file system.

3. rootfs - It contains the R5F core binaries in the /lib/firmware folder path.


Now let us explain our queries

1. Consider we placed two qnx-ifs(qnx-ifs_A and qnx-ifs_B) image in boot partition and We need to switch to new qnx-ifs(qnx-ifs_B) during run time from the next boot-up cycle, Shall we do this By changing the bootcmd in uEnv.txt?


dorprocboot=1
bootcmd=run main_cpsw0_qsgmii_phyinit;run boot_rprocs; fatload mmc 1 80080000 qnx-ifs_A; go 0x80080000
uenvcmd=boot

                                          |
                                         V

dorprocboot=1
bootcmd=run main_cpsw0_qsgmii_phyinit;run boot_rprocs; fatload mmc 1 80080000 qnx-ifs_B; go 0x80080000
uenvcmd=boot


2. If we have two partition for qnxfs (i.e qnxfs_A and qnxfs_B) and both the partitions are mounted at startup, Is there any way to make the selected one (either A or B ) as active partition.

3. We have usecase to update the R5F core binaries at runtime for that we tried to mount the rootfs partition, But the mounting is not working for us. Please find the command we used for mounting the rootfs partition.

mount -v -t ext4 -o exe=all /dev/sd0t131 /rootfs


Kindly give valuable feedback

  • Hi,

    (1) modifying the uboot command seems reasonable.  Is this a production solution being worked on, or more of a development setup?

    (2) One thought would be to mount the desired partition, to the path which is going to be used/searched, based on the environment variables.  The 2nd partition could be mounted to directory path which is not part of the search path.   Without understanding the intent of having the two partitions, will stop there.    Please note that QNX/Blackberry would have more experience in the use of the driver / filesystem which they own.

    (3) The rootfs format is ext4, which is what the Uboot requires to read the firmware libraries.  By default QNX would not be able to mount to it.  QNX/Blackberry could be contacted to see if the ext4 format is supported.    Otherwise Uboot would need to be modified to use a fat32 partition at which point the rootfs could be changed to fat32 which QNX can mount to.    Note that the SBL boot flow from SDK RTOS could also be considered.

    Regards,

    kb

  • Hi KB,

      Thanks for your quick response.

    (1) modifying the uboot command seems reasonable.  Is this a production solution being worked on, or more of a development setup?

            Ans : We are working for the production solution not for a development setup.

    (2) One thought would be to mount the desired partition, to the path which is going to be used/searched, based on the environment variables.  The 2nd partition could be mounted to directory path which is not part of the search path.   Without understanding the intent of having the two partitions, will stop there.    Please note that QNX/Blackberry would have more experience in the use of the driver / filesystem which they own

    Ans : Our intention for two partition approach(A/B Partition) is not to disturb the existing partition content during the new update (via OTA) so that if any issues raised with the new update we have the option to switch to the existing working partition. Hope this will help you give more input on this.

    (3) The rootfs format is ext4, which is what the Uboot requires to read the firmware libraries.  By default QNX would not be able to mount to it.  QNX/Blackberry could be contacted to see if the ext4 format is supported.    Otherwise Uboot would need to be modified to use a fat32 partition at which point the rootfs could be changed to fat32 which QNX can mount to.    Note that the SBL boot flow from SDK RTOS could also be considered.

    As per our understanding, QNX may not support ext4. If this is the case, how can we modify U-Boot to use a file system supported by QNX, such as DOS or FAT32?

  • Hi,

    Regarding the two partitions.   

    • My understanding would be that the intent of those partitions, is that they would be static filesystems, with no writes to them being done by S/W during runtime.   
    • With this understanding, some persistent storage would be required (or outside event), to determine which partition should be active
    • To control which partition is active there would many approaches, two I could think of are:
      1. Mount either partitionA or paritionB, to the desired directory path /active/filesystem, the other could be mounted to /inactive/filesystem
        • All search paths would point to /active/filesystem
      2. Always mount partionA to /partitionA/filesystem and partitionB to /partitionB/filesystem
        • When booting set envrionment variables to drive which filesystem will be included in the search path.

    Regarding "how can we modify U-Boot to use a file system supported by QNX, such as DOS or FAT32?", 

    • please open a separate e2e for this topic.  This will be a uboot conversation for which a different TI resource would need to be looped in.
    • As mentioned SBL boot flow could be considered as well, where the images would be loaded from boot media by the MCU R5.

    Regards,

    kb

  • Thanks again for the clarifications.

    My understanding would be that the intent of those partitions, is that they would be static filesystems, with no writes to them being done by S/W during runtime. 

     No, In our case both partitions (qnxfs_A and qnxfs_B) should not be static means These partitions will be accessed for write operations.

    Regarding "how can we modify U-Boot to use a file system supported by QNX, such as DOS or FAT32?", 

    • please open a separate e2e for this topic.  This will be a uboot conversation for which a different TI resource would need to be looped in.

    Sure , Will open separate e2e for this topic for this

  • Hi,

    Regarding the qnxfs_A and qnxfs_B and the usage of two partitions in the OTA, are there any remaining questions on this?

    QNX/Blackberry should also be contacted for system level consult on how this is best achieved with their drivers, and filesystem.

    Thank you for opening the separate thread, it has been assigned to someone knowledgeable with Uboot.

    Regards,

    kb

  • Thanyou KB for your inputs