Self booting systems with out bootloader?!!!

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

Reply to
s.subbarayan
Loading thread data ...

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.

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.

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. ]

Seems pretty likely.

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.

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

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

--
Andrew
Reply to
Andrew Reilly

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.

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

Reply to
Gene S. Berkowitz

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.

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.

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.

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.

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

Reply to
Antti Keskinen

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.

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.

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.

Reply to
Tom

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.

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.

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.

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

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

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

Reply to
David Lindauer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.