LOCAL_MEM_AUTOSIZE in Dual Core Processor
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()
Please give your ideas. Thanks in advance.
Re: LOCAL_MEM_AUTOSIZE in Dual Core Processor
On Aug 27, 3:01 am, prem.chakaravar...@gmail.com wrote:[color=blue]
> 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()
> Please give your ideas. Thanks in advance.
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
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
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.