Tag Archives: development

96boards goes enterprise?

96boards is an idea from Linaro to produce some 32 and 64-bit ARM boards. So far there were two boards released in “consumer” format and few more announced of rumoured. The specification also lists “extended” version which has space for some more components.

But during Red Hat Summit there was announcement from AMD with mention of “enterprise” format:

How would you like an affordable and compact 160x120mm board to jump start your development efforts with AArch64? AMD and Linaro have been collaborating to develop a 96Boards Enterprise Edition (EE) specification that is ideal for the individual developer. Targeting the server and networking markets, the board will feature a 4-core AMD Opteron A1100 Series processor with two SO-DIMM memory slots, PCIe®, USB, SATA, and Gigabit Ethernet capabilities. Popular operating systems such as CentOS, Fedora, and Red Hat Enterprise Linux Server for ARM Development Preview are targeted for use with this particular board. Additional software downloads, updates, and a forum for software developers will be available via the 96Boards web site. The board is slated to be available in 2H 2015 from distribution partners worldwide and it will be supported through the Linaro Enterprise Group’s 96Boards.org site.

I do wonder where from they took idea to name yet-another-crazy-non-standard board format “Enterprise Edition”. In my understanding what enterprise user like is something which just works and comes with support and does not require crazy embedded nonsense hacks.

So when I saw post from Jeff Underhill with photos of the board I noticed few arghs.

Top view of AMD "Enterprise" board

Bottom view of AMD "Enterprise" board

First of course is board format. 160x120mm does not sound like any industrial format. Nano-ITX is 120×120, Mini-ITX is 170x170mm. But everyone knows that enterprise people love to be creative and make own cases. Why it was not done as 170×120 with partial compatibility with mini-itx cases?

Second thing (related to first) is connectors placing. With PCI-Express x16 slot (with x8 signals) I wonder how it will look when some cables go one side or the other while card sticks out of board. With SATA ports moved to the other side there would be space for USB and Ethernet ports so all cables would be in same area. Note also molex connector to give power to SATA disks.

Nice that there are two memory slots (DDR3 ECC SO-DIMM). But with second on the bottom we probably can say goodbye to all PC cases as it would not fit. Yay for creativity when it comes to cases (again).

There are holes to mount heatsink above CPU. From quick look I think that those for FM2 socket may fit.

HDMI connector suggests some graphics to be present. I did not heard about Radeon core inside AMD Seattle CPU but it could change since last check.

But even with those “issues” I would like to have that board ;)

Git commands which you should really know

