One of my goals for my Empeg Logo Editor has been to eliminate the need for a manual power-cycle when you send a logo to the Empeg. Removing and re-inserting the power connector causes wear and tear-- it would be more efficient if the software could reboot the unit to begin the flashing process.

To that end, I've been researching the way that EmpegUpgrade goes about rebooting the player to perform an upgrade. I spent some time looking at the emptool source code, but despite what I learned, I was unable to get my modifications to download.c working at all.

So, as the old engineer's saying goes: "When all else fails, use brute force".

I packet-sniffed the serial output from EmpegUpgrade.exe. Now my "upload.exe" program just sends those bytes blindly to the serial port. And on my player, on my test system, it seems to work just dandy. It reboots the player, then the player accepts the upgrade. All seems well.

My concern is that I've got absolutely no clue what those bytes are telling the player to do. There is one big 279-byte packet that really concerns me. I haven't gone through it byte-by-byte to see what it's sending. For all I know, it could be incompatible with Mark2 players, it could be serial-number-specific data, it could be the dimensions of the Playmate of the month, I don't know.

So here's what I'm asking, anyone reading this: If you're the type who's not afraid of doing something risky to your player, would you mind testing my code for me? In theory, the worst that can happen is that you'll need to re-apply one of Empeg's .upgrade files if this does something horrible. But I'm not sure what it'll do on someone else's player, so there's some risk involved.

Are you game? Cool! Here's what to do.

- Download and install version 1.1 of my Empeg Logo Editor. Make sure it works for you as-is, and that you can send logos to the player without a problem. You will have to manually unplug and re-plug the power to send a logo.

- Download and unzip this replacement file attached to this message. Copy it over the existing one that came with the original logo editor program.

- Try sending some logos with the new file in place. If all is well, it should be able to send a logo to the player without the need for a power pull.

