I've just been playing with v116.

Now that kernel ftp support is on place I was wondering if this suggestion for a potentially useful Hijack request might be useful to others.

I suggest that we add a special device either to the kernel or [more simply] just have a special device name reserved within the ftp process in the Hijack kernel that allows us to upload .zimage files to the empeg via ftp.

This special device name is used by the hijack kernel to upload the zimage files containing the kernel image to be flashed.
The zimage file being ftp'ed is then 'received' by the kernel and buffered [in memory as the disks are probably mounted ro] .
Once the zimage file is all received its then checked for validity [doing some basic checks on the .zimage file - I am not sure what if any checks are done other than its a empeg kernel image].

Once the file is verified as all ok, the kernel then opens /dev/flash [and whatever devices] and does whatever Tony Fabris's upload program does to erase and reprogram the kernel flash area - but this is done on the empeg, by the kernel itself. So it becomes a self-flashing system.
[then of coruse it reboots itself].

This would mean that we could upload future upgrades to the kernel ala Hijack by simply ftp'ing the zimage file to /dev/kernel_flash or whatever its called.

I would rather that the kernel do this as its available 'in the box' once you have a Hijack kernel later than v117 or whatever implements this feature.

For major upgrades that changes files on the Empeg then the emplode upgrade process would still be used, but for the kernel changes in between these releases being able to ftp the files would mean we can install hijack kernel updates in empegs even if they are in the home docking stations etc.

I've seen other embedded devices offer similar capabilities and the usual caveats apply - like if you lose power half way through - but the same caveats apply now via the serial updates.
In my experience provided the flash routines are pretty failsafe theres not much that can go wrong.

Any comments?

I agree with the idea, I would like to loose the serial connection for most purposes. However, this would probably only be useful for the Hijack uploads themselves as the full .upgrade file does more than just reflash.

It would be a nice feature but it is down to Mr Lords Copious Free Time.

I second this!

The ability to install upgrades over USB and Ethernet using the upload-then-self-flash method is something that the empeg guys have been planning on implementing natively for a while now.

The HSX-109 already does this quite well, it can even go out and grab the latest version from the web via broadband ethernet link.

Dunno when we'll see it happen on the car player, but the fact that it works on the HSX is promising.

>I suggest that we add a special device either to the kernel
>or [more simply] just have a special device name
>reserved within the ftp process in the Hijack kernel that
>allows us to upload .zimage files to the empeg via ftp.

Well.. this turns out to be extremely easy.. since the Empeg boys have already done it for us (Thanks, Hugo!).

Flashing A Kernel via Ethernet:

(1) Prepare the player: this needs to be done just once:
-- install the developer software image
-- install a Hijack kernel (v119+ recommended) the "hard way", and reboot.
-- login over the serial port (hit 'q').
-- type this command:rw && mknod /dev/flash_kernel b 60 8 && ro && sync && exit

(2) Once you have done the prep work (once ever per Empeg unit.. dunno if upgrades will wipe it out or not), you can flash new (Hijack!) kernels at will using FTP:

-- ftp empeg
-- put zImage /dev/kernel_flash
-- quit

(3) wait 10 seconds (the flash write may happen asynchronously).

(4) reboot the empeg from the Hijack menu, or by cycling the power.

Cheers

-ml

On further experimentation, this seems to have a success rate of about one in two or one in three.. not sure why. But worst case, one might have to reflash the kernel via the serial link.

You can verify a freshly programmed kernel by reading back from /dev/flash_kernel over FTP.. the file you read back will be larger than the original kernel zImage, so only compare the bytes up to the size of your zImage file.

-ml

Okay, after playing with it some more, it appears to be just a "sync()" issue. I've added a "sys_sync()" invocation to Hijack v120, which will get done after each FTP session finished (after you QUIT from FTP). But even without it, things are reliable enough so long as one does a readback after writing to flash.

For my own use, I have a shell script that ftp's a kernel to the empeg, reads it back again, and compares the readback to the original. Works great! Much faster than the slow serial downloads..

FTP burn & verify shell script (UNIX) attached.

-ml

Step 2 has a typo, should be /dev/flash_kernel

Mark, mind if I throw this stuff on the developer info section on riocar.org?

Go for, if you haven't already.

Especially the shell script.. that's how I download new kernels for testing nowadays.. MUCH faster than serial.

-ml

We should probably put the correct device nodes on the player in the first place... I'll make a note for the next release...

Hugo

Yeah.

For now, hijack just creates a device node under /proc/ so that everyone has access to it without fiddling.

/proc/empeg_kernel

Cheers

-ml

Hi Tony,

FYI.

When you put this on RioCar.org you put the typo in step 2 aswell.

I have tried this using cuteFTP Pro 2...No luck.

