Author Archives: Stuart

By Any Means Necessary

It’s been a few years since I last posted. Today I’m writing about the MacchiatoBin – see http://macchiatobin.net

The MacchiatoBIN is a development board based around the Marvell 8040 SoC, which is intended to be used in network equipment. Having worked for some years at Arm, one thing I’ve been wanting is a decent Arm computer at home. The MacchiatoBIN is the first thing that could be described as a real computer, for the following reasons:

  1. It comes in a standard form factor. It is actually mini-ITX, and so it can be installed into a standard case (see below).
  2. It has a DIMM slot, so can take 16GB of RAM. That’s pretty decent.
  3. It has 3 SATA powers. You can actually have decent I/O (to be measured).
  4. There is a 1GB ethernet port. In fact, the Double Shot I have has 1x1GB, 2x10GB (SFP+ and copper), and 1×2.5GB (SFP) ports. Of course, it is built around a networking chip.
  5. It has UEFI. It is a development board, so it can load firmware from SD card, eMMC or SPI ROM.
  6. There is a USB2 header, and USB 3.0 at the rear. My case has USB 2 at the front.
  7. There is a reset button on the board. Fine, but there is a reset header too, so your case’s reset switch will work.
  8. There is a PCI-e x4 3.0 slot. While it is only x4, it is an open-ended slot, so larger cards will fit.
  9. There are 4xCortex A72s. They are better than Cortex-A57s and they are set to run at 2.0 GHz. These are out-of-order cores, so they are interesting from a performance perspective.

There are all good things – not necessarily brilliant, but it is a good step. I wouldn’t be interested if they were Cortex-A53s – they just aren’t interesting for performance reasons. Unlike other development board projects, having a standard format really does sell the idea as you can stick it in any consumer case.

MacchiatoBIN installed in a mini-ITX case

A MacchiatoBIN board installed in a case.

There are some shortcomings, however:

  1. 8 x Cortex-A72s would have been just perfect. As it is, building OpenJDK on my i7 Ultrabook takes about 12 minutes. On this MacchiatoBIN it takes 20 minutes. Decent and usable, but could be better.
  2. The firmware and kernel are quite raw. In the future it ought to just work with UEFI, but there are some outstanding issues.
  3. The PCI-e slot won’t work with modern graphics cards just yet – using it as a desktop machine won’t work just yet. Cards tend to lock up the machine, or when they do work, train  at slow speeds. You might be lucky with an old card. (An Nvidia 6200 might be ok).
  4.  The ATX power supply is controlled by the PSU power switch. The power button on your case will do nothing. Also, the machine can’t power itself off.

I’m interested in addressing the last point. I run my home server and this machine off of a UPS. For that reason I would like the machine to be able to do a controlled shutdown if power is lost. To that end I’m investigating using a micro-controller to control the ATX power.

The ATX power standard has two relevant features. Firstly, the PSU, even when the machine is off, supplies 5V on standby. Obviously if you turn the PSU off at it’s own switch or the socket there is no standby power. Secondly, the motherboard can signal to the PSU to turn supply power by shorting the PS_ON# pin to ground (see https://en.wikipedia.org/wiki/ATX#Power_supply). The MacchiatoBIN circuit diagram explicitly states that these are permanently shorted.

I have an Arduino, and an old power supply, so I can prototype this. My first experiment is simply to see if I can manually turn on the power supply. I could just jam a paperclip into the appropriate pins, but instead I hooked up a breadboard with a button.

ATX power supply and breadboard

ATX PSU and Breadboard

The 20-pin ATX connector has the same pins as the more recent 24-pin connectors, less 4, so in practice it is the same here.

No heat, not smoke, it just worked.

The end goal is to wire up a microcontroller to the PSU lines, the case LED and power switch and a serial port such that the machine will work like a normal PC and be able to be operated by its power switch and have the kernel shut itself down.

While there is a microcontroller attached to power and serial ports, there is a stretch goal of fashioning it into a BMC, but I’ll talk about that another time.

Circuit diagram

This is a possible arrangement for a BMC.

Whatever Happened to Mr. Garibaldi?

It has been a long while since I posted, and a lot has happened since then.

The Apache Incubator Kato has been retired and lots of inactivity. This was not surprising, there just wasn’t the will for the project to start again, and in open source an unwanted project dies, and rightly so. While I would have liked to, commitments at work at IBM and the birth of my daughter conspired to prevent that from happening.

I have also moved from Winchester to Cambridge, changing from working at IBM to working at ARM, which changes my perspective on things too, and my paymaster.

So what’s in the future? I will be learning lots about the ARM architectures – particularly ARMv8 and the 64bit variant of that. I have ideas for some projects, but more on that in the future.

The Long Dark

If there is one thing I’ve learned from the Kato project, it’s that open source software needs a community with the motivation to participate. Unfortunately with the acquisition of Sun by Oracle, JSR-326 has been held up as we really needed Sun/Oracle to participate. Of course, the Apache Kato incubator is not JSR-326, but the two were tied together, and the outcome of Kato was to produce JSR-326’s reference implementation.

So what has happened after the 0.1 release of Kato? Well, conversations have been had between representatives from IBM and Oracle, led by Steve Poole. Events have been progressing extremely slowly, as Java debugging in the manner of Apache kato hasn’t been a huge priority – Java 7.0 has been the highest priority. My hope is that the once Java 8 gets the focus JSR-326 and Kato will get some attention. Oracle have apparently assigned someone to work on this – we look forward to hearing from him.

