The new jEmplode supports auto updating of your Hijack kernel (finally got tired of constantly checking ) and uses Mark's addition of uploading Logos w/ Hijack (very cool and seems to work great!! Thanks alot!).

For Autoupdating:
0) You have to have _some_ version of Hijack already installed
1) Go to Tools...
2) Go to Options ...
3) Select "Use Hijack when Possible"
4) Select "Autoupdate Hijack"
5) Put in mk1 or mk2 and empeg kernel version (read the tooltip attached to the labels for more info). Just leave these alone if you're running mk2 w/ the latest kernel.
6) Close Options
7) Restart jEmplode (or close and reopen a connection to your Empeg). The autoupdater will run just prior to downloading the database from your Empeg after you select the connection from the dialog.

To update, but not automatically:
0) Have some Hijack already installed
1) Connect to an Empeg
2) Tools...
3) Update Hijack Kernel

To upload logos w/ Hijack
0) Have Hijack installed
1) Tools...
2) Options...
3) Select "Use Hijack when Possible"
4) Close Options
5) Tools...
6) LogoEdit
7) Do your business
8) File..Upload to Empeg
9) BLAMMO!

Mike

Incidentally, autoupdating is heavily dependent on the page contents and naming conventions of the Hijack website.

Hey Mark -- what do you think about a text file on your site that just contains the name of the latest version. Also, is that filename format going to stay the same (i.e. v<version>.hijack.v<kernelversion>.<mk1/2>.zImage) ?

Mike

Nifty features! But when I was getting ready to try them out, I noticed the following bug in the options screen:

Just tried out the auto-update feature and it rocks.

