AM6442: memory.loadRaw() warning

Hi Andrea,

Do you have TI board with you on which you could run the same procedure & see if the warning comes sometime.

Regards,

Prashant

Hi Prashant,

I have an EvalBoard with the old Sitara without secure boot; my custom board mount the production device

To test your suggestion I should change my script to manipulate .appimage files (and not .hs_fs)

It's not a short job because my script also integrates the load_dmsc(), which is different for the 2 versions of Sitara

I try to do this exercise and I'll update you

Thanks, Andrea

Hi Prashant,

using the EvalKit, the memory.loadRaw() function return "Data verification failed at address 0x81000000" ... I configured the DDR controller correctly, I don't understand the reason for this error...

While I was investigating, with my custom board I made this discovery: when loadRaw() returns the warning (Only [N] bytes are loaded from the file...), N is always greater than the real file size (for example N=16936 with a filesize of 16933 --> 3 more bytes)

The problem seems to lie in the loadRaw(): it reads more bytes than the real size of the file and, paradoxically, sets the remaining ones to 0 --- which "remaining bytes" if it read more ?

Into the same warning, I see "Unexpected end of file" ... it is possible that the .appimage.hs_fs file is not ended correctly?

This file was generated in CCS, calling the "makefile_ccs_bootimage_gen" as post-build step

Best regards, Andrea

Hi Andrea,

Thank you for debugging!! Apparantly I have replicated the issue of "Unexpected end of file". Though interestingly, the issue is random. It comes with HS-FS appimage of one example while it is not coming with HS-FS appimage of one another example.

The issue comes with the below attached image

gpio_led_blink.release.appimage.hs_fs

while it does not come with the below attached image

ospi_flash_diag.release.appimage.hs_fs

Could you also test if you see the same behaviour with the above files.

Regards,

Prashant

Hi Andrea,

Changing to 8 bit size word in loadRaw should resolve the problem. Like if I use the below command

dsCPU.memory.loadRaw(0, 0x80000000, path, 8, false);

where path variable is path to the file, I do not get any warnings.

Regards,

Prashant

Hi Prashant,

your suggestion solve the warning returned by loadRaw(), but now the application doesn't start...

my javascript uses loadRaw() to write the appimage into DDR; then a custom writer copy the data from DDR to eMMC

I will check, but I would exclude that the problem is now in this writer, because when loadRaw() does not return problems, the writer works fine and the applications start succesfully

I have to check how loadRaw() writes data in DDR by setting the parameter to 8 rather than 32... but it's not simple

Regards

Andrea

Hi Prashant,

modifying the writer, I printed the first 64 bytes that loadRaw() writes into the DDR with the parameter '8'

30 00 00 00 82 00 00 00 07 00 00 00 a0 00 00 00
30 00 00 00 82 00 00 00 05 00 00 00 88 00 00 00
a0 00 00 00 03 00 00 00 02 00 00 00 01 00 00 00
02 00 00 00 02 00 00 00 14 00 00 00 41 00 00 00

Opening the appimage file with a binary reader, this is its content

As you see, the bytes of the appimage (30 - 82 - 07 ...) have been copied into memory as long words (30 00 00 00 - 82 00 00 00 - 07 00 00 00 ..); this explain why the application doesnt' start

A possible patch can be:

• force loadRaw() with parameter '8' to be sure all bytes are written into DDR (this avoids the original warning and data loss)
• then change the writer to copy from DDR to eMMC removing all the "triple 00s" in between 

It's not an elegant solution, but maybe it works

That said, I think loadRaw() with parameter=32 and appimage.hs_fs files doesn't work correctly...

What do you think?

regards, Andrea

Andrea - if you use the Memory Browser to manually load the file as a binary, do you get the same issue regarding the warning and also the application not starting?

Hi Ki,

thanks for your suggestion.

If the binary file that generates the problem with loadRaw() is loaded manually using the CCS tools --> no warning occurs and the application starts successfully

I have a question: loadRaw() reports "Unexpected end of file"; if it says this, it means that it knows the length of the binary file and, after reading, it finds an anomaly; correct? If yes, the length of the file is written somewhere, for example in an initial header. If this assumption is correct, is it possible to know how an appimage.hs_fs file is structured? In this way we can understand if the problem is inside the loadRaw() function or the file is not generated correctly.

We noticed that loadRaw() never returns the warning with nTypeSize = 8 but only with 32; I'm thinking that, after removing the header, what remains is not a multiple of 4 bytes and this would explain the "Unexpected end of file"

Best regards

Andrea Pizzato said:

If the binary file that generates the problem with loadRaw() is loaded manually using the CCS tools --> no warning occurs and the application starts successfully

It looks like when using the loadRaw API in the scripting console with typesize 32, if the last bit of data is not 32-bits it will "pad" the data. This is not happening when loading via memory view.

For example, I loaded gpio_led_blink.release.appimage.hs_fs twice. Once via loadRaw using the scripting console and once by the memory view. I filled the memory range with 0xFFFFFFFF between each load.

Loading from the Memory Browser view:

Loading from the Scripting Console:

The only difference between the two loads is the highlighted address in the image above. Hence writing that extra padded data must be causing the issue.

This is likely a bug with the loadRaw API

Thanks

ki

Ki said:

The only difference between the two loads is the highlighted address in the image above. Hence writing that extra padded data must be causing the issue.

Please confirm that this is what you observe on your end also.

Thanks

ki

To expand on this error message:

MCU_PULSAR_Cortex_R5_0: Unexpected end of file: C:/Temp/gpio_led_blink.release.appimage.hs_fs. Only 27992 bytes are loaded from the file into the memory and the remaining bytes are set to zero.

Basically with a typesize of 32, I guess the API was expecting the data to end on a 32-bit alignment and it did not, hence the "unexpected end of file" and padded the remaining data with zero, hence  "the remaining bytes are set to zero"

I confirmed that I observe the same phenomenon; in my case, this is the situation

Loading from the Memory Browser

Loading from the Scripting Console

I'm not able to explain 00007F00 instead of FFFFFF00, but this seems to confirm a bug in the loadRaw() function

I repeated the same procedure with another appimage not returning warning with loadRaw(); in that case, there is no difference in the end-of-file dump

Loading from the Memory Browser --> 0000BD80 F0000000 FFFEE320 0000EAFF and then all FFFFFFFF

Loading from the Scripting Console --> 0000BD80 F0000000 FFFEE320 0000EAFF and then all FFFFFFFF

Andrea