VIP size issues? - VxWorks

This is a discussion on VIP size issues? - VxWorks ; I have a question regarding a VIP. I have the need for a very large struct array. I get a size error message telling me to up the value of RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: VIP size issues?

  1. VIP size issues?

    I have a question regarding a VIP. I have the need for a very large struct
    array. I get a size error message telling me to up the value of
    RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the problem.

    Here are my specifics:

    MVME5100 board with 512MB RAM

    VxWorks6.3 BSP

    Workbench 2.6

    If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the card
    boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to anything
    higher than 16MB, it appears that the bootloader fails--I get *nothing*--no
    LED flickers (which I think indicate the bootloader is/has loaded the
    image), no console port messages, etc.

    I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results. I
    recall reading somewhere that RAM_HIGH_ADRS has to be less than
    LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value is
    32MB to begin with--but since we are using auto sizing to handle our various
    capacity boards, I was hoping this restriction would not apply. This however
    seems to not really matter at this point because even 31MB did not work
    (boot). Note that the rebuild of the VIP itself works fine with the larger
    values--it seems to be a bootloader issue. I modified config.h, and the
    RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    re-flashed. This procedure worked for 16MB.

    Does anyone have any insight as to what may be happening? I'd really like to
    be able to up the RAM available to the VIP to 128MB for my 512MB card and
    32MB for our 64MB MV5100 cards.

    Thanks,

    Bo



  2. Re: VIP size issues?

    On Apr 10, 11:41 am, "Bo" wrote:
    > I have a question regarding a VIP. I have the need for a very large struct
    > array. I get a size error message telling me to up the value of
    > RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the problem.
    >
    > Here are my specifics:
    >
    > MVME5100 board with 512MB RAM
    >
    > VxWorks6.3 BSP
    >
    > Workbench 2.6
    >
    > If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the card
    > boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to anything
    > higher than 16MB, it appears that the bootloader fails--I get *nothing*--no
    > LED flickers (which I think indicate the bootloader is/has loaded the
    > image), no console port messages, etc.
    >
    > I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results. I
    > recall reading somewhere that RAM_HIGH_ADRS has to be less than
    > LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value is
    > 32MB to begin with--but since we are using auto sizing to handle our various
    > capacity boards, I was hoping this restriction would not apply. This however
    > seems to not really matter at this point because even 31MB did not work
    > (boot). Note that the rebuild of the VIP itself works fine with the larger
    > values--it seems to be a bootloader issue. I modified config.h, and the
    > RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    > re-flashed. This procedure worked for 16MB.
    >
    > Does anyone have any insight as to what may be happening? I'd really like to
    > be able to up the RAM available to the VIP to 128MB for my 512MB card and
    > 32MB for our 64MB MV5100 cards.


    First suggestion would be to dynamically allocate the huge array and
    leave RAM_HIGH_ADRS alone.
    Second suggestion, if that won't work for you, is to verify that the
    bootrom is correctly setting up all available RAM.
    A JTAG tool such as a Wind River ICE would help here.
    Finally, remember that if the PPC exception vectors are too far away
    from the exception handlers, you'll need to reconfigure more than just
    RAM_HIGH_ADRS -- you'll need to enable extended call exception
    handlers.

    HTH,
    GV



  3. Re: VIP size issues?


    "gvarndell" wrote in message
    news:1176232575.556284.201590@b75g2000hsg.googlegr oups.com...
    > On Apr 10, 11:41 am, "Bo" wrote:
    >> I have a question regarding a VIP. I have the need for a very large
    >> struct
    >> array. I get a size error message telling me to up the value of
    >> RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the problem.
    >>
    >> Here are my specifics:
    >>
    >> MVME5100 board with 512MB RAM
    >>
    >> VxWorks6.3 BSP
    >>
    >> Workbench 2.6
    >>
    >> If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the
    >> card
    >> boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to anything
    >> higher than 16MB, it appears that the bootloader fails--I get
    >> *nothing*--no
    >> LED flickers (which I think indicate the bootloader is/has loaded the
    >> image), no console port messages, etc.
    >>
    >> I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results. I
    >> recall reading somewhere that RAM_HIGH_ADRS has to be less than
    >> LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value is
    >> 32MB to begin with--but since we are using auto sizing to handle our
    >> various
    >> capacity boards, I was hoping this restriction would not apply. This
    >> however
    >> seems to not really matter at this point because even 31MB did not work
    >> (boot). Note that the rebuild of the VIP itself works fine with the
    >> larger
    >> values--it seems to be a bootloader issue. I modified config.h, and the
    >> RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    >> re-flashed. This procedure worked for 16MB.
    >>
    >> Does anyone have any insight as to what may be happening? I'd really like
    >> to
    >> be able to up the RAM available to the VIP to 128MB for my 512MB card and
    >> 32MB for our 64MB MV5100 cards.

    >
    > First suggestion would be to dynamically allocate the huge array and
    > leave RAM_HIGH_ADRS alone.


    That won't work in my application without a lot of re-write of existing code
    base...

    > Second suggestion, if that won't work for you, is to verify that the
    > bootrom is correctly setting up all available RAM.
    > A JTAG tool such as a Wind River ICE would help here.


    I'm not sure what I would look for?

    > Finally, remember that if the PPC exception vectors are too far away
    > from the exception handlers, you'll need to reconfigure more than just
    > RAM_HIGH_ADRS -- you'll need to enable extended call exception
    > handlers.
    >

    On this last point-- the wind river folks told me to be sure to turn on the
    absolute-far switches for code/data to generate 32bit addresses instead of
    24bit addresses and to build new image and bootrom with these switches. I
    did this but it didn't work. This sounds related to what you are saying. How
    does one enable extended call exception handler? WindRiver has not made a
    similar suggestion. I am using diab toolchain.

    Thanks,

    Bo



  4. Re: VIP size issues?

    On Apr 12, 12:50 pm, "Bo" wrote:
    > "gvarndell" wrote in message
    >
    > news:1176232575.556284.201590@b75g2000hsg.googlegr oups.com...
    >
    >
    >
    > > On Apr 10, 11:41 am, "Bo" wrote:
    > >> I have a question regarding a VIP. I have the need for a very large
    > >> struct
    > >> array. I get a size error message telling me to up the value of
    > >> RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the problem.

    >
    > >> Here are my specifics:

    >
    > >> MVME5100 board with 512MB RAM

    >
    > >> VxWorks6.3 BSP

    >
    > >> Workbench 2.6

    >
    > >> If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the
    > >> card
    > >> boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to anything
    > >> higher than 16MB, it appears that the bootloader fails--I get
    > >> *nothing*--no
    > >> LED flickers (which I think indicate the bootloader is/has loaded the
    > >> image), no console port messages, etc.

    >
    > >> I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results. I
    > >> recall reading somewhere that RAM_HIGH_ADRS has to be less than
    > >> LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value is
    > >> 32MB to begin with--but since we are using auto sizing to handle our
    > >> various
    > >> capacity boards, I was hoping this restriction would not apply. This
    > >> however
    > >> seems to not really matter at this point because even 31MB did not work
    > >> (boot). Note that the rebuild of the VIP itself works fine with the
    > >> larger
    > >> values--it seems to be a bootloader issue. I modified config.h, and the
    > >> RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    > >> re-flashed. This procedure worked for 16MB.

    >
    > >> Does anyone have any insight as to what may be happening? I'd really like
    > >> to
    > >> be able to up the RAM available to the VIP to 128MB for my 512MB card and
    > >> 32MB for our 64MB MV5100 cards.

    >
    > > First suggestion would be to dynamically allocate the huge array and
    > > leave RAM_HIGH_ADRS alone.

    >
    > That won't work in my application without a lot of re-write of existing code
    > base...
    >
    > > Second suggestion, if that won't work for you, is to verify that the
    > > bootrom is correctly setting up all available RAM.
    > > A JTAG tool such as a Wind River ICE would help here.

    >
    > I'm not sure what I would look for?
    >
    > > Finally, remember that if the PPC exception vectors are too far away
    > > from the exception handlers, you'll need to reconfigure more than just
    > > RAM_HIGH_ADRS -- you'll need to enable extended call exception
    > > handlers.

    >
    > On this last point-- the wind river folks told me to be sure to turn on the
    > absolute-far switches for code/data to generate 32bit addresses instead of
    > 24bit addresses and to build new image and bootrom with these switches. I
    > did this but it didn't work. This sounds related to what you are saying. How
    > does one enable extended call exception handler? WindRiver has not made a
    > similar suggestion. I am using diab toolchain.


    Bring up the Workbench help facility and type extended-call in the
    search thingie.
    The assembly code the kernel plants in the exception vectors calls the
    C handlers using a PC relative branch.
    If the called code being is more than 32M away, as it will be when
    RAM_HIGH_ADRS is too high, everything goes bad.
    Make sure you chastise (gently) the support staff that failed to tell
    you about this.
    Finally, for more efficient boot code, turn off the "long-call"
    switches -- as you found out, that doesn't help this.

    HTH,
    GV



  5. Re: VIP size issues?


    "gvarndell" wrote in message
    news:1176408051.802896.134930@l77g2000hsb.googlegr oups.com...
    >> > On Apr 10, 11:41 am, "Bo" wrote:
    >> >> I have a question regarding a VIP. I have the need for a very large
    >> >> struct
    >> >> array. I get a size error message telling me to up the value of
    >> >> RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the
    >> >> problem.

    >>
    >> >> Here are my specifics:
    >> >> MVME5100 board with 512MB RAM
    >> >> VxWorks6.3 BSP
    >> >> Workbench 2.6

    >>
    >> >> If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the
    >> >> card
    >> >> boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to
    >> >> anything
    >> >> higher than 16MB, it appears that the bootloader fails--I get
    >> >> *nothing*--no
    >> >> LED flickers (which I think indicate the bootloader is/has loaded the
    >> >> image), no console port messages, etc.

    >>
    >> >> I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results.
    >> >> I
    >> >> recall reading somewhere that RAM_HIGH_ADRS has to be less than
    >> >> LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value
    >> >> is
    >> >> 32MB to begin with--but since we are using auto sizing to handle our
    >> >> various
    >> >> capacity boards, I was hoping this restriction would not apply. This
    >> >> however
    >> >> seems to not really matter at this point because even 31MB did not
    >> >> work
    >> >> (boot). Note that the rebuild of the VIP itself works fine with the
    >> >> larger
    >> >> values--it seems to be a bootloader issue. I modified config.h, and
    >> >> the
    >> >> RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    >> >> re-flashed. This procedure worked for 16MB.

    >>
    >> >> Does anyone have any insight as to what may be happening? I'd really
    >> >> like
    >> >> to
    >> >> be able to up the RAM available to the VIP to 128MB for my 512MB card
    >> >> and
    >> >> 32MB for our 64MB MV5100 cards.

    >>
    >> > First suggestion would be to dynamically allocate the huge array and
    >> > leave RAM_HIGH_ADRS alone.

    >>
    >> That won't work in my application without a lot of re-write of existing
    >> code
    >> base...
    >>
    >> > Second suggestion, if that won't work for you, is to verify that the
    >> > bootrom is correctly setting up all available RAM.
    >> > A JTAG tool such as a Wind River ICE would help here.

    >>
    >> I'm not sure what I would look for?
    >>
    >> > Finally, remember that if the PPC exception vectors are too far away
    >> > from the exception handlers, you'll need to reconfigure more than just
    >> > RAM_HIGH_ADRS -- you'll need to enable extended call exception
    >> > handlers.

    >>
    >> On this last point-- the wind river folks told me to be sure to turn on
    >> the
    >> absolute-far switches for code/data to generate 32bit addresses instead
    >> of
    >> 24bit addresses and to build new image and bootrom with these switches. I
    >> did this but it didn't work. This sounds related to what you are saying.
    >> How
    >> does one enable extended call exception handler? WindRiver has not made a
    >> similar suggestion. I am using diab toolchain.

    >
    > Bring up the Workbench help facility and type extended-call in the
    > search thingie.
    > The assembly code the kernel plants in the exception vectors calls the
    > C handlers using a PC relative branch.
    > If the called code being is more than 32M away, as it will be when
    > RAM_HIGH_ADRS is too high, everything goes bad.
    > Make sure you chastise (gently) the support staff that failed to tell
    > you about this.
    > Finally, for more efficient boot code, turn off the "long-call"
    > switches -- as you found out, that doesn't help this.
    >
    > HTH,
    > GV


    GV,

    Thanks for the suggestions. Just to be clear--

    Do I need the longcall switches for bootrom? Do I need them for the VIP?
    I'm guessing no and yes, respectively. Support came back with the extended
    vector suggestion--so I can't chastise them for that. Although it did cost
    me a day trying the other suggestions.

    The latest support email suggests:

    "reverse the values of RAM_HIGH_ADRS and RAM_LOW_ADRS in both the config.h
    file and the Makefile. This will load the bootrom into low memory and the
    kernel into higher memory. This will remove the restriction of your array
    growing as time progresses. You won't have to worry about the relative
    difference between RAM_HIGH_ADRS and RAM_LOW_ADRS decreasing causing you
    problems in the future. For example, by default the values of these two
    macros are:

    #define RAM_HIGH_ADRS 0x00800000 /* RAM address for ROM boot */
    #define RAM_LOW_ADRS 0x00100000 /* RAM address for kernel */

    Reverse them as follows in both config.h and Makefile:

    #define RAM_HIGH_ADRS 0x00100000 /* RAM address for ROM boot */
    #define RAM_LOW_ADRS 0x00800000 /* RAM address for kernel */

    This will provide enough space for a bootrom to be 8 MB in size. Most
    bootroms are no where near this large, so if your bootrom is say less than 2
    MB, you could then make RAM_LOW_ADRS to be 0x00400000, which will give you
    plenty of growth space for the bootrom, yet keep the kernel in the first 32
    MB of memory which should not require the change above to
    excExtendedVectors, as long as the exception vectors can be reached within
    the 26-bit values"

    My question regarding this suggestion is: Why isn't it done this way to
    begin with? Surely there must be a good reason. Do you agree this is a good
    option?

    Thanks,

    Bo




  6. Re: VIP size issues?

    On Apr 16, 9:10 am, "Bo" wrote:
    > "gvarndell" wrote in message
    >
    > news:1176408051.802896.134930@l77g2000hsb.googlegr oups.com...
    >
    >
    >
    > >> > On Apr 10, 11:41 am, "Bo" wrote:
    > >> >> I have a question regarding a VIP. I have the need for a very large
    > >> >> struct
    > >> >> array. I get a size error message telling me to up the value of
    > >> >> RAM_HIGH_ADRS, rebuild and re-flash a new bootloader to fix the
    > >> >> problem.

    >
    > >> >> Here are my specifics:
    > >> >> MVME5100 board with 512MB RAM
    > >> >> VxWorks6.3 BSP
    > >> >> Workbench 2.6

    >
    > >> >> If I up RAM_HIGH_ADRS to 0x0100 0000 (16MB), re-flash/rebuild VIP, the
    > >> >> card
    > >> >> boots and loads the VIP fine. However, if I set RAM_HIGH ADRS to
    > >> >> anything
    > >> >> higher than 16MB, it appears that the bootloader fails--I get
    > >> >> *nothing*--no
    > >> >> LED flickers (which I think indicate the bootloader is/has loaded the
    > >> >> image), no console port messages, etc.

    >
    > >> >> I tried RAM_HIGH_ADRS values of 32MB and 31MB, both with same results.
    > >> >> I
    > >> >> recall reading somewhere that RAM_HIGH_ADRS has to be less than
    > >> >> LOCAL_MEM_SIZE--which is why I tried 31MB. I'm not sure why this value
    > >> >> is
    > >> >> 32MB to begin with--but since we are using auto sizing to handle our
    > >> >> various
    > >> >> capacity boards, I was hoping this restriction would not apply. This
    > >> >> however
    > >> >> seems to not really matter at this point because even 31MB did not
    > >> >> work
    > >> >> (boot). Note that the rebuild of the VIP itself works fine with the
    > >> >> larger
    > >> >> values--it seems to be a bootloader issue. I modified config.h, and
    > >> >> the
    > >> >> RAM_HIGH_ADRS definition in the makefile (for the bootrom.bin) and
    > >> >> re-flashed. This procedure worked for 16MB.

    >
    > >> >> Does anyone have any insight as to what may be happening? I'd really
    > >> >> like
    > >> >> to
    > >> >> be able to up the RAM available to the VIP to 128MB for my 512MB card
    > >> >> and
    > >> >> 32MB for our 64MB MV5100 cards.

    >
    > >> > First suggestion would be to dynamically allocate the huge array and
    > >> > leave RAM_HIGH_ADRS alone.

    >
    > >> That won't work in my application without a lot of re-write of existing
    > >> code
    > >> base...

    >
    > >> > Second suggestion, if that won't work for you, is to verify that the
    > >> > bootrom is correctly setting up all available RAM.
    > >> > A JTAG tool such as a Wind River ICE would help here.

    >
    > >> I'm not sure what I would look for?

    >
    > >> > Finally, remember that if the PPC exception vectors are too far away
    > >> > from the exception handlers, you'll need to reconfigure more than just
    > >> > RAM_HIGH_ADRS -- you'll need to enable extended call exception
    > >> > handlers.

    >
    > >> On this last point-- the wind river folks told me to be sure to turn on
    > >> the
    > >> absolute-far switches for code/data to generate 32bit addresses instead
    > >> of
    > >> 24bit addresses and to build new image and bootrom with these switches. I
    > >> did this but it didn't work. This sounds related to what you are saying.
    > >> How
    > >> does one enable extended call exception handler? WindRiver has not made a
    > >> similar suggestion. I am using diab toolchain.

    >
    > > Bring up the Workbench help facility and type extended-call in the
    > > search thingie.
    > > The assembly code the kernel plants in the exception vectors calls the
    > > C handlers using a PC relative branch.
    > > If the called code being is more than 32M away, as it will be when
    > > RAM_HIGH_ADRS is too high, everything goes bad.
    > > Make sure you chastise (gently) the support staff that failed to tell
    > > you about this.
    > > Finally, for more efficient boot code, turn off the "long-call"
    > > switches -- as you found out, that doesn't help this.

    >
    > > HTH,
    > > GV

    >
    > GV,
    >
    > Thanks for the suggestions. Just to be clear--
    >
    > Do I need the longcall switches for bootrom? Do I need them for the VIP?
    > I'm guessing no and yes, respectively. Support came back with the extended
    > vector suggestion--so I can't chastise them for that. Although it did cost
    > me a day trying the other suggestions.
    >
    > The latest support email suggests:
    >
    > "reverse the values of RAM_HIGH_ADRS and RAM_LOW_ADRS in both the config.h
    > file and the Makefile. This will load the bootrom into low memory and the
    > kernel into higher memory. This will remove the restriction of your array
    > growing as time progresses. You won't have to worry about the relative
    > difference between RAM_HIGH_ADRS and RAM_LOW_ADRS decreasing causing you
    > problems in the future. For example, by default the values of these two
    > macros are:
    >
    > #define RAM_HIGH_ADRS 0x00800000 /* RAM address for ROM boot */
    > #define RAM_LOW_ADRS 0x00100000 /* RAM address for kernel */
    >
    > Reverse them as follows in both config.h and Makefile:
    >
    > #define RAM_HIGH_ADRS 0x00100000 /* RAM address for ROM boot */
    > #define RAM_LOW_ADRS 0x00800000 /* RAM address for kernel */
    >
    > This will provide enough space for a bootrom to be 8 MB in size. Most
    > bootroms are no where near this large, so if your bootrom is say less than 2
    > MB, you could then make RAM_LOW_ADRS to be 0x00400000, which will give you
    > plenty of growth space for the bootrom, yet keep the kernel in the first 32
    > MB of memory which should not require the change above to
    > excExtendedVectors, as long as the exception vectors can be reached within
    > the 26-bit values"
    >
    > My question regarding this suggestion is: Why isn't it done this way to
    > begin with? Surely there must be a good reason. Do you agree this is a good
    > option?


    I've never put a boot image 'under' a VIP, so I don't even know if
    this will work.
    I will assume that, if Wind River people told you it will work, then
    maybe it will.
    If it does, you will have sacrificed nearly 8 meg of RAM, but your
    loaded image will not need extended call exception vectors.
    The beauty of having the boot image above the RAM load area is that
    the loaded RAM based image (the VIP) just 'takes over' the memory the
    booter was using.
    That's about the best reason I can think of not to do what they're
    suggesting by default.

    On the subject of long call, it's needed whenever some code calls some
    other code that is more than 32 meg away.
    Usually a problem when downloading DKMs into a target that has a lot
    of memory.
    Occasionally even rears its ugly head with statically linked apps --
    if it's a huge, bloated C++ application.

    BTW, Wind River tech support people read this newsgroup.

    HTH
    GV



+ Reply to Thread