Hijack v336 is now out.

This version reverts to the original serial port behaviour by default: The player takes control of the serial port on startup again.

But.. when in DC/Car mode (only!), there is now a new Hijack menu entry to select whether the player, or an app (such as GPSapp), gets control of the serial port. When "App's" is selected, the player is restarted with the "-s-" parameter, mimicing the v335 Hijack default behaviour.

Serial programming is a big secret, in that it's hard to please all. Hopefully this works.

Cheers

Thanks for this new version! It's superb you made the player startup configurable!

However, I'm having some problems compiling the kernel from scratch. I arm running as root, and my $PATH includes /usr/local/armtools-empeg/bin (this is on Redhat). The armtools-empeg directory was untarred from the toolchain downloaded from your website. This is the same toolchain that I used to build Hijack v320 with successfully.

My method for compiling Hijack with the new patch format was this:

1. I downloaded v300.tar.bz2 from the Hijack website, and uncompressed it into /home/empeg/kernel
2. I downloaded every patch file from v300-v301 to v335-v336 and put them in /home/empeg/hijack
3. I chdir to /home/empeg/kernel and run zcat `ls ../hijack/*patch.gz | sort -n` | patch -p1. This runs fine with no errors.
4. I modify the /home/empeg/kernel/arch/arm/def-configs/empeg-car2 file to include what I want (actually I don't modify it as it already has CONFIG_IRDA=y) and copy that to /home/empeg/kernel/arch/arm/def-configs/empeg
5. I then run make empeg_config
6. Then I run make oldconfig. All the questions are answered for me exept for the command line, and I leave that blank (take the default)
7. Now I run make dep; make clean; make zImage. It fails at make zImage.

The specific error that I am getting is with time.c:

make[1]: Entering directory `/home/empeg/kernel/arch/arm/kernel'

...(compiles a few files fine, then)...

arm-empeg-linux-gcc -D__KERNEL__ -I/home/empeg/kernel/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -msoft-float -march=armv4 -mtune=strongarm110 -c -o time.o time.c
time.c:68: redefinition of `mktime'
/usr/local/armtools-empeg/lib/gcc-lib/arm-empeg-linux/2.95.3/../../../../arm-empeg-linux/include/linux/time.h:71: `mktime' previously defined here
time.c:86: warning: `do_profile' defined but not used
make[1]: *** [time.o] Error 1
make[1]: Leaving directory `/home/empeg/kernel/arch/arm/kernel'
make: *** [_dir_arch/arm/kernel] Error 2

I must be doing something wrong, so what is it?

I had to read it twice to understand that my empeg switched wildly around while getting new positions from my gps-mouse :-). I was wondering how much features you can control via the serial port. I have seen them all as I was driving home. So I switched manually to AC-Mode and all worked perfectly (why?). But now even me has found the additional function in the hijack-menu...

Next time I'll read twice before upgrading. JEmplode is too easy for upgrading, so you might forget reading what's new :-).

Thanks again for the new version.
Rolf

Switching to AC mode probably resulted in the baud rate changing to 115200, which would not normally be compatible with your GPS mouse, causing the latter to be mostly ignored. I think.

Cheers

Hi Mark, update on my problem, and a big THANK YOU!

I commented out the 'mktime' function in /usr/local/armtools-empeg/arm-empeg-linux/include/linux/time.h:71, and I got my kernel to compile successfully. I don't know why this function would be included both in the toolchain and the kernel, but I'm sure that it was probably something that I overlooked.

After I got my kernel compiled (with IrDA support, but not IrCOMM) I wanted to compare the sizes of the kernels to see how much bigger my kernel was with IrDA support than the stock Hijack kernel that did not include IrDA support (I thought). To my surprise, the stock kernel was bigger than mine! I loaded the stock v336 kernel on my Empeg, and I was very happy to see that IrDA support is included in the download from your webpage! THANK YOU very much for this! I will update my Palantir webpage with instructions to just download the latest version of Hijack in order to gain IrDA support.

If you are considering coming to the Cinci meet this fall, and would like to take some time to climb at the Red, I will be your guide and belay slave for the trip

Oh heck.. is IRDA on by default? Oh wait.. I see that it's a stock item from the original empeg sources, at least as of v2.00-rc1. Mmmm.. maybe I should turn it off in Hijack to save memory..

As for the "mktime" thing, what you did is fine. I vaguely recall some such problem here too, way way back...

Dunno about the Laurameet yet -- I'll probably leave it until the final moment again this year. But we're definitely "on" for climbing if I make it down.

Cheers

Oh heck.. is IRDA on by default? Oh wait.. I see that it's a stock item from the original empeg sources, at least as of v2.00-rc1.

Yeah, it was always standard in the empeg-car2 config file

Mmmm.. maybe I should turn it off in Hijack to save memory..

Ack! Maybe I shouldn't have told you about it . One thing you can do is turn off IrCOMM... I don't think there is anyone who is actually using it for anything, and it would save 9,304 bytes on the compressed kernel (dunno about memory footprint). IrDA and the OBEX stuff I'm doing work just fine without IrCOMM enabled.

>One thing you can do is turn off IrCOMM..

Done. Thanks.

Mark, I'm not seeing the new Hijack menu entry for the Serial Port behaviour, and I know that I've installed v336. I was browsing through hijack.c and I saw it there, but I'm not getting it in my Hijack menu on my player.

I've seen this entry by switching manually to DC-mode in the hijack-menu. The entry is named "serial port assignment" and is placed between the screen blanker and show flash savearea.

Rolf

How silly of me. Of course it would only be an option when you are on DC mode (car).

Thanks!

By the way: I don't know if it's a good way to only show it in DC-mode:

If I switch my empeg on in the car, just after booting the GPS-mouse makes the empeg unusable. So you can't access the menu to switch it off. As I've noticed this, I switched manually to DC-mode at home to switch to the "gps-mode".

Wouldn't it be better to point to the old style as default?

I doesn't disturb me, it was only a one-time action. But maybe there are other users who stumble into the same thing.

Rolf

Yeah, I thought about which way to make it default to.

And decided that, in the past, far more people have complained about it defaulting to NOT being able to control the player via serial, than those complaining about it the other way around.

So.. stock player behaviour is what you get by default, as many of us might expect it to behave.

I suppose I could have it recognize NMEA strings coming in, and auto-switch the serial to the other method.. but by then it's too late.

Cheers

>I suppose I could have it recognize NMEA strings coming in...

Wow, this would not even make life easier than to solve a problem with not enough serial ports on the empeg. You have a one-way-communication at 4800bps from the gps-mouse, so there might be enough space (it sends once a second) to control the empeg or (in further versions) sends a command from the car like "everything's ok" => www.ross-tech.com.

But this is future... Though, if it's not too much work, it would be perfect.

Rolf

Mmm.. The only problem I see with this is that the player will have already been started (and have taken over the serial port) by the time Hijack sees any NMEA coming in from an attached GPS.

So.. one problem is how to split the serial port, for which the solution is to create a second device entity that multiplexes into the serial driver, similar to the existing RDS userland hack. When Hijack recognises NMEA (or what else?) coming in, those lines get redirected to the second device, everything else goes to the player.

But wait, even better: with a second "device" for GPSapp to open/use, Hijack could just "disconnect" the player (blocking all serial input/output) whenever it sees a userland app open() the second device for use.

The only thing NOT caught by this would be the boot-up spewing of stuff out the serial link, and possibly a few lines from the player before GPSapp (or other userland app) gets going and opens the second device.

But that's probably not a big deal. And all this would allow me to rip out the serial port menu entry (no longer needed) in favour of this new automatic method.

What's everyone think of this idea? It looks darned near trivial to implement, but I could be wrong about that..

Cheers

So basically you are saying that if a userland app open()s the serial port for reading/writing, then you would shut off serial access to the player? Sounds like a good idea, but what would happen if another app tried to write to the player while the first app has control of the serial port? Would an error be returned? This is the only gotcha I can think of right now.

I'd like to see something like this, and I had a similar idea a few weeks ago; You're just actually likely to do something about it whereas I'm about to leave town and have no time

I'm not sure what you mean by "another apps tries to write to the player" . ?

The idea is to create a new device node, say.. /proc/ttyS0, which userland apps would open instead of /dev/ttyS0. Both of those map to the same serial port, but whenever /proc/ttyS0 is open, the player's /dev/ttyS0 stops sending/receiving data out the back of the empeg (still works internally for Hijack notify and Hijack serial commands though).

Cheers

Ahh, perfect. This sounds like a smashing idea. I was just thinking that /proc/empeg_notify would no longer work once the redirection has taken place, but that isn't the case. Great idea!

Hmm, the time after booting and before Hijack hijacks the player could resolve in unwanted controls from the gps-mouse, right? In worst case it marks my best songs for deletion. And if I believe Murphy I won't recognise them as marked before I delete those songs. Bye... I've seen my gps-mouse controlling my empeg, many songs have been marked so quick.

Rolf

When your player boots, it boots Hijack. Hijack is the kernel, so it is what controls the data coming in from the serial port from the beginning. After Hjijack sets up all the rest of the hardware, then IT starts the player. So your problem will not exist anymore.

Thanks for this reply, I was very unsure if the kernel at the Empeg is not to be seen as a kernel on my linux-machine. Now my world of kernels is ok again ;-). Kernel is kernel.

Rolf

But wait, even better: with a second "device" for GPSapp to open/use, Hijack could just "disconnect" the player (blocking all serial input/output) whenever it sees a userland app open() the second device for use.

The only thing NOT caught by this would be the boot-up spewing of stuff out the serial link, and possibly a few lines from the player before GPSapp (or other userland app) gets going and opens the second device.

But that's probably not a big deal. And all this would allow me to rip out the serial port menu entry (no longer needed) in favour of this new automatic method.

Looks like you never did this. Did it turn out to be difficult or just fall off the list?

Yeah, I forgot about it.

It looks to be really really easy so long as we never want to hand back the serial port to the player. So, once any app opens the port, the player will lose it forever. Agreed?

Cheers

It doesn't seem like a high price to pay, but let me ask this: will the player still get input written to it via /proc after it loses the serial port with what you have in mind?

Yes, it better!