cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
whelm
Explorer
Explorer
11,905 Views
Registered: ‎05-15-2014

Can't flash QSPI

Jump to solution

7Z007S, Vivado/SDK 17.3.  New custom hardware--too many unknowns at once.  One poster saw a change in behavior going to 17.3, but I haven't tried this on any older version.  I've done this on two previous designs, but they were 7Z010 and older Vivado versions.

 

Program Flash says "Problem in Initializing Hardware".  This occurs right after reading the boot mode register (which returns all 0s, as it is configured for JTAG booting).

 

If I try again (without power cycling the hardware) it says can't read boot mode register, so whatever happened would appear to have affected access to PS system registers.

 

No problem loading PL over JTAG, so programmer and JTAG are fine, Nor is there any problem running and debugging over JTAG.

 

One difference I notices is that Flash programming wants the FSBL.elf, which I don't recall previous versions needing.  I'm wondering if that has any impact.  I presume it is getting some configuration information from the header block in that.  And I presume previous versions were using defaults of some sort instead.  Possibly there is an issue with the FSBL.  Can't test it without flashing it, so no way to know.

 

0 Kudos
1 Solution

Accepted Solutions
whelm
Explorer
Explorer
11,913 Views
Registered: ‎05-15-2014

Wow.  I have it working, but with questions.

 

