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

From: Antti Keskinen (antti.keskinen_at_REMOVEME.koti.luukku.com)
Date: 01/24/05 

Date: Mon, 24 Jan 2005 16:52:03 +0200

"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

Relevant Pages

  • Re: Softkicking on a DKB Cobra/1240
    ... the memory the CPU executes data from might go ... Whether or where the ROM remapping goes I don't know. ... on the board whether the remapping is reset, ...
    (comp.sys.amiga.programmer)
  • Re: When a computer start
    ... The code there did either a "big-real" mapping and jumped to the ROM up at the top, or went into protected mode and jumped there. ... exceptin the 64 bit versions which I've not yet had an opportunity to go at with an ICE. ... I once checked the memory contents below the top 4GB assuming ... On the machines I note above, and on the one or two PCs I used an ICE on, I *DID* see the ROM repeated at the top of memory DURING reset, but on the PC machines, it disappeared when the main-board was released from reset. ...
    (alt.lang.asm)
  • Re: Softkicking on a DKB Cobra/1240
    ... Whether or where the ROM remapping goes I don't know. ... on the board whether the remapping is reset, ... then this memory should *disappear* after a reset and thus will remain ...
    (comp.sys.amiga.programmer)
  • Re: maybe a bit OT: EEPROMs and PCs
    ... | Ahh, okay. ... | BIOS chips. ... For all ROM code I'd use ... The things inbetween these brackets are the memory address. ...
    (alt.lang.asm)
  • Re: IIgs peculiarities
    ... permanently shadowing from bank 0 would have corrupted whatever was ... Same for a ROM 1 or ROM 3. ... Memory cards which support more than four "rows" do so via a mechanism ... so a memory card which uses this technique is ...
    (comp.sys.apple2)