Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

20090410

Two Bits

Well, I've finally done it. I've been working for a few months now on porting Linux to a new device. Do you know what it came down to in the end?

Two bits in a 32-bit number.

That's it. There were times when I became quite a hermit working on this device. People would look at me like I was crazy sometimes. I had to open it the case and solder a few connections on. At the very beginning I was probing pcb pads to find the right traces. I hooked it up to a scope, put together a few voltage-level shifter circuits. I designed and fabricated a breakout board for easier access to some really small traces.

Just when I thought that I was destined to lose my grip on reality, I was greeted by what seemed to be some ascii characters on the oscilloscope. Then, with a bit more tinkering, at a point in time that seemed to be more precious than diamonds, as my eyes started to well up a little bit, I saw the following message on my console:
Linux version 2.6.29 (cfriedt@localhost) (gcc version 4.1.2 (Gentoo 4.1.2 p1.1)) #5 Fri Apr 10 18:16:27 CEST 2009
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f
...

The device itself will remain unnamed .... for now ...

20071118

IEEE.tv Article Interviews John Stevens

John Stevens, CEO of Visible Assets, was recently featured in an interview at the RFID conference in Dallas. Actually, the conference took place 26-28 March, 2007. I only just noticed the interview because I started subscribing to IEEE.tv through Mozilla Thunderbird's RSS news reader. I also happen to work for Visible Assets, and so I thought I'd take this opportunity for some shameless corporate promotion :)

In the interview, John explains some of the details about RuBee(tm), the pending IEEE protocol (IEEE P1902.1), and how Visible Assets applies the relatively young technology of long-wavelength radio tags. At Visible Assets, we basically sell a service that builds upon RuBee(tm). Through the grouping of distributed, collaborative, and localized networkable transceivers, RuBee(tm) securely enables the authorized end user to asynchronously monitor their assets from anywhere in the world. All communication between the transceivers and the end user are event-based, which cuts down on bandwidth over long distances, enabling local monitoring in real-time and remote monitoring with extremely low latency.

RuBee(tm) is protocol that can overlay the common IEEE 802 standard. What that means in human terms, is that every tag can be assigned an IP address, just like the computer on which you read this article. When IPV6 takes over, boasting an addressable space of 2128 (about 3.4×1038), that means that every single tag will have a globally visible, unique address on the internet. Pretty astonishing, isn't it.

If I slapped a tag on my favorite toothbrush, flew to Japan, and visited an internet cafe, I have the potential to be disappointed that I forgot my favorite toothbrush on the other side of the planet. But hey, at least I would know that it was safe and sound back home ;-) That's really a crude example. Our primary clients are those who need high data reliability when monitoring their assets, such as those in the medical, pharmaceutical, agricultural, and defense sectors.

RuBee(tm) is the main feature of our infrastructure. Therefore, I should take the opportunity to share some information about the unique technology that we, at Visibile Assets, bring to the RFID spectrum.

Our tags do not belong in the same category as RFID, although they could conceptually be used in many of the same situations where RFID is used today. It should be noted that our tags operate at the lowest end of the RF spectrum (below 450 kHz), and should therefore be considered a complement to RFID. This difference in carrier frequency results in some fundamental contrasts between our tags and conventional RFID. Namely,
  1. RFID has very short range with low penetration, while our tags have very high penetration and a considerably longer range,
  2. RFID electro-magnetic (wireless) signals are largely composed of electric (E) fields, while our tags contain 99% magnetic (B) fields
  3. RFID signals have a high bit-error-rate (BER), while our tags have a low BER
  4. RFID tags are generally passive devices, whereas our tags can be passive, or optionally active devices for wireless data-acquisition applications (temperature, pressure, etc)
My job at Visible Assets, Inc. is to design and implement low-level software and high-level hardware. In some sense, I transform our transceivers from simple radios into intelligent nodes within the aforementioned distributed, collaborative system. We call the end product a Sidewinder and of course, one could say that it is indeed an internet appliance (INAP) in the trademark-free sense of the word.

