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)

Werner Almesberger | 19 Aug 03:42 2014

Anelok: user interface simulator

To make user interface development a bit faster, I've written a simulator
that provides "touch" input (from the X pointer) and displays the result
in an SDL window.

To run it, do this (main prerequisites: SDL, SDL_gfx):

git clone git://gitorious.org/anelok/anelok.git
cd anelok/sim

Now a little (128 x 64 pixels) black window should appear. Left-clicking
corresponds to a press on the touch slider. A small bar on the right edge
of the window indicates the current position. The X position of the mouse
doesn't matter.

To "switch on" the device, place the mouse roughly in the middle and
press the left button. After a brief pause the text "ANELOK" will appear.
Now release the mouse button. A trinary login screen will appear.

To log in, draw a "V" by clicking briefly on the top, the middle, the
bottom, the middle, and the top again. The screen should now look like


Now click on the bottom. Hold until the "enter" symbol highlights, then
release the mouse button. You now get an ugly list of accounts.

That's all the demo does so far. You can return to the beginning with the
(Continue reading)

Werner Almesberger | 18 Aug 09:50 2014

Anelok: board coming along

The new prototype is coming along nicely. I've now placed most of
the components. Besides rfkill acting as system-kill, the design
seems to be free from embarrassing mistakes so far.

Top view, without OLED:

Top view, with OLED:

Bottom view:

Cheat mode alert: the memory card holder isn't soldered. There are
a number of traces that pass underneath it and I'm a bit concerned
that it may short them. If that happens, fixing it would be somewhat
messy. So I'll keep that experiment for later.

The ugly mess of colored wires should of course disappear.

Side view:

Note that the two boards (main and battery) will not be at the same
height, so there won't be the sort of huge empty space this picture

You may wonder why it's taking me so long to put together the board
this time. After all, this is something that should take a day or
two, not weeks. The reason is that I'm also measuring the system's
(Continue reading)