The solution was recognizing that even when called from Program Flash, FSBL was running in the debugger, and there were breakpoints, including one at main (I don't think I put it there, I think SDK put it there from a previous debug session).  I removed all breakpoints and it started working.

 

So the questions are:

  1.  When I did "Run as ... Launch on System debugger" it was stopping at main like I would expect if I had done "Debug as.".  Apparently Debug and Run are closely associated--too closely in this case.  How do I shut off whatever flag makes it think it should be debugging rather than running?

  2.  Even when called from Program Flash, this behavior continued.  It opened a disassembly window and everything went flying by.  I would not have expected that and don't want it.

  3. Compiling a release version and using that eliminated the last item--but only when I "disconnected" from target.  OK that seens reasonable given the details of the situation, but it was unexpected.  I guess the moral of the story is don't try to program flash while the debugger is connected, since program flash runs code on the processor.

  4.  This operation can also be done from Viviado's Hardware manager (or Vivado Lab Edition).  As one might expect, those did not work when Program Flash from SDK did not work.  They also work now.  The fast that the last issue was a breakpoint is even more surprising here, because Vivado shouldn't be doing anything with breakpoints.

 

For those who may be struggling with Program Flash and land here, Here are the things I had to do to make it work:

 

First, The FSBL used for Program Flash must NOT be an XIP version.  That was where I started.

Second, On systems without DDR, the default FSBL simply won't work.  It seems crazy to me that FSBL uses DDR by default, and doesn't even offer a fallback position to OCM, but that is the way it is.  The fix is simple enough one would think it ought to be in the distro.

 

There is a line about 296 in main.c

     #ifdef XPAR_PS7_DDR_0_S_AXI_BASEADDR

Removed that line and the next about 14 lines that do DDR R/W test.

 

At the end of main there is an else / endif for NO_DDR.  That no longer has a matching if and should be removed.

 

In lscript.ld, there should be two memory regions defined

 

  ps7_ram_0_S_AXI_BASEADDR  0x00000000    0x00030000

  ps7_ram_1_S_AXI_BASEADDR  0xFFFF0000   0x0000FE00

There may be other values that work, but these do.  All memory mapping should go to 

  ps7_ram_0_S_AXI_BASEADDR

except the last one (stack) which should go to

  ps7_ram_1_S_AXI_BASEADDR

I also reduced the stack size to 0x2000.  Probably not critical or essential.  In reality, the stack usage of this program is probably a lot less than that and heap usage is zero or near zero.

 

I also made a few other changes that I doubt were necessary:

    In Image_mover, I removed two lines (417 and 425) that called FsblFallback()  Since I don't think FSBL is moving an image when run by Program Flash, I doubt this matters.  It might come into play if the boot configuration was something other than JTAG.  Speaking of which, if you want to program flash without regard to the boot configuration switches, I would suggest stripping the other options (such as QSPI, etc) from main.c so it always ends up in FsblHandoffJtagExit();  JTAG can override boot config settings, but if the code flows down another path, it could change some configuration so as to not be useful.  If this is done, this FSBL should ONLY be used for Flash Programming.

 

In qspi.c I removed an if statement around line 232 so it always executes:

     FlashReadBaseAddress = XPS_QSPI_LINEAR_BASEADDR;

Again, probably not necessary for this application, but it was suggested elsewhere and I had done it.

 

That's pretty much it.  For me, this was only for Program Flash.  I use a different FSBL that has XIP for inclusion in the boot image.

 

View solution in original post

17 Replies
whelm
Explorer
Explorer
11,869 Views
Registered: ‎05-15-2014

Adendum:  I have done two tests to eliminate any hardware issues (besides the fact that the hardware is designed the same as two previous projects and several commercial boards):

 

1.  I jumpered it for QSPI boot, which will fail, because the QSPI is blank.  Then I looked at the waveform on the QSPI pins to make sure there was connectivity and no signal integrity problems.

 

2. In JTAG boot mode, I tried to flash it and noted that the CS line never went low, so the failure is before it even tried to communicate with the IC.

 

For these reasons, I'm fairly certain this is an SDK/ Vivado related problem.  I'm strongly leaning towards a change in 17.3 or earlier 17.x because the last version we did this for on an earlier board was 16.4 and we had no problems.  As stated, I don't thing it needed an FSBL file, which is a change.  It is possible there is something wrong with the FSBL file, but without some insight into what the program is doing and expecting, it is hard to know where to start looking.

 

0 Kudos
ibaie
Xilinx Employee
Xilinx Employee
11,812 Views
Registered: ‎10-06-2016

Hi @whelm

 

There is an AR ongoing (should be published this week) explaining why FSBL is required for Zynq-7000 starting from 2017.3 release, but basically this has been done to have a common flow between zynq-7000  and ZU+.

 

As far as you have a JTAG connection working proplery you can generate the FSBL in SDK and Debug/Run it to ensure that the FSBL you will be using for programming the device is fine.

 

Once you have that running you can use the XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES enviromental variable as explained in AR#59174 to get more information from the programming feature.

 

Regards,

Ibai


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

Let me know when it is out and I can see if it sheds any light on my problem.  The situation is this

1.  We have two projects that we have designed and programmed using 16.4 that are working properly.

2.  We created a third board using the same QSPI Flash IC connected the same way.

3.  The new project works fine with JTAG for running (from debugger) and debugging.

4.  The new project won't write to the flash.  It errors out before the first chip select enable to the Flash

5.  The flash receives all the correct signals, as determined by trying to boot from FLASH.  It obviously can't boot because there is nothing in the flash, but I can see the appropriate signals on the pins.

 

There are two known differences between the old and new designs:

1.  The new design was developed under 17.3

2.  The new design uses 7z007, whereas the previous designs used 7x010

Obviously the fact that it is a new design opens up other possible differences, but there aren't any known ones.

I doubt that the 007 would be the issue, so I'm suspecting their is either something adversely different about how 17.3 writes to flash or it is looking for something in the FSBL that isn't set up right.

 

0 Kudos
ibaie
Xilinx Employee
Xilinx Employee
11,796 Views
Registered: ‎10-06-2016

Hi @whelm

 

The AR#70148 has been finally released, so as you can see the workflow has been modified and now the FSBL is used to configure the clocks in the PS.

 

As pointed in the previous post I would suggest you to to the following steps to debug your issue further (described in AR#59174):

1. Use FSBL_DEBUG_INFO in your FSBL application to get more detailed information when programming the flash

2. Set XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES enviromental variable in your host machine to get more detail of the programming feature

 

Regards

Ibai


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
msqxl
Visitor
Visitor
11,668 Views
Registered: ‎01-02-2018

According to AR# 70148 to do, still can't burn the flash,Please give more detailed solution

flash.png

 

uart.png

 

cmd.png

0 Kudos
ibaie
Xilinx Employee
Xilinx Employee
11,595 Views
Registered: ‎10-06-2016

Hi @msqxl

 

In your case the issues seems to be related either to your PS configuration or Hardware, as the console output generated by U-Boot points that the system was not able to detect the SPI Flash device. I would suggest your first to bood by JTAG or SD card and make U-Boot read/write the SPI flash device. Once you are sure that the hardware and configuration are OK then try to program the flash device from SDK.

 

@whelm Did you had some progress on the issue?


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

OK.  I'm going to need some more help on this.  I finally got to the point where I could focus on it, but haven't made much progress.

 

First, I don't see any point in generating debug information in FSBL.  I know how to do that and have done it in the past.  But since I can't even write the FSBL to the flash what is that going to tell me?

 

Second, I set the environmental variable, but it didn't result in more information.

 

I have looked at AR#59174, but it is of limited value.  Obviously steps 1 - 4 and 8 assume there is something in Flash, so don't apply. As stated below, I don't know if 6 applies.  As stated above, 5 didn't shed any light, and 7 seems to be the whole point of reading the FSBL.elf

 

I have tried this three ways:  1) with SDK, 2) with Vivado, 3) with Vivado Lab.  All three behave exactly the same way.

 

