Since I've got the source code to DOWNLOAD.C (and I'm bending it to my will), I'm wondering if I can do something:

When DOWNLOAD.EXE is finished sending the file to flash, the player sits there frozen with the standby light on "steady" instead of "pulsing".

Is there a couple of bytes I can send to the serial port after the upgrade is done and it says "Program OK", that can reboot the player so they can see their new logo? As it stands right now, I have to physically remove the power a second time to get it to work.

While I'm on the subject, what to I send to get it to accept an upload without having to reboot?

___________
Tony Fabris

Is there a couple of bytes I can send to the serial port after the upgrade is done and it says "Program OK", that can reboot the player so they can see their new logo?

r

Borislav

Gee wiz, even I could have come up with that one ...

Of course the r of 'empeg player please pRetend I switched of the power and then plugged it back in' ...

Cheers,
Hans


Mk2 - Blue - 080000431

Tried it. That "r" command seems to just quit/restart the player, it doesn't fully reboot the unit.

I'm looking for the command which causes the unit to fully restart from the ground up. The one they use to do the .upgrade files.

___________
Tony Fabris

I tried the "r" command and it works for me. (opening a serial console after kernel upload and give r at the ?-prompt).

I can see it is loading the new kernel; I don't know if this also implies showing the new bootimage

Frank van Gestel

Edited by fvgestel on 18/10/00 08:54 PM.

I can see it is loading the new kernel; I don't know if this also implies showing the new bootimage

It doesn't work on my player when I try it. It just restarts the player but doesn't fully reboot the unit. Kind of useless for my purposes.

I tried reverse-engineering the bytes that EmpegUpgrade.EXE sends to the player to make it reboot, but I think I'm doing it wrong or something. The bytes I see it sending are:

19 0d 0a 02 2c 8b 43

But when I send those bytes to the player with my code, it just sits there happily playing music and doesn't do anything. I think there's probably some handshaking that needs to go on, and I just don't know what that handshaking needs to be.

Hugo, are you listening? What do I do in this situation?

___________
Tony Fabris

No, the 'r' command is the only one we use when applying upgrades.

There's a reboot command that can be issued to the pump program which does a full reboot, but the usual upgrade sequence is this:

Power on, go into flasher
Flash all areas necessary
'r' to run the bootstrap
Enter pump program when kernel boots
Repartition & download data to disk
Reboot in pump program (I seem to remember this is ctrl-A to get into the pump, then "reboot" to reboot).

Hugo

Thanks for the info, Hugo.

Okay, I discovered that the reason "R" didn't do the trick for me was that I had a modified init. When I re-installed 1.01 developer with the default init, "R" now properly reboots the kernel after the end of a flash. Cool. So that's half of what I wanted to know.

BUT...

Now how do I get a flash upgrade to work without a power cycle? R still doesn't work for this purpose, at least when I try it.

You said that the start of the upgrade sequence goes like this:

Power on, go into flasher
Flash all areas necessary
(...)


But the upgrade program does one extra step before power on that you didn't list, and that's what I'm asking for.

The upgrader has the ability to begin the flash upgrade without having to apply power. And from looking at its serial output, it doesn't look like it sends an "r" to do this. If I send an "R" to the player, it just restarts the player and I never get the magic "Peace..." string which tells me it's OK to begin flashing.

How do I tell the player to begin accepting a flash upgrade without a power cycle? Is there some sort of complex handshaking I need to do? Does it require the "r" and then something else that I don't know about yet? Please help, I'm stumped!

___________
Tony Fabris

Erm, I think the upgrader sends a reboot packet to the player program (or something like that) which forces the empeg to do a reboot (like typing shutdown -r now at the bash prompt).

Doesn't always work, though...

Hugo

Erm, I think the upgrader sends a reboot packet to the player program (or something like that) which forces the empeg to do a reboot

Ah, cool. That's what I'm getting at. Any clues as to the format of that packet?

Like I said, I tried to reverse-engineer it, but I think I've got it wrong somehow.

___________
Tony Fabris

It's in the source for emptool. At least, it should be...

/empeg/lib/protocol/protocolclient.cpp

Look at ProtocolClient::RestartPlayer()



Roger - not necessarily speaking for empeg

Thanks!

I'm downloading the source code now.

___________
Tony Fabris

You were probably expecting this...

Okay, I've looked at the source code and I'm slowly beginning to understand how it works. But since I'm looking at it from the "inside out" as it were (starting with the restartplayer() function and then finding all the bits that it calls), I'm slightly confused about how to proceed.

I'm not sure how much more work I want to put into this. Here's what I'm after:

I want to be able to plug a string of hard-coded writebyte() statements into DOWNLOAD.C that will reboot the player. I'm wondering whether this is even possible.

I think I can construct a hard-coded reboot packet in a pretty straightforward fashion. But that's just the packet itself. Then I need to append a 16-bit CRC on the end of the packet. Even that's do-able, especially since the packet will be hard-coded.

But what I'm not sure about is whether any handshaking needs to go on before the packet itself can be sent. When I try to just send the raw packet, nothing happens on the player. I'm not sure whether it's because I've got the CRC wrong, or if it's because the player isn't listening at all because I haven't done the right handshaking to make it listen for a packet in the first place.

Here is what I think needs to be sent to the player, correct me if I'm wrong (all multi-byte values send LSB first):

PSOH = 02 00
Datasize = 07 00
Opcode = 0C
Type = 0
Packet_ID = (four-byte value, minimum value of 43, exact number unimportant)
Command = 00 00
Param0 = 02 00 (restart_unit, possibly 02 F0 for restart_in_slumber)
Param1 = 00 00
Param2 = 00
CRC = ?? ??

If I get the CRC right, can I just throw those bytes down the serial cable, or is there more handshaking needed before the player will listen to that packet?

I'm also assuming that if I get the CRC wrong, the player will ignore the packet. Is this correct?

If I don't have to do any handshaking, then I'll take the time to work out the CRC and send it. If there's handshaking involved, then I'm just going to drop this idea and let the user cycle the power themselves.

___________
Tony Fabris