Forums

Self booting systems with out bootloader?!!!

Started by s.subbarayan January 24, 2005
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
On Sun, 23 Jan 2005 23:06:02 -0800, s.subbarayan wrote:
> 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?
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.
> 2)My query is what do you mean generally when you say "self booting" > systems?
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.
> 3)Does that mean there is no RAM present and the code executes fully > from ROM?
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. ]
> 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?
Seems pretty likely.
> 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?
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.
> 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?
No boot-load step --> no (reduced, anyway) boot time: instant on.
> 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.
Depends strongly on the size of the system. Details matter. -- Andrew
In article <c396173e.0501232206.72314037@posting.google.com>, 
s_subbarayan@rediffmail.com says...
> 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.
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.
> 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.
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
> > Looking farward to all your replys and advanced thanks for the same, > Regards, > s.subbarayan >
"s.subbarayan" <s_subbarayan@rediffmail.com> wrote in message

<snipped off for clarity>

> 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?
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.
> 2)My query is what do you mean generally when you say "self booting" > systems?
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.
> 3)Does that mean there is no RAM present and the code executes fully > from ROM?
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.
> 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?
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.
> 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.
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
"s.subbarayan" <s_subbarayan@rediffmail.com> wrote in message news:c396173e.0501232206.72314037@posting.google.com...
> 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?
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.
> > 2)My query is what do you mean generally when you say "self booting" > systems?
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.
> > 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?
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.
> > Looking farward to all your replys and advanced thanks for the same, > Regards, > s.subbarayan

"s.subbarayan" wrote:

> Dear all, >
> 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? >
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.
> > 2)My query is what do you mean generally when you say "self booting" > systems? >
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.
> > 3)Does that mean there is no RAM present and the code executes fully > from ROM?
>
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.
> > 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? >
you need variables in RAM for any real product... and the kernel will reserve space for its own variables as well.
> > 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?
Based on the quotes you gave, I think that is a fair assessment of the situation.
> > > 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. >
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