Robert Burrell Donkin has continued to show superhuman levels of patience with his encouraging words. Even with months and months of activty he continues to encourage us. The original goals of this project were worthy enough, but I believe it would have been better for us to develop the technology, open-source it for collaboration in an Apache Incubator, and then consider standardizing it. One of the options considered was to ignore the JSR for now and continue developing cool technology – I would like to explore that idea.

Personally, there has been a lot going on since 0.1. In IBM I’ve occupied three different roles (none of them in JVM technology). I also managed to get married and my baby daughter was born in June this year! So doing open-source projects in your free time has proven difficult when free time is in such short supply.

So, to the future:

I believe JSR-326 will probably be completed. However, it would be advantageous if we reevaluated it’s goals in light of developments since this project started. One area we could consider addressing is debugging in cloud environments.

I’d like to see Apache Kato decoupled from JSR-326 if the JSR does not seem likely to continue – a new JSR could be submitted if the Apache Kato technology proved valuable enough for standardization.

OpenJDK will continue as is, and we need to consider our relationship with it carefully. Technology embedded in the JDK would be GPL licensed. The code that tooling would use to interact with OpenJDK would be best distributed with a permissive licence, i.e. Apache, so that tools development could be collaborated on. I imagine this will turn out to be a mine field, so we shall see.

So here’s to the next quarter – may it be more interesting that the last 6!

A Voice in the Wilderness

Well, January was an interesting month.

The Kato project had some much needed input from Lukasz from Poland. One of the more useful things about the Apache Kato project is it provides an API for accessing hprof files. Previously each tool would need to write its own implementation of an hprof file reader.

The kato project includes a little tool called “KatoView” that allows hprof files to be queried on a command line. While it’s usefulness is limited, there are some useful things that can be done.

I am learning to be a release manager for the project. Apache operate in its own unique way, and it is taking some getting used to, but one of the fundamental processes is the Voting process.

Last week I asked the Incubator project management to vote on whether or not Kato’s first release should be allowed out into the wild.The voting process is roughly as described here. An email is sent with the subject “[VOTE] subject to vote on”, a description of what is being voted on and an announcement of when the vote is to be closed. This should be a minimum of 3 days. People will then vote +1, 0 or -1.

+1  is used to indicate when someone supports the proposal.

0 is used when the voter is neutral.

-1 is when the voter is opposed to the proposal.

Often voters will have additional comments, especially if -1 or even 0 votes are submitted.Generally at least 3 +1’s are required. Under some circumstance -1 constitutes a veto.

The Apache Kato incubator has few active participants, and with insufficient votes the “lazy consensus” approach is often used. i.e. lack of votes constitutes tacit support.

1 day to go on the M1-incubating release. Fingers crossed for lots of +1s 🙂

Chrysalis

Well, it’s nearly the end of 2009 and the Apache Kato podling has progressed somewhat during the year.

The high points were:

  • Java One,  where Steve Poole presented Kato and JSR-326 a Birds of a Feather session.
  • The JSR 326 Early Draft Review was published by the JCP
  • The CJVMTI agent was written to produce the dumps required for a reference implementation, and this continues to progress.
  • The TCK is up and running, so we can test.
  • The Hprof implementation also continues to progress.
  • The first release candidates were made available.

There are still plentyof things to do next year:

  • We will have our first release, a milestone release to demonstrate what we have so far.
  • The dump API is to be completed. This means that dumps can be initiated by programs consistently.
  • After the Final Draft Review, we should have a standard.
  • Then, who knows, maybe it will be included in Java 7.

I was hoping to have in this blog, useful information for diagnosing problems – once we have a first release I write about the API and what you can do with it.

Signing off,

Stuart

Signs and Portents

It has been a very long time since my first post.

Most of the work I’ve been doing on the Kato project has been on the Early Draft Review of  JSR-326 (available here: JSR-326).

More interestingly, in IBM here we’ve had a summer student (Paul Sobek – I don’t have a link to him) writing a JVMTI agent in C that dumps all sorts of Java goodness. Our problem was with hprof there wasn’t quite enough information for our needs, and the information is offered was limited. Using  his agent it is now possible to inspect local variables at the time a dump was taken.

Ultimately, we’d like this to be our Reference Implementation, after much more testing against our TCK and implementation of non-JVM information (such as the machine’s hostname). In combination with our JDI connector, it is possible to attach a Java debugger to the dump files and determine what caused them.

Would this be something you want? For example, take a long running server. If an ArrayIndexOutOfBounds exception is thrown, then either the JVM will exit, or it will be caught and ignored. Using this agent, a dump could be taken automatically, and offline it could be debugged.

Soon I hope to write here how you can try this out for yourself…

And Now for a Word

I like blogs, however the blogs I like most are those I can find on Google through a search engine in answer to a specific problem.

I’d like this to be one of those blogs.

Hi! My name is Stuart Monteith.I created this blog because of my involvement in the Apache Kato incubator project. This project aims to develop JSR-326, a Java standard for an API that allows tools to debug Java programs, possibly JVMs.

Why should you care? Ultimately, the aim is to solve programs with Java programs in a different way that you might be used to.  Anyone using more static languages, such as C and C++, will be used to attaching debuggers (such as windbg, dbx, gdb) to running programs. Fine, but they could also attach to programs that had crashed, or generated a core file for some other reason. You can’t do that in Java.

That is a little lie. However, you can’t do that on every JVM from every vendor and write tools to do it.

And finally, a link to a most excellent, non-Java blog: http://www.pagetable.com/?p=48

The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.