cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jovliegen
Contributor
Contributor
880 Views
Registered: ‎04-08-2009

MicroBlaze stalls when switching from FSBL to u-boot

Jump to solution

Hello,

I'm trying to run PetaLinux on a MicroBlaze design. After a whole week of testing, reading documentation and debuging it is still not working.

The main problem is with the booting of u-boot. Upon programming the FPGA, the bitstream gets updated with the FSBL. After precise debugging, all the address offsets seem to be in order for: 1) FSBL, 2) the source address where the u-boot binary is stored, and 3) the offset for the RAM address.
(attachment shows the debug feedback of FSBL, on the left)

Through the debugger I've checked the first instruction that u-boot is supposed to execute. Off course, this only works because the FSBL has already copied this binary from Flash to DDR. This first instruction "0x9400C001" does match with
u-boot.elf binary.

After the jump to the first line of u-boot the MicroBlaze stops working. Using the debugger to stop the execution gives following error message:
    xsdb% stop
    Cannot stop MicroBlaze. Stalled on instruction fetch

Reading the registers of MicroBlaze learns that all registers have value: NA
(attachment shows the registers, on the right)

I have also ran the memory test example software in SDK. This to verify that DDR is not in (accidental) reset through mis-configuration of SOC.

Any pointers would be very welcome

 

peta_debug.png
0 Kudos
1 Solution

Accepted Solutions
jovliegen
Contributor
Contributor
635 Views
Registered: ‎04-08-2009

I was able to figure it out and start u-boot. In case anyone else stumbles upon this issue, I'll mention what fixed my issue.

 

Apparently there was still a "mis-configuration" in the SOC. I'm not 100% sure but I think it had to do with the fact that CACHEd memory was not covering the same memory address range as the DDR. With a number of attempts to get it right, without violating timing constraints, I have a working SOC now. Everything was verified through SDK templates (hello world, memory test, and peripheral test). The final SOC looked like this:

xil_for_5.png

 

 

 

After rebuilding petalinux, I'm able to get u-boot starting. (However it still fails quite early )

xil_for_6.png

 

 

View solution in original post

14 Replies
stephenm
Xilinx Employee
Xilinx Employee
851 Views
Registered: ‎09-12-2007

The Microblaze is probably already hanged before the fsbl hands off to it. The Microblaze will execute for the boot vector set in the Microblaze config in IPI. So, assuming this is at 0x0. If you program the PL, then toggle the ps pl reset (this is done in fsbl), the Microblaze will start to execute and this might be too early.

You can try hold the Microblaze in reset, and control this wakeup in the FSBL. I have a wiki on a similar topic where I am executing from the PS DDR that is worth a try

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842424/Execute+Microblaze+Application+from+PS+DDR

0 Kudos
jovliegen
Contributor
Contributor
811 Views
Registered: ‎04-08-2009

Hello Stephen,

Thank you for your quick reply.

I forgot to mention that I'm using a VC707 board, hosting a Virtex7. As there is no PS in there, the booting of the FSBL already occurs on the MicroBlaze. The bitstream that configures the PL has the FSBL present in BRAM. From the fact that the FSBL runs, I'm assuming that MicroBlaze is not in a reset.

 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
795 Views
Registered: ‎09-12-2007

ah, ok. what threw me was the fsbl. you meant fs-boot

 

Can you do a memory test on your DDR?

0 Kudos
jovliegen
Contributor
Contributor
785 Views
Registered: ‎04-08-2009

Right, my bet, sorry.

I used SDK to run a memory test program. As you can see in the image below, the memory test passes.

xil_for_1.png

 

If I program the VC707 using XSDB, the fs-boot starts running immediately (and halts there). The copy of u-boot-s.bin has been done. I verified this by resetting the debugger and reading the 0x80100000 address. This is address (in DDR) to which the hand-off is done. With a hex-editor, I verified that the content of u-boot-s.bin is indeed stored in DDR, as is shown in the screenshot below.

xil_for_2.png

 

Thanks again for your quick replies !

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
784 Views
Registered: ‎09-12-2007

Can you post the uboot elf?

0 Kudos
jovliegen
Contributor
Contributor
776 Views
Registered: ‎04-08-2009

Sure

I had to zip it because the error below was shown upon hitting the "Reply" button.

xil_for_3.png

 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
775 Views
Registered: ‎09-12-2007

Actually, I can access a vc707 board. So, if you send the XSA I can try this on my end

0 Kudos
jovliegen
Contributor
Contributor
740 Views
Registered: ‎04-08-2009

I'm still using Vivado 2017.4 (and petalinux 2017.4). I zipped the "Vivado Export Hardware" folder. Hope that his helps you.

0 Kudos
jovliegen
Contributor
Contributor
678 Views
Registered: ‎04-08-2009

I revisited the SOC and noticed that some interrupt lines were not connect. This error has been fixed and the block design now looks as shown below:

xil_for_4.png

 

Unfortunately this didn't fix the problem of the stalling MicroBlaze. Using the debugger I was able to step to instruction 0x99FC9800. This instruction is an unconditional branch to the correct absolute address (0x80100000) with the D and L flags set (Link with delay). That seems to make sense.
On the target address is the instructions: 0x9400C001. This sets and resets the MSR.

Could it be that there is an issue with the reset ?

EDIT: Added a new zip file with the exported hardware

0 Kudos
jovliegen
Contributor
Contributor
636 Views
Registered: ‎04-08-2009

I was able to figure it out and start u-boot. In case anyone else stumbles upon this issue, I'll mention what fixed my issue.

 

Apparently there was still a "mis-configuration" in the SOC. I'm not 100% sure but I think it had to do with the fact that CACHEd memory was not covering the same memory address range as the DDR. With a number of attempts to get it right, without violating timing constraints, I have a working SOC now. Everything was verified through SDK templates (hello world, memory test, and peripheral test). The final SOC looked like this:

xil_for_5.png

 

 

 

After rebuilding petalinux, I'm able to get u-boot starting. (However it still fails quite early )

xil_for_6.png

 

 

View solution in original post

ramesha.a
Visitor
Visitor
102 Views
Registered: ‎02-13-2020

Could you please tell me steps involved in going from hdf file generation (i.e. exporting to SDK) using ISE14.7  to application development on Petalinux Platform.

with regards,

Ramesha

 

0 Kudos
ramesha.a
Visitor
Visitor
101 Views
Registered: ‎02-13-2020

Sir,

Could you please tell me steps involved in going from hdf file generation (i.e. exporting to SDK) using ISE14.7 to application development on Petalinux Platform.

with regards,

Ramesha

0 Kudos
ramesha.a
Visitor
Visitor
98 Views
Registered: ‎02-13-2020

Sir,

I want to build microblaze based processor system for Kintex7 FPGA. Could you please tell me steps involved in going from hdf file generation (i.e. exporting to SDK) using ISE14.7 to application development on Petalinux Platform.

with regards,

Ramesha

0 Kudos
jovliegen
Contributor
Contributor
88 Views
Registered: ‎04-08-2009

Hi,

Up until now, I wasn't able to run the Petalinux Platform. The project got put in the freezer, since.

I'd like to point out to you that ISE14.7 doesn't support any 7-series devices. You have to use Vivado/Vitis, as far as I understand.

kind regards

jo

0 Kudos