There are quite a few steps and preparations needed to do this, however, this is for documentary purposes only. You don't need to do any of the stuff below (except backup), you can just flash my OpenWRT firmware and be none the wiser. However it might be useful if you want to port it to a new device, I could not find any tutorial about this.

How booting works

When the CPU starts up it goes to the first address inside the flash memory to look for an executable. It finds uBoot at position 0x00 and hands over control to that. uBoot then does some housekeeping and decides where to jump next.

In the case of this device, if the reset button is kept pressed while powering on, uBoot will jump to 0x50000 (mtd4), otherwise it will jump to 0x21000 (mtd5).

Conclusion: wifi led (blue), power led (blue), charge led (yellow) seem to be hardwired, Red led is bit 9+1 of GPIO; reset is pin 10+1
There's also a low battery indicator that I was not able to read or write to.

Getting dirty - OpenWRT configuration

The first step is to retrieve the repository, set up all the tools and dependencies. I will not go into those details as they are a moving target.

We already know from the teardown that the CPU is Ralink RT5350F. Luckily, OpenWRT already provides this platform for us under the name rt305x.

Add the following entry into /target/linux/ramips/base-files/lib/ramips.sh :

+*"i.onik Wi-Fi Cloud Hub")+name="ionik-cloud-hub"+;;

Then this under /target/linux/ramips/base-files/lib/upgrade/platform.sh, under the ip2202 entry :

+ionik-cloud-hub|\

Not sure how correct is that. I think this file controls how the original (factory) firmware does checksumming in order to get your "trojan" firmware accepted as an upgrade.

Then this under /target/linux/ramips/image/rt305x.mk :+Image/Build/Profile/IONIKCLOUDHUB=$(call BuildFirmware/Default8M/$(1),$(1),ionik-cloud-hub,IONIKCLOUDHUB,Linux Kernel Image)

I found out that - after a test build - my custom firmware only recognized 32M of RAM instead of the 64M that are available. So modify the CONFIG_CMDLINE parameter inside target/linux/ramips/rt305x/config-4.4 b/target/linux/ramips/rt305x/config-4.4 :+CONFIG_CMDLINE="rootfstype=squashfs,jffs2 mem=64M"

Specifying the network interfaces, I probably goofed on this but it still works, add the platform inside target/linux/ramips/base-files/etc/board.d/02_network :@@ -142,6 +142,7 @@ ramips_setup_interfaces()"0:lan" "1:wan" "6@eth0";;b2c|\+ionik-cloud-hub|\nw718|\psr-680w|\sl-r7205|\

I wanted to flash the red LED when booting but it did not work. target/linux/ramips/base-files/etc/diag.sh :@@ -138,6 +138,7 @@ get_status_led() {status_led="$board:blue:status";;miwifi-mini|\+ionik-cloud-hub|\zte-q7)status_led="$board:red:status";;

I also want the wireless to be up after booting since the 'router' lacks an ethernet port. This could be done in a better way, with a default password or one based on MAC. So from package/kernel/mac80211/files/lib/wifi/mac80211.sh you need to comment out the line that says 'option disabled 1'.

This is the most important part. It specifies the flash configuration, for example it tells that uBoot resides between addresses 0x0 and 0x30000. I don't know if this is correct, but it works for me. The important bit is the "firmware" partition at the end. Everything else was mostly guesswork and might be wrong. But it works.

I have no idea what anything above does. But every other device seems to have them, so I added them in. EHCI and OHCI refer to USB ports, as far as I can tell.

Building the custom firmware

After making sure all the files above are modified/added, you just need to type "make menuconfig".
Then go wild adding options to your ROM. You will quickly run out of flash space.

An option marked as 'm' means module. The option is compiled but not included inside the image. Rather, you can add it later to your device, temporarily, via a USB stick or similar. It might trigger (on) some other features which will eat precious Flash space. So just add only what you need, check the size of the image, repeat.

To build run "make -j4". This builds the firmware using 4 threads. If anything fails, you will have to build single-threaded and with verbose mode one. Refer to the documentation.

The system is goingRestarting system.ps-rt305x-ionik-cloud-hub-squashfs-sysupgrade.bin to mtd5 ... [w]

I don't remember the details right now, the above might be reversed, but you can play around if you have a backup. Make sure you are writing to the correct partition and do not touch uBoot and minisystem.

If you mess up, you will have to use an SPI flasher to restore the flash contents. There are various tools and tutorials online, you could probably use a Raspberry PI or Arduino for this, but you would still have to solder the tiny wires or buy a SOIC-8 clip.

After the first OpenWRT image is flashed from the command line, and it works, subsequent images can be uploaded from the web interface.

Sunday, February 12, 2017

Living close to a densely populated area means that it's hard to do consistent testing without spending a lot of fuel, which is also expensive.

Nevertheless, I took the pen&paper approach and started working my way from the basics.

I studied all the Bosch sensors from this page, used a bit of common sense and figured out that my sensor is a Bosch 0281002691, or similar, with a 180 MPa (26000 psi) nominal rating. This might be wrong but It's a good place to start.

I've already used Torque and my multimeter to get some data and it seems to fit with the sensor I've chosen. It might be wrong, but so far it clicks into place.

Using the data I've gathered I've created a simple JS page that shows some logs and tries to simulate what my module (and sensor) does: https://jsbin.com/goyavabuju/edit?html,output
(Note that this is the HTML/JS result after I did the interpolation.)

So the basic function is: the ECU commands the pump, this delivers a pressure, my module receives the sensor data (voltage), offsets it, outputs a new voltage to the ECU, the ECU processes it. I missed a step the last time: the ECU will receive the adjusted pressure, output a new pressure, the pump delivers, a new pressure is measured. This can cause oscillations within the engine, as the tuning module attempts to adjust for the new value.

I am no specialist on this stuff but I've managed to keep my unit running after it was used in an office environment (>50000 coffees). So for me it's mostly guesswork and some logic, but I'll display this so that you can help figure out the problem with your own unit. I'll try to make this accessible to non-technical people, let me know if some idioms are too advanced.

I will try to update this guide with usual questions, but this is not a replacement for professional servicing.

Before troubleshooting make sure that the unit is cleaned and descaled and has enough water. Use the manual for this, each unit is different. Also, try turn the unit off and on, perhaps leaving it 1h undisturbed. This works around some of the bugs in software (firmware).

Learn the sounds of the machine and try to understand what it does in its normal state. There are several motors and they are easy to identify by sound.