Bootloader

It is all explained here...

They are used the same way they are in non-embedded programming.

Maybe you don't. Some platforms use them, some don't. Whether you need one or not depends on your hardware and software architecture. Small embedded systems often don't have a bootloader.

A bootloader initailizes the hardware and then loads/starts a second, larger application.

No clue what you mean by that.

Don't know what you mean by that either.

Mostly the same as desktop programming, although on a small embedded application your usage of all that is heavily shaped by the fact that you don't have a lot of memory or processor time to waste.

You don't _need_ a bootloader, per se. Often if you've got some really big software load (like linux with applications, or VxWorks, etc.) a bootloader makes your life easy.

A shippable product does not have a debugger attached to it, any more than your average 18 year old kid still has an umbilical cord.

Presumably you are asking a question about a specific processor or board. This may sound odd, but not everyone here has used everything available. Perhaps this has to do with people having finite lifetimes.

I suggest you either tell us more about what PBL and SBL are, or that you study the documentation for the product in which you've found those terms and see if you can figure it out for yourself.

Grant Edwards schreef op 04-Feb-14 7:36 PM:

You interpret the term 'bootloader' as a minimal piece of software that always gets control at startup, and is responsible for the loading of the 'real' application.

There is another interpretation, mainly for small microcontrollers with flash memeory. In this case the bootloader is a small piece of software that CAN be run at startup to load new content for the flash over some communication link, after which the chip can be reset another time, this time enabling the (new) application in flash.

This second form of bootloader is very common on small micronctrollers, for instance all LPC ARM/Cortex UC's I know have a built-in serial bootloader, and some have an additional bootload option over CAN or USB.

For this interpretation, an answer could be 'to facilitate in-field software updates'.

Wouter

Given the context from the other questions, my _guess_ would be the OP means Primary Boot Loader and Secondary Boot Loader.

My _guess_ would be the PBL is the on-chip boot ROM and the SBL is something like the U-Boot SPL loader.

Simon.

When you have homework questions, be honest about them. You are a /long/ way from being in any industry as yet.

I made a shipping product with a debugger still attached. I used an FTDI 2232C chip with one channel connected to the microcontroller's UART (for normal PC to board communication while running), and the other as a JTAG-style connection (BDM, to be accurate) to the microcontroller. While it didn't support full debugging, it supported "programming over the debugger" from the PC for downloading and updating the software. It worked very well, and is a method I could well use again - especially for ARM chips with OpenOCD running on the PC side.

Get out while you can.

Yes!

You don't need it since you use debugger.

Some memory is more equal than other.

Vladimir, come back, we need you...

Very much so :)

prashanthgr.1992, you need help on the ground.

The n> Hi all,

Those are just elements of 'C' programming and not constrained to embedded.

Supposedly, you really cannot ship a product with a debugger attached. A boot loader "loads" a program at "boot" time. Examples might be LILO or U-Boot.

your question as asked leads to a lot of questions.

Beats me. Sounds specific to an architecture.

Do you mean "shipped" as in "run at a test site" or "as production"? Having an end customer run a debugger at boot time*, or even at update time seems troublesome.

Even on stuff with 68000 or Codlfire-in-68000, long as there's FLASH memory for program storage, I've mainly seen people write program loaders over a 232 port for going on 25 years now.

Even better; have a filesystem in FLASH.