Upgrading the Olimex A20 LIME2 to 2GB RAM, by learning to BGA solder and deep diving into the U-Boot bootloader process

As I’ve written about previously I have had the Olimex A20-OLinuXino-LIME2 in service for quite some time. But one thing that I’ve been curious about is why it’s only available with 1GB of RAM, when the A20 chip itself can support up to 2GB? Could it be upgraded to 2GB RAM by a simple swap in of a larger memory module?

If you check the schematic the address lines are actually wired up: both A14 and A15 which are labelled NC (no-connect) on the chips are wired up on the address bus, meaning a full 2¹⁶ row addresses should be addressable. So this might actually work out!

Detour: How do CPUs access memory?

From a very high level the way a CPU accesses memory is the same all the way from a small microprocessor like the RP2040 up to a x86. There are a number of pins connecting the CPU and the RAM:

• A number of address lines, e.g. A0–A15 in our case. These are always driven by the CPU.
• A number of data lines, e.g. DQ0–DQ15. These are bi-directional and driven by the CPU for writes, but by the RAM for reads.
• A couple of signalling lines to control the communication, e.g. the shared clock, or the CPU signaling that the address lines are set with the address for a read, or the RAM signaling that the data lines are populated with the data read out. These can be quite complicated, as seen with DDR3 in this instance, where signalling talks about “banks”, “lower/upper byte data strobe”, “data masks” and “chip select”.

The most crude form of using more than one RAM chip would be to use “chip select” as known from SPI or I2C communication. This is however not how it’s done on the LIME2: address, data and chip select lines are wired in parallel for the two chips. The only difference in wiring is on the “DMU”, “DML”, and “DQSU” and “DQSL” lines: these are used for lower and upper byte data strobes, meaning that the same address is setup for both chips, and then the chips are strobed one at a time – effectively allowing each chip to prepare the read in parallel.

Finding compatible chips with 256Mx16

Luckily DDR chips are standardized, but it seems that the standardisation does not quite go all the way to the datasheets, in e.g. pin naming and concepts. But at least the density and organization are standardised: the 256M is the number of different addressable storage locations, and the x16 is how many bits are stored per location. Multiplying those gives the number of megabits stored, 4096 megabits in this case, so dividing by 8 gives the number of megabytes stored: 512MiB.

Looking at the pinout for the specified chip (K4B4G1646D-BYK0, a Samsung chip):

We can see it specifies only address lines A0–A14, which is enough for a 256M module. But the LIME2 schematic was helpful enough to hookup A15 to the JEDEC standard location, even if that pin is NC on all memory modules shipped. This might actually work!

The last crucial parameter for selecting bigger RAM chips is the supply voltage. DDR3 comes in both standard and low-voltage (DDR3L) variants. The LIME2 schematic actually just specifies that “When DDR3L is used, VDD&VDDQ are set to 1.35V!!!“, so to know which it is we would have to look at the particular board and measure the power supply line. But luckily, almost all DDR3L chips are backwards compatible to the 1.5V DDR3 level, so as long as we can find a DDR3L chip voltage shouldn’t be an issue.

So in theory any 512Mx16 DDR3L chip should work. In practice I ended up trying two variants:

• Micron MT41K512M16, which seems to be the only option on AliExpress, and cheap, but which (spoiler alert!) I did not get working
• ISSI IS46TR16512BL, which I did get working, but is more expensive to the point that the two needed RAM chips cost more than the LIME2 itself.

Learning to BGA solder

Finally, we can jump to the microscope soldering station, and learn to BGA solder. This was by far the longest part of this project. The chips come pre-balled, so in theory the job could have been as simple as desoldering the old chips and soldering on the new ones. Not so easy in practice. I ended up having to re-ball and re-solder chips, apply flux, solder-wick and ethanol in copious amount, re-attach SMD resistors that had taken a stroll under the heatgun, and battling a self-compiled U-Boot that I probably messed up badly. You get to see my frustration in a few nice pictures.