Git is now ten years old. More and more developers get lost when have to deal with CVS or Subversion as first SCM they learnt was git. But in daily work I see many people limited to very basic use of it ;(

There is a lot of commands and external plugins for git. I do not want to mention them but rather concentrate on ones installed as part of git package. And only those which I think EVERY developer using git should know that they exist and how to use them.

Dealing with other repo is easy set: “pull” to merge changes (“fetch” if you only want to have them locally), “push” to send them out. “git remote” is useful too.

Branching is easy and there is a lot of articles how to do it. Basically “git branch” to see which one you use, “git branch -a” to check which are available and “git checkout” to grab code from one.

Checking changes is next step. “git diff” with all variants like checking local not committed changes against local repo, comparing to other branches, checking differences between branches etc. “git log -p” to check what was changed in earlier commits.

Then goes “status” to see which local files are changed/added/removed and need attention. And “add”, “rm” and finally “commit” to get all of them sorted out.

Lot of people ends here. The problem appears when they get patches…

So how to deal with patches in git world? You can of course do “patch -p1 <some.patch” and take care of adding/removing files and doing commit. But git has a way for it too.

To generate patch you can use “git diff” and store output into file. But this will lack author information and description. So it is better to commit changes and then use “git format-patch” to export what you did into file. Such file can be attached to bug tracker, sent by email, put online etc. Importing it is simple: “git am some.patch” and if it applies then it is merged like you would do local commit.

There are other ways probably too. Quilt, stgit etc. But this one is using basic git commands.

And I still remember days when I thought that git and me do not match ;D

Rawhide: unwanted baby in Fedora world?

For something about 15 years I was using Debian distribution and ones which derived from it (like Ubuntu). Basically whole time I used development versions of them and amount of issues was nearly not existing. Now I run Rawhide…

For those who do not know: Fedora world contains four distributions: Fedora, RHEL, CentOS and Rawhide. All new stuff goes to Rawhide which is then branched to make Fedora release. Every few years Red Hat forks released Fedora and uses it as a base for new RHEL release. Then CentOS guys create new release based on RHEL. At least this is how I see it — others will say “but rawhide is fedora”.

I think that the problem lies in development model. All new stuff goes to Rawhide but at same time nearly no one is using it anything can happen there. For example my KDE session lacks window decorations, Konsole5 freezes on any window resize and the common answer for such issues is “You should expect that in rawhide”.

Going into Fedora irc channels with questions is just waste of TCP/IP pockets because in a moment when you mention rawhide it is like everyone fired /ignore on you.

And it is some kind of fun (for some sick/weird definition of it) to watch how people start development of packages just after Fedora releases something. They upgrade and then start to seek what interesting happens in rawhide and can be built.

Each day I am closer to go back to Debian/Ubuntu for a desktop with just keeping Fedora in VM for development of some packages.


So today Linaro announced their first board from 96boards project. It is named HiKey and is based on HiSilicon cpu for mobile phones.

I had an occasion to see that board during FOSDEM and decided to write something about it after it land on my desk (which will happen sooner or later). But I have read specification for this and next boards and decided to write few words from my perspective.

First thing? Footprint. Good that two sizes are available for designs as not everyone may want to squeeze into small one.

Second? Ports. 2015 year and no Ethernet, no SATA? Sure, first board is based on SoC from a mobile phone but there is no place on small board for them and extended version looks like not allow for extra ports too.

Next? Power supply. 8-18V in a world where everything is on 5V already. The only place where 12V is mentioned in spec is “external fan power”.

So as we are on voltage… Serial at pins and 1.8V level. Nice way of forcing everyone to buy new serial dongle (Arduino ones are 3.3 or 5V).

But assume that we got it powered and have serial connected. How to boot it? According to specs mainline kernel (or AOSP one or LTE one) has to be used. I wonder how HiSilicon cpu is supported in any of those. From what I read during day (on quite slow connection) it is still not in a kernel…

Graphics situation is still shitty. Vendor is allowed to provide binary blobs to get display working. Did they not learnt from OMAP? PowerVR again someone? But sure, plain framebuffer is all you need. OpenGL is for weak.

I prefer not to discuss about selection of signals on low/high connectors. There are more capable people for it. I only wonder why 2mm raster where nearly all boards I had played with had 2.500 one.

I like list of distributions listed as ones to choose. No longer Android/Ubuntu but also Debian, Fedora or OpenEmbedded based one

But give them time. It is just first board and next ones are announced. Marvell will produce one (they are in a Linaro group for it), other will (probably) follow. Hope that there will be something better.

Gained new power

Today Dennis Gilmore asked me on #fedora-arm “Are you a packager in Fedora?” so I answered that I am in “packager” group but do not own a package in Fedora and do not have plans to change it.

It turned out that the question was part of thinking that maybe I should get membership in the secondary arch group which would allow me to commit my fixes directly. Normally I prefer to grab maintainer’s attention with new reported bug or even IRC discussion about an issue. But sometimes there is no response and fix is aarch64 related without any changes for primary architectures.

So now I can commit fixes to Fedora packages directly to git repositories. Will not overuse this privilege and make it only when it is really required.

I am starting to dislike GNU project

When GNU project was announced over 30 years ago it was something great. But time passed and I have a feeling that it is more and more politics instead of coding.

I do builds. For over 10 years now. It was ARM all the time with some bits of AVR32, MIPS, x86. During last two years it is nearly 100% AArch64. And during last months my dislike to GNU project grows.

Why? several reasons.

Commit messages

There is a lot of articles about “how to write good commit messages”. I can tell you where to look for bad ones: gcc, binutils, glibc — base of most of GNU/Linux distributions. All of them can be fetched from GIT repositories but look like deep in CVS era. Want to find what was changed? You will get it in commit message. Why it was changed? Forget.

GNU forks

Do you know what IceCat is? Or GNUzilla? Let me quote official homepage:

GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the GNU version of the Firefox browser. Its main advantage is an ethical one: it is entirely free software. While the Firefox source code from the Mozilla project is free software, they distribute and recommend non-free software as plug-ins and addons.

Where is source? Somewhere in GNU cvs probably. I failed to find it. OK, there is a link to something which is probably source tarball but we have XXI century — developers take source control systems got granted.

Of course IceCat fails to build on AArch64. Why? Because it is based on already obsoleted by upstream version 24 of Firefox. Support for 64-bit ARM platform was merged around Firefox 30 and is complete in version 31. Sure, I could dig for patches for IceCat version but no. This time I refuse.

I do not know, but maybe GNU project needs some fresh blood which will make them more developer friendly?

From a diary of AArch porter –- testsuites

More and more software come with testsuites. But not every distribution runs them for each package (nevermind is it Debian, Fedora or Ubuntu). Why it matters? Let me give example from yesterday: HDF 4.2.10.

There is a bug reported against libhdf with information that it built fine for Ubuntu. As I had issues with hdf in Fedora I decided to look and found even simpler patch than one I wrote. Tried it and got package built. But that’s all…

Running testsuite is easy: “make check”. But result was awesome:

!!! 31294 Error(s) were detected !!!

It does not look good, right? So yesterday I spent some time yesterday on searching for architecture related check and found main reason for so big amount of errors — unknown systems are treated as big endian… Simple switch there and from 31294 it dropped to just 278 ones.

Took me a while to find all 27 places where miscellaneous variations of “#if defined(__aarch64__)” were needed and finally got to point where “make check” simply worked as it should.

So if you port software do not assume it is fine once it builds. Run testsuite to be sure that it runs properly.