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

I've been using the uploader included in 4-20204-UploadRebootTest.zip

Brian

-See my empeg here-

I've been using the uploader included in 4-20204-UploadRebootTest.zip

Interesting. There is a slightly newer one here that I posted earlier today that works slightly differently. Just for ha-ha's, do you wanna try that one and see if it induces the bug? If the first one didn't, then this one shouldn't either, I just wanna be sure.

___________
Tony Fabris

That newest version works great. Didn't have to manually kill power to load images. And again no garbage screen.

Brian

-See my empeg here-

That newest version works great. Didn't have to manually kill power to load images. And again no garbage screen.

And you said you're running a custom kernel right now? Did you compile that kernel yourself? Depending on the outcome of a test I hope to do tomorrow, I might have you and Richard compare notes on how you're building that kernel.

___________
Tony Fabris

the new one

Frank van Gestel

Correct. I compiled my own kernel with Richard's voladj patch and Frank's IR hack patch.

Could you do me a favor? Could you compile a Mark1-player 1.01 version of that kernel, zip it, and e-mail it to me? I would like to test to see if I can induce the behavior with that in place.

If the reboot works OK with your kernel but not with Richard's kernel, then we need to compare the difference between the way you build your kernels and Richard builds his kernels.

By the way, this morning Mike told me that even the Empeg folks haven't gotten to the bottom of the "garbage screen after soft reboot" problem, it seems to happen intermittently to them.

But on my player I'm able to reproduce it every time under controlled conditions (stated elsewhere in this thread).

___________
Tony Fabris

The "garbage after soft reboot" is a known problem, though I've not seen it for quite a while now. The SA1100's LCD controller appears to go loopy.

Hugo

Well, Brian e-mailed me his kernel compilation and it appears as though the kernel really is the deciding factor. With Brian's kernel, there is no garbage screen, with Richard's kernel, there's a garbage screen every time. At least on my player.

I'm e-mailing Richard with this information, perhaps he and Brian can compare build techniques and decide where the problem lies. Once they've gotten to the bottom of it, then we'll make that information public and we can all sleep better.

At least it's not my uploader that's causing the problem. Phew!

___________
Tony Fabris

The "garbage after soft reboot" is a known problem, though I've not seen it for quite a while now. The SA1100's LCD controller appears to go loopy.

Yeah, Mike said that.

But read farther down in this thread... I can now reliably reproduce the garbage screen every time under controlled conditions, and I can make it go away under the same controlled conditions by altering one variable.

The one variable is: Who compiled the kernel, Brian or Richard?

I'm composing an e-mail to Richard right now, so that he and Brian can compare the method they're using to build the kernels. If that reveals anything, we'll be sure to share it with you.

___________
Tony Fabris

I don't believe it is just the kernel-compilation.
On tuesday I reinstalled my custom kernel. Everything was fine, no garbage on screen after reboot. This morning I modified config.ini and added the following items :
[Startup]
reservecache=32
[menu]
quit=1

After reboot the garbage reappears. I deleted the above items from config.ini again, but the garbage still appears !
I can't get rid of it anymore other than reinstalling an upgrade... (maybe a default kernel would work, but I haven't got one around)
This is starting to get really confusing...

Frank van Gestel

(maybe a default kernel would work, but I haven't got one around)

No, I think it might have something to do with the way the kernel is built. Richard sent me a "plain vanilla" kernel that he compiled, and it induced the bug. The kernel I got from Brian never induces the bug, despite having several major modifications.

___________
Tony Fabris

This is a question for Frank. Where did you get your toolchain? Or if you compiled your own what versions of the various packages did you use? I guess the same would go for Richard if he's around.

Here is a list of the packages I used to make my toolchain

• binutils-2.9.5.22.tar.bz2
  
• gcc-2.95.2.tar.gz
  
• gcc-2.95.2-diff-991022.gz
  
• chris-rutter-patch-for-gcc-2.95.2
  
• glibc-2.1.3.tar.gz
  
• glibc-crypt-2.1.tar.gz
  
• glibc-linuxthreads-2.1.3.tar.gz
  
• And the empeg kernel from Version 1.01
  

Also if someone would like to ftp me their kernel source tree I could compile it and see if the resultant zImage is different.

Brian

-See my empeg here-

I actually compile the kernel on the empeg itself.
Here are the packages I use (potato-dist) :

binutils 2.9.5.0.31-3

gcc 2.95.2-13

libc6 2.1.3-8

I do not know dpkg well enough to get the info I want ( how do I do an rpm -q -a ?)

As I said, it is a standard potato distribution residing on the empeg(+/- 500Mb). The kernel source is the one from the empeg web-site with all the patches installed. I got the config file from Kim Salo, as it was posted somewhere on the BBS (I own an MK2).


Frank van Gestel

I'm not sure if that will make a difference or not. If you want to compare your config file with mine I've attached it here. It was originally based on a config file I got from Mike.


Brian

-See my empeg here-

I actually compile the kernel on the empeg itself.

This got me thinking.
How did you install the kernel afterwards? Did you transfer it to your PC and then used the supplied utilities? Or is there a way to install the kernel on the empeg directly? If so, how?

cu,
sven
(MkII 12GB blue, #080000113)

Good question,sven. Me too would be interested in flashing the kernel from the empeg itself.
I currently copy it to the PC and use tony's excellent logo-editor to flash the kernel-image to the empeg.

Frank van Gestel

I currently copy it to the PC and use tony's excellent logo-editor to flash the kernel-image to the empeg.

Aw, an endorsement, thanks.(blush)

I'm glad you find that feature useful. I find it quite useful, too. Now that I've got 32-bit common dialogs working, I really like being able to use that screen to pick my kernel file.

In fact, since my program deliberately does a long-to-short filename conversion before launching Upload.exe, you can now even name your kernel files with spaces in their names if you want. I dunno if anyone caught that yet or not...

___________
Tony Fabris

> I'm glad you find that feature useful.
It's great...I've got a short-term memory for numbers ( and I'm afraid of writing the kernel at the wrong address ) so every time I've got to find out the right address. Now I can blame your program instead of my stupid typo when my empeg gets screwed up. hehe...

Frank van Gestel

Do we know the ".upgrade" file format? It would be really conveniant if we could put together a "developer-extra.upgrade" package that included binutils, gcc, libc6, and other packages that are of interest to programmers.

I'd love to be able to compile the kernel and other user programs, at a shell on the empeg, but I don't have the patience to manually install each package after every major release by the empeg guys. Instead, we could just tack our extras onto the end of each developer.upgrade they release.

Do we know the ".upgrade" file format?

No, we don't at the moment. There was already a thread on this subject recently... anyone have that link?

___________
Tony Fabris

yup ... link


|| loren.cox
|| 080000446