VAI Prime Overlays Accessible Via Layman

After making my vuze-bin overlay accessible via layman, I decided to apply the same approach to my ts72xx related overlays on VAI Prime.

You can see the overlays via layman with

layman -o http://vaiprime.visibleassets.com/~cfriedt/layman.conf -i [overlay-name]

So far, the available overlay-names are as follows:

• jvmcp (Miniaturized Java environment suitable for the ts72xx boards)
  
  • custom JamVM (1.5.1)
  • custom GNU Classpath (0.97.1)
• vai (mainly custom apps for the ts72xx)
• custom JamVM (1.5.1)
• custom GNU Classpath (0.97.1)
• custom battery monitor
• maverick (overlays necessary for creating a EABI/MaverickCrunch toolchain for the ts72xx)
• patched binutils
• patched gcc
• patched crossdev
• patched uclibc
• ts72xx (overlay of applications for the ts72xx)
• patched fastjar
• patched busybox
• patched screen
• patched portage-utils
• patched bash
• patched java-config
• patched jamvm
• patched rxtx
• patched ant-core
• patched ant-eclipse-ecj
• patched eclipse-ecj
• patched gnu-classpath
• patched mpfr
• patched nfs-utils
• patched libnfsidmap
• patched openvpn
• patched dropbear
• patched wpa_supplicant
• patched binutils (2.15)
• patched gcc (3.4.6
• patched db
• patched psmisc
• ts72xxtc (binary-compatible toolchain for factory TS filesystem)
• patched glibc
• patched linux-headers

It would probably be wise to move at least the binutils and gcc from ts72xx to ts27xxtc.

Anyway, check out the overlay with

layman -o http://vaiprime.visibleassets.com/~cfriedt/layman.conf

Back in Montréal ! Happy St. Patrick's Day!

Wow, what a wild month this last one has been!

I guess my last post was just 2 weeks before when I started studying day and night for my DSP and Signals exams. Before then I was working a bunch on my most recent project for work, which has resulted in 2 main articles so far. Those are Gentoo for the TS72xx Single Board Computer (Full Distro), and Gentoo for the TS72xx (Old Toolchain). The first of the two links contains information on how to put the ARM EABI kernel and userland on your TS72xx board, for a 25 time speedup in floating point processing. The second link contains information on how to create a 'compatibility' toolchain for building software that is compatible with the existing programs and libraries on the board as it is shipped.

After I finish one small project for my company, I would like to write up some information on replacing glibc with uClibc, for added space savings.

Anyway, I just finished writing my two exams! I passed them both, although not by any means with outstanding grades. I suppose that has to do with several things: having less time to study than my classmates, having an actual engineering job (not some job as a lab assistant), moving from Germany to Canada the same week that the exams were being written, and just organizing things. So, needless to say, it has been a bit stressful.

In any event, I'm very happy to be back in Montréal! Erin and I have a new apartment too, with an excellent location right across the street from Parc LaFontaine. It's beautiful! Also, I can't begin to express how nice it is to see the sun again on a daily basis - Kiel gets nothing but cloud and rain in the winter. The snow is also a very welcome sight. I know that most of you in the area are pretty sick of snow, but believe me, if you had nothing but rain all winter, you would beg to have the piles of snow back, and you would be happy about it too!

Erin & I just came from the radiology department at St. Mary's hospital here in Montréal, and we got the 2nd round of ultrasounds for Julien. It was quite funny actually, I asked them if I could put the images on my USB memory stick instead of a CD and they said that was fine if I could figure it out (they have some custom made software which is a bit confusing). So I did it and showed them how to do it and they gave us the images free of charge! I'll put them up on something like Picassa soon enough.

Happy St. Patty's Day by the way! Dr. Shine, our obstetrician, is also from Ireland and I think that today he was pretty happy when we said happy St. Patrick's day to him too!

I also just figured out a problem I was having with linux-2.4.26 and glibc-2.3.2 trying to get the aforementioned compatibility toolchain working. The problem was quite simple - __NR_waitpid, which is a syscall constant, was being defined in the ARM/linux headers, but the function is actually unimplemented for the ARM and is replaced by wait4.

The effects of this bug were, for instance

• Bash saying "wait_for(): Function not implemented
• waitpid and popen not working, returning errno 83 (ENOSYS/Function not implemented)

The problem was easy to fix by simply removing the definition in include/asm-arm/unistd.h for __NR_waitpid. (see Gentoo bug 213690). It's not defined in the 2.6 kernel headers either, and I think it was probably put there by accident.

Error in glibc's select() function

While doing some programming for work, I discovered that the select() function provided by glibc does not accurately describe when data is ready to read from a socket.

The purpose of select() is to block on a file descriptor until data becomes ready, unless a specified relative timeout expires or an error occurs.

When data is ready, select will return a positive number corresponding to one of the sockets contained in one of the file-descriptor sets that were passed as parameters. If a timeout occurs, zero is returned. If an error occured, -1 is returned and errno is set appropriately.

I found that if select was called, a timeout occurred, then data became ready to read on the socket, if select was called one more time (after data has obviously arrived), then select fails to notice. That implies that glibc select() only checks for socket readiness whenever the kernel signals that the socket is ready, and not when it is initially called.

From the select(2) man page, there exists no such condition stating that the data must become available after select has been called and not before.

That's a major bug if I've ever heard of one. Hmm... it's too bad my project can't wait until the next release of glibc, when someone might have corrected this.