cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
bg_viv
Observer
Observer
336 Views
Registered: ‎05-19-2021

Issue enabling MMU in Vitis 2020.2

Hello,

I am experiencing an issue when enabling the MMU in an application project in Vitis 2020.2.

This project involved migrating a workspace from SDK 2018.2 to Vitis 2020.2. I began by following the Xilinx migration guide https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Step-By-Step-Guide-To-Xilinx-SDK-Project-Migration-To-Vitis/ba-p/1050061 but unfortunately the project would not successfully import.

From there I recreated the workspace manually by creating a platform from an XSA created in Vivado 2020.2, and using the SDK source files for each project to recreate them in Vitis, this approach resulted in all of the projects building with all build configurations successfully. 

After this creating was done, a response to this post was made that explained how to solve the import issue I was originally experiencing: https://forums.xilinx.com/t5/Vitis-Acceleration-SDAccel-SDSoC/Unable-to-read-in-MSS-file-during-import-to-Vitis/m-p/1248970. This process was tested and it led to the same workspace setup where all the projects could be built with all their build configurations.

Since these workspaces were built successfully, the next step was testing them on the FPGA. Note that in the following tests the exact same results were seen for the first created workspace (created manually with SDK source files) as seen in the second workspace created (following the import recommendation in the above forum post). 

The first test was programming the Flash with a generated .bin file, when done for the project in SDK the flash programmed successfully and the board was able to boot. When done with the project in Vitis, the flash programmed successfully according to the console; however, the board would not boot upon reset, and showed an error state.

This led to testing through the debugger. The debugger was setup to run one of the applications, breakpoints were put into the boot.S file (platform > psu_cortexa53_0 > standalone_domain > bsp > psu_cortexa53_0 > libsrc > standalone_v7_3 > src > boot.S). It was determined that after enabling the MMU (line 289), the debugger would get caught in a SynchronousInterruptHandler inside asm_vectors.S after line 291 (See image below for the section of code in boot.S). 

bg_viv_0-1625747180209.png

A hello_world application was created from the standard template and loaded onto the board to test if this was an issue with the application specifically. The hello_world application successfully passed the above section of code in boot.S and displayed Hello World as expected.

The next step was to introduce small parts of the real application (that was being debugged and failing) into the hello_world application (that was running). We found that everything was fine if we included header files, but the minute we added, or even linked in any function not in the original hello_world application, the resulting application would fail at the aforementioned MMU enablement. Furthermore, once that error had occurred, it would remain, even if the addition/linkage was rolled back. The only way to get hello_world working again was to create a fresh application from scratch.

We’re stumped as to what is the root cause of this issue (we’re not convinced its simply an MMU error given the way it persists even if we remove the error-causing conditions). Furthermore, this is preventing us from migrating from the old SDK environment to Vitis, which is a real issue in terms of long term support and maintenance for our application.

Has anyone seen this sort of issue in their own migration attempts? Does anyone have any ideas for further experiments that we could perform to try and better understand the issue, or potential fixes for it? Any and all assistance would be greatly appreciated. Thank you.

3 Replies
maps-mpls
Mentor
Mentor
246 Views
Registered: ‎06-20-2017

>We found that everything was fine if we included header files, but the minute we added, or even linked in any function not in the original hello_world application, the resulting application would fail at the aforementioned MMU enablement. Furthermore, once that error had occurred, it would remain, even if the addition/linkage was rolled back. The only way to get hello_world working again was to create a fresh application from scratch.

That is strange.  The code you added runs after the suspect code in boot.S, if I am reading this right. 

1.  Did you remove the code and then exit out of Vitis, power down the card?  I cannot reconcile your need to recreate the project from scratch.

2.  What does your linker script look like? 

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
0 Kudos
ericv
Scholar
Scholar
220 Views
Registered: ‎04-13-2015

@bg_viv , when enabling the MMU and a Sync trap occurs, the two most probable causes I'm aware of are:

- Invalid MMU table address or erroneous MMU table

- The code where the MMU enable (it crashes there) is located in an invalid area in the MMU table.

A quick way to zoom into the problem is to put a break-point at the "msr SCTLR_EL3, x1" and look at what is in the memory address held in X1. The MMU tables are multi-level tables. So you'll have to look at the 64 bit value held in X1 (that's level #0 table); the next level table is that value (ignore the least 2 bit, they are 0b11). Look where your code is located in the map file (not the script file as non-declared sections end up in no man's land) and check the contents of the level #1 table. You'll have to dig into this doc (MMU section) how to interpret that table.

https://developer.arm.com/documentation/ddi0500/d/

I hope this help

 

0 Kudos
ericv
Scholar
Scholar
197 Views
Registered: ‎04-13-2015

@bg_viv , the instruction to break on is msr TTBR0_EL3, x1 ; not the one I wrote in my previous post

0 Kudos