LOCAL_MEM_AUTOSIZE in Dual Core Processor - VxWorks

This is a discussion on LOCAL_MEM_AUTOSIZE in Dual Core Processor - VxWorks ; Hi friends, I am working in X86 arch and VxWorks 6.6. LOCAL_MEM_AUTOSIZE (Auto memory scan) is working in single core processor. But it is not working in dual core processors. Enable this in dual core processor, then it BootROM gets ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: LOCAL_MEM_AUTOSIZE in Dual Core Processor

  1. LOCAL_MEM_AUTOSIZE in Dual Core Processor

    Hi friends,

    I am working in X86 arch and VxWorks 6.6.

    LOCAL_MEM_AUTOSIZE (Auto memory scan) is working in single core
    processor. But it is not working in dual core processors. Enable this
    in dual core processor, then it BootROM gets hang in V1.6++++
    itself. Without this option, dual core processor BSP is working fine.

    It is booting before sysPhysMemTop() function in BootROM. It might get
    hang in sysPhysMemTop() function or kernelInit() in usrInit()
    function.

    Please give your ideas. Thanks in advance.

    -Thanks
    C.Premnath

  2. Re: LOCAL_MEM_AUTOSIZE in Dual Core Processor

    On Aug 27, 3:01 am, prem.chakaravar...@gmail.com wrote:
    > Hi friends,
    >
    > I am working in X86 arch and VxWorks 6.6.
    >
    > LOCAL_MEM_AUTOSIZE (Auto memory scan) is working in single core
    > processor. But it is not working in dual core processors. Enable this
    > in dual core processor, then it BootROM gets hang in V1.6++++
    > itself. Without this option, dual core processor BSP is working fine.
    >
    > It is booting before sysPhysMemTop() function in BootROM. It might get
    > hang in sysPhysMemTop() function or kernelInit() in usrInit()
    > function.
    >
    > Please give your ideas. Thanks in advance.
    >
    > -Thanks
    > C.Premnath



    Ok, you need to be clear here.

    You say "BootROM gets han in V1.6++++ itself." Unfortunately, this is
    ambiguous. There's actually two possibilities:

    1) The vxld.bin boot block prints only a few + signs and then stops.

    2) The vxld.bin boot block prints many lines of + signs and stops.

    The boot block prints a + every time it reads a sector from the disk.
    The bootrom.bin file occupies several dozen sectors on the disk, so
    ideally you should see 6 or 7 full lines of + signs across the screen,
    and then the bootrom will start. (If you've built your bootrom with
    the VGA console option, the screen will turn blue and you'll see the
    Wind River copyright notice and bootrom output. If not, the output
    will show up on the serial port.)

    If the vxld.bin boot block only manages to print a few + signs and
    then gets stuck, then your problem has nothing to do with the BSP: you
    haven't even finished loading the bootrom.bin image at this point. If
    this is what's happening, then there's something wrong with your boot
    disk, or there's an issue with the BIOS that's preventing vxld.bin
    from loading the bootrom properly. (Sadly, vxld.bin isn't the most
    robust piece of code in the world, and it has been known to fail with
    some BIOSes.)

    You did not tell us which case you're experiencing. It's not clear if
    it's 1) or 2). Again, if it's 1), then there's a problem with your
    boot disk, which has nothing to do with the BSP.

    Anyway, if the issue really is 2), then you could indeed be having a
    problem with the memory autosizing. The autosizing scheme that VxWorks
    currently uses on BIOS-based x86 systems is actually a crude hack: it
    just does a write/read test on every memory page, increasing the page
    address as it goes, until it gets to a page where the write/read test
    fails. (That is, it writes some data and reads it back. If it doesn't
    read back what it wrote, it assumes it went past the end of RAM and
    into an area of the address space where no RAM is mapped.)

    This technique is unreliable: if you are unlucky, the BIOS may have
    mapped the register window for some random device on the motherboard
    right beyond the top of memory, and writing to that mapping
    indiscriminately may hang the system. (There's know way to know for
    sure; it might not, but the results are unpredicable.) The fact that
    this happens to work on some machines is largely a coincidence.

    (What you're *supposed* to do is query the memory map from the BIOS.
    However you can't do this from protected mode, and the bootrom
    switches the CPU into protected mode immediately after entry. Ideally,
    romInit() should dump the memory map from the BIOS while it's still
    running in real mode and save the results so that VxWorks can process
    it later.)

    Anyway, if your problem really is a memory autosizing failure, it has
    nothing to do with whether you have a single core or dual core CPU.
    The CPU type doesn't matter: what matters is what devices are present
    on your board and how the BIOS has mapped their register windows or
    memory apertures for you. I've had memory autosizing fail on both dual
    core (Core Duo) and single core (Pentium 4 D) systems.

    The workaround is:

    1) #undef LOCAL_MEM_AUTOSIZE in config.h

    2) Manually set SYSTEM_RAM_SIZE in config.h to reflect the actual
    amount of RAM on your board. (You can set it to a value less than the
    actual amount of RAM if you want, though that means the remaining RAM
    will go unused.)

    In other words, turn the memory autosizing feature off and hardcode
    the memory size instead. This is what I've had to do on a couple of
    occasions. It's not terribly pretty, but if you're building a device
    with a static hardware configuration -- that is, nobody's going to add
    or remove RAM once it's in the field -- it should be ok.

    -Bill

+ Reply to Thread