The official webpage goes through how one should program their Arduino Due using the Arduino software.
For those who are going to develop a project without Arduino but with basic g++, one must understand how to program his chip. Apparently, the Due - SAM3X - has a booting process somewhat different from the AVR, and it is not quite the same as firing up the "avrdude" and be done with it. Ardunio has designed the board such that flashing firmware is easier than what the stock SAM3X has offered, here explains the booting process and the tricks that Arduino implemented.
The SAM3X comes with a built-in bootloader, called SAM-BA. Standalone SAM-BA tools could be downloaded from the Atmel website. SAM-BA is permanently burned in the chip ROM straight out of factory, and is not using up any of the flash space. This is very different from AVR that AVR doesn't come with any built-in bootloader.
In addition to SAM-BA, SAM3X could be booted in the middle of the flash, instead of the very beginning of the flash like they normally do. One could code their own userspace bootloader in the 0-256KB, and the real application in the 256KB-512KB.
So in short, there is three boot start points - SAM-BA, Flash 0 and Flash 1, this can be controlled by tweaking the GPNVM bits in EEFC0.
In Arduino, as well as most of the scenarios, the code is flashed with SAM-BA tools. Flash 0/1 userspace bootloader is not used in Arduino.
SAM3X will boot to SAM-BA when: A) the GPNVM bits have been modified (set to 0) to instruct SAM3X to boot to SAM-BA. It can be done in userspace code. B) Erasing the chip (Erase button) which will also clear/zeroing the GPNVM bits and leads to the SAM-BA again.
In SAM-BA, firmware could be flashed over the native USB port, which will be put in CDC mode, or through the first UART channel. SAM-BA will wait indefinitely without timeout. In other words, once the GPNVM bit is cleared for SAM-BA booting, it will always be there waiting for flashing, even after power cycling.
Of course, the flash content and the GPNVM bits could be flashed over the JTAG, which will not be discussed here.
Two things have been done by Arduino such that users need not to press the ERASE button everytime.
The ATMEGA16U2 chip, acting as a USB bridge to expose the UART as USB replacing the FTDI chip, actually does more than that.
If the host is connected to the programming port at baud rate 1200, the ATMEGA16U2 will assert the Erase pin and Reset pin of the SAM3X. Forcing it to the SAM-BA bootloader mode.
At any other baudrate, it will reset the SAM3X. This is done to simulate the behavior of the AVR-based Arduino - connect and reset.
The code, firmware of the ATMEGA16U2, currently lives in ide-1.5.x branch of /hardware/arduino/sam/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c.
When Arduino uploads the sketch, it will actually wire up some additional C-code. One in particular, is that it configs the native USB port as CDC for serial communication. That specific code has a similar detection of ATMEGA16U2 in place. When the port is opened with baud rate 1200, it will set the GPNVM bits appropriately for booting to SAM-BA, and reset itself.
The corresponding code lives in ide-1.5.x branch in /hardware/arduino/sam/cores/arduino/USB/CDC.cpp.
Everything after erase is just SAM-BA logics, user could connect to the SAM-BA through the SAM3X native USB, which is put into CDC mode by now. Or to the UART, through the Programming port which is also CDC but exposed by ATMEGA16U2.
If someone is going write C from scratch, it's unlikely that the On-chip CDC 1200 hack would be taken care, hence opening 1200 baud rate on the native port won't work. One could refer to Arduino's implementation for keeping the same behavior if wished.
If the native USB port is put into other uses other than CDC, this obviously won't work. It is a USB 2.0 High Speed 480Mbps port, someone would possibly have made a better use of it other than CDC.
The ATMEGA16U2 would always work. Anyone unhappy of the 1200 tricks of course could modify the firmware themselves, flash it over the ICSP header with AVRISP technique.
For opening the port in 1200, one could use Putty (an open source software commonly used for SSH in Windows) to connect to the corresponding COM port. If this is done over the native USB port, after closing the connection, the port will disappear shortly afterwards, and a new COM port with another identifier will come up, which is the SAM-BA native USB CDC.