Currently I'm doing a master's degree in Digital Communications during the day, but then at night I assume the role of my secret identity as embedded systems engineer for Visible Assets. Right now I'm implementing a fairly sophisticated software stack in probably the best C code I've ever written in my life!! Needless to say, it keeps me reading up on all of the distributed / intelligent systems literature that I can get my hands on.

In the interview, John really spells out a highly technical subject in such a way that the average layman can understand, which isn't a very common ability among engineers. Don't let that fool you though. There are only a few people who understand our technology through and through, and John is one of them.

That's only one of the reasons I really like working under him. John has a great relationship with all of his employees. Last year we had our staff Christmas party at his home, which is more of a personal touch than I've seen at any other company. He gave this great speech which was followed by a cheerful toast, and it really motivated me - I'm working on some pretty cool stuff!

John gets so excited when he finds out about new progress that we've made. The only analogy I can give is to compare him to a child with a new train set. He's always excited to figure out how things work and he loves talking about all of the development details, like what challenges we faced, where we made compromises, and new and interesting ways we've used to overcome obstacles.

Nice interview John! I'm looking forward to showing you what's been keeping me so busy lately.

Other articles about what we do at Visible Asests:

Converge! Network Digest [20060609]:
IEEE Begins Work on Wireless, Long-Wavelength Standard
Sensors Specialty Markets [20060612]:
New Wireless Standard for Healthcare and Livestock Visibility Networks
RF GlobalNet [20060612]:
IEEE Begins Wireless, Long-Wavelength Standard for Low-Cost Radio Tags
RF Design [20060614]:
New IEEE standard to bring local network protocol to thousands of radio tags with long battery lives

RFID Journal [20060619]:
Visible Assets Promotes RuBee(tm) Tags for Tough to Track Goods
IDTechEx [20070208]:
IEEE RuBee(tm) Network Standard Meeting
Epson [20070507]:
Visible Assets, RuBee(tm) Technology Leader, Announces Investment from Epson Electronics America

20070720

Done Exams!

I've finished my exams for the 2007 summer semester here in Kiel. Both of them went pretty well. The first was Computer Vision II: Stochastic and Topological Approaches to Image Processing, and the second one was Neuroinformatik. CVII went pretty well, although I was a bit pissed about the last question. Neuro went better actually, although I like CV a bit more. CVII is actually a fairly hard course, not as hard as CVI, but still.

I had a beer, as per tradition, as soon as I got out of the last exam, and then on the walk home, the air smelled fresher, the sun felt brighter, all of the music on my iPod seemed to fit perfectly with everything - a good sign ;-) Actually, having the ability to take time and walk home was a big change all by itself ;-) Usually I have no time what so ever, and am racing to catch the next bus too hand something in, or meet up with my study groups.

I'm looking forward to coming home ____SO____ much!!!


Now I can focus on my work a bit more, and get a couple of big projects out of the way. I'm excited to actually be able to concentrate on one 'job' for the summer, getting new toys to play with (i.e. embedded devices), and doing some electrical design / hacking too! I'm also planning on hacking a couple of open source apps like Banshee, iPodLinux, and writing more interesting code for my various embedded devices.

Finally, I can design some image processing hardware too, once I learn about the PCI bus and interface with the new TS-7800 boards ;-) Since I tore apart my old crappy 1.3 megapixel digital camera, I'm also hoping to put linux on it.

As of next semester I'm going to be registered in the M.Sc. in Digital Communications, which is taught in english, as opposed to Informatik, which is taught in german. That should lighten my load considerably, but also provide the same type of challenges that I'm used to in areas such as DSP, communication theory, analog & digital circuit design, and so on.

Digital Communications is an engineering program, which I like better. Not to say that I didn't like all of the experiences I had in Informatik - Professor Sommer's lectures are exactly what I was looking for by travelling halfway across the world, and I can't even put a price on some of the things I learned studying with him. The things that I have yet to develop will likely be some of the most advanced in my life.