One feature request: Optionally have it reboot the player (with the http://empegaddr/?reboot command) when the kernel-squirt is done.

Speaking of that, by the way:

Mark, why are there two long stalls or pauses during FTP uploads of new kernels? I've noticed it both when using the Internet Explorer FTP extensions to send a kernel, and now the same thing when using Jemplode to send a kernel.

In both cases, two stalls happen. One at about 1/3 of the way, and another at about 9/10 of the way. The FTP upload seems to temporarily stall for about 5-10 seconds each time. After the stall, the upload then continues normally. These stalls (in the past) prompted me to pause/unpause the player when they happened, until I realized that nothing I did to the player would change the behavior of the uploads, the FTP stalls still happened.

I assumed this was an effect of buffering (i.e. it quickly reads a large chunk into a buffer, then slowly writes it to the network/flash). Just a guess though ...

Whoops I double-added that entry ... curious result. I'll put up a new version in a sec after I add reboot-after-update.

OK -- You got your reboot (though it uses ProtocolClient.restartUnit(..) as opposed to Hijack reboot, since the empeg reboot will allow me to wait until it's fully restarted -- interestingly, waitOnPlayer immediately returned with a Hijack reboot).

I just downloaded the absolutely bleeding edge version of jemplode20.jar (2002-03-09 11:something Eastern) and tried to upgrade Hijack from 230 to the latest (235). It checked the versions, downloaded the kernel, uploaded it and - nothing, empeg stuck. After power cycling serial shows is stuck after 'Calling linux kernel...'. Obviously, the kernel got corrupted somewhere along the way

Ah, well, I didn't do old fashioned upgrade in a while....

What was the last jEmplode message you saw? Rebooting Empeg, or something else?

'Rebooting empeg', 'Waiting for empeg to reboot', something lige that.

Same here...

Check the log:

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux.............................................................
..................................................(data abort vector)

What version of Hijack are you updating from?

I did from V234 to V235!. But now it does not boot up anymore.... I have an MK2.

I wonder if that reboot after update is hosing it ... Maybe the reboot is happening too soon after update.

Your gets a bit further, it actually bombs.

Boohoo, I just discovered I haven't kept my 'restore_root.sh' script up to date. Well, remembering yet another thing to re-install the whole evening will teach me to be more pedantic about this!

230

I'm going to pull this version till i can figure out why people are getting corrupted kernels .... It will be back soon

Just downloaded and tried the new Beta for the first time. Worked flawlessly.

The one thing I can't figure out is if there is a way to add track number to downloaded file names... What's the {syntax} for that? If it exists, how does it work? Does it take the track position in the list and use that or does it take it directly from the tag?

- Thanx
- Jon

http://www.jempeg.org/tagNames.html

Oops. Missed that. Thank you!

- Jon

OK guys -- The open-source FTP client I was using was either a little screwy or I wasn't using it properly. Regardless, I've switched it out for another client that seems to be much more reliable (for me anyway). Give the new version a shot and see what happens.

After you get a working kernel back on, if you're daring enough, try the new version You should be able to use jEmplode to serial-update your Hijack kernel back on (that's what I do when I hose my player up). You'll want to turn off the Tools..Options...Use Hijack When Possible prior to doing a Tools..Upgrade Empeg.

Mike

>Incidentally, autoupdating is heavily dependent
>on the page contents and naming conventions of the Hijack website.

>Hey Mark -- what do you think about a text file on your site that
>just contains the name of the latest version. Also, is that filename
> format going to stay the same (i.e. v<version>.hijack.v<kernelversion>.<mk1/2>.zImage) ?

I expect the filename format to remain the same, but it would be best not to depend upon it. To help with that, perhaps I could add a NEWEST_VERSION file, which contains two lines with the filenames of the newest version in it. eg.

## Newest versions for auto-updating:

v235.hijack.v2b11.mk1.zImage

v235.hijack.v2b11.mk2.zImage

Just ignore the top line. Okay?

The pauses/stalls during the kernel FTP are in the flash-empeg.c driver code. It can only write the kernel in chunks of 64KB, so it sits there collecting and reordering packets until it has a full chunk to write out, and then writes it. The pauses are the flash write time (and possibly a read-modify-write sequence for the tail end).

The first couple dozen writes of new kernels take only a couple of seconds, after that the flash slows down and takes longer, and longer, and longer, and.. after 10000-100000 writes just never finishes anymore.

Cheers

Basically, you have to hang around long enough for the flash update to complete before issuing the reboot. The simplest way to ensure that this happens correctly regardless of client, is to read back the kernel after writing it. Readback only takes about a second or so. And while you're at it, you might as well compare the readback with the file that was written.

Cheers

Okay, the NEWEST_VERSION file is now on the server, and in my install scripts for subsequent updates.

Cheers

Cool -- thanks

No problem. Now if only the BBS would pick up my new image..

Getting the new image fine here Clear your cache.

Well, it's working now, but the BBS was definitely generating pages that referenced the old (non-existant) one for quite a while after I changed it (I even tried with a different browser, to negate any possibility of caching issues here).

So I just linked the new image to the same name as the old one, so that they both "worked" during the transition period (however long that was).

Cheers

The zImage for 236 = 511940 bytes

If I download /proc/empeg_kernel back off, it is 655360 bytes.

This is on a succesful update ... Am I getting the gunzipped version back off, or something?

Mike

The read-back will always be exactly (640 * 1024) bytes. Ya just have to compare from the beginning only the number of bytes actually sent.

Cheers

Just compare the first <kernel length> bytes. The rest is trash.

(640 * 1024) == size of kernel flash area. Reading it returns the whole thing, since there is no marker to say how much was "used". Current kernels are about 120KB smaller than that.

Cheers

/proc/empeg_kernel will give you the entire flash space no matter what is currently there. My hijack update script that I grabbed from here does this at the end to compare the two:

echo "Readback kernel.."

/usr/bin/ftp ${IPADDRESS} >/dev/null <<-EOF



        get /proc/empeg_kernel ${TMPFILE}

        quit

        EOF



KSIZE=`/bin/ls -l ${ZIMAGE} | awk '{print $5;exit}'`



echo -n "Comparing ${KSIZE} bytes.. "

dd if=${TMPFILE} bs=${KSIZE} count=1 2>/dev/null | diff ${ZIMAGE} -



if [ "$?" = "0" ]; then

        echo "Success!"

else

        echo "FAILED ($?) -- try again!"

fi

rm -f ${TMPFILE} 2>/dev/null

Thanks guys ...

Works flawlessly now (as you know). Thanks! (Comparing sent and received kernel image is a bit slow, but that's a small price to pay for reliability.)

Thanks for new 'parent playlist lookup' features, too.

Yeah -- I'm going to work on the comparison speed ... I think I'll just calculate a CRC while sending and a CRC while receiving and just check that as opposed to downloading the kernel, writing to disk, reading both of them back in and comparing them ... Kind of wasteful.

Mike