Self booting systems with out bootloader?!!!

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Dear all,
   I was going through vxworks6.0 kernel programmers manual.I came
across the section on kernel and found this following sentence
regarding the various boot images possibles with vxworks6.0 version:

"Self-booting VxWorks image can also be created, which do not require
a boot
loader."
After this sentence a few pages down,I found the following line again:

"For self-booting images, the data segment of a ROM-resident VxWorks
system is
loaded at RAM_LOW_ADRS (defined in the makefile) to minimize
fragmentation."

1)I am not getting the relation between fragmentation and storing the
data in low address area of RAM.How does loading data section in low
address area prevent fragmentation?

2)My query is what do you mean generally when you say "self booting"
systems?

3)Does that mean there is no RAM present and the code executes fully
from ROM?

4)If thats the case,then the second sentence as stated above confuses
me,because it says the data section will be present in
RAM_LOW_ADDRESS.Can some one clarify me this?

AFAIK,when we say selfbooting,this applies for production systems in
some embedded products(not for every embedded device) where the code
will be executing completely from ROM and boot code will not get
copied to RAM and code will be executed from ROM.Is this understanding
correct?

I have worked with avionics protocols and consumer electronics related
embedded systems.But I am curious enough to know what sort of embedded
applications can be created with ROM only version with out
bootloader?IMHO its going to be taking more time to boot from ROM as
compared to RAM.Given the fact that,most embedded systems are for
mission critical stuff,what will be advantage in moving to ROM only
systems?I think consumer electronics apps are less critical as
compared to medical and avionics systems,but still in the consumer
electronics devices (typically DVD player,STB),I have worked with had
a boot loader and was not executing from ROM.

Looking farward to all your replys and advanced thanks for the same,
Regards,
s.subbarayan

Re: Self booting systems with out bootloader?!!!
Quoted text here. Click to load it

If you don't start using RAM from the lowest address, then there will be
some unused space below the address that you do start from.  I guess they
consider that to be fragmentation.

Quoted text here. Click to load it

Processor starts executing from a certain address.  You arrange for that
address to be in ROM, and for the instructions to be from your program,
rather than a boot-loader that finds your program somewhere else.

Quoted text here. Click to load it

There may be RAM present, but the code executes from ROM.  [Or (in the
wider context of comp.arch) perhaps a system service processor held the
main processor in reset while it did the boot-load step, and then released
the main processor when the program was loaded. ]

Quoted text here. Click to load it

Seems pretty likely.

Quoted text here. Click to load it

Lots of SOC deep-embedded chips have the application in mask-rom.  Access
time is the same as on-chip RAM: there is no speed penalty, and a savings
in RAM by not requiring duplicate space.

Quoted text here. Click to load it

No boot-load step --> no (reduced, anyway) boot time: instant on.

Quoted text here. Click to load it

Depends strongly on the size of the system.  Details matter.

--
Andrew

Re: Self booting systems with out bootloader?!!!
s snipped-for-privacy@rediffmail.com says...
Quoted text here. Click to load it

Well, that opinion would be incorrect.  With the exception of toys and
other such ultra-high volume products, modern consumer electronics are
more and more often based on Flash memory, not true ROM. Access time
of flash today is equivalent to DRAM of about 5 years ago.  Depending
on the application, the microprocessor may have on chip cache RAM that
avoids bottlenecks accessing the flash.

Quoted text here. Click to load it

Boot loaders today serve the purpose of allowing the firmware in Flash
to be updated.  Since it is not possible to execute from flash while it
is being erased or programmed (with the exception of certain, pricey,
dual segment devices), the boot loader has a requirement to copy its
image into RAM and execute from there during a flash programming
operation.

If the application is never intended to be replaced, and the firmware
executes from ROM or flash, as opposed to being copied into RAM and
executed from RAM, there is no need for a boot loader at all.

--Gene

Quoted text here. Click to load it

Re: Self booting systems with out bootloader?!!!

<snipped off for clarity>

Quoted text here. Click to load it

The way I see this is that if there are unused areas between used areas
(like, addresses 0x0000-0x0002 are unused, and program code starts from
0x0004) then the memory is considered 'fragmented'.
A non-fragmented memory just means that every byte from the start of memory
has a purpose: data or program code, and the only place where 'free space'
is available is at the end of the memory range.

Quoted text here. Click to load it

