With the newer version of Pi4J are the LEDs operational, but the port fails for the baud rate. I will keep on digging.
After investigation I saw a change in the PI4J API, the changed the class NativeLibraryLoader in 2014. The say they have simplified the loading thing and that it now (after 0.0.5), only supports the loading for the embeded resource, aka the so-file/ native library. When I look in the I2C.java file the removed the same statement, just as you have pointed out for the NativeLibraryLoader.
static {
// Load the platform library
// Removed -> NativeLibraryLoader.load(“pi4j”, “libpi4j.so”);
// Added -> NativeLibraryLoader.load(“libpi4j.so”);
}
The first parameter is “pi4j” and points to a native library in the system classloader but not on the lib dir. When it fails in will try to resolve the so file in the jar itself. In the newer version it loads only from the jar file. I will seek if there is libpi4j.so somewere in the classpath on the PI.
It could also be the case that the libpi4j.so is hacked for the baud rate.
@mtstorm - I was guessing the libpi4j.so might also be hacked for higher baud rate. I did extract the native .so file from current and 0.0.5. On my Pi3 it didn’t work with the motor. I will try it with my Pi 2B and B+ this weekend if I have time.
peter
@mtstorm - I came across this bug in pi4j that has been closed. The baud rate was limited due to the wiringPi pi4j was using.
That bug was closed. I think 1.1 snapshot is suppose to have the fix.
@woolfel Nice!!! Thanks for your updates. I will start working on it. I will get the pi4j snapshot from there repo, this is good news. I will post my progress asap to let you know if it works. On Twitter they say they will release half of april!! Then this can be included in the repo 
as a project dependency. I will keep you posted!!!
Small update; The new version of pi4j is nicer than the previous one and is not backward compatible. With some minor code changes it’s easy todo. Changes are is that the interface Serial is now thowing IOException (very nice better). AutoClosabe is now on the interface Serial (love that) so try with resources can be used. There are some renames of methods like availableBytes() -> available() . The read is now very nice, no read for a single byte but an array, so you need to use read (int length). Than it easy to implement it. The shutdown of the serial has been removed, need to figure that out how to release the serial (other then close, do not know yet.)
I’m still working on it, I will keep you posted.
An update. I have added the snaphot version “1.1-20160409.004953-44” of pi4j-core that should work, but I am a bit clueless. The API has changed and I think I am overlooking some new features of the serial interface of PI4J. The only thing now is working are the LED on the BrickPI, but there is no communication between the software and the BrickPi CPU’s yet using the serial. I can open the serial port with the correct baudrate of 500,000 but then, after sending, there is no response of the BrickPI. I have made a loopback connection for the serial and that running fine (I have added some stuff to the baudrate issue https://github.com/Pi4J/pi4j/issues/89 , maybe they have some nice suggestings.). I do not have an osciloscope here at my disposal, but I have and idea that the brickpi is not getting any data. I made a loopback connector for the serial and run a test and that runs fine.
Is there a possibility to make a ping between the rpi and the brickpi. This would be very nice to check if the communication between hardware and software would be running. Is this an idea to implement that in the monitors of the brickpi? for instance getting the version of the monitors software, and implement a basicloopback feature in it (ping idea).
I think I made an error somewere, the bug is between the monitor and the keyboard ;-). I will continue an keep you posted.