cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
7,017 Views
Registered: ‎05-31-2011

MMU Hardware exception while Xilkernel initialization for Microblaze Virtual mode execution

Hello,

 

I am using a XUPV5-LX110T evaluation platform board to run xilkernel on the MMU-enabled Microblaze (virtual mode), s.t.C_USE_MMU = 3.
Trying to run the xilkernel_posix_threads_demo application from the template xilkernelon EDK/SDK 13.1.
However, the execution does not proceed beyond xilkernel_init() function.
The execution jumps into the exception handler module and keeps looping there due to multiple TLB miss exceptions.
I traced the execution flow and discovered that the VM mode initialization in the mpu_init() function is responsible for this execution flow break .
When the VM mode initialization section is commented out, the execution continues for the main thread and it keeps looping in the idle_task() (which it should do).
However a master process, though created, is not scheduled for execution and never executes(or may be prematurely terminated).
Could someone give some feedback as to why the virtual mode initialization leads to a TLB miss during the mpu initialization step?
Note: The application works fine for the hardware generated with (C_USE_MMU<=1)

 

Thanks.
0 Kudos
17 Replies
Highlighted
Visitor
Visitor
7,004 Views
Registered: ‎05-31-2011

 just wanted to add some update.

I discovered that after the VM mode enabling, the application incurs a TLB miss because the TLB is not updated with instruction addresses while mpu initialization.

However, even after i add the tags and RPN entries in tlbhi and tlblo registers during mpu initialization, the application still incurs a TLB miss immediately after the VM mode initialization.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,991 Views
Registered: ‎10-08-2010

It is possible the issue has to do with the linker script.

 

Since the MMU uses fixed page sizes from 1KB, the linker script must take this into account by aligning sections on 1KB boundaries, which is not done in the automatically created linker script. This is described in the "OS and Libraries Document Collection" UG643, in the chapter "Memory Protection".

 

I attach a linker script that works for me.

 

Highlighted
Visitor
Visitor
6,976 Views
Registered: ‎05-31-2011

Great. That actually worked. When i align the text, data, readonly data and stack sections to 1KB boundary, the execution proceeds to completion without any hardware MMU exception.

In my previous attempt, i initialized the MPU with the entries corresponding to the address range of all the segments as generated in the linker script, but it did not work. However they were not 1KB aligned. I guess, this is a xilinx implementation specific requirement.

 

Thanks a lot stefana.

0 Kudos
Highlighted
Observer
Observer
6,450 Views
Registered: ‎12-24-2009

it's appeared, this script working for XILINX POSIX THREAD DEMO, but not for any application accessing peripherals.

 

could you help to fix it? I can't use GPIO API, etc - all crashing with the error (0x8140000C - XPS_GPIO address):

 

Platform initialized

 

xil kernel initialized

 

init thread appended

 

THREAD_ACTIVATED

 

XMK: pid (1) performed illegal operation @ PC (0x48012BB4),

 

fault code: (0x12). \0x09fault address: (0x8140000C).

 

XMK: Terminating (1).

0 Kudos
Highlighted
Observer
Observer
6,426 Views
Registered: ‎12-24-2009

file sw/lib/bsp/xilkernel_v5_01_a/src/src/arch/microblaze/mpu.c line 167

 

appeared to have commented out block with important tracing information.
the problem disappear once the following block being uncommented:

 

                DPRINTF ("XMK: TLB %d region: 0x%x - 0x%x, size: 0x%x, access: 0x%x.\r\n", tlbindex, base & sizemask[sizeindex],
                (base & sizemask[sizeindex]) + area_size - 1,
                tlbsizemask >> 7, tlbaccess >> 8);

 

More over this issue:

if VERBOSE is enabled, TLB run-out makes XilKernel run without MPU but no hanging:

 

XMK: Out of TLB entries.

XMK: Add TLB entries for System I/O ranges - failed

XMK: MPU Initialization failed. Kernel will run without memory protection.

XMK: System initialization.

Platform initialized

 

xil kernel initialized

 

XMK: Process scheduling starts.

init thread appended

 

THREAD_CAN_ACTIVATED

 

 

 

ngpio_initGpioCan : CAN gpio init succeeded

Initial data = 0

Intermediate data = 1

final data = 1

PWON flag is Wake-up from Sleep

 

but if VERBOSE is not enabled, XilKernel intend to use MPU even with TLB run out of entries:

 

XMK: Add TLB entries for System I/O ranges - failed

XMK: MPU Initialization failed. Kernel will run without memory protection.

XMK: System initialization.

Platform initialized

 

xil kernel initialized

 

XMK: Process scheduling starts.

init thread appended

 

THREAD_CAN_ACTIVATED

 

XMK: pid (1) performed illegal operation @ PC (0x48012D54),

\0x09fault code: (0x12).

\0x09fault address: (0x8140000C).

XMK: Terminating (1).

 

from my chair I believe it shouldn't be a relative config settings, but they are.

I suggest somebody in Xil open a BR about this issue.

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,425 Views
Registered: ‎10-08-2010