I have a suspicion that I messed up U-Boot at one point, by trying to compile it with automatic impedance calibration, instead of leaving the LIME2 defaults DDR settings in. This might be the reason I couldn’t get the Micron MT41K512M16 chips to work, but I will have to investigate this more. I probably also messed up the first soldering on of a chip, by not using enough heat. My main piece of advice would be to not be too afraid to get the temperature of the chip up, if you spend more than about a minute trying to solder or desolder the chip, chances are you will be heating up the rest of the board much more than needed and the chip itself too little!

The moment of seeing the board booting with 1GB from a single ISSI IS46TR16512BL was a great success though — soldering on the other ISSI chip was basically a walk in the park.

Further U-Boot adventures of a curious character

A serial terminal is absolutely essential for getting any kind of feedback on the early part of the boot process, and the first user-controlled software encountered on the LIME2 is U-Boot. U-Boot is the universal bootloader responsible for figuring out the basic hardware configuration (including RAM configuration), finding the (Linux) kernel and moving it into RAM and giving over control to the kernel for further booting. Curiously, U-Boot can run with absolutely no RAM chips (guess how I know!), because the SunXi early boot process happens entirely in on-chip ROM and a small on-chip SRAM.

But how does U-Boot actually determine how much memory is there? Well, remember that accessing a memory location is just putting an address on the address lines and pulling some signalling pins. So U-Boot simply tries and write to increasing addresses and see if the expected data can be read back. How is the memory size then communicated to the Linux kernel? By a bootarg parameter, e.g. mem=2048M. Does this mean we can try and trick the Linux kernel into thinking it has more memory than physically present? Yes, but with disastrous results if the non-existent memory is ever attempted to be used.

I now possess a unique 2GB LIME2

Until told otherwise, I will happily claim that this is the only 2GB LIME2 in existence — but do let me know if you give the procedure a try! In the end the process was much simpler than I thought: the tricky part was definitely getting the hang of BGA soldering. Don’t be afraid of raising the temperature! Peeking into the innards of U-Boot was also fascinating: there is definitely a layer below of pretty dark bit-setting magic, but the overall process is really well structured!

Making a too cheap LED lamp safe to use

This could happen to you: A really cool LED lamp was found online, on a Danish and well-written homepage. Unfortunately, when the lamp arrives it is a cheap Chinese production, of questionable quality and safety. This is a non-rational quest to make such a cheap LED lamp safe to use.

From the outset the wires are tiny. The wires are connected with wire nuts *gasp*! (Wire nuts are basically unheard of in Europe). The LED driver itself that converts the 230V AC into DC has absolutely no separation, and as we will see later, absolutely no safety features. It did have a cool feature of changing light color temperature by turning the lamp on and off a couple of times, though.

But happily going to 300mA when shorted, going up to 118V unloaded, and full willingness to spark away, is a deal-breaker. This abomination was not being powered on in this house! It should be possible to replace the unsafe parts with safer (and more expensive) parts.

The first step was understanding the mess of wires. This took quite some pondering to figure out that all the LEDs were basically in series, and that it was wired with a “common positive”, with either the white or the black wire (or both) acting as ground depending on the wanted color temperature.

In the end the entire schematic was reverse engineered.

That LED driver was going nowhere but the electronic garbage bin, so a replacement of decent quality had to be acquired: a constant-current LED driver (configurable from 200mA–350mA) was purchased from a reputable source. That gave the next problem: an LED driver of quality was at least double the size of the unsafe one, and did not fit in the original round enclosure. 3D-printing to the rescue, and a new bigger round enclosure was printed.

Now everything should be able to fit and work! Instead of that illogical wiring of putting the LEDs in series, why not just put the two parts in parallel? Well, that won’t work. Only the path of least-resistance would light up, in this case the dome LEDs. So, back to the original wiring in series.

Unfortunately, the next problem was that the new LED driver was unwilling to drive LEDs as originally wired, that seemed to require somewhere above 45V, out of spec for the new driver. More stuff had to change. Looking at the schematic, the long strip in the circle could be cut in half, and the two half put in parallel instead. This should reduce the power going to those LEDs, and thus also the light output, but should also help to decrease the required voltage. But first I had to learn again the hard way that putting LEDs in parallel they need to match quite closely: the original LED strip had 11 segments, and dividing into 6 and 5 gave lights only in the one part.