There are multiple unknowns here. 

     FIrst, since I can't run FSBL, I don't know what if anything might be wrong with it, and since Flash Programming reads FSBL.elf, that could be a problem.  That is a chicken and eggs issue. 

     Second, although there are no known issues with this board and it is derived from previously known working design and I have indirect evidence that the QSPI flash is working, there isn't 100% assurance that there is no hardware issue. 

     Third, this is the first design we have done with 17.3/4 that uses the changed Flash methodology, which is likely the most significant issue.

     Fourth, this is being run as a DDRless system right now.  I don't think this should impact flash programming, because it should occur from cold start with no assumptions about how it is being used.  However, it is possible that some of the ps7 settings it snoops and finds from the FSBL.elf file may be causing problems.  FSBL is also XIP, which again should not matter to flash writing.

     Fifth, the design runs OCM high.  Again, I don't see how this would impact Flashing, except if it got MMU, etc info from FSBL which was not appropriate for the flash routine. 

     Sixth,  the clocking scheme on this board is not generic. I presume that is the sort of information the flash code gets from FSBL, but maybe it doesn't or doesn't do it quite right.  This is an 007s-2, so able to run a bit faster than normal.  The input clock is 50 MHz.  PLLs are ARM 1500, DDR 1050, IO 1000.  Processor runs 767, DDR (which isn't enabled) 534,  QSPI 200.  Again, most of this probably shouldn't matter.  As long as the flash routine knows that the clock is 50 MHz, it should be able to set everything else as it wishes.

 

My next question has to do with uboot, and is in two parts. 

     First, uboot is apparently used to do the flashing. Does uboot need DDR?  Does the copy of uboot it uses know how to work in a DDRless system?

     Second, uboot is probably a useful tool for getting a better understanding of what is going on, and even possibly flashing.  BUT, again, does it need DDR?  Or can (must) it be specially build for systems without DDR?

 

The messages I'm getting right now are:

Initialization done, programming the memory
BOOT_MODE REG = 0x00000000
Problem in running uboot
Flash programming initialization failed.

 

I can load and run from JTAG, including loading PL and PS (OCM), so issues with JTAG and most of the hardware are eliminated.  I haven't tried making the application write or read flash.  That is one possible approach, although one that has its own pitfalls, and still might not add any useful information.  There is a learning curve, the code could be buggy, giving a false negative, etc.  Given that I've never been given a message about Flash failure or that it ever got far enough to know whether the Flash worked, that doesn't seem like the most productive path.

 

I looked at the answer record mentioned, but was not sure how to apply it to the situation.  Without looking up each register and analyzing each bit, I don't know what useful information I could glean.  It seems that the whole point of using the FSBL.elf was for the program to analyze that data intelligently, and it should need the ps7 file unmodified.

 

Where do I go next?  My customer is getting restless.  Especially because they were supposed to leave a sample with their customer in Alaska today, and can't do so without leaving SDK, the program source, and a JTAG programmer, too

 

 

 

 

0 Kudos
ibaie
Xilinx Employee
Xilinx Employee
11,375 Views
Registered: ‎10-06-2016

Hi @whelm

 

Quite large post to reply :) Let's see if I can answer some of your questions and provide some guidelines that could be usefull for you.

 

First progress points answers:

 

1. As you noticed in the past the program_flash tool makes use of FSBL to configure the PS side before running the internal u-boot that actually writes the flash device. Enabling the debug info is useful as you can check if something is going wrong before the pre-built u-boot has been launched. Take into account that it's not using the FSBL stored in the flash it's just using the FSBL ELF file which should be stored in OCM.

 

