Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 272 subscribers
  • Views 299 views
  • Users 0 members are here
Related

Second Stage Boot Loader (SSBL) for Microzed

Former Member

Dear all,

I bought a Microzed board for implementing my projects on it. One of my projects is writing a second stage boot loader (SSBL) for it.

So the flow of booting is:

  1.   Booting of Boot Rom
  2.   Booting of First Stage Boot Loader (FSBL) (the FSBL is the example which is in SDK)
  3.   The FSBL loads the my SSBL (in the SSBL I use LWIP lib for having network connection, the load address is 0xA00000)
  4.   At the end the SSBL loads my application (the load address is 0x100000).

All the codes are loaded from QSPI.

Some additional information about my SSBL, I have used LoadBootImage() and FsblHandoff() functions as they are in FSBL. The difference between my SSBL and FSBL is that in the SSBL some data is received from network and stored in QSPI. Then the loading of my application is done.

The problem is that sometimes my application runs but sometimes it does not run. Sometimes When the application runs the FsblHandoff() function is not invoked. I do not know how it is possible.

Please help me how could I solve the problem? And what is my mistake?

Yours sincerely.

  • 0

    Zara,

      There are many things that could be wrong, and unfortunately they are specific to your application so there is no "generic" solution that applies.  The steps you outline seem valid at a high level, but the devil is in the details.   You note that sometimes your application runs and sometimes it does not, which points to a transient error and those are notoriously hard to track down.  So all I can do is give you some suggestions for possible root causes:

    1. Pay close attention to the address space occupied by your SSBL and the application that you are loading.  In particular, the interrupt tables in low memory.  If you overwrite something that is in use by the SSBL before the SSBL has handed off to the application, and an event occurs that causes a context swtich to an interrupt handler (for instance), if the vector has been updated it will not find the appropriate function and the processor will likely attempt to execute an invalid instruction.  That would cause execution to terminate, and would be an intermittent problem.

    2. Make sure your network connection is reliable in terms of setting up the data transfer.  Network operations are subject to interactions outside of your application space, and you have no control over them.  If your transfer times out, or the connection is dropped, your SSBL may be waiting for incoming data that never arrives.   It might make sense to try loading your application from QSPI or uSD before injecting the network complication.  Once you have that working 100% of the time, you can carefully add the network code back in to determine the source of the problem.

    3. I have not looked at the FSBLHandoff code, but it is worth examining it carefully to determine if there are any assumptions made during FSBL execution that are not valid during SSBL execution.  

    I think the best course of action is to revert to a simpler version of your SSBL that works consistently, then add in each new element until you encounter a problem.  At least then you can easily isolate the change that injected the bug.

    Good luck with this.  It is certainly possible.  U-boot is an example of a working implementation.

    Ron

  • 0 in reply to Former Member
    Ron,
     
    thanks a lot for your prompt reply. 
     
    you mentioned important points. I will keep you posted.
     
    Zara