Reddit Upvoted: My Attempt at a New Method of Flashing via /r/ChipCommunity


My Attempt at a New Method of Flashing

I'm trying to make flashing the CHIP as easy as I can, and I think I have gotten as far as I can get in the flashing department. I've created a new method that runs an on-device web server that allows you to upload images to the CHIP directly without having to use a serial console or a command line. The downside is that you still need to use the command line to flash the initial bootloader. I don't see any way around that for the time being. The method is built on the wonderful tools SWUpdate and Buildroot.

SWUpdate in Action.

The main advantage of this method is that once the bootloader is flashed you can just keep reusing the SWUpdate mode again without ever having to mess with the command line for flashing. Additionally, this is the first tool (that I am aware of) that preserves wear leveling information when you replace the rootfs. This means that erase counters (which are vital for properly tracking and managing the lifetime of raw NAND) is preserved even if you erase the rootfs.

Additionally, relative to the thread posted here, I have replaced the older SPL files with mainline versions. This allows us to use redundant U-Boots, so in the event of NAND corruption of the first U-Boot a second backup is used.

I run all the commands for flashing as sudo. If your dbus rules are set correctly for sunxi-tools this is not necessary, however for a one-time flash simply using sudo before the commands should suffice (you can omit sudo if you prefer and your dbus is set up correctly).

As for the steps to flash:

Step 0: Build sunxi-tools from source. You will need the latest tools (most likely) rather than what came with your distro. There is a great guide here to help you accomplish that: https://linux-sunxi.org/Sunxi-tools#Building_from_Source The version of sunxi-tools I am using for this is sunxi-fel v1.4.2-116-g6c02224, for reference.

Step 1: Download the tools located here and save them to your machine. https://macromorgan.s3.amazonaws.com/ntc-chip-mainline/flash_tool_v3.tar.gz https://macromorgan.s3.amazonaws.com/ntc-chip-mainline/ntc-chip_2022.02.25.swu

Step 2: Extract the contents of the "flash_tool_v3.tar.gz" archive with the following command: "tar -xzvf flash_tool_v3.tar.gz". This will extract the necessary files in a directory labelled "flash_tool_v3".

Step 3: Put your CHIP into FEL mode by jumpering the FEL pin and a ground pin (using a paperclip, a dupont wire, or anything else suitable). Plug the CHIP into your computer with the necessary files for flashing and then run the command "sudo sunxi-fel -l". If you see output mentioning a USB Device for an Allwinner A13 things are working correctly. If you do not see any output, check that the device is in FEL mode and that you are using the most recent sunxi-tools.

Step 4: From this directory, run the script labelled "flash_device_erase_nand.sh". This script will need to be run as root unless certain dbus permissions are set up correctly (they were not on my system). I will explain in a follow-up post why there exists a second script labelled "flash_device.sh" and what its purpose is. For now, ignore it. Run "sudo ./flash_device_erase_nand.sh". You should see the progress indicators as various things download to your CHIP. Once this step has completed the CHIP should shut itself off after about 15-30 seconds (as soon as it finishes writing everything from memory to the internal NAND).

Step 5: Remove the FEL jumper, and plug the CHIP into a computer with a web browser. For my example I am using a Windows 11 PC. The CHIP will likely "blink" for a second after you plug it in and then shut itself back off. This is normal, it is because the bootloader is now programmed not to turn the CHIP on unless you press the power key.

Step 6: Press the power key to turn the CHIP on while it is plugged into a computer with a web browser. After the CHIP boots it should present itself to your computer as an ethernet device and should automatically asign an IP address to said device via DHCP (what we are calling SWUpdate mode). You can observe your CHIP is in SWUpdate mode at a glance by observing the LED flashing every second.

Step 7: Open a web browser and go to http://chip.local/. Occasionally I had trouble accessing the CHIP via DNS, so I had to try http://10.10.10.10/. Please try the IP address if the DNS location does not work for you.

Step 8: On the web page there is a box that says "Click here, or drag and drop a software update image file to this area". Either click the box and select the ntc-chip_2022.02.25.swu downloaded previously, or drag and drop said file into that box. At this point the web application uploads the image to the CHIP and it is written as it is uploaded. Once the image has been successfully written, your CHIP should reboot itself.

That should be it, assuming everything worked you now have a CHIP that is fully flashed. This is mostly the same image (with the same bugs) as posted previously. This image still suffers from several known issues including occasional freezing at shutdown and issues with function keys in Xorg applications. Some (but not all) of the wifi bugs have been fixed by disabling wifi power management and character maps for the console itself should be working better now (kbd is now installed by default and the pocketkeys.service script has been fixed).

To reflash a new rootfs image: From within the existing rootfs simply run "sudo restart_swupdate" to reboot into the flashing interface and repeat steps 6-8. If you choose the "Restart System" option from the web interface it will restart back into the rootfs. If you are unable to use restart_swupdate (either because you are using a different image or have corrupted your rootfs) you can also trigger SWUpdate mode by jumpering the pin labelled TWI1-SCK to GND while the device is off (while not utilizing a DIP or the PocketCHIP) and then turning it on. See here for the pinouts: http://chip.jfpossibilities.com/docs/chip.html#pin-headers. As long as the jumper is connected the device will always boot into SWUpdate first.

Please note that this tool is still very much considered "alpha" and I'm looking for info to see if there are any ways to improve it. Like I have done for the necessary Linux and U-Boot bits, I'll be documenting the Buildroot and SWUpdate bits so others can reproduce this work.

edit 1: Forgot to mention but SWUpdate mode has ssh enabled by default too. You can ssh into it with the username of root and the password of swupdate at the address chip.local (or 10.10.10.10 if DNS is being difficult like it occasionally would be for me).

Submitted March 01, 2022 at 11:25PM by macromorgan
via reddit https://bit.ly/3PlMnZc