Making Sea Salt

I did something completely different. I didn't boot my laptop the entire Thanksgiving weekend.

I went to the beach, ate steamed oysters, grabbed several gallons of water, spent time with my wife, filtered the water, watched television, and boiled the water to get sea salt. I now have a nice little container of sea salt flakes from my favorite beach and a salt slurry.

I read a couple of web pages on doing this and most of what they say is common sense. Filter the water to clean out the sand and other impurities. Boiling is recommended to kill off any nasty organisms. Getting the water from a beach that is not polluted is recommended.  Also do not collect just after a rain. The resulting salt is a mixture of salt flakes similar to kosher salt and crystals like the fancy salt mills use. I may take the salt slurry and add a bit of water and put in a shallow pan to crystallize so it is nicer looking.

I'm considering making some of this into Christmas presents to family who like our little beach cottage.

Now that was something completely different.

Building the GNU ARM Toolchain: Part 2

Lesson learned on doing a toolchain build or anything else for that matter; make sure you are reading the most current documentation available.  I was working with very old versions of the software by using the GNU ARM website mentioned earlier.  In digging into the problems for those builds, I found a few other sites that have detailed discussions on building the toolchain for specific version of the ARM platform.

One of interest is the OpenHardware Building the ARM GNU 4.3.2 that has lots of useful hints.  Also, the Installing Gnuarm ARM Toolchain on Ubuntu 9.04 had some useful notes as well.  Both are very different approaches and for very different ARM platforms but they have lots of useful notes on how to create a toolchain.  I'll probably use something in the middle between the two to get the job done.

So I lost some time with old versions but learned a good bit about the software in the process.

The tools for the toolchain are:
binutil: low level tools for manipulating object code such as the assembler and linker tools
gcc: GNU compilers which has C/C++ and other tools related to compilation of code to object code
gdb & insight: debugger allowing for finding problems in code
newlib: a standard C library for embedded systems

Each tool builds forward until you have a complete toolchain that allows for creating programs for the platform. We are doing something even more interesting called cross-platform compilations. Since I don't have an ARM platform that I want to build a C compiler on and all the other tools, I am building those tools on my Intel Laptop under Ubuntu 10 LTS.  This means my Intel x86_32 processor will be running a compiler that will output an ARM executable. So the compiler is built to run on x86 but produce ARM.  This is cross platform compilation and is very typical for embedded systems work.

The problem I'm encountering is that I don't want to just use an existing binary build of the toolchain but produce one myself.  The age of the toolchain provided by Seagate is such that even if I wanted to find those versions of the software, I'm unlikely to find them and get them working.  So I'm looking for build a newer version of the compiler and see if the software will run afterwards.

My first program produced will likely be just a simple HelloWord app but from small things come larger ones.  Building OpenSSH, rsync and other tools will follow quickly if I get the toolchain up and running.

Building the GNU ARM Toolchain: Part 1

I found the GNU ARM Toolchain website awhile back and that they have several different versions out there for the toolchain. A toolchain is just the basic tools needed to build software.  In this case it is the standard libraries, the compiler, debugger and various other tools needed to write software.  The version of the toolchain that is provided by Seagate is version 3.0 and a very old version.  The oldest on the ARM website is 3.3 with 4.1 being the newest.

I've pulled down the 3.4, 4.0, and 4.1.  The 4.1 does not compile on my which is Ubuntu 10 LTS and may have to do with x86 versus x86_64 differences.  I'm not sure enough to diagnose yet so I dropped back a version to 4.0 and will check again.  The error in the 4.1 build was in the assembly code opcode section so that isn't an area I want to try debugging at this point.  The version 4.0 of the toolchain software is building cleanly for the initial libraries then failed in the GCC compiler. Sometime it pays to drop back a version to avoid bleeding edge pain and sometime you just find new pain.

Status:
So for 4.1: we have opcode errors in binutil which is very early in the build process and the errors look nasty.

For 4.0, we have an error in GCC "fcntl2.h:51: error: call to â__open_missing_modeâ declared with attribute error: open with O_CREAT" which looks like an error encountered before from some quick google searches. Not spent enough time yet to consider this a loss.

Building the toolchain makes it easier to understand the toolchain provided by Seagate even if it is an older version. Once I get done, I'll write up some details on a the process when I get it working right.

We'll see what happens with building the toolchains over the next day or so.

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.