Werner Almesberger | 31 Oct 03:09 2014

KLtab: becoming a programmer

To eliminate the risk of there being an unexplained and unobservable
interaction between the reluctant board and the Ben (acting as
programmer), I also tried to replace the Ben with something else.

Since I had a bunch of bored KLtabs at my hands, the choice of that
"something else" was easy. Also, the programming/testing fixture for
Anelok will be able to program the boards it is working on, so I'll
need to have my own programmer solution by then anyway. Just didn't
expect to have to implement it so soon ...

Anyway, I cleaned up swdlib such that it can run on a KL2x and added
a simple USB-based interface. A few things don't work reliably yet
and signal integrity seems to be quite horrible, but it's getting

This is what a KLtab programming another KLtab looks like:

swdlib is still in the Anelok repo (will move out some day):

The KLtab firmware is here:

And the rather primitive user-space tool is here:

I may eventually convert all this to be DFU-based, but the
proprietary protocol is more convenient for now.

(Continue reading)

Werner Almesberger | 31 Oct 02:56 2014

Anelok: results of mixed goodness

I tortured the KLtab boards in many ways, but could never get them
to behave like the chip on the non-programmable Anelok board #2.

There is one thing that I didn't try yet, and that's completely
locking down one of the chips on the KLtab boards. The reason is of
course that this would make the board unusable - unless I implement
some clever backdoor.

But in any case, if the chip was protected that way, then it wouldn't
indicate that it can be mass-erased, would it ?

Well, I don't know for sure yet, but I noticed something else: a
while ago, I had broken the build process of the boot loader in a
way that would put incorrect data at the location of the
all-important Flash security byte (FSEC).

I reconstructed the likely version of the boot loader I had at that
time, and found that FSEC was probably set to 0xed. This decodes to:

11 = backdoor disabled
10 = mass erase disabled
11 = Freescale access granted
01 = MCU security status is secure

The backdoor is a mechanism that needs firmware support, so that
wouldn't work with this broken boot loader, even if I had implemented
such support (which I haven't). All other settings are such that I
can't get in :-(

This still doesn't explain why the chip happily announces that it
(Continue reading)

Werner Almesberger | 1 Oct 04:24 2014

KLtab: first two boards

Since KLtab is only 22 x 22 mm, one can fit four of them easily on a
5 x 5 cm piece of PCB. Here's an example with two of the four KLtabs
assembled in the minimal configuration:


In the unpopulated circuits in the back one can see holes in the center
pads. They were a misguided attempt of mine to properly solder that pad.
Unfortunately, the holes are a bit too small to get anything useful
done with them.  

I added a straightforward SWD-to-UBB pin assignment to the KLtab
schematics (lower right corner):


And this is what the corresponding cable looks like:


Apart from the center pad hole mishap, the KLtabs were as easy to make
as expected, and they both identify nicely over SWD:


- Werner

Werner Almesberger | 30 Sep 07:09 2014

KLtab - Kinetis L series Throw-Away Board

To experiment with the permission bits of the KL2x MCUs, I designed a
very simple and very cheap board. Since it's quite likely that some of
these experiments will end with locking up the chip for good, it's
important that these boards be as un-fancy as possible.

Here are the schematics:

And the layout:

The board is single-sided, but I had to cheat a little and cross
conflicting traces with two 0 Ohm resistors (R5 and R8).

The only things that are required are the MCU, all the capacitors but
C1, and a connection to some programmer on CON5. The following features
are optional:

- two LEDs going to GND (to they're lit when the CPU drives them high),
  connected to high-drive pads,
- two LEDs going to 3.3 V (to they're lit when the CPU drives them
  low), also connected to high-drive pads,
- a Micro USB AB (or B) connector with series resistors, to play with
  USB if SWD gets too boring.

Note that there's no crystal, so USB will have to content itself with
the internal RC oscillator. This should be good enough for device mode,
but may not quite cut it for host mode.

- Werner
(Continue reading)

Werner Almesberger | 30 Sep 06:45 2014

Anelok: update

This has been a very quiet month, so here's a quick update on what's
happening with Anelok: I started to assemble a second board. My plan
is to keep #1 as "known to be good" reference and use #2 for "real
life" use and for experimenting with the case.

This is what it looks like in the box:

Most of the components I soldered are under the OLED so all one can
see are the LED and a few passive components.

Unfortunately, I then hit a snag: the MCU doesn't want to be
programmed. It says it has been set to be "secure", which is
apparently something Freescale sometimes do at their fab. Secure
means that one can't debug the core, that one can't read the Flash,
and so on.

However, unless "mass erase" is also disabled, one can still erase
everything on the chip, including that "secure" flag. The chip says
that mass erase is permitted. Alas, it doesn't acknowledge or
execute the mass erase command.

So I spent some time trying to find out what I may be doing wrong,
but so far it seems that I'm doing everything right and that there's
something wrong with the chip.

Since desoldering the 48-QFN chip is a bit risky with the tools I
have, I want to be absolutely certain that the problem is not just
caused by some stupid bug in my program.

(Continue reading)

Apelete Seketeli | 10 Sep 23:34 2014

Re: jz-3.16 branch released - upstream status

Hi Maarten,

First of all, thank you very much for taking the time to give a clear
status; this might prove helpful to pick up some patches and resume
hacking on it.

On Tue, Sep-09-2014 at 03:47:01 PM +0200, Maarten ter Huurne wrote:
> On Tuesday 09 September 2014 00:53:46 Apelete Seketeli wrote:
> > Maarten ter Huurne (14):
> >   fbcon: Add 6x10 font
> I just submitted this upstream.
> >   /dev/mem: Add kernel config option to omit this device
> I submitted this a while ago and got the review comment that /dev/mem should 
> be made into a module. I agree, but I haven't done that work yet.

Very nice, thanks.

> >   mtd: cc_ftl: New FTL driver for media players using China Chip
> >     firmware
> This driver is pretty dirty; it cannot be submitted as-is. It was useful on 
> the Dingoo A320 to interoperate with the native OS partition, but it is not 
> useful on pure Linux devices like the GCW Zero and CI20. So both the 
> motivation and the urgency to clean it up are pretty low, which in practice 
> means it won't happen.
(Continue reading)

Werner Almesberger | 9 Sep 18:56 2014

Anelok: BOM (components only)

By the way, I've added semi-automatic BOM generation, using the tools
recently made for the Neo900 project.

"Shopping list" for things that go on the PCB (excluding the raw PCB
itself, case, connection between the two boards if separated), assuming
an order of 10 part kits (*):


And here are pie charts that show where the money goes:


Disclaimer: the BOM still needs to be manually checked for correctness
and there could be part I didn't associate correctly.

- Werner

Apelete Seketeli | 9 Sep 00:53 2014

jz-3.16 branch released - upstream status

Hello there,

Yet another Qi-kernel release announcement, this time for Linux kernel
3.16 enhanced with Qi all over the place.

Not much happened since jz-3.15, except for a couple of new patches
here and there on MMC and USB front. To put it another way, we still
have quite the same amount of patches out-of-tree.

For those who haven't been following the MIPS scene recently, some of
us witnessed the release of a product from Imagination Technologies
based on a new Ingenic SoC. The guys at ImgTec recently announced the
MIPS Creator CI20 single board computer powered by an Ingenic JZ4780
SoC [1].

Wondering what it has to do with Qi-kernel ? Well, it's not only the
hardware, but also a lot of kernel code that got out in the wild [2].
It seems the code will be heading upstream, in an effort to get
unified kernel support across the JZ47xx range.

I asked about this before [3], but what about taking the time now to
push upstream the few patches we too still have out-of-tree ?

The idea is to ride the JZ47xx upstream wave and contribute to the
unified kernel support effort; we already did a lot of hard hacking as
the patches below show, and we already have good support for JZ4740
and Ben NanoNote in mainline. It would be great to go that extra mile
and get the rest of our code in mainline as much as possible :-).

With the babbling now over, Lars, Maarten, Paul, if you agree with the
(Continue reading)

Werner Almesberger | 8 Sep 01:44 2014

Anelok: happy anniversary !

I just realized that Anelok had its first anniversary yesterday:

This may be a good moment to have a quick look at where we are and
what to do next:

- the 2014 design seems to work well so far, but there's still more
  that needs testing and improving. Specifically,

  - the capacitive slider doesn't perform great yet. That may just
    be a question of finding a good algorithm, or maybe I need to
    change the shape of the sensor a bit.

  - I haven't really tried to run it on battery power yet. So this
    rather important area still need careful examination. In order
    to get meaningful results, I'll first have to implement proper
    power saving - right now, the choice is between either playing
    dead (all that works in that state is the wakeup timer) or
    burning power like there's no tomorrow.

  - I haven't tried to use RF and memory card yet. Basic RF
    operation has been verified in Y-Box and I've tested the memory
    card in the 2013 Anelok design, so both should be low-risk.

  - battery swapping also needs to be tested: there can be up to
    three large silo capacitors to maintain MCU state and time, but
    I need to see a) if can detect loss of power quickly enough to
    reach a low-power mode while there's still some juice left in
    these capacitors, and b) if that amount of juice will be large
    enough to last through the time it takes to pry out the old
