I did just yesterday !
I was hacking on fluxbox and rebuilding the package to test directly on my system.
When I was happy with my changes I thought, I should write a patch for this…
But guess what ! With format 3.0 (quilt) it was already there, in the debian/patch directory, just waiting to be renamed and completed with a nice DEP-3 header !
It is a lot more easy to contribute with those tools!
So thank you debian folks !
Here is my report for the first week, (actualy I’m a little bit late, but friday loked like a better day for such reports)
That’s it… about 880 bugs more to go !
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
First, Hello Planet Debian !
I’m a new member of the X Strike Force, the debian team responsible for packaging Xorg. I basically stepped in with the openchrome driver.
I also have wider interest in free software or open source in general, but you can have a look at the rest of my blog, so I won’t bother you with too much details.
Talking with various attendant at MiniDebConf Paris, I got the impression that people think working on Xorg is hard.
I must say: It’s not !
First debian work is mostly packaging, and the developers of the applications we package (debian call them upstream) are pretty responsive, so you won’t be on your own.
Most of the work is preparing the packages for their new release, place them in experimental first, and ask for testers.
Then people test and the real work start: we receive bug reports.
Sometime seeing the report, it’s easy to point the user to test some other version, do some change, remove some old libraries in /usr/local/lib.
Sometime we need to ask for more information.
I said we, but for now unless it’s about openchrome, I can’t help much, but I follow the bugs on the X mailing list and learn from others response, I think I’ll be able to help soon.
I’m sure you’ve read about RCBW, kudos to every one posting some and to every BSP attendant.
But if you thought X was hard, you certainly find the remaining RC bugs too hard (Or if not, you might want some distraction with an easier task).
So I have a proposition for you: Triage X Bugs of the Week (TXBW)
As Lucas told on his blog I’ve proposed him a patch to help triaging X bugs using UDD. And he accepted it, Thanks !
So here is the link I’m using: XSF unstable bugs sorted by date.
But remember the udd database is not live data, if you close a bug, it won’t disappear immediately.
Also please read the X Strike Force Bug Closing Procedure before starting.
To conclude my TXBW data (well TXB of the Day so to speak)
I hope this can be a success like the RCBW initiative is.
Currently there are hundreds of X bugs, more than a half are at least one year old so they deserve to be triaged !
The X Strike Force (still) needs you !
I’ve been more on software recently, and I didn’t blog much…
I’m still maintaining openchrome Xorg driver, not much to do now that the latest upstream SVN version is on KiBi’s X autobuild system. Except waiting for the bugs to occur.
I also just requested to become DM to release the X Strike Force of the task of sponsoring me…
After a rather awkward first message (still sorry about that), I started working on webalizer’s debian package.
Nothing’s published yet, but this will come.
Finally I received an email from Axel Beckert about xrootconsole, well he already blogged about it, I accepted to co-maintain xrootconsole with him. More details on my xrootconsole page.
To conclude, after some month following the debian community, I’m starting to feel part of it!
The study covered 88 CPU projects.
16 (18%) CPU have no license text and no license header in the files. To my opinion that makes them unusable, anyway most of them are also not active. In any case it show that the developer didn’t really care about how other could use his work.
At least 47 (53%) appear to be inactive. Most looks like design dropped here and forgotten. Well that’s life, but if you start a project with such core, you will end-up being your own support… not a comfortable place.
On the other hand, 24 (27%) looked really active with 13 (14%) being marked as ‘stable’ (whatever that means).
Let’s look at the category, I must admit that I didn’t fill the category for some inactive project as I didn’t look into enough detail to choose one. Also few projects are clones of legacy architecture, well this could be a category on its own…
So we have:
Well I guess my limit between embedded CPU and portable CPU is kind of subjective, I would say that embedded CPU don’t need and MMU nor 64bit data path.
Anyway That’s more embedded CPU than I though, I mean I had the impression to fill only tiny micro-controller, as many small project driven by one developer are just that anyway.
29 (32%) uses GCC or provide patch to GCC. (Some CPU are clone so they kind of have it for free). And most of the embedded CPU have gcc support, and all portable and high end CPU have too.
And most tiny micro-controller don’t use GCC, except mainly AVR clones. But that’s normal, most are programmed in assembly anyway, others are so simple that writing a compiler would be longer than writing the CPU !
The study items are listed on the Open Source CPUs post, especially the category description.
I’m planning to finish the current list of processor projects on OpenCores. As the list is long and for most cpu all informations are likely to be present on the OpenCores page I will just add them to the summary table. I will silently discards the one without files, as those are just useless.
I’ve gone through the whole list, there was not much more to say about most CPU, but here are some thought.
It was long since I didn’t read about some asynchronous design, if your looking for that, it might be good for you 😉
I’m more a C than Java programmer but his could be a nice stuff. Just a though if it is used for a smartphone/tablet it could require a kind of virtualization to run each app in a separate context… Maybe it’s already possible, I’ve not looked into the details.
While reading Yellow Star details I found an interesting letter from MIPS on Yellow Star’s page.
I was telling about my doubts with AVR clones, at least for MIPS this was clear (in 2002), they really did not like the clones at all!
So I guess MIPS is not an option unless they change their politics to win back some ARM market share…
As usual the summary table is there: Open Cpu Study Summary.
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.
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.
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.
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.
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.
The study items are listed on the Open Source CPUs post, especially the category description.
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.
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.
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.
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.
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.
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.
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 😉
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.
The study items are listed on the Open Source CPUs post, especially the category description.
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 !
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.
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.
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.
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 🙁
This is a Atmel AVR ATtiny261/461/861 compatible core. LGPL and not updated since Nov 10th, 2008.
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.
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 😉