Monthly Archives: August 2010

CPU review: openMSP430, Plasma, T400 and T48.

The study items are listed on the Open Source CPUs post, especially the category description.

Let’s have a look at OpenCores Certified processor Projects.
OpenRisc1000 is already done.

openMSP430

This is a clone of TI’s MSP430, a 16bit micro-controller. Just by this it’s a tiny micro-controller again…
Also it’s a clone again, there is a port of GCC for the MSP430 family: mspgcc.

Plasma

This on is a Mips-like, that is to say it has most MIPS I instructions except the patented one (the page says the patent expired, so one could probably add them, need to check the legal stuff, remember I’m no legal expert).
Well it work, is still serving a website so great 😉
It does not look like there is any MMU, so it’s an embedded CPU.

T400 µController

An implementation of a legacy cpu again… clone of National’s 4-bit COP400 microcontroller.
The distribution include a GPL V2 text but the header in the vhdl files does not refer to GPL but gives a rather more permissive licence (looks BSDish to me) especially allowing synthesized work to be distributed without the source…
As for the category, it’s a 4bit cpu remember, so a tiny micro-controller.

T48 µController

This is a MCS-48 microcontroller clone. The licence is the same as T400 above (it’s the same author).
A 8bit micro-controller that will continue to flood the tiny micro-controller category.


As usual the summary table is there: Open Cpu Study Summary.

CPU review: LEON 3, ZPU, xilinx MicroBlase and PicoBlase clones, legacy x86 clones.

The study items are listed on the Open Source CPUs post, especially the category description.

LEON 3

This is another well know GPL processor. With great resources and specific model for commercial use. The cpu is a 32bit SPARC V8 with caches, MMU and other high end features, I think it’s configurable enough to fall into my portable CPU category.

ZPU

It uses a BSD license for the HDL and a GPL for documentation, architecture and tools. Interesting choice to allow commercial hardware… Well let’s look into it: The ZPU is a zero operand, or stack based CPU, 32bit datapath, 8bit instruction set. As for the category, it looks like an embedded CPU, however the presentation claims it’s not targeted for running uCLinux, also remembering why Navré (see previous post on the topic) was started, ZPU is probably not powerful enough for this class, so it will be a tiny micro-controller.

AEMB

The AEMB instruction set is taken from Xilinx MicroBlase. The gcc toolchain is the one for the MicroBlase from xilinx, it does not look like it is in mainstream gcc. The AEMB license is GPL v3, it’s in beta state according to it’s page on opencores. It’s a 32bit RISC cpu, apparently able to run uCLinux, so it’s an embedded CPU.

OpenFire

There in an other project page on opencores (with no files) OpenFire.

The project looks stopped…
It’s another clone of the MicroBlase. It uses MIT license, so it’s free.

PacoBlase

To stay in xilinx cloned material. This is a rewritten PicoBlase implementation in modified BSD license. The project looks stopped (no update since may 2007).
It’s an 8bit micro-controller, the project also release an assembler for it KCAsm, It does not looks like there is any gcc available here. So we have yet another tiny micro-controller.

YASEP

Looks like an always in development CPU project. Licensed under GNU Affero General Public License version 3. It has it’s own assembler written in javascript.

I don’t know if this is still relevant but the obsolete page states the following:

If you’re brave enough, you can attempt to create a C compiler for YASEP, but this is a bit sarcastic. If you want to lose time, port GCC. But YASEP’s architecture does not suit C nor GCC well. In fact YASEP is designed to be programmed in assembly language, which is quite simple thanks to a barebone RISC approach. YASEP is a microcontroller, after all.

So gcc will probably never come for this CPU.
I see this project more like an architecture research than a really usable CPU, if you can’t write C at least for generic non over-optimized code, then it’s hard to port any existing software to it without much effort.
It also fall in the tiny micro-controller category.

CPU86

This comes with a GPL 2 license text but all cpu86 design files refer to LGPL 2,1+ in their headers… The CPU86 core is binary/instruction compatible with an iAPX8088 processor.
It’s probably only useful to update the hardware of a legacy system using 8088 CPU where nobody is able/willing to update the code that runs on it.
Well this don’t fit my categories 😉

Zet86

The goal of this project seams to rebuild a PC with open source hardware. It’s licensed under GPL version 3. It’s recent, and only implementing 16bit modes (ie 8088/80186).
This one also don’t really suit well with my categories…