I've also learned some very interesting things in CV, Neuro, Numerische Math., and yes, even Mathematical Logic!! Unfortunately, I have to give up my office, which is a bummer, but the change to Digital Communication will surely have plenty of benefits to make up for it ;-)

The best and most important part everything now, though, is enjoying the summer!!! I'm really looking forward to meeting up with all of my friends in Canada, seeing all of my family, and of course Erin too :) woohoo!

20070531

My experiences with Qemu - Part II

So I've managed to get this far with Qemu:

(qemu) Uncompressing Linux......................................................... done, booting the kernel.
Linux version 2.6.20.6 (cfriedt@sith) (gcc version 3.4.4) #35 Thu May 31 21:57:50 CEST 2007
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00003137
Machine: ARM-Versatile PB
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists. Total pages: 65024
Kernel command line: root=/dev/nfs nfsroot=192.168.7.1:/usr/gentoo_root,uid=0,gid=0,rsize=32768,wsize=32768,timeo=14,nfsvers=3,rw rw ip=192.168.7.2:192.168.7.1:192.168.7.1:255.255.255.0:qemu console=ttyAMA0,115200
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 258048KB available (1516K code, 174K data, 100K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PCI core found (slot 11)
PCI: bus0: Fast back to back transfers disabled
PCI map irq: slot 0, pin 1, devslot 12, irq: 27
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
CLCD: unknown LCD panel ID 0x00001000, using VGA
CLCD: Versatile hardware, VGA display
Clock CLCDCLK: setting VCO reg params: S=1 R=99 V=98
Console: switching to colour frame buffer device 80x30
Serial: AMBA PL011 UART driver
dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a AMBA/PL011
dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a AMBA/PL011
dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a AMBA/PL011
fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 38) is a AMBA/PL011
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
eth0: SMC91C11xFD (rev 1) at d080a000 IRQ 25 [nowait]
eth0: Ethernet addr: 52:54:00:12:34:56
mice: PS/2 mouse device common for all mice
TCP cubic registered
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation
input: AT Raw Set 2 keyboard as /class/input/input0
eth0: link up
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
IP-Config: Complete:
device=eth0, addr=192.168.7.2, mask=255.255.255.0, gw=192.168.7.1,
host=qemu, domain=, nis-domain=(none),
bootserver=192.168.7.1, rootserver=192.168.7.1, rootpath=
Root-NFS: unknown option: uid=0
Looking up port of RPC 100003/2 on 192.168.7.1
Looking up port of RPC 100005/1 on 192.168.7.1
VFS: Mounted root (nfs filesystem).
Freeing init memory: 100K
init: must be superuser.
Kernel panic - not syncing: Attempted to kill init!

It's looking fairly bright now ;-) All I have to do is figure out why (this has absolutely no real reason) Linux would start up as someone who isn't the superuser
... hmmf..

Weeee !!! I just added an init= option to the 'append' section of Qemu!!! sahweet!!! She's ready to roll ;-)

The option to enable 16-bit UID system calls must be selected as well, otherwise root (0) will get mapped to 0xffffffff (-1 in 2's compliment == -EPERM).

My experiences with Qemu - part I ... was "Building GNU Classpath for the ARM (Cont'd)"

Ok, so it looks like the external USB hard disk idea was not as good as I was hoping. The problem is that the board just has too little RAM !!! (to compile such a package as the GNU Classpath)

What happens in either the NFS case or the USB HD case, is that eventually the swapd and the jikes process enter this vicious cycle, where jikes caches the first half of what it needs to compile, swaps it out, and then caches the second half of what it needs to compile - clearly if it doesn't have 100% of the things it needs to compile in RAM (this occurred even without using -pipe) then it will enter an infinite loop (it would be nice if that was detected by jikes - i think that's CRC32 or something?).

