UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
978 Views
Registered: ‎05-15-2014

Boot process for debug

Jump to solution

Are there any documents that describe the boot process into JTAG debug in clear detail?  Or can someone fill in a few blanks.

 

Here's my situation.  I'm working with a variant of the numerous projects where FSBL sets up various thinks like MMU table, caching, and in some cases vectors, and then hands control to the application, which is aware of them and continues to use them.  My assumption was that a debug session would start by running FSBL from QSPI, ending at the JTAG exit (WFE) and the debugger would unobtrusively take over from there.  That does not seem to be the case.

 

Obviously there would have to be an alternate mechanism, because initially there is no flash image to draw from.  For flashing, that is handled by having a non-XIP FSBL that is executed, followed by a stripped down U-Boot.

 

The special MIO lines are read into a register at reset, but how is it used.  ROM boot must use it to decide which I/O subsystems to initialize and use to search for an image to load.  If ROM boot sees JTAG, it would seem that it wouldn't even look for an image.  OTOH, FSBL also looks at that register and branches to various options, one of which is JTAG.  If FSBL isn't even loaded by ROM in JTAG mode, then why should it even have a JTAG exit path?  Or more to the point, is it possible to force ROM to load FSBL so that the debugger can assume various things FSBL might need to do?  Or to give the debugger the path to an FSBL it could load and use?  There must be a way to debug applications that depend on things FSBL does.  Such an arrangement would probably eliminate the need for ps7init.tcl, since FSBL executes the equivalent ps7Init.c.

 

Any clarification on any of this?  I'm hoping in the end to pull the obscure and disjointed pieces of the whole startup process together into a document that others can benefit from.

 

Wilton

0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
780 Views
Registered: ‎05-15-2014

Re: Boot process for debug

Jump to solution

It's taken a while to return to this issue, but it has been resolved and I have learned a lot about the boot process, which I will share in another thread.  There were several issues involved.  The most critical is that the FSBL exit codes all disable the MMU, and I hadn't removed that code from all relevant paths.  That alone was a show stopper before the application code loaded.

The idea of not checking the reset CPU box was also an essential part.  I'm not sure if unchecking the ps7_init boxes made any difference.  In the end, to streamline the process, I replaced ps7_init.tcl with a script that loaded and ran the FSBL, then opened up the memory region, before allowing the calling debugger script to load the application.  The result was a one-click debug session that works flawlessly.

In the process we encountered one unexpected side effect.  We lost access to the AXI PL interface.  After trying several things it was determined that we had to run the original ps7_init calls before running FSBL.  That came as a surprise, since FSBL included ps7_init() from ps7_init.c.  Haven't sorted out what the difference there was, or why it would make us lose access to that memory region when it is set up properly in the MMU table.  But we have a process that works and is seamless.

Thanks,

Wilton

View solution in original post

0 Kudos
5 Replies
Xilinx Employee
Xilinx Employee
941 Views
Registered: ‎10-11-2011

Re: Boot process for debug

Jump to solution

Roughly the JTAG boot mode works like this.

- Boot mode pins are all zeros (indicating JTAG boot mode)

- ROM comes up, samples those pins, does some basic initialization of the system (nothing much really), enable the JTAG chain exit.

- Using the debugger you can now download the FSBL.elf to the target and execute it.

- The FSBL execute the system initialization (ps7_init()), samples the same boot mode pins (reading a register) and since it's JTAG it simply exit. NOTE: there's no attempt to fetch the application from a flash since the boot mode is JTAG. The FSBL is executed purely to initialize the system (MIO, clocks, etc...) but it won't load anything from flash.

- At this point, using the debugger, the user can:

Program a bitstream

Download an application elf

This is the intended way of operation.

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Explorer
Explorer
934 Views
Registered: ‎05-15-2014

Re: Boot process for debug

Jump to solution

OK.  That makes sense.  I tried running FSBL and then launching the application on the debugger, but it appears that this undoes some of what FSBL did, so I'm trying to figure out how to avoid that.  To be specific, the FSBL is setting up the MMU, and L2Cache (common code before boot type is determined).  I also need a couple XSCT commands to make a memory region available.  By the time the debugger tries to launch the application, at least some of that is undone, and the debugger fails to load the application as a result.

 

Wilton

0 Kudos
Xilinx Employee
Xilinx Employee
905 Views
Registered: ‎10-11-2011

Re: Boot process for debug

Jump to solution

Be sure the debugger doesn't have ps7_init() or psu_int() option checked.

That would re-run overwriting what the FSBL did before.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Explorer
Explorer
894 Views
Registered: ‎05-15-2014

Re: Boot process for debug

Jump to solution

I tried it with ps7_init.tcl not checked, although I don't know of anything in there that impacts MMU.  I don't see psu_int--maybe that is for a different target.  I tried to see if there was any place that the FSBL could be added as a precursor instead of ps7+init, but couldn't find it.  I've tried every variation I can think of to load and run FSBL and then debug the application, but I always come up with the MMU table section in OCM all zeros and a different MMU table at a different location in OCM pointed to by the register, and my L2Chache which was locked is no longer accessible.  This is even if I check breakpoint at start, so I know it isn't my startup code.

 

Given that the register pointing at MMU is part of the C15 coprocessor, I'm not even sure how something like ps7_init could even change that.

 

Wilton

0 Kudos
Explorer
Explorer
781 Views
Registered: ‎05-15-2014

Re: Boot process for debug

Jump to solution

It's taken a while to return to this issue, but it has been resolved and I have learned a lot about the boot process, which I will share in another thread.  There were several issues involved.  The most critical is that the FSBL exit codes all disable the MMU, and I hadn't removed that code from all relevant paths.  That alone was a show stopper before the application code loaded.

The idea of not checking the reset CPU box was also an essential part.  I'm not sure if unchecking the ps7_init boxes made any difference.  In the end, to streamline the process, I replaced ps7_init.tcl with a script that loaded and ran the FSBL, then opened up the memory region, before allowing the calling debugger script to load the application.  The result was a one-click debug session that works flawlessly.

In the process we encountered one unexpected side effect.  We lost access to the AXI PL interface.  After trying several things it was determined that we had to run the original ps7_init calls before running FSBL.  That came as a surprise, since FSBL included ps7_init() from ps7_init.c.  Haven't sorted out what the difference there was, or why it would make us lose access to that memory region when it is set up properly in the MMU table.  But we have a process that works and is seamless.

Thanks,

Wilton

View solution in original post

0 Kudos