So I’m done with the CPU currently listed on wikipedia’s soft microprocessor page.

As usual the summary table is there: Open Cpu Study Summary.

CPU review: PicoBlaze, LatticeMico32 and ARV clones

The study items are listed on the Open Source CPUs post, especially the category description.

PicoBlase

However wikipedia marked it as open source, it’s not what I call open source hardware! Ok you will have the source code, but you have to register and accept a licence explicitly restrict you to use it only on Xilinx chips to access the download page. Not to count the warning against some possible patented content in each file…
Definitely non-free !

LatticeMico32

I could not find the licence text from the lattice web site. It’s possible to download some LatticeMico32 demo code, but it does not include the license text.

First time I’ve read about LatticeMico32 was in a French GNU/Linux magazine, an article presenting the Milkymist project. So I headed here and there archive contain the licence text from Lattice.
The most important part from our point of view the Appendix C: “Lattice Semiconductor Corporation Open Source License Agreement”.

Note sure about the section 6 ‘export control’, but I guess it’s just repeating something from the US laws (any legal experts reading me?). To me, it looks like a particular case of GPL2 point 7 or 8: the intent is to protect the license not to prevent the use. I mean if it’s illegal, then there is no way a license text will make it become legal !

But overall it looks fairly open to me.

So let’s look at this CPU !

It’s a 32Bits RISC (instruction and data) with no MMU and optional caches. That makes it fit the embedded CPU category.

The lm32 architecture seams to be integrated in binutils and gcc, so no need for extra patch, just build it.

Navré

To stay on the Milkymist project, lets consider Navré. This one was created for Building a free OHCI host controller for USB.

So It’s GPL, it’s very new, it’s very small, it perfectly fits the tiny micro-controller category. Let’s wish it good luck.

On the AVR cloning idea, I don’t know Atmel’s opinion on this… If we end up building Arduino clones using open source AVR clones they might argue, but I think for now at least in term of cost and process, we are far from it. (Is there any opens source flash process to build our chips ?)

While we are at it, let’s look a few other AVR clones.

pAVR

Targeted to be a superset of all AVR at its origin, the project has stopped. It has some bugs open and this has not evolved since 2005.

AVR core

This is a clone of AT mega 103. Unfortunately I could not find any licence in the archive… So it can not be considered open source hardware 🙁

AVRtinyX61core

This is a Atmel AVR ATtiny261/461/861 compatible core. LGPL and not updated since Nov 10th, 2008.

Reduced AVR Core for CPLD

AVR core in single verilog file… There is not much info, the project was recently created on opencores and the homepage (from the source header) is in Russian…

Ok that’s all for today 😉

As usual the summary table is there: Open Cpu Study Summary.

New Projects pages and Gengo update.

I’ve been adding pages for my Projects. Previously this kind of data was on Trac, but I’ve never been using it actively. And I’m mostly using git for my new development instead of subversion.

I could have used Trac with git, but for project presentation WordPress pages are good enough.

But I wanted to have comments on some pages, which meant a theme update and another Gengo fix. Also I’ve done a big history rewrite by moving my version of gengo to git. If ever Jamie Talbot is really seriously considering starting development again. Then I hope he can pick some patches from my version 😉

First CPU review: OpenRisc, OpenSparc and S1 Core

The study items are listed on the Open Source CPUs post, especially the category description.

OpenRisc

The goal of the project fits my view of open source hardware, nice 😉
They claim a stable status and both fpga and asic proven design, well after reading the OpenRisc 1000 is a family specification, so this really applies to the OR1200 which is the only actual implementation existing today. It’s a 32bit RISC CPU with Harvard architecture, caches and MMU.
So it fits in the portable CPU category.

OpenSparc

It really look like sun needed some publicity to me, anyway here it is, a strong high end CPU (8 cores 64bit Risc…) it’s released under GPL v2. I don’t know if oracle buying sun interfered here, but some link on the site were broken, and the data did not seam to be that recent… But if it’s stable they don’t need more releases. Finally it’s really too high end for any geeky project, but there is a more suitable fork: look at S1 Core.

Simply RISC S1 Core

This is a reduced version of OpenSparc T1 with a single core, so it’s still a powerful 64bit Risc, but I think it’s more accessible so it fits the portable CPU category.