In any event, with the suggestion that my boss Dave gave me, I'm now working on emulating an appropriate kernel, and using the appropriate uclibc-softfloat userspace for the ARM, using Qemu. This should solve all of my compilation woes because I would then be able to have enough actual physical RAM to compile everything natively. I believe that the VersatilePB platform available in Qemu has a limit of 256MB RAM though. That should be enough (I assume).

Aside from the target having a different name, the main other differences between the TS-7xxx boards and the Versatile PB are:

  • The Versatile PB uses an ARM926T chip instead of an ARM920T
  • The Versatile PB supports an SMC 91c111 ethernet device instead of the ep93xx device.
  • The Versatile PB names its serial devices /dev/ttyAMA[0-n] instead of /dev/ttyAM[0-n]
All of the exact details are here:

http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC53

Now, a brief overview of the differences and what they will mean.

  1. The ARM926T chip vs the ARM920T chip. To quote from the linux kernel help page:
    This is a variant of the ARM920. It has slightly different instruction sequences for cache and TLB operations. Curiously, there is no documentation on it at the ARM corporate website [EDIT: There is now].

    Say Y if you want support for the ARM926T processor. Otherwise, say N.

    I tried compiling for the Versatile PB without ARM926T support and that didn't even compile - it would be nice to have the ARM920T as an option here too. Anyways, that's not really a problem. As long as I can run Qemu with an ARM chip emulated and use an NFS root to compile, that's all that matters.

  2. eth0 is eth0 ... I doubt it matters what hardware is underlying for my purposes.

  3. Some scripts and applications will have to be aware of the difference of platform, if i end up coding scripts and things of the like on the emulator. I just as soon wouldn't, but it could be quite beneficial. In any event, that's not a real issue, it's as simple as replacing a string from my perspective. The cool part about that is that we could end up simulating our hardware, including the EM noise model - cool ;-)

I'll keep you posted!

20070527

