How does flashing work
Note: this text is copy-paste from  and reproduced here in the event that the forum disappears.
I’ve spent some time looking into the flashing process. If you’re still interested in these questions:
- From snooping on the Chrome extension, I’ve found this: http://flash.getchip.com/flashImages 110
- The CHIP-tools repo looks in a completely different place, for differently-packaged files.
- I’ve come to a roughly affirmative conclusion, but I can’t be entirely sure there isn’t some other stuff that is supported in other branches in CHIP-tools.
- The by/4.4+ branch looks like it has some newer stuff. It downloads stuff from a different place from the chip/stable branch, that’s for sure.
- Yes, it’s the bootloader. But one feature of its operation is that it runs scripts, which is involved in the flashing procedure.
- As answered before, fastboot is something that the Android project made for flashing devices. I’ve heard it described as being three things: (i) a small bootable piece of software on a device capable of flashing its memory, (ii) a program for a computer for sending images to (i), and (iii) the protocol through which (i) and (ii) communicate.
On the C.H.I.P., the fastboot software is actually integrated into NTC’s build of u-boot. Fastboot is somehow smarter/more stable/otherwise better than FEL at transferring data over USB, so it’s preferred to a “no-fastboot” method of flashing. For one thing, fastboot has a way to chunk up large transfers, so you can flash partitions that are larger than RAM, so it’s actually required for some firmware images.
The flashing process
When the CPU boots up with the FEL pin connected to GND, it boots into a basic programming environment (called FEL). The way FEL works is hard-coded in ROM on the CPU. It’s really simple, so it can’t do the whole job of flashing the C.H.I.P., which leads to the flashing process being complex. FEL mode can read and write data into memory and execute code in memory. At this point, the C.H.I.P. shows up on the flasher computer as a FEL USB device.
FEL mode starts out not even knowing about DRAM, so the first job of the flashing tool is to upload and execute some code to set up the RAM. This is done with fel spl sunxi-spl.bin. The fel spl command itself is pretty complex due to some strange limitations in FEL mode and the sunxi-spl.bin program not fitting anywhere in memory without DRAM.
Moving on, sending data over USB through FEL is somehow inefficient, so the next step is to install something smarter into memory that can handle data transfers more intelligently. That something is fastboot, which you may know from the Android project. For the C.H.I.P., the fastboot device software is built into u-boot. That, padded-u-boot gets transferred into an address in RAM (0x4a000000).
At this point, we also transfer some of the smaller things we need, still over FEL. These are:
- Another copy of the SPL, sunxi-spl-with-ecc.bin (into address 0x43000000). It’s in a different format, which is suited for storage on NAND. This will let the device boot without FEL holding its hand.
- A script for u-boot to run, uboot.scr (into address 0x43100000). U-boot alone is just an interpreter, and this script instructs it to handle the rest of the flashing procedure. You can take a look at what it does by running strings uboot.scr. When the fel command uploads this, it also modifies some memory that will later inform u-boot that there is a script for it to run at this address.
Now, we use fel exe 0x4a000000 to start u-boot, which will interpret the uboot.scr script.
Hooray, now we are in u-boot, which additionally knows how to interact with flash memory. We finally have our 64 Gib at our disposal.
First, the script erases everything. Then, it does some of the easy flashing:
- It writes two copies the content from 0x43000000 (the SPL, remember) into the SPL and SPL-backup partitions.
- It writes a copy of the content from 0x4a000000 (u-boot itself, remember) into the u-boot partition.
- It sets up the u-boot environment partition with a series of setenv operations followed by saveenv. One of these is bootcmd, which is a u-boot script to run when it doesn’t have a uboot.scr around to hold its hand.
Then, it enters fastboot mode with the fastboot 0 operation. This causes the C.H.I.P. to appear as a different USB device.
The computer transfers the root filesystem with fastboot -i 0x1f3a -u flash UBI rootfs.ubi. The fastboot software on the C.H.I.P. receives this piece by piece, writing each piece into the UBI partition.
In the end, the computer uses fastboot -i 0x1f3a continue to make the fastboot 0 u-boot operation return. And then, like, either there’s an infinite loop at the end of uboot.scr or it just ends, and u-boot runs the bootcmd and the C.H.I.P. loads up the newly written kernel and starts booting normally.