Note: From the S1 Core project page on OpenCores the same maintainers started a new and similar project OpenSPARC-based SoC

A summary table including those CPU is available, currently only in OpenOffice Format: Open Cpu Study Summary.

Open Source CPUs

I recently blogged about Open Source Hardware, lets take a look a bit more at the FPGA/ASIC kind of projects.

Any project big enough will require a CPU to control the rest of the hardware and maybe just run some user software. So we need an open source CPU ! That is to say, the code of a processor in a common HDL language (VHDL, verilog) with an open source licence.

A quick search on the internet and we have plenty of soft-processor, some open source, some not:

So how do we compare all that ?

There is an interesting article on the subject on 1-code technologies: Soft CPU Cores for FPGA. It compares the cpu in terms of features and size (in FPGA cells).
(As too often on the internet it’s lacking a publication date so it’s hard to know how recent the information is.)

So I’m planning to review several CPU and publish my results.

Continue reading

Installing debian on EeePC 1201HA: the synaptics touchpad

As usual debian’s wiki is a great resource, look it’s page about Synaptics Touchpad and most of the configuration is done.

So here I got the finger tap to work, but is spite of my efforts, the two finger scroll would not work. Well actually it did work using synclient but it was lost by next restart… And the hint was on the wiki but on Elantech Touchpad‘s page, near the end, in “GUI assistance” section: “Beware that they can override the global X settings in xorg.conf.”

So if you’re using gnome, look at the Mouse setting in gnome menu. You can also try gsynaptics, but while gnome mouse settings are reloaded each time you switch VT or suspend the computer, gsynaptics has to be reloaded manually.

Gnome didn’t let me check the two finger scroll option, so I opened gconf-editor searched for the touchpad key and found it as /desktop/gnome/peripherals/touchpad and changed scroll_method to 2. It’s still grey in the menu, but it’s checked an it works!

There is one remaining issue with gnome, if you want a different button for 2 finger tap than button 3, you can’t! I first fell on the fedora bug report about it which lead me to gnome’s one. So as of today, there is a patch, but not integrated in gnome, and I did not test it.

So I was tempted to switch to my old wm fluxbox, but didn’t take the time to configure it yet. Also reading Who-T’s blog, and especially this post xmodmap keyboard deconfiguration made me think that configuring one’s desktop trough Gnome and the like is going to be “the right way” in near future. As fluxbox session is just a plain bash script, we’ll need more working CLI tools for the hotplug configuration…

Well to come back, the touchpad is not going to be hotplug so a plain old config file like xorg.conf should in my opinion remain a valid choice (especially now that it does no goes through some other xml stuff as with hal). But then, the desktop configuration (ie Gnome) shouldn’t mess with it as it’s doing now!

Open Source Hardware

I’m fan of free software, I’m also a Micro-electronic engineer, sometimes I wish I could apply the free software philosophy to some hardware projects.

Well I could just applying some nice licence to some design and publish it. For hacking this works, just look at Arduino‘s success !

And there are plenty of other examples :

I think one great part of the success is related to the fact that you can do it yourself.

Now if you consider bigger projects like FPGA/ASIC design, it seams harder, well yes you loose the ‘do-it-yourself’ fun, and you compete with big companies, but still there are some examples:

Ok this is possible, now let’s go further, how do I choose my licence ?
Continue reading

Installing debian on EeePC 1201HA: the grub 2 trick

As already stated in the previous post update I’m now using the method described on debian eeepc wiki for booting in native resolution, so I’m no longer using the IEGD driver (nor my xserver by the way).

I find it a lot more stable !

I no longer have the issues with the mouse cursor jumping randomly to the lower right corner.

I even configured the touchpad to use the tap to click mode and the two finger scroll mode. (This will be the subject of a following post)

One more thing about using 915resolution in grub2, if like me you find that windows no longer want to boot, then only load 915resolution.mod before loading the linux kernel and not at grub startup.
You can do that by adding the following lines in /etc/grub.d/10_linux.

	echo insmod 915resolution
	echo 915resolution 58 1366 768 32

Instead of creating the /etc/grub.d/01_915resolution file.

I did place it at the end of the if block testing the GRUB_GFXPAYLOAD_LINUX variable.

Hope this will help some of you !