Building GNU Classpath for the ARM (Cont'd ...)

I spontaneously decided to copy over the entire Gentoo stage3 filesystem to my external hard-disk, which is recognized as a general USB storage device under linux. NFS was taking waaaaay too long for this compilation. I had checked everything out with top, under linux, played with the swappiness parameter in /proc/sys/vm, and also attempted to renice the jikes processes' priority to a whopping 17! Non of those had a major effect on the cpu-usage of the jikes process. The highest that I'd seen it was 10% for a whole 2 seconds.

The problem lies with NFS root and the overhead associate not only with RPC, but also the fact that my swap was also on the NFS root, effectively squaring the complexity of the overhead. With my Gentoo stage 3 root filesystem located on a locally attached usb storage device, along with the swap file, the speed of compilation increased dramatically! The jikes process has just started and its already achieved 50% of the cpu time! That's up from an average of maybe 3% with the tweaking I mentioned previously.

I'd better mention this to Dave as well, so that he's not stuck ever repeating my stupid mistake of compiling on an NFS root!

Building the GNU Classpath for ARM

My preferred method now for building packages on the TS-7xxx series of single board computers (SBC's) is to use the gentoo stage3 filesystem as an NFS root, which comes with a C/C++ compiler and most of the necessary utilities. It is much slower, but this way I don't have to work around any strange cross-compiling issues or annoying pkgconfig native-executable requirements which tend to pollute configure scripts for most higher level applications.

The target I'm building for is an ARM 920T processor from cirrus - the EP93xx series of processors - which have only recently acquired a decent level of support in the Linux kernel. Also, as of gcc-4.1.1 the Thumb instruction set is supported as well, although I don't really use it. The ARM EABI is quite useful for those that require floating point functionality, but most of what my company does requires integer math for the most part. For that reason, the stage3 filesystem I use for my NFS root is the arm-softfloat-linux-uclibc stage3 filesystem located here:

http://adelie.polymtl.ca/experimental/arm/embedded/stages/stage3-arm-uclibc-softfloat-20050811.tar.bz2

However, please feel free to select any Gentoo mirror from this site:

http://www.gentoo.org/main/en/mirrors.xml

I've posted several sets of instructions for those that would also like to use the 2.6 kernel I've compiled for the TS-7xxx boards as well. If you're interested, please see the mailing list archives:

http://tech.groups.yahoo.com/group/ts-7000/message/6574

You can also download the kernel directly from here:

http://vaiprime.visibleassets.com/~cfriedt/zImage-2.6

and the config, here:

http://vaiprime.visibleassets.com/~cfriedt/linux-2.6.20.6.config

I recently changed my kernel configuration to include swap functionality, specifically because compiling the gnu classpath for the arm used over 3 times as much memory than was available on the board.

The tricky part though, is that Linux doesn't play very well with swap files on an NFS filesystem. But after doing a bit of googling, I found that there is 1 commonly used work-around.
# dd if=/dev/zero of=/mnt/swapfile bs=1024 count=$((1024*256))
# losetup /dev/loop0 /mnt/swapfile
# mkswap /dev/loop0
# swapon /dev/loop0

In the above section, I've created a 256MB swap file for the linux kernel, and it is accessed by the kernel through a loop device, which offers some apparently greater level of control than simply using swapon /mnt/swapfile.

I'm still compiling the gnu classpath, and I'm not sure exactly how far along the process is, but here are some of the memory usage figures:
=========================
MemTotal: 62192 kB
MemFree: 2728 kB
SwapCached: 12172 kB
SwapTotal: 262136 kB
SwapFree: 127772 kB
=========================

I'll continue to update this blog post as the compilation proceeds, but it's already been going for 2 hours steadily...

20070520

Progress with Work

I've accomplished several things for work - that is several programs compiled for my new uclibc root for the arm boards / TS-7xxx series - including

  • getting nfs-mounting to work
  • building / testing OpenVPN
  • building troll-ftpd (needs testing)
I've also started a document to release to the ts-7000 group on how to do this from scratch. The cool part is that all of the configuration data, patches, binpkgs, etc are simply stored in /tinygentoo/etc/portage /tinygentoo/etc/make.conf /usr/portage/local/overlay and /usr/portage/local/binpkgs.

Troll-ftpd was compiled all-right, but I can't sign in as root, even though I could with the TS distro. I think I might have to write another patch for ftpd.c so that it properly checks passwords without crypt().

I also re-built openssl, but it seems a little bit bloated with the gentoo installation, and with the new 'engines' structure. I'm hopefully going to get rid of all of that, because really, we don't need all of the ciphers and we definitely don't need any of the engines because we have absolutely no crypto-specific hardware. Have to figure out what's up with that, so i'm waiting to hear back on the openssl list.

Still need to create a custom ebuild for JamVM - or even get it to build for the arm under uClibc for that matter :p

Also need to create a custom ebuild for the GNU Classpath, considering 90% of it goes to waste on our boards (and it's just fat anyway).

20070517

Things on the To-Do List for work

I have to push a new filesystem and kernel, as well as installation instructions for work.

Currently, we're using the TS-7xxx boards, with a Cirrus EP93xx / ARM 920T processor, for our embedded devices. The trouble is, that the boards ship with a non-standard 2.4 kernel and the bloated glibc library. I've successfully compiled and installed the 2.6.20.6 linux kernel as well as a uClibc userland for the boards, but now I'm in the process of working out bugs and installing other software that is necessary for the basic functionality of our boards.

To-Do:
  • Make nfs-mounting work on the boards (recompile uClibc with full RPC, and then busybox)
  • Build OpenVPN
  • Build an FTP service
  • Build JamVM
  • Copy over the GNU Classpath that we have
  • Build Avahi
  • (etc, etc)
You may have guessed that this isn't such a small job. Anyway, I'm going to try to do quite a bit of it today.

Ciao!