Sun Java SE for Embedded Systems (Jazelle DBX)

Earlier I mentioned a technology called "Jazelle DBX" for the ARM processor that allows for Java Bytecode eXecution (JBX) directly in the ARM hardware which should make it run faster. That DBX technology is being phased out with newer Thumb-2 instruction set being the new preference by ARM for acceleration.  However, the processor in the BlackArmor NAS was the first processor to have this Jazelle DBX feature and I want to see if it has any merit. I did some digging around, like I mentioned I would, and found that Sun had produced a version of Java that may have this technology.

Sun has two small version of Java.  Once is called Java ME (micro-edition) and the other is Java SE for Embedded. The micro-edition was only for really tightly constrained environments like older cell phones that only had 8MB to 16MB of RAM. It was a feature reduced subset of Java with lots of limitations to make it work in that environment. Remember my old Motorola Razor cellphone from earlier posts and that is where this version of Java lived. That version of Java was crippled and never really seemed to take off.  On the other hand that version of Java is in some of our BlueRay players so it wasn't all bad. We just don't want this version of Java on the BlackArmor as it doesn't give us any interesting things other than cell phone Tetris.

The other version of Java is called "Sun Java SE for Embedded" and lifts many of the limitations of the ME version of Java.  It is a mostly full implementation of Java and allows for most libraries to be used from the reading. The downside is that it requires licensing when being used by a business. Fortunately, development work is free. I pulled a copy of the software as a tarball from Sun and will be taking a look at it when I get an environments setup and some times to play.  It has some requirements that may make is hard to use as it takes a minimum of 32MB of RAM per virtual-machine. Remember that the BlackArmor, only has 128MB total of RAM so that is a quite a lot of memory for just one Java VM.

We'll have to see if this is even feasible but it may open up a huge number of possibilities when you look at the diversity of Java code running out there.

Well that was my fun reading for the evening.  I hope you enjoyed my brain dump or at least found it tolerable. Anyone with experience in the area, please drop comment.

Reading on ARM Architecture

So earlier I was digging around trying to find out more about the Black Armor NAS hardware and pulled some interesting information.  Unfortunately, I don't have a lot of ARM background so a good bit of it was confusing as I reviewed it.

Snippet from earlier hardware information gathering:
$ uname -a
Linux NAS3 2.6.22.18 #1 Thu Aug 26 12:26:10 CST 2010 v0.0.8 armv5tejl unknown
$ cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 1 (v5l)

To rectify my lack of knowledge I started reading on Wikipedia and found the ARM architecture which made me realize that I've been missing out on an entirely different ecology of technologic innovation.  The features that are available for each processor was an interesting ride down memory lane with my memory of Intel CPU features, that I'm familiar with, running parallel to the ARM decisions in the same areas. They have two completely different paths but seem to have interchange between the two. ARM has an interesting history as a company as well.

So, I found information on the processor on the Wikipedia page for List of ARM Cores and the earlier reading on architecture helped me understand the differences between the Family, Arch and Core. Again, interesting ecology of processor technology.

ARM Family:       ARM9E
ARM Architecture: ARMv5TEJ
ARM Core:         ARM926EJ-S
Features:         Thumb, Jazelle DBX, Enhanced DSP instructions
Cache (I/D), MMU: variable, TCMs, MMU
Typical MIPS@MHz: 220 MIPS @ 200 MHz

This helps me understand what I will need in a toolchain and setup for that environment.  Earlier earlier I was not even aware that I was missing most of this background information. The ARMv# versus the ARM##XXX were confusing me but now I see the difference.

From the ARMv5TEJ, the "T" is the Thumb instruction set which is a subset of the overall ARM instructions optimized for performance by reducing some features.
T: Thumb Instructure Set support

So, the "J" in the ARMv5TEJ means we have "Jazelle" support. This feature initially stood out for me as it is direct execution of Java Bytecode against the underlying hardware. This could have be useful if a small Java VM could take advantage of the hardware but it looks like a dead-end since it is a closed implementation. It has also been made less relevant with the Thumb-2 implementation and it depends on the specific implementation if it is real hardware support or not now.  It is interesting to see the "Jazelle" feature was first implemented on this particular CPU.  I'll have to do more reading on it to see if anyone actually got a JVM running with hardware support.
J: Jazelle support

The "E" means Enhanced DSP support and that may be used for the streaming media or not. TDMI is implied by the E as well which gives us support for:
E: Enhanced DSP (digitial signal processing) support
T: Thumb Instructure Set support
D: JTAG debug support
M: Enhanced multiplier support
I: EmbeddedICE support
That is interesting in that each of those features can be enabled during compilation of software and might be used to improve performance.

Black Armor status

So my list of things to figure out keeps growing but I don't seem to get any time to work on them.

1. UPS software setup
2. DLNA server functionality
3. USB Hub issue to figure out so I can run the UPS and Printer together.

