Tegraparser_v2 behaves differently between L4T 35.4.1 and L4T 32.7.4

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

I am working on getting a signing server that is compatible with L4T 35.4.1 tooling. Given this fragment from a flash layout xml:

        <partition name="DATA" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> -1 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 0x808 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename>DATAFILE</filename>
            <description> **Required.** Automatically takes all remaining space on the device except that
              occupied by the `secondary_gpt` partition. Allocation attribute must be set to 0x808.
              May be mounted and used to store user data. </description>
        </partition>

The signing server’s tooling which wraps L4T tooling will just touch both APPFILE and DATAFILE creating zero length files. The point at which tegraflash_internal.py calls tegraflash_generate_index_file to run this command:

tegraparser_v2 --pt flash.xml.bin --generateflashindex flash.xml.tmp flash.idx

will fail with File read failed with L4T 35.4.1 tooling while L4T 32.7.4 tooling succeeds. Since tegraparser_v2 is a binary for which no source is available I used strace to show the differences between the two runs. It appears that APPFILE is ignored completely while DATAFILE is attempted to be processed (a dummy DATAFILE that is of zero length). Here is what strace shows:

For L4T 32.7.4 (works):

open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)                                = 0
open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)                                = 0
open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)

For L4T 35.4.1 (fails):

open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)                                = 0
open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)                                = 0
open("DATAFILE", O_RDONLY|O_LARGEFILE)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(3, "", 0)                          = 0
close(3)                                = 0
write(1, "File read failed\n", 17File read failed
)      = 17

Can you please confirm the change in behavior of the tool and whether current behavior is the desired behavior. If it is then a work-around must be developed.

3

hello chad.mcquillen

I would like to say there’re lots of change for tegraparser_v2, it’s expected to behaves differently between L4T 35.4.1 and L4T 32.7.4
such File read failed may returned if the read bytes is zero.

4

OK, thank you for confirming.