Reducing to 5 and 5 segments worked really well!

Finally, the total voltage of putting the two parts of the lamp in series was below what the new LED driver would supply.

The only task remaining was to fit everything back into the enclosure, and add copious amounts of Kapton tape and hot glue. And finally, the spaceman could go star-fishing – safely.

Fantus-button part 2: the physical button build and the network communication

First part of this series is here, covering the reverse engineering of the DRTV Chromecast App.

I wanted the physical appearance to be extremely minimalistic, with slight references to various cubes from videogames. Because it is a remote control, it of course has to be wireless and battery-powered.

The box is lasercut from 6 mm MDF, and with a giant red arcade button on top with a red LED inside.

The electronics inside is a battery-powered Wemos D1, along with 4 x 18650 Lithium battery cells. After some experimentation on the response time, which is primarily dominated by the time it takes to reconnect to the WiFi network, I initially only used “light sleep”. This resulted in a battery time of just over a week, which is okay, but not great.

In order to preserve battery deep sleep would be really nice. The problem is deep sleep on the Wemos can only be interrupted by a reset. The idea was to use a MOSFET (in this case an N-channel logic level mosfet, IRFZ44N) for the Wemos to be able to select whether a press of the button should reset it, or it should just register on a pin as normal.

This circuit allows RST to be pulled low by the button, as long as D0 is high. Luckily, D0 is high during deep sleep, so as long as the Arduino code keeps D0 low button presses will not reset — but can still be registered by reading pin D1.

This works out “responsively enough” because the initial start has some delay due to the Chromecast initializing the app and loading media. Any subsequent button presses within the 30 seconds the Arduino stays awake are instant though. With this setup the battery life is not a problem – I’ve only had to charge it once. As a bonus feature/bug whenever the battery gets low the Wemos will trigger a bit sporadically: this causes “Fantus-bombing” where Fantus will just randomly start; quite quickly thereafter the Fantus-button is being charged 😉

The Wemos itself is not powerful enough to do all the pyChromecast communication needed, so I setup a small Raspberry Pi to handle that part. Since I didn’t want to spend too much time and effort setting up the communication between them, I ended up using a trick from my youth: UDP broadcasting. Because UDP is datagram-oriented you can send a UDP packet to the broadcast address (255.255.255.255) and then it will be received by all hosts on the local area network: no configuration needed. In Arduino code it looks like:

  Udp.begin(31337);
  Udp.beginPacket("255.255.255.255", 31337);
  Udp.write("emergency-button\n");
  Udp.endPacket();

(Full Arduino code available here.)

At this point I had a UDP packet that I could receive on the Raspberry Pi, and it was just a matter of writing a small server program to listen, receive and process those UDP commands. However, at this point a thought entered my mind, that derailed the project for a while:

netcat | bash

Why write my own server to parse and execute commands, when Bash is already fully capable of doing exactly that with more flexibility than I could ever dream of? And netcat is perfectly capable of receiving UDP packets? This is a UNIX system, after all, and UNIX is all about combining simple commands in pipelines — each doing one thing well.

The diabolical simplicity of just executing commands directly from the network was a bit too insecure though. This is where Bash Restricted mode enters the project: I wouldn’t rely on it for high security (since it is trying to “enumerate badness“), but by locking down the PATH of commands that are allowed to execute it should be relatively safe from most of the common bypass techniques:

netcat -u -k -l 31337 | PATH=./handlers/ /bin/bash -r

The project was now fully working: press the button, Fantus starts. Press it while Fantus is playing: Fantus pauses. Press it while Fantus is paused: Fantus resumes. The little human was delighted about his new powers over the world, and pressed the button to his hearts content (and his parents slight annoyance at times).

(Full code for handler available here.)

But wouldn’t it be cool if the little human had a (limited) choice in what to view?…