2. The enviromental variable prints messages from the pre-built u-boot. If programming does not reach that stage (like in your log file) it might be possible that you don't get any extra info.

 

Unknown question answers:

1. This is one of the key points, you need a running FSBL to be able to initialize the PS before programming the flash. That means that you need OCM based FSBL at least for programming phase.

2. It's always good to know there is no known issues in hardware :)

3. I guess that in previous projects you use earlier version where FSBL was not required to use program_flash (a pre-build initalization code was used)

4. I think this is the KEY POINT. You should be able to use DDRless board with program_flash and the pre-built u-boot work with that use case, however you cannot use the XIP based FSBL with program_flash. You need to create a new FSBL just for programming purposes that uses OCM.

5.I guess you mean that application runs on OCM high. No issues with that, I mean use XIP FSBL in your final deployment but use OCM FSBL for programming.

6.Clocking should be handled by FSBL. No issues.

 

Questions:

1. The pre-built u-boot within program_flash is designed to work also in ddrless systems.

2. You can build yourself without DDR I guess but I think you can first try the next steps.

 

Next steps:

1. Create a FSBL that runs in OCM and enable the FSBL_DEBUG_INFO symbol to print out the debug info. Run it through JTAG to be sure it's running properly.

2. Enable the U-Boot debug enviromental variable and use program_flash to write something in flash.

3. Post the output of both SDK log and UART port.

 

Regards

Ibai

 

 


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

Sorry for such a long post, but you can see how it all ties together, and you did a good job of answering.  I didn't realize that it actually ran the FSBL.  I thought it just peeked into it to get parameters.  That makes a significant difference.  Nor did I ever think that one could run FSBL from JTAG.  I figured it was special enough that it had to run directly from the ROM bootloader. That is a huge help.

 

Unfortunately, the UART stuff will complicate things.  This board needed about five serial ports--mostly for dedicated hardware.  The one used for normal serial communication is actually a virtual comm port via an I2C on the Zynq, so I will have to free up one of the others for this purpose.  Not a big deal, just a special connector.

 

I had figured out a couple of days ago that I needed a non-XIP FSBL, and now I understand why. I had tried using a normal automatically generated FSBL, but have not had success.  I will follow along the suggestions and see where it takes me.  I'm sure I can get to the bottom of it.  I've debugged DDRLess XIP FSBLs before, so this shouldn't be that hard.  I just got blindsided by too many unknowns all at once.  Thanks for clarifying things.

 

Wilton

 

0 Kudos
whelm
Explorer
Explorer
10,594 Views
Registered: ‎05-15-2014

The Zynq development environment is one of the most complex around, because it manages both hardware and software.  The tools are designed to automate as much as possible, which is helpful, but, unfortunately, hides details, and finding descriptions of those details can be hard.

 

In this case I have determined that the normal FSBL indeed does require DDR.  I stepped through the code, and because there was no DDR claimed, it went to fallback and then exited.

 

I have the DDRless source and tried with that, but now I have a bunch of undefined references involving dataLMA, and VMA.  One question involves BSP.  The SDK hierarchy has platform at the bottom, BSP on top of that and application on top of that.  Clearly for a given board (and therefore project) only one platform should be necessary.  But one would also think that one BSP ought to suffice as well.  In this case, there are three software projects, FSBL, XIP FSBL, and application.  But since they all run on the same hardware, one would think a single BSP should suffice.  But I'm beginning to think not.  It seems that the BSP only contains files for portions of the system needed by the application it is supporting and/or the way the hardware is configured.  I'm guessing that my LMA and VMA omissions are because the BSP was created from the XIP version which didn't need to do the copying, therefore the BSP didn't include the file needed for LMA/VMA--but I'm not sure about that.  My next step would be to recreate the BSP.

 

Wilton

 

0 Kudos
glena
Moderator
Moderator
10,580 Views
Registered: ‎03-19-2014

Try adding this environment variable:

 

XIL_CSE_ZYNQ_UBOOT_QSPI_FREQ_HZ = 10000000

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

I don't understand that at all.  I can see its usefulness in some situations, but QSPI hasn't even entered the picture yet.  

 