(Continue reading)

lkcl . | 27 Aug 12:23 2014

rhombus tech eoma68 jz4775 cpu card

hi all,

i don't know if anyone here has been following the rhombus tech
project but it basically involves a simple upgradeable cpu card
standard where any card is compatible with any base unit it's plugged
into.  several revisions of the first standard (eoma68) later and the
ingenic jz4775 qualifies as an SoC that's suitable.

i've been working with ingenic to get a first prototype eoma68-jz4775
cpu card ready, and i am planning to send the gerbers off to a company
to get some samples made up, in the first week of next month

basically i wanted to let people know that the project is going ahead,
because there may be projects that people are doing where a
self-contained ready-made 5mm x 85mm x 54mm cpu card with an ingenic
JZ4775, 2gb of RAM, a GbE PHY, standard interfaces such as SD/MMC,
SPI, UART, 2 USBs, I2C, 18-pin RGB/TTL and some GPIO including PWM and
two dedicated EINT lines would be useful to have as a way to greatly
simplify project development.

so if anyone would like to take a risk to get some early first
revision samples (with no guarantees or even any software installed),
or if you would like to wait till later for a 2nd revision, please do
say so.


Werner Almesberger | 20 Aug 16:45 2014

Anelok: the encasing

I made a first rough prototype of the case. It's a simplified variant
that has only two shells (the final version will have a separate cover
for the battery compartment) and lacks a few details.

This is what the parts look like:


We also need something to put inside. I didn't want to risk breaking
the one working board I have now, so I took an unpopulated PCB and
separated main board from sub-board:


The first thing that goes into the case is the OLED. Here I picked an
old defective one that's idead for mechanical experiments. It is held
in place by the structures in the top shell:


Next, the two boards go in. Note that they're at different heights:


In real life, they would be connected by a little cable. But I'm not
that far yet. Also, the OLED's FPC would be soldered to the PCB, so all
the parts go in at the same time.

This is what the closed case with some content looks like:

(Continue reading)