The I/O ranges should be automatically enumerated when the BSP is generated, to ensure that the processor will allow access to the peripherals. Look in the file microblaze_0/include/config/config_init.h in the BSP. I have attached an example of this file from my project.

 

If this doesn't work for some reason, you can always define your own I/O ranges. For details see http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_6/oslib_rm.pdf page 41.

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,422 Views
Registered: ‎10-08-2010

The DPRINTF is intended for debugging the TLB assignments, and should normally remain commented out. I suspect the reason it works now is that you regenerated the BSP. Could that be the case?

 

0 Kudos
Highlighted
Observer
Observer
6,416 Views
Registered: ‎12-24-2009

unfortunately NO, I'm always re-generating BSP once some modifications being done inside.

 

so far the ONLY working solution being found is to replace ALL DPRINTF with actual xil_printf in place inside mpu.c and mb-hw.c files. attached are the working version ones.

 

modification #define inside decls.h didn't helped however (no idea why).

0 Kudos
Highlighted
Observer
Observer
6,414 Views
Registered: ‎12-24-2009

my range is a bit longer, so it appear, 64 TLB isn't enough

 

by the way, your "lithium" seems like having attachment types failure, only ZIP files are accepted

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,599 Views
Registered: ‎10-08-2010

That explains your issue. Unfortunately, with Xilkernel the 64 TLB entries is a hard limit.

 

There are two possible workarounds:

1. Manually coalesce some of the adjacent I/O ranges in config_init.h. The coalesced ranges should match one of the possible TLB entry sizes (1, 4, 16, 64, 256 KB; 1, 4, 16 MB). Make sure to save the modified config_init.h, since it is regenerated and overwritten when the BSP is rebuilt.

2. Change the linker script to ensure that each section requires as few TLB entries as possible. This can be done by aligning the section end to the nearest TLB entry size.

 

0 Kudos
Highlighted
Observer
Observer
5,596 Views
Registered: ‎12-24-2009

the non-switching back to non-MPU mode defect in case if TLB run out of size, which is working only in VERBOSE mode for now, cound't be solved by your proposal to use less TLB elements. it's clear not the problem cause but the work around.

 

by the way it could be much easier to avoid TLB overflow if xilkernel_v2_1_0.tcl could be able to skip driver address space selected as NONE.

 

I'm attaching to you my version of xilkernel_v2_1_0.tcl having this fix in place.

in brief you have to avoid using non-smart xget_hw_bus_slave_addrpairs procedure (line 569), instead compare peripheral regions with MHS file list before adding new region into the list:

 

            set addrlist [list]

        set ipinst_list [xget_hw_ipinst_handle $mhs_handle "*"]
        foreach ipinst $ipinst_list {

        set ipname [xget_value $ipinst "NAME"]
        set addr_params [xfind_addr_params $ipinst]
        foreach arg $addr_params {
            set value [xget_param_value $ipinst $arg]
            if {$value != ""} {
            set value [xformat_addr_string $value $arg]
            set drv_handle [xget_sw_driver_handle_for_ipinst $sw_proc_handle $ipname]
            if { $drv_handle != "" } {
                lappend addrlist $value
            }
            }
        }
        }

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,587 Views
Registered: ‎10-08-2010

Thank you for the updated Tcl. I will create an internal change request to get this included in Xilkernel.

 

I will also look into including an automatic coalesce of I/O ranges. It should be relatively straight forward to add that to the Tcl function.

 

Let me know if you need any more assistance.

0 Kudos
Highlighted
Observer
Observer
5,583 Views
Registered: ‎12-24-2009

sure, may I propose a few fixes inside decls.h removing warning appearing in mpu.c?

see the file attached. basically, all MPU tags are no longer void type but unsigned int one.

0 Kudos
Highlighted
Observer
Observer
5,568 Views
Registered: ‎12-24-2009

could you confirm, if switching back to non-MPU mode would be possible? because now if there is not enough TLB entries the XilKernel just hangs.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,560 Views
Registered: ‎10-08-2010

It is certainly possible to turn off protection by setting C_USE_MMU = 0 in the hardware implementation. That way XilKernel is not built with MPU support, but on the other hand you will lose the memory protection functionality.

 

Could you post your system.mhs and linker script? If so, I can take a look at ways to reduce the TLB usage, with either or both of the workarounds I suggested.

0 Kudos
Highlighted
Observer
Observer
5,553 Views
Registered: ‎12-24-2009

could you confirm, if TLB run out of entries during MPU initialization inside XilKernel and the message about "XilKernel will run without memory protection" appear, the actual XilKernel switch back to non-MPU mode is working? because now in my case if there is not enough TLB entries the XilKernel just hangs.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,543 Views
Registered: ‎10-08-2010

That certainly sounds like a bug. The kernel should never hang. If it detects insufficient TLBs, it should simply not enable Protected Virtual Mode, and run as if no protection is available.

 

Can you check the MSR value after the hang occurs? That should tell you if the VM (Virtual Mode) bit in MSR is set or not.

0 Kudos