4. Serial Port hack (new)

I also want to get the serial port hack working which requires some physical work disassembling the NAS and maybe some soldering work to build a serial converter. The major work is already done by another guy on http://crapnas.blogspot.com but I'd have to follow along. There also appears to be a shortcut with an old Nokia USB cell phone cable that might be worth checking out.

Maybe next weekend I'll get some time. Project is just not getting cycles but I'm still thinking about it.

USB Ports on NAS

So I'm working on the UPS addition and forgot I use that USB port for my printer sharing. So time to do some reading on USB hubs and the Black Armor NAS 110. The printer is important and the UPS is important.  I wonder if I can mix my peanut butter and chocolate.

Even stranger, there is a USB port on the front of the box but that is special purposed for just USB Memory backups only.

So I have several paths here to check.

Black Armor: A ToDo List - UPS and DLNA

I have two new quick projects that I need for my Black Armor NAS 110 in the immediate future.

First I need the UPS functionality for this device as I'm taking power hits at my residence and my old UPS' are just way too old and not working to keep the NAS running after a power blip. I bought an APC Back-UPS ES BE550G 550 VA 330 Watts at CostCo with one of their specials. The Black Armor NAS documentation said it only works with APC UPS so I thought I was okay but with further reading in the forums they say results vary with APC devices. So time to see if my new APC UPS will work with the built-in software or if the software needs improvements. So I hope to have a smart UPS running but just the dumb UPS functionality without a shutdown mode will have to do if I cannot get it working. The smart UPS depends on apcupsd 3.12.2 according to a post.


$ /usr/sbin/apcupsd --version
apcupsd 3.12.2 (18 January 2006) redhat

Next on the list is to figure out how functional the streaming media works on the device.  This will hopefully be more straight forward than the UPS. Family time will be vastly improved if I can get the DVD collection running off this device. DLNA is an interesting subject and my BlueRay player hooked to my TV may be able to play movies off the NAS. That would be optimal.

Black Armor NAS Information

Here is the beginning of a dump of information on the Black Armor device from the Linux kernel and environment.  From this I learned the processor type and features. I also got some pointers to cross-compiler options used. These will all be important later.

$ uname -a
Linux NAS3 2.6.22.18 #1 Thu Aug 26 12:26:10 CST 2010 v0.0.8 armv5tejl unknown
$ cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 1 (v5l)
BogoMIPS        : 794.62
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 16384
I assoc         : 4
I line length   : 32
I sets          : 128
D size          : 16384
D assoc         : 4
D line length   : 32
D sets          : 128


Hardware        : Feroceon-KW
Revision        : 0000
Serial          : 0000000000000000

$ cat kmsg

<5>Linux version 2.6.22.18 (root@jasonDev.localdomain) (gcc version 4.2.1) #1 Thu Aug 26 12:26:10 CST 2010 v0.0.8

<4>CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053977

<4>Machine: Feroceon-KW

<4>  Marvell Development Board (LSP Version KW_LSP_4.2.7_patch21_with_rx_desc_tuned)-- MONO  Soc: 88F6192 A1 LE

$ dmesg

... way too much stuff ...

Rsync on Black Armor NAS 110

I figured out something simple but neat on the Black Armor NAS 110 (BA-NAS110) device.  It has rsync a powerful file-system replication tool from UNIX.

Caveats are that in order to do this you must have root on the device and a ssh connection with the command line. I'll write a friendly doc on how to get 'root' later. (Just search for Hajo Noerenberg's work on the subject sans the friendly write up if you want to do it now.)

So, the BA-NAS110 is capable of using rsync from the command line to replicate its data to another NAS or Linux system if you have root on the system. Getting it setup was simple enough but knowing that the rsync daemon and client were on the systems was the trick.

You have to create a rsyncd.conf file since there isn't one pre-built. Syntax is common to the typical rsync 3.0.4 version.

Hosting system
$ id
(root)
$ cat /root/rsyncd.conf

pid file = /var/run/rsyncd.pid


[rsyncftp]
path = /shares/Public
comment = rsyncftp

$ rsync --daemon --config=/root/rsyncd.conf

Client system (could be another BA-NAS110 or Linux)
$ id
(root)
$ rsync --progress --stats -v -t -r rsync://admin@/rsyncftp/* /shares/Public
  ... watch the good times roll ...

Note: Add the "-n" option to rsync on the client side for the initial test connection to put it in test mode without data copy.  Remove "-n" when you actually want to copy data.

The transfer speed between two BA-NAS110 devices across a dedicated switch is about 6-8MB/s. I've read some comments about performance on these devices being dogs and that there tweaks that might help.

I don't have my toolchain setup for compiling native apps yet but getting all my data copied out of my old device to my new one was a pretty important step to playing around with the older one.  So I figured someone else might benefit from this bit of lore.