- Lemme know if it worked! (If possible, tell me your system configuration and the type of Empeg you're using. Hopefully, I'll get responses from both Mk1 and Mk2 owners on several OS's.)

If I get positive feedback, the next release of the logo editor will incorporate this change.

Now, on to the advice...

Does anyone know what the heck EmpegUpgrade is sending before that reboot? Everything I read in the Emptool sources indicated that it should only need one tiny little packet, only about a dozen bytes long. But I couldn't make that work, so I had to send a huge 279-byte packet in addition to a few small ones. Whazzup with that and am I doing anything dangerous?

___________
Tony Fabris

Works fine on my system, Win98SE (swedish) w/ complete
Office2000 and DevStudio.

Empeg MkI

Doesn't look as if it scrambled anything else either...

Sweet. Thanks!

Anyone with a Mark 2?

___________
Tony Fabris

I did some printouts in JEmpeg during the call to ProtocolClient.restartPlayer (there is a similarly named class+method in emptool). Here's what gets sent/received:

Sent: CommandRequestPacket
Recv: CommandResponsePacket
Sent: PingRequestPacket
Recv: ProgressResponsePacket
Recv: ProgressResponsePacket
Recv: PingResponsePacket

So the size of the packet comes from the definition in packets.h of tagCommandRequestPacket, which is:

typedef struct tagCommandRequestPacket
{
EmpegPacketHeader header;
int command; // COM_RESTART
int parameter0; // RESTART_PLAYER
int parameter1; // 0
char parameter2[256]; // NULL
} CommandRequestPacket;

So there's your packet -- it should be a little more than 300 bytes I think.

Good luck -- let me know if you need more info.

Mike

Actually, there's a little bit more detailed data needed than that, but I don't think that it needs the entire 256 bytes of that string, does it?

(If it does, then damnit that was my problem all along!)

Prior to the packet, theres a PSOH command byte, bytes to tell it that it's a command packet and what size the packet is. Then at the end of a command packet, you need a 16-bit CRC, too. And prior to that command packet, you have to tell the player to start listening for a packet to begin with, and I haven't figured out that code. But from sniffing the serial port, it looks like sending 0x19 0x0D will get the player to start listening.

Maybe I'll try padding that string out to all 256 bytes and see if my old code works. If so, it'd be cleaner than what I've got. Well, except for getting the CRC implemented. Damn this is messy...

___________
Tony Fabris

Sweet. Thanks!

Anyone with a Mark 2?


Yup, works fine on my Win2k box.
(logo, and kernel)

________
Donato
MkII/Blue/40GB/080000565

I believe you do write the entire 256 bytes out (all zeros in this case). Here's what the packet looks like:

Packet Header (every packet has this):
1: PSOH
2-3: data size (num bytes in packet body, 268 in this case)
4: opcode (0x0C for command)
5: type (0x00 for request)
6-9: packet ID (unique counter for packet; starts at 42)

Command Request Packet
10-13: command (0x00 - restart)
14-17: param 1 (0x01 - restart player)
15-18: param 2 (0x00)
19-274: empty byte array

Closing:
275-276: crc

Yup, that's what I'd figured out, except I thought the empty byte array was variable length. I'll try it again with a fixed-length array and see how far I get...

___________
Tony Fabris

Yup, works fine on my Win2k box. (logo, and kernel)

Cool. I found a bug where sometimes you get garbage on the screen after the upgrade (goes away after a power pull), so I'll play with that and see if I can fix it as well.

___________
Tony Fabris

That's funny, I tried your upgrade last night and had the same problem. I didn't reply to your request earlier because I thought it was my kernel causing this behaviour. Have you got the default kernel running ? Now after every soft-reboot ( reboot -f in shell ) the garbage appears....
I had the same garbage when I deleted the IP-information in config.ini ( see bug-reports ), but this was only once and the empeg rebooted OK after power-loss
I've got an MK2.

Frank van Gestel

Now after every soft-reboot ( reboot -f in shell ) the garbage appears....

If you do a power pull, does the problem go away for future soft-reboots, or did my upload permanently damage your player? If the latter, does a developer/consumer re-upgrade solve the problem?

___________
Tony Fabris

permanently, I allready tried installing a different kernel, which didn't help. I don't know if your upgrade caused this behaviour; I had the display garbage before and didn't do a soft reboot in a while.
BTW, I uploaded the logo with the default bitmaps of empeglogo

Frank van Gestel

I believe you do write the entire 256 bytes out (all zeros in this case).

Damn, that was my problem. You're right. Now I can build a packet properly and make it reboot the player. It works. Thanks for that clue. The only other piece of information I needed was that the player needs to be send 0x19 0x0d as an "Attention" signal to get it to listen for the packet.

One thing: Where you said param1 should be 0x01 (restart player), for my purposes it needed to be 0x02 (reboot unit) instead. But I'd already known that.

Now, on to the garbage-screen-after-soft-reboot problem...

___________
Tony Fabris

Frank, I've been experimenting with the garbage screen problem.

If I install the 1.01 .upgrade file (in my case, developer 1.01 but I don't think it matters), then do a power-pull after the upgrade, everything is fine after that.

But if I install RJlov's volume adjustment kernel after that, then I get the garbage screen with every soft restart after a logo flash. I don't know if RJlov's kernel is the cause or if that's just a coincidence.

It is possible that the test version of my upgrade.exe did something bad, since I was blindly sending "monkey-see-monkey-do" packets to the serial port. Attached to this message is another version of upgrade.exe that does the absolute minimum necessary to reboot the unit. Could you do me a favor?

What I'd like you to do is:
Install consumer 1.1, full-power-cycle the unit, use this new upload.exe to send a logo, and then tell me if your garbage screen problem is gone. Would that be OK?

___________
Tony Fabris

Oh -- sorry I forgot about the 25,13. This is sent at the head of a ping and a quit request. A ping is typically the first thing you do, so this is probably secretly the "wake up" bytes. Incidentally, this is "%". If you do this on the serial console, you probably can start sending packets to it yourself.

So usually, you would do a {25,13} then send a PingRequestPacket and get a PingResponsePacket (to make sure the Empeg is on the connection), then you would send your CommandRequestPacket (and it would send you a CommandResponsePacket)

I installed developer 1.1 and the problem is gone. The kernel I had used was a standard one with extra features:
- IP-firewalling
- IP-aliasing
- IR-Lpt
it also had my IR-hack. As I had some reply from borislav about the patch, I realized I had made some big mistakes.
I'll try to resolve them. I do not think it was your uploader that caused the initial problems, it was just the fact a soft reboot was triggered.
Now we've got to isolate the problem as I do not think that RJlov made the same mistakes in his kernel-patch as I did.
Is there a maximum size on the kernel image? After all, it is flashed into a limited amount of memory; what is the maximum size a kernel-image can be?

Frank van Gestel

Interesting.

I was just corresponding with Richard, and he doesn't think it's a size problem. He suggested that it might possibly have something to do with the way you guys are building the kernels, but he's not sure.

The next test is to build a plain-vanilla kernel from Empeg's pure sources and see if that induces the problem. If it does, then I'll see if I can grab just a plain kernel file from Mike and we'll go from there.

___________
Tony Fabris

By the way, where is the source to the kernel that is in the current empeg release (1.1?)

All sources should be at www.empeg.com, somewhere in the "support" section.

___________
Tony Fabris

Right now I'm running a kernel with both RJlov's patch and your IR hack. I have initiated a soft reboot a couple times and have not gotten the garbage screen. I have not used Tony's editor to send a custom image to the player. I'll try that out a little later and see if anything changes.

Brian

-Finally received my Mark2 no thanks to customs.

[Right now I'm running a kernel with both RJlov's patch and your IR hack. I have initiated a soft reboot a couple times and have not gotten the garbage screen. I have not used Tony's editor to send a custom image to the player. I'll try that out a little later and see if anything changes.

Remember that a simple "r" sent to the player doesn't induce the problem for me. I only get the problem when my flash-uploader utility sends the "r" immediately after the flash upgrade. This may have something to do with it, but I don't know.

(Yes, I've tried inserting a pause after the flashing, it doesn't change the results.)

___________
Tony Fabris

I just tried to use the logo uploader and under Windows NT machine I had some problems. It kept repeating something about zero bytes read and com port may need to be reset. But it did eventually reboot the player and the logo I had on had not changed. I tried this a couple times and never got the garbage screen. How often have you gotten the garbage screen?

-Finally received my Mark2 no thanks to customs.

I just tried to use the logo uploader and under Windows NT machine I had some problems. It kept repeating something about zero bytes read and com port may need to be reset.

This happens to me if I use EmpegUpgrade.EXE before running the logo editor. Seems to only happen on NT. Reboot the Empeg, open HyperTerminal and connect to the empeg, then close HyperTerminal. That'll reset the Com port and then the logo editor will work after that.

I'm going to have to figure out why that happens and see if I can get upload.exe to just do that com-port-reset itself every time. But that problem is unrelated to the garbage screen problem.


How often have you gotten the garbage screen?

Every single time, but only under the following conditions:

- A third party kernel is installed instead of the default Empeg one.
- A reboot packet was used to reboot the Empeg in preparation for a flash upload.
- Immediately after the flash upload completes, an "r\n" is sent to the empeg to make it reboot again.

Any of the following conditions will prevent that garbage screen from appearing:

- The default Empeg software is on the unit (no third-party kernels).
- The Empeg was booted with a physical power-pull in order to get the flash upload started.
- The r\n is sent when the player is in normal playback mode (i.e., it's playing a song rather than sitting there doing nothing after a flash upload).

___________
Tony Fabris

I had it every time I used reboot -f from the shell.
I only ran Tony's logoedit once. I have replaced the init-shellscript with the standard one and resetted config.ini to default values. No results. I compiled the kernel on the empeg itself, maybe that could be the problem.


Frank van Gestel

small addition :

This problem started a week ago with a modified kernel with
IP-firewalling, IP-aliasing & IRLPT enabled.
I reported a bug in the bugs forum that if no values were set for IP-information in config.ini and dhcp was set to 0,
the problem would occur. If they were set properly, the display would stay correct after soft reboot. Since then I only edited drivers/char/empeg_ir.c. The constant display-garbling after soft reboots started around the time I had used empeglogo.
I will try to install a custom kernel again and see what happens.

Frank van Gestel

This problem started a week ago with a modified kernel with IP-firewalling, IP-aliasing & IRLPT enabled.

Oh, good, then it's not my editor. Because I didn't implement anything special in upload.exe until yesterday. Prior to yesterday, upload.exe was just a port of download.c with different text messages. All I've added in the last couple of days is the soft rebooting stuff, and if my guess is correct, it's only giving us a chance to see the problem, rather than being the cause of it.

If there's something about upload.exe that caused the problem, then download.c would have caused it as well, I think...

Hopefully Mike will be able to help me clear this up tomorrow.

___________
Tony Fabris

I have now successfully used logoeditor at home on my 98 box. And as I said I have a custom kernel I compiled. The uploader reboots the player loads the new image and finally reboots the player again and I do not get the garbage screen. I have used the program four times and haven't seen the garbage screen once.

Brian

-See my empeg here-

I installed my custom kernel, I have used Tony's uploader, and the problem hasn't occured yet. I rebooted 5 or 6 times...

Frank van Gestel

I have used Tony's uploader, and the problem hasn't occured yet.

Remember that the original uploader that's on my web site (v1.1 of Logoedit) isn't the one that induces the problem I'm worried about. The problem only happens when using one of my new test uploaders (two versions of this are linked in messages in this thread) to soft-boot the player at the beginning of the upgrade process.

Are you referring to the new upload.exe or the one that shipped with v1.1 of Logoedit?

___________
Tony Fabris

I have used the program four times and haven't seen the garbage screen once.

Remember that the original uploader that's on my web site (v1.1 of Logoedit) isn't the one that induces the problem I'm worried about. The problem only happens when using one of my new test uploaders (two versions of this are linked in messages in this thread) to soft-boot the player at the beginning of the upgrade process.

Are you referring to the new upload.exe or the one that shipped with v1.1 of Logoedit?

I get the garbage screen every single time on both my NT4 and 98 boxes.

___________
Tony Fabris