These days I've noticed some similar projects which are appeared AFTER this project.

For example: https://oshwhub.com/dr.zhang/Nokia1110-ESP32

I have nothing to do with these projects. Thank you.

Always imitated, never surpassed.

Time to make a conclusion of this project.

Now

As of 2022-10-22, here's the summary of the V2.0 hardware:

Working:

• LCD screen
• Keypad
• WiFi
• RGB LED
• RTC
• USB OTG
  • Both Device & Host mode works
• Power management
  • Battery gauging
  • Battery charging and OTG 5V boost
• Audio
  • Only playback is tested. Both loudspeaker and earpiece work

Partially working:

• Bluetooth
  • Needs a jumper wire to connect 32kHz clock source to the AP6214
• Suspend-to-RAM and wakeup
  • The old X1000 SoM doesn't have a 32k crystal, so it uses a lot more power
• LoRa
  • The SX126x SiP module works, but the 433MHz antenna barely works

Not working:

• GPS
  • Subject to removal

Future

Name change

The earlier name poll has a 4-way tie. So Idk.

However, a staff from Hackaday showed their support of this project. So I'm not sure if the name still needs to be changed.

Opinions are welcomed.

New hardware reversions

The V3.0 hardware is still being designed. TBH I don't have a lot of time recently.

Nevertheless, all the design files will be uploaded to GitHub soon and you can hack it by yourself.

Original date: 2022-10-09

Related tweets: [1] [2] [3] [4] [5] [6] [7] [8]

Dismissing the "new arch"

Since the suspend-to-RAM works perfectly on the latest X1000 SoM, there are no strong reasons to keep a separate "EC" MCU anymore. But unfortunately I already bought 25 pcs of the PIC24 MCU, and they're EXPENSIVE. :(

So I decided to let the X1000 do everything as before. But it's not easy because of the missing/broken Linux drivers...

The EVB

Despite I said that I'm "too lazy to draw a EVB" (lol), a proper EVB is still needed to verify its functionalities. So I drew one.

Bitter fighting with Linux drivers

Peripheral drivers

I spent a week to get the Ethernet and I2S audio working.

The DMA problem

Early struggles

If you read my tweets carefully in the last season, you can see I'm occasionally concerned by the "DMA problems" of the mainline kernel. And it's a very long story. Basically, it always give me a feeling that the DMA on the X1000 (and X1501) never worked correctly with the mainline kernel. This includes the standalone DMA controller (PDMA) and busmastering DMAs of certain peripherals.

I first noticed this problem in 2022-06. The symptom is very confusing: if you use SLAB/SLUB for the Linux mm implementation, everything seems to be working, but if you use SLOB, visible kernel oops and panics will appear as soon as something started a DMA transfer. As someone who only had the experience of debugging driver problems on x86 processors at that moment, I don't have a single clue about what happened. The SLOB allocator has bugs? Unlikely. The DRAM KGD is broken? No, everything is fine with Ingenic's old 4.4 kernel. Then there must be the problem of the DMA implementation itself.

We started by enabling a few memory debugging options of the kernel that scans its data structures constantly for corruption, and only enable the DMA of one peripheral at a time. But the results were inconclusive. The memory corruption sometimes happens, sometimes don't. I originally suspected that it's the "INCRxx" setting of the AHB bus of these busmastering peripherals that caused these problems, but setting to a lower value only let the data corruptions happen less, and they're not entirely eliminated.

What else can I suspect? The only remaining thing would be the cache management code of the Linux kernel. I started reading the code in Ingenic's old 4.4 kernel, and yeah! It must be the problem! So I asked in the linux-mips mailing list:

In the past month, I was struggling with random memory corruptions and crashes on the Ingenic X1000. After some detailed testing, I need to point out, the current cache management routines seems to be incorrect for X1000, and maybe all X series SoCs. It mainly affects DMA operations. Every form of peripheral to RAM transfer will corrupt the RAM, and this includes the dwc2 and SFC's DMA and the PDMA controller. If all the DMAs are disabled (e.g. hard coding dma_capable = false in dwc2), it will be fine running CPU and I/O benchmarks for a week. If you have the hardware, you can enable the kernel data structures & memory debugging and see for yourself.