The reality is that contrary to previous statements, the default FSBL code WILL NOT WORK WITHOUT DDR -- period.  Near the beginning of main there is a check if DDR is present, and if not, it skips the whole of main and exits with a No DDR message.  So any attempt to make this work must first remove the DDR test from the source code.

 

I've now done that and FSBL runs and correctly determines it's in JTAG mode and goes to the JTAG exit.  I'm not sure what it is supposed to do after than, but what it actually does when I try and use that to flash QSPI is:

 

cmd /C program_flash -f C:\WV-Git-Zynq\FTRTS\FTRTS.sdk\FTRTS\bootimage\BOOT.mcs -offset 0 \
-flash_type qspi_single -fsbl C:\WV-Git-Zynq\FTRTS\FTRTS.sdk\FSBL\Release\FSBL.elf -cable \
type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2017.4 (64-bit)
  **** SW Build 2086221 on Fri Dec 15 20:55:39 MST 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

 

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-HS3-210299A1F56B
 Device 0: jsn-JTAG-HS3-210299A1F56B-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory

 

At which point it drops into the debugger in the middle of some assembly code that appears to be the result of an unhandled exception.  All of this is new since my last post, as I removed the DDR stuff.  In case it is of any value, the PC where it stopped was 00007784 and there is a push instruction there.  Actually it would appear that it stopped at the previous instruction which is a b -8 -- i.e. unconditional jump to itself.  The stack traceback is empty, so no help.  It does say (Cannot halt processor core, timeout) which makes sense, but doesn't shed any light on the subject.

 

0 Kudos
glena
Moderator
Moderator
10,568 Views
Registered: ‎03-19-2014

Do you have the uBoot debug messaging environment variable set?

 

XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES 1

 

Refer to AR59272 

 

This will provide more detail.   If in your debug messages you see sf probe 0 0 0 not detecting your QSPI device, then add the previously mentioned env variable.

 

An older AR shows how to build a Zynq 7000 system without DDR AR56044   Line numbers for the code have changed since 2014.4, but the general flow is accurate.

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

Yes the environmental variable is set.  Does that put more information out on the console, or does it depend on a UART?

I'm not sure how far it gets.  The last message is "Initialization done, programming the memory"  That would seem to come from Uboot--I can't find it in the FSBL source anywhere.  If that is the case, then presumably the FSBL is doing its job.  But the disassembly that pops up when the program crashes tends to make me think it is coming from FSBL.

 

I don't have any information on the version of Uboot that is loaded (like source code) or the sequence of events SDK is using to orchestrate this, other than it is calling program_flash and giving it the name of the boot file and fsbl file to use.  If  had more information, I might be able to solve this.

 

0 Kudos
whelm
Explorer
Explorer
10,544 Views
Registered: ‎05-15-2014

OK.  I've dug a little deeper, and again hit a lack of information wall.

 

I created a debug version of FSBL, with debug messages enabled.  I can run it under the debugger and see the FSBL sign on message, the comment that Devcfg driver initialized, Silicon Version 3.1 and boot mode is JTAG, at which point it enters the infinite loop (presumably waiting for JTAG to stop it and do something else).

 

However when I provide a link to that FSBL to the Program Flash link in SDK, two things happen:

     1. Like before I get the messages up through Retrieving Flash info. . . and Initialization done, programming the memory (on the console).

     2. I never get the FSBL messages (or anything) (on the RS-232).

 

Once again, I'm lost as to the next step, because I don't have access to enough information.  Clearly FSBL did not run.  Either it was skipped or it is later in the programming path.  The latter seems strange, as I would expect it to be before the message 
"programming flash".  So I have no clue why it didn't run, why it was skipped or why  the process stopped before it got there.  Obviously it has to run before anything can communicate with the QSPI Flash, because it has to configure all the Arm and other PS stuff so it can communicate with the flash.

 

I'd really like more information here.  I am willing and able to run tests, but without a clue as to what is going on and what to expect, it is hard to know what to run.

 

0 Kudos
whelm
Explorer
Explorer
11,914 Views
Registered: ‎05-15-2014

Wow.  I have it working, but with questions.

 