A self-booting system is a device where the first program code byte is in
the location where the processor's program counter (PC) register points to
after hardware reset. This means that after a reset is made, the processor
starts instantly running through the actual code it's supposed to execute
(like monitoring an input or generating an output)

A non-self booting system is otherwise similar, but the program counter
register points to a small fragment of code that either copies the actual
program code into the processor memory or relocates the PC pointer. For
example, if after hardware reset the first byte PC points to is part of a
jump instruction to external memory location, we have a so-called
'bootloader', although a very simplistic one.

Quoted text here. Click to load it

These are non-related. Lacking a bootloader just means that the processor
starts directly to work on the actual code without doing *anything* else.
You can have RAM, if you need, but the first byte where PC points to after
reset must already be part of your program the processor is supposed to
execute. So, in general sense, it means that the code is (in full or partly)
in processor ROM. In very rare CPUs the PC points directly to external
memory area immediately after reset.

Quoted text here. Click to load it

Partly, yes. Selfbooting system does no prelimenary steps before it starts
executing the 'work program'. The term 'work program' means the program the
processor is supposed to do, like monitoring an input, generating an output.
The term 'instant on', like someone already stated, is most accurate.

Quoted text here. Click to load it

All embedded applications without a bootloader usually have non-changeable
firmware. For example, a simple device that just calculates the frequency of
the input signal and outputs a serial code based on it's range is an
embedded system which needs no bootloader. Just hit in a Intel 96-processor
and program the processor ROM address 2080H to contain the first work
program byte.

Like you might fathom, even a tad larger system which might allow updates
later on does not qualify to 'non-changeable firmware'.

These are my opinions on the matter. They might or might not be correct, but
at least I've done well with them :)

-Antti Keskinen



Re: Self booting systems with out bootloader?!!!
Quoted text here. Click to load it

It's been a while since I used vxWorks, but IIRC RAM_LOW_ADRS is the lowest
usable ram address - the idea is that you end up with the vxWorks data segment
as far
down in Ram as possible, and the rest of Ram free, so malloc(rest_of_ram) works.

Quoted text here. Click to load it

I think they mean that it starts executing the the final vxWorks image in Rom, as
opposed to a system with a vxWorks bootrom, which tries to load an image
via ftp and start that.

The idea is that while you're debugging you use the bootrom, and switch to
a self booting system for production.

Quoted text here. Click to load it


Code is in Rom. Data needs to be in Ram so you can change it. The idea
is that you need to have enough Rom for the code, and enough Ram for the
Data.

If you need to run the code from Ram, which is usually quicker, you need to
have enough Ram for Code and Data - in this case the image is usually compressed
so you need a Rom ~50% of the size of Code and Data. A bit less actually, since
some of the data will be BSS, which initialized to zeros.

Quoted text here. Click to load it



Re: Self booting systems with out bootloader?!!!



Quoted text here. Click to load it


if you load it in the middle of memory, you immediately start with two
'fragments' of memory devoted to the memory pool, so you can't allocate
all of memory in one chunk.  So you gotta load at the top or bottom.

Quoted text here. Click to load it

they are just talking about not having a bootloader, I think.  Had to have
some way of informing their customers that now vxworks could do what most
other embedded systems have always done, and this is the sales
terminology.

Quoted text here. Click to load it


nope.  They won't have been able to create a kernel that can run without
variables stored in RAM.  But from the quotes you gave it does indicate
that you can run the kernel from ROM so you won't need enough RAM to load
the whole kernel into.

Quoted text here. Click to load it

you need variables in RAM for any real product... and the kernel will
reserve space for its own variables as well.

Quoted text here. Click to load it

Based on the quotes you gave, I think that is a fair assessment of the
situation.

Quoted text here. Click to load it

Well for example we do life-safety systems that aren't usually high-speed,
and for a lot of it we don't use VxWorks but code close to the metal, e.g.
by putting our own start addresses in the processor's initialization
vector and bringing the board up ourself.  We run these systems entirely
out of ROM chips  (actually FLASH chips) rather than placing other types
of storage into the system.  It has been said there are far more embedded
computers than there are desktop computers...  and in the early days *ALL*
of them were done this way, even today I don't think it is uncommon
although more and more we start with a basic operating system except when
production quantity means cost scaling can't do with run-time licenses.

But also more and more even in these systems, a separate 'boot' app is
added that has basic functionality such as the ability to download a new
image into the flash chips or maybe self test code.

David

Site Timeline