Okay the PWM device was built in the device table blob, so getting it available was mostly a fight with setting up the tools and finding the correct node in the table to edit. Here are my notes.
First off, you will need to grab the fdt edit files from the outernet server that @Abhishek posted above. We are going to make a file in the downloads folder named tools to place them in. Get started by using ssh to log into your CHIP. Username: outernet Password: outernet
All of these of commands will be run as root, so we are going to just change over to root instead of sudo'ing everything.
sudo su -
Password again: outernet
Then we will make our directory to hold our tool files.
We make a directory...
and then set the permissions...
chmod 755 tools
and change into the dir.
Now we will pull the files from the internet.
Set our permissions again, do this one at a time if you have other files in this directory. Otherwise...
chmod 755 *
Now make the /boot file system read/write. As Abhishek noted above do not monkey around with any files here, your CHIP will stop booting.
So lets go play with those files we should not play wirh...
And lets patch up the device tree to turn on the PWM hardware. (see note 1 at the bottom)
/mnt/downloads/tools/fdtput -t s sun5i-r8-chip.dtb /soc/pwm status okay
That line patched up the device tree, now for the cleanup.
We should be about done here. It's time to power off and reboot. I had issues with reboot, YMMV.
At this time you should be able to press the power button on the chip to boot back up. To see if things worked after the system restarts log in and...
You should now see the control node pwmchip0. That is what you want to use the HW PWM, perfect for driving your servo. Good luck. See the NextThingCo boards for more info on how to set this up, a shell script can do all the work from here. If you need some floating point math that is what the other file "bc" is for. Look up there in the outernet archinve for the executable bin.
It seems that few if any people edit device tree blob files. Every discussion I could find generally referenced working with the device tree during the kernel build setup scripts. So I just ended up banging away with fdtget until I understood the filesystem type structure that was in the compiled device blob. Anyhow I don't recommend trying to find or learn this from google searching.
UBIFS flash file systems are slightly better documented than DTB's are, but I had barely found the chbootfsmode command (in the outernet docs on compiling your own kernel) when Abhishck warned me about how easy you can corrupt them. I can only guess how big a pain in the sas it was to find how to build this, I will be watching to see how the OTA overlays work with this filesystem. I am not sure how needed that 'sync' is before I switched /boot back to read only, but I thought better safe than sorry.