Fantus-button part 1: Reverse engineering the DRTV Chromecast App

I want to build a physical giant red button, that when pressed instantly starts a children’s TV-show, in my case Fantus on DRTV using a Chromecast.

The first part of the build is figuring out how to remotely start a specific video on a Chromecast. Initially I thought this would be pretty simple to do from an Arduino, because back in the day you could start a video just using a HTTP request. Very much not so anymore: the Chromecast protocol has evolved into some monster using JSON inside Protobuf over TLS/TCP, with multicast DNS for discovery. Chance of getting that working on a microcontroller is near-zero.

But remote control is possible using e.g. pychromecast which has support for not only the usual app of YouTube, but also a couple of custom ones like BBC. Let’s try and add support for DRTV to pychromecast, starting at the hints given on adding a new app.

Using the netlog-viewer to decode the captured net-export from Chrome, and looking at the unencrypted socket communication, the appId of the DRTV app is easily found.

However, one of the subsequent commands has a lot more customData than I expected, since it should more or less just be the contentId that is needed:

{
  "items": [
    {
      "autoplay": true,
      "customData": {
        "accountToken": {
          "expirationDate": "2022-07-02T00:48:35.391Z",
          "geoLocation": "dk",
          "isCountryVerified": false,
          "isDeviceAbroad": false,
          "isFallbackToken": false,
          "isOptedOut": false,
          "profileId": "c4e0...f3e",
          "refreshable": true,
          "scope": "Catalog",
          "type": "UserAccount",
          "value": "eyJ0eX...Dh8kXg"
        },
        "chainPlayCountdown": 10,
        "profileToken": {
          "expirationDate": "2022-07-02T00:48:35.389Z",
          "geoLocation": "dk",
          "isCountryVerified": false,
          "isDeviceAbroad": false,
          "isFallbackToken": false,
          "isOptedOut": false,
          "profileId": "c4e0a...f3e",
          "refreshable": true,
          "scope": "Catalog",
          "type": "UserProfile",
          "value": "eyJ0eXAi...IkWOU5TA"
        },
        "senderAppVersion": "2.211.33",
        "senderDeviceType": "web_browser",
        "sessionId": "cd84eb44-bce0-495b-ab6a-41ef125b945d",
        "showDebugOverlay": false,
        "userId": ""
      },
      "media": {
        "contentId": "278091",
        "contentType": "video/hls",
        "customData": {
          "accessService": "StandardVideo"
        },
        "streamType": "BUFFERED"
      },
      "preloadTime": 0,
      "startTime": 0
    }
  ],
  "repeatMode": "REPEAT_OFF",
  "requestId": 202,
  "sessionId": "81bdf716-f28a-485b-8dc3-ac4881346f79",
  "startIndex": 0,
  "type": "QUEUE_LOAD"
}

Here I spent a long time trying without any customData, and just using the appId and contentId. Initially it seemed to work!

However, it turned out it only worked if the DRTV Chromecast app was already launched from another device. If launched directly from pychromecast the app would load, show a spinner, and then go back to idle. Here much frustration was spent; I guess the customData is actually needed. And indeed, putting that in works! But where do these tokens come from, and how do we get those tokens from Python?

Using Chrome’s developer tools (F12) on the DRTV page, and then searching globally (CTRL-SHIFT-f) for various terms (“expirationDate”, “customData”, “profileToken”, “accountToken” etc.) revealed some interesting code, that was as semi-readable as any pretty-printed minifyed Javascript. Eventually I found the tokens in local storage:

Using these tokens work really well, and allows starting playback!

Some further exploration proceeded: using the showDebugOverlay flag reveals that the DRTV player is just a rebranded Shaka Player. The autoplay functionality can be disabled by setting chainPlayCountdown to -1, which is honestly a real oversight that it cannot be disabled officially, to not have to rush to stop the playback of the item before the next autoplays.

With all the puzzle pieces ready, I prepared a pull request (still open) to add support for DRTV to pychromecast.

Fantus-button part 2 will follow, detailing the hardware build and network integration with the support from pychromecast.