So I went back and looked at Ingenic's old 4.4 and 3.10 kernel sources. They used a separate file (sc-xburst.c) for the cache routines, which is based on an very old sc-mips.c. And there are two important macros, called MIPS_CACHE_SYNC_WAR and MIPS_BRIDGE_SYNC_WAR. They're both set to 1. However these macros are removed from the kernel long time ago. The line `mips_sc_ops.bc_wback_inv = mips_bridge_sync_war;' seems to be the key point.
Do you have any recommendations of what could be done to fix this problem?

And sadly, no one seems to be interested in this topic. I'm on my own. But I don't have the expertise. This incident also severely prevented the launch of another project of mine, the X1501 Pico SoM. I had no choice but to suspect the SLOB allocator really has problems.

Time flies

It's finally October (2022-10). And the DMA problem is still a mystery. I started to get desperate. Change to another SoC? It's already too late, and AFAIK nothing else can achieve such a low power consumption. I started to get more and more desperate.

I started reading everything in `arch/mips` desperately. I'm not going to share what I did in these days since this article is already too long, but I was really not in a good shape, believe me. Eventually, I found a way to disable the L2 cache. All DMA problems appear to be disappeared. I can run I/O benchmarks for 24 hours without problems. All? Yes, not all. But now only these non-busmastering peripherals still have occasional problems. So I started to read the driver code of the standalone DMA controller (PDMA), that is, `drivers/dma/dma-jz4780.c`. It took me half an hour to found a NULL pointer dereference bug in the code by my bare eyes and kernel crash logs. And I fixed it.

Finally

Just at the time that I thought I fixed everything and I can finally celebrate. Another problem happened. Playing audio in the 44100Hz sample rate will stall everything that is using the PDMA. Bruh... I really don't know what to say about it. It just sucks.

I went 10x more desperate. And after a random nap in a random day, I decided to port the DMA driver in the old 4.4 kernel to mainline. The code is spaghetti, but TL;DR it finally works! Everything finally works! I tried more than 10 different ways to trigger the bugs, but they're finally gone!

Still, I'm speechless and I don't know how to make a conclusion of this incident.

Original date: 2022-09-07

Related tweets: [1] [2] [3] [4] [5] [6]

TL;DR it's awesome! I'm so happy!

So I received the new X1000 SoM from JLCPCB. Surprisingly, the quality is good enough. They got everything right, including the 0201 passive components, 1612 crystals, XDFN-4 LDOs, and the 0.8mm BGA X1000. Nice.

And then, I can't wait to test if it works, so I used the jumper wires exactly like last time (lol). Smoke test passed, USB bootloader recognized, and firmware flashing works. Good. So then I built a new kernel image with the RTC clock workaround code removed. And... and !! The suspend-to-RAM FINALLY WORKS!!!! I used a USB multimeter to measure the power consumption, and it's ONLY 0.003W!!!! This means the X1000 itself can standby for more than a month on a 1000mAh Li-ion battery!!

Did you ever noticed that I actually soldered all SPI flashes upside down? It's embarrassing bruh ,-,

Original date: 2022-08-29

Related tweets: [1] [2] [3]

I finished designing the new X1000 SoM, and the main changes were:

• Added 32k crystal for proper shutdown of the main clock domain
  
  • Let's hope the suspend-to-RAM will work properly this time!
• Changed to a modern 2.2MHz buck DC-DC w/ PFM mode
  
  • It's supposed to use a lot less power when in idle
• Form factor changed from castellated holes to LGA pads
  • Better mass production quality and the ability to V-CUT
  • Contributes to the mechanical strength of the underlying PCB better when soldered
• Added clearance space for installing a metal cover
  • Provides a chance to improve EMI performance & mechanical strength even more

It was submitted to the PCB factory in the same day.

It's also worth noticing that this new SoM was not exclusively designed for this project. Now it can be used for other purposes, and even in harsh conditions like industry control (will industry control system designers ever choose a SoM with cute drawings on it? lol). All components on it are qualified for operating in -40 to 85 degrees. I also ensured that every wire has a near continuous ground plane this time.

Original date: 2022-08-26

Related tweets: [4] [3] [2] [1]

I received the RF test PCB and soldered it. TL;DR It's not so good.

I tried different placements and a few known pi matching networks (different values of inductors, caps, etc) for the new SMD 433MHz antenna. It's definitely better than the last reversion: the received RSSI is ~10dBm better in average, but no matter how I try, it's still ~15dBm worse than a common dipole antenna. But fortunately, its performance almost didn't change after I did the assembly simulation by putting it into a real shell, with the LCD screen and the BL-5C battery installed.

The good news is, the 2.4GHz antenna is a great success. At least it outperformed the 2.4GHz antenna inside my smartphone. There's a thick wall built by cement + reinforcing steel between my room and the server room (which contains the WiFi AP, 20dBm TX power), and it has -45dBm RSSI. Bravo!

I still feel disappointed. Or I shouldn't be too strict for such a "hobbyist project"?

Another comforting news is, the manufacturer of the SMD 433MHz antenna offers free impedance matching service. But they said I need to give them the final reversion of the fully assembled device (i.e. not a bare PCB) because everything on/near the PCB affects the impedance. So this has to wait...

Original date: 2022-08-19

Related tweets: [1] [2]

The RF test PCB was submitted to the PCB factory. In the meantime, I was trying to redesign the architecture to mitigate the problems of the current design:

• Power consumption is not low enough
  • It can't even reach the standby time of the original Nokia 168x now
• Physical difficulties
  • Frequent kernel/rootfs changes are needed in the development stage. But currently it's really inconvenient to push the RESET button (which is behind the battery) and the BOOT0 button (which is the left func key of the keypad) at the same time.
  • The only UART connection is the 3 tiny little pads on the PCB. It would be hugely better if the serial console can be controlled via a built-in USB to UART.
• Multiple missing Linux drivers
  • Many drivers isn't working properly

So, the idea is to use a ultra low power MCU to act as the "EC" of this device. It's exactly the same definition of the "EC" in your PC or laptop. The MCU is supposed to do these things:

• Extended power management
  • Controls the power supply of individual components on the board
• Handle all LoRa communications
  • Power to the X1000 can be shut off entirely in standby mode
• Keypad polling
  • Spares a PCA9555
• Act as a USB to UART bridge
  • Life is a lot easier!
• Control the RESET and BOOTx lines of the X1000
  • Boot device selection can be achieved using a USB CDC console then

Original date: 2022-08-17

Related tweets: [0] [1] [2]

In the previous logs and tweets, I said that I'm going to remove the 433MHz LoRa support. But who truly wants to do that?

Since the 433MHz LoRa antenna was a complete failure, I designed a dedicated RF test PCB in exactly the same shape to test different antennas and the impedance match parameters & possible placements of them.

This PCB contains antenna slots of both 433MHz and 2.4GHz, a simple PIC32MM MCU, and the SiP LoRa module. Future tests will be conducted by a proprietary software designed by me on the PC.

Bad news: Nokia Corporation said the name "Notkia" is an infringement of their rights.

See this tweet for more information. Spread the word if you feel you want to.

WE WILL CHANGE THE NAME. New name suggestions are welcomed.

Read the complete update if you're a patient human being.

Progress Overview

• Hardware
  • Most essential components are verified working
  • There are some difficulties with RF sections
  • The v3.0 PCB is being designed
  • Introduced the idea of “accessories”
• Software
  • Minor tweaks of the Linux kernel configuration
  • Investigation of the suspend-to-RAM process is started
• Fundraising
  • This project is accepted by Crowd Supply
  • We’re negotiating with them

PCB version 3.0 ChangeLog

• Removed: GNSS section
  • a quad protocol GNSS receiver BLE accessory will be available
• Removed: LoRa spring antenna
  • will revert to Nokia 168x’s original antenna with quad GSM bands
  • a LoRa transceiver accessory with external antenna will be available
• Removed: internal 5MP AF camera
  • an 13MP AF camera USB-C accessory will be available
• Added: built-in UART to Bluetooth for easier hacking
• Change: SPI NOR changed to W25Q512
• Bugfix: add power sequencing MOSFET to meet SD NAND’s VDD rise time requirement
• Bugfix: AP6214 Bluetooth needs 32.768kHz clock to work
• Bugfix: AP6214’s VBAT should be connected to VSYS, not 3V3, for better power efficiency
• Bugfix: More capacitance on 3V3 rail to prevent LCD backlight knocking out the BQ25895 without battery