If I CWD to /dev, I do not see the flash_kernel folder to put the zImage file into.

Any suggestions?

This has since been changed to /proc/empeg_kernel. The dev entry had to be manually created to be able to flash it.

Huh ???

I don't seem to have a /proc/empeg_kernel either.

In /proc I have load of directories from 1 to 7 , 25-39 and bus,fs,ide,scsi etc.....

This never seems to work for me, is it perhaps an ascii vs binary problem?

Assuming you have a very recent Hijack kernel installed, you should be able to flash the next (newer) ones using:


ftp myempeg

binary
put v135.hijack...zImage /proc/empeg_kernel

If this fails, then try pausing your music player while flashing (hit pause on the remote first). Replace the "v135.hijack...zImage" with the actual filename of the Hijack kernel.

If you can burn a kernel over the serial link, then the above will also work. Unless you're using one of those windows ftp clients that crashes hijack (bug I just fixed in v135, so okay after that..).

Cheers

If you don't see /proc/empeg_kernel on your player (not your host), then it's because (1) you don't have Hijack installed yet, or (2) your version of Hijack is too old, or (3) you're going blind from too much personal self-adoration.

-ml

Hey that works now!!!

Thanks!

Oooo, ya cheeky monkey(3).

Well I CAN see it when connected serially, not through cuteFTP though..

Why would that be?

>Well I CAN see it when connected serially, not through cuteFTP though

Well, /proc/empeg_kernel is configured as a "block device", which perhaps your "view" options in CuteFTP are set to ignore ("hide system files" or some such thing..).

-ml

Hmm I thought that...checked.... it says show hidden/system files?????

So I downloaded SmartFTP (seems good and is freeware) same thing, no /proc/empeg_kernel. Checked the view settings, same thing. All looks OK but can't see it.

Should a block device show up as a folder or file?


Oh, and another thing, sorry but initial.C still does not work for me in the latest build.

Thanks,

Mr Whinging Git (UK)

Devices should show up as "files".

Getting your GUI to work properly is your problem.

Cheers

Hi.

Might be a completely stupid question, but as /proc/empeg_kernel shows up in SmartFTP on my empeg with the latest hijack kernel: Did you reboot the player after flashing the new kernel?

cu,
sven

>Oh, and another thing, sorry but initial.C still
>does not work for me in the latest build.

Okay try initial.H and initial.C in v136.

In particular, I've noticed the player seems to toss the first few IR codes after startup, even when they come from the RIO remote directly.

So.. just prefix your initial sequence(s) with ffffff.L,ffffff.L and then they should work fine (they did for me).

initial.C=ffffff.L,ffffff.L,20bf1c,...


Does anyone else use this feature? It's causing me a ton of grief and I'd like to remove it..

Cheers

-ml

Hi Mark,

Perfect, all of my problems are solved. I can now see /proc/empeg_kernel, I can replace it and it flashes.

With v136 initial.C and initial.H both work perfectly (maybe you could leave them in now?)

I am sorry they were causing you a headache. I promise not to bother you for another 3 revisions of Hijack (propably 12 hours or so.)

Keep up the good work.

This may be a dumb question but, can this be used for the .upgrade files too?

Uploading hijack is not that slow, but upgrading the main kernel is very slow.

It cannot currently be done for .upgrade files, the only way of applying them is via the serial port. In theory code could be added to the kernel to enable .upgrade files to be applied via Ethernet as well, but I doubt if that is likely to ever happen.

I think it would be a neat feature to add to hijack. Temporarily unpack the upgrade file to empeg/var, replace the player partition, then remove the temp file from var.

The only tricky part is that hijack would be unable to flash itself out of existence to replace the kernel contained in the upgrade file. This would actually be OK if you made sure the .upgrade file and the currently-installed hijack were compatible.

Actually, the kernel currnntly DOES flash itself "out of existance" with the existing mechanism.. the flash copy can be replaced while running with no issues.

An ethernet upgrader is not so much a Hijack project, as a project for the platform from which it will be run (Linux, Windows, Java). The bits and pieces needed to support it are already mostly in place in Hijack (or perhaps ALL of them are in place).

(1) overwrite a filesystem with a new image: just FTP to /dev/hd*

(2) upgrade kernel: already there

(3) reboot: already there

I'm not that familiar with the other steps.. what else is there?

Cheers

Actually, the kernel currnntly DOES flash itself "out of existance" with the existing mechanism.. the flash copy can be replaced while running with no issues.

True, but what I meant was this: The factory ".upgrade" files contain a kernel that isn't a hijack kernel. If you used the enclosed kernel and flashed hijack out of existence, then this hypothetical tricky ethernet upgrade mechanism would work exactly once, after which you're back to using serial.