Boot loader woes - VxWorks

This is a discussion on Boot loader woes - VxWorks ; A new boot loader that I built off a legacy code that I inherited is giving me a lot of trouble. The BSP, code base has been in use for production for several years. Recently there was a requirement to ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Boot loader woes

  1. Boot loader woes

    A new boot loader that I built off a legacy code that I inherited is
    giving me a lot of trouble. The BSP, code base has been in use for
    production for several years. Recently there was a requirement to
    upgrade RAM in one of our products. All these years it was 16 MB; now
    it is 32 MB. That's the only change in hardware.

    Tornado: 2.0.2
    VxWorks: 5.4
    Processor: MPC8241

    This is my first brush with PowerPC architecture. And none of the
    engineers who actually wrote/ported the BSP is with the company any
    more. I just opened the project/workspace in Tornado, changed the
    memory size macro and the RAM high address in config.h and project
    parameters, that's it. The boot loader just does not start at all.
    There is no activity on the serial console the moment I power my board
    on. These are the old and new memory macros' values:

    LOCAL_MEM_LOCAL_ADRS: 0x0 (no change)
    LOCAL_MEM_SIZE: 0x1000000 (changed to 0x2000000)
    RAM_LOW_ADRS: 0xA00000 (no change)
    RAM_HIGH_ADRS: 0xE00000 (changed to 0x1F00000)
    RAM_DST_ADRS: 0xA00000 (no change)
    RAM_DATA_ADRS: 0xD00000 (no change)

    First, I wonder if it's okay to have RAM_DATA_ADRS different from
    RAM_HIGH_ADRS! Is this acceptable? Ours is a compressed boot loader.
    Seems the boot loader has problem with the memory size. If I change
    the LOCAL_MEM_SIZE back to 0x1000000, even with new RAM_HIGH_ADRS, if
    works perfectly fine.

    Could someone please provide me any clue as to what could be
    happening? Has it anything to do with all those PPC's MMU, cache, etc?
    Should I start looking at the romInit.s code and see how things are
    being done there and probably change something there? Thanks.

  2. Re: Boot loader woes

    VG wrote:

    >A new boot loader that I built off a legacy code that I inherited is
    >giving me a lot of trouble. The BSP, code base has been in use for
    >production for several years. Recently there was a requirement to
    >upgrade RAM in one of our products. All these years it was 16 MB; now
    >it is 32 MB. That's the only change in hardware.
    >
    >Tornado: 2.0.2
    >VxWorks: 5.4
    >Processor: MPC8241
    >
    >This is my first brush with PowerPC architecture. And none of the
    >engineers who actually wrote/ported the BSP is with the company any
    >more. I just opened the project/workspace in Tornado, changed the
    >memory size macro and the RAM high address in config.h and project
    >parameters, that's it. The boot loader just does not start at all.
    >There is no activity on the serial console the moment I power my board
    >on. These are the old and new memory macros' values:
    >
    >LOCAL_MEM_LOCAL_ADRS: 0x0 (no change)
    >LOCAL_MEM_SIZE: 0x1000000 (changed to 0x2000000)
    >RAM_LOW_ADRS: 0xA00000 (no change)
    >RAM_HIGH_ADRS: 0xE00000 (changed to 0x1F00000)
    >RAM_DST_ADRS: 0xA00000 (no change)
    >RAM_DATA_ADRS: 0xD00000 (no change)
    >
    >First, I wonder if it's okay to have RAM_DATA_ADRS different from
    >RAM_HIGH_ADRS! Is this acceptable? Ours is a compressed boot loader.
    >Seems the boot loader has problem with the memory size. If I change
    >the LOCAL_MEM_SIZE back to 0x1000000, even with new RAM_HIGH_ADRS, if
    >works perfectly fine.
    >
    >Could someone please provide me any clue as to what could be
    >happening? Has it anything to do with all those PPC's MMU, cache, etc?
    >Should I start looking at the romInit.s code and see how things are
    >being done there and probably change something there? Thanks.


    I see a couple of things that may be causing your problems.

    First, the value of RAM_HIGH_ADRS must be defined identically in both
    the BSP's config.h and Makfile files and you didn't include Makefile
    in the list of files you changed.

    The second is that LOCAL_MEM_SIZE - RAM_HIGH_ADRS used to be 0x200000
    and now it is 0x100000. This may not be enough room for the boot
    loader image in RAM.

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

  3. Re: Boot loader woes


    > I see a couple of things that may be causing your problems.
    >
    > First, the value of RAM_HIGH_ADRS must be defined identically in both
    > the BSP's config.h and Makfile files and you didn't include Makefile
    > in the list of files you changed.


    Well yes both are identical. As I said ours is a T2 project build and
    I changed the macro definitions in the project settings. This, I am
    sure, would modify the makefile automatically.

    > The second is that LOCAL_MEM_SIZE - RAM_HIGH_ADRS used to be 0x200000
    > and now it is 0x100000. This may not be enough room for the boot
    > loader image in RAM.


    I didn't mention in the original post, but I tried with RAM_HIGH_ADRS
    0x1E00000 too..a difference of 0x200000. But the result was the same.

  4. Re: Boot loader woes

    On Mar 25, 4:06 pm, VG wrote:
    > A new boot loader that I built off a legacy code that I inherited is

    [snip]
    > Should I start looking at the romInit.s code and see how things are
    > being done there and probably change something there? Thanks.


    Yes.

    HTH,
    GV



  5. Re: Boot loader woes

    Hi,

    I believe you need to check few things additionaly.

    a) SDRAM register initialazation in bootrom (I suppose romInit.s
    file). If your SDRAM controller is not configured for 32MB you may not
    be able to copy image in to RAM.

    b) When you changed config.h you need to create a new project.
    Remember that any change in BSP config.h will not be refelected in
    already created project.

    HTH

    Best Regards
    VKG | Ritsoft Technologies

  6. Re: Boot loader woes

    VG wrote:

    >> I see a couple of things that may be causing your problems.
    >>
    >> First, the value of RAM_HIGH_ADRS must be defined identically in both
    >> the BSP's config.h and Makfile files and you didn't include Makefile
    >> in the list of files you changed.

    >
    >Well yes both are identical. As I said ours is a T2 project build and and
    >I changed the macro definitions in the project settings.


    You also said that you changed "the RAM high address in config.h" which
    means that you changed the BSP as well as the project. There is nothing
    wrong with this, in fact, it's necessary.

    > This, I am
    >sure, would modify the makefile automatically.


    I'm talking about the BSP Makefile rather than the project Makefile.
    The former is not automatically regenerated.

    >> The second is that LOCAL_MEM_SIZE - RAM_HIGH_ADRS used to be 0x200000
    >> and now it is 0x100000. This may not be enough room for the boot
    >> loader image in RAM.

    >
    >I didn't mention in the original post, but I tried with RAM_HIGH_ADRS
    >0x1E00000 too..a difference of 0x200000. But the result was the same.


    OK, but other factors were probably not valid at that time. I suggest
    sticking with RAM_HIGH_ADRS = 0x01E00000.

    Other things to consider:

    1) The SDRAM chip select's option register mask field as set in the
    BSP's romInit.s file.

    2) Unless the new SDRAM differs only in size from the original the
    UPM table values in the BSP's romInit.s file may need to change.
    This is not a trivial exercise.

    3) The SDRAM's entry in the sysPhysMemDesc[] table defined in the BSP's
    sysLib.c file may need to be changed if values are "hard coded"
    rather than with macros.

    I don't agree with VKG that you need to create a new project because
    you changed the BSP's config.h. You do have to make certain that
    all memory related configuration items agree after the change, however.

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

  7. Re: Boot loader woes

    There is at last something to cheer about, as at the moment things
    seem to be limping back to normal.

    I figured out and modified the assembler file that initialises the
    SDRAM registers in the processor. The board now starts fine and shows
    the boot loader prompt. I am still doubtful about the RAM refresh
    count I used, though.

    Now the balls lies in the dreaded QA's court. They're yet to load the
    application and see how it goes.

    Thanks a lot to all those who tried to help.

    PS: Huh! the PPC architecture is damn complex and confusing. So is its
    instruction set.

+ Reply to Thread