The solution was recognizing that even when called from Program Flash, FSBL was running in the debugger, and there were breakpoints, including one at main (I don't think I put it there, I think SDK put it there from a previous debug session).  I removed all breakpoints and it started working.

 

So the questions are:

  1.  When I did "Run as ... Launch on System debugger" it was stopping at main like I would expect if I had done "Debug as.".  Apparently Debug and Run are closely associated--too closely in this case.  How do I shut off whatever flag makes it think it should be debugging rather than running?

  2.  Even when called from Program Flash, this behavior continued.  It opened a disassembly window and everything went flying by.  I would not have expected that and don't want it.

  3. Compiling a release version and using that eliminated the last item--but only when I "disconnected" from target.  OK that seens reasonable given the details of the situation, but it was unexpected.  I guess the moral of the story is don't try to program flash while the debugger is connected, since program flash runs code on the processor.

  4.  This operation can also be done from Viviado's Hardware manager (or Vivado Lab Edition).  As one might expect, those did not work when Program Flash from SDK did not work.  They also work now.  The fast that the last issue was a breakpoint is even more surprising here, because Vivado shouldn't be doing anything with breakpoints.

 

For those who may be struggling with Program Flash and land here, Here are the things I had to do to make it work:

 

First, The FSBL used for Program Flash must NOT be an XIP version.  That was where I started.

Second, On systems without DDR, the default FSBL simply won't work.  It seems crazy to me that FSBL uses DDR by default, and doesn't even offer a fallback position to OCM, but that is the way it is.  The fix is simple enough one would think it ought to be in the distro.

 

There is a line about 296 in main.c

     #ifdef XPAR_PS7_DDR_0_S_AXI_BASEADDR

Removed that line and the next about 14 lines that do DDR R/W test.

 

At the end of main there is an else / endif for NO_DDR.  That no longer has a matching if and should be removed.

 

In lscript.ld, there should be two memory regions defined

 

  ps7_ram_0_S_AXI_BASEADDR  0x00000000    0x00030000

  ps7_ram_1_S_AXI_BASEADDR  0xFFFF0000   0x0000FE00

There may be other values that work, but these do.  All memory mapping should go to 

  ps7_ram_0_S_AXI_BASEADDR

except the last one (stack) which should go to

  ps7_ram_1_S_AXI_BASEADDR

I also reduced the stack size to 0x2000.  Probably not critical or essential.  In reality, the stack usage of this program is probably a lot less than that and heap usage is zero or near zero.

 

I also made a few other changes that I doubt were necessary:

    In Image_mover, I removed two lines (417 and 425) that called FsblFallback()  Since I don't think FSBL is moving an image when run by Program Flash, I doubt this matters.  It might come into play if the boot configuration was something other than JTAG.  Speaking of which, if you want to program flash without regard to the boot configuration switches, I would suggest stripping the other options (such as QSPI, etc) from main.c so it always ends up in FsblHandoffJtagExit();  JTAG can override boot config settings, but if the code flows down another path, it could change some configuration so as to not be useful.  If this is done, this FSBL should ONLY be used for Flash Programming.

 

In qspi.c I removed an if statement around line 232 so it always executes:

     FlashReadBaseAddress = XPS_QSPI_LINEAR_BASEADDR;

Again, probably not necessary for this application, but it was suggested elsewhere and I had done it.

 

That's pretty much it.  For me, this was only for Program Flash.  I use a different FSBL that has XIP for inclusion in the boot image.

 

View solution in original post

whelm
Explorer
Explorer
10,503 Views
Registered: ‎05-15-2014

I have attached a Word document that tries to capture all the information I needed to get a working copy of a project into Flash memory on 2017.4.  It describes details I've had trouble finding about running under the debugger, using the Program Flash option and creating an FSBL for a flash image and how it is used.  All of this is fairly straightforward, but I haven't found it adequately documented anywhere, so I set about to solve that problem, after having been through the grief of debugging the process twice now.  This is particularly relevant to those using custom hardware that does not have DDR.  There are several options available: using OCM, running FSBL from Flash (XIP - execute in place) during boot (but not for Program Flash - it won't work), Using L2 cache as memory, Relocating OCM as a single block at the top of the address space. All of these are discussed.  I have used all of them except the cache part.  The document refers the reader to a wiki page that addresses that item as well as the others and includes source files.

 

I hope the attached file is helpful to others in removing some of the mystery surrounding FSBL.

 

Wilton Helm

Embedded System Resources