IDBG - any suggestions ?
werner at openmoko.org
Thu Jul 15 18:12:41 EDT 2010
Ron K. Jeffries wrote:
> showing my ignorance here, but what does this mean:
> [you wrote]
> - has a dual USB stack that allows the regular firmware
> (Open Source, of course) to be updated via DFU.
The firmware consists of two parts: one part is the boot loader and
the other one is the application. The boot loader always runs first.
It sets up the chip and then checks if the Ben is powered up. If it
it, the boot loader jumps to the application.
If the Ben is not powered up, the boot loader loops, waiting for
either the Ben to power up or for the host (the PC) to send a DFU
command. (For those who don't know DFU: that's a very simply
protocol for downloading firmware over USB. A bit like TFTP, but
With DFU, one can flash the application into the MCU on IDBG.
The application implements the serial console, remote access to
GPIOs/reset, etc. The boot loader is protected against overwriting.
The boot loader is flashed over a special serial protocol when
making the board.
The idea here is to make sure that, no matter what the application
does, we always have a chance to upload a new version through DFU,
thus making IDBG unbrickable. Boot loader and application each have
their own USB stack, so that any bugs in the application's stack
don't affect the boot loader. (I could probably make the
application reuse part of the boot loader's stack, but then I'd
have to add better abstractions, worry about compatibility between
distant versions, etc.)
The switch between boot loader and application is relatively
transparent. If you plug in the USB cable of IDBG while the Ben is
already up, the boot loader doesn't show up. If you plug in the
cable before powering up the Ben, the serial console application
won't connect until application and PC have finished their USB
formalities, and you'll miss the first boot messages. Since IDBG
is now running the application, nothing will be lost after the
next reset or power cycle of the Ben.
IDBG itself must be unbrickable, because 1) it controls the Ben's
USB boot, thus becoming part of the Ben's own unbricking
procedure (you could still force USB boot manually, but that
wouldn't be very elegant), and 2) it controls the hardware reset,
so a runaway IDBG could just hold the Ben's CPU forever in reset.
More information about the discussion