when i applied the new v300 hijack kernal with the kernal flash utility, i got the meesage below in the DOS window. never got anything like it....any ideas?

found empeg unit: entering program mode
manufacturer=0089, product=88c1
waiting for prompt
starting erase [100%] erase ok
starting program at 0x10000 [Failed to get echo-back on lock/unlock command.

Error: lockpage(10000,1) got code 1

Can't say I've seen it, but incidentally, did you try flashing a second time, to see if it was transient?

Try:

- Pull the empeg's power. Do not plug it back in.

- Start the kernel flash process.

- When prompted, and only when prompted, apply power to the empeg.

If that doesn't work with the hijack kernel, try the same thing with a standard .upgrade file.

If that doesn't work, try a different cable AND a different computer.

I get the same error message. Tried 3 times. I flashed v299 back on for now.

So 299 worked but 300 didn't? I didn't realize that. That's strange. Wonder if it's something about the file.

Okay, I get this exact same error message when I try it. So it's not your cable or your PC or a corrupted file download. There's something unusual about the file, its file name, or something. I am investigating.

This is exceptionally odd.

- Jemplode has no trouble upgrading the player with v300 via FTP.

- The file that Jemplode auto-downloaded and successfully upgraded the player with is binary-identical to the one that I downloaded and tried to upgrade with using Logoedit. So there's nothing wrong with the file.

- It's not file size, because I've used logoedit before to upgrade the player using both smaller files as well as larger files. At least I think I have.

- I know my upgrader and cable are working because I can easily apply the V299 upgrade with logoedit.

Still investigating.

Nope, not file size, because:

- Easily upgraded to v299 from serial, file size 455k
- Easily upgraded to v271 from serial, file size 505k
- v300 is between those two sizes, at 480k.

Not a problem with the file NAME because it's nearly identical in name to the others that successfully upgraded, except for the 300. And I even tried renaming it to "new.zimage" and upgrading from that. No dice.

Not a problem with the file itself because Jemplode has no trouble upgrading the player successfully with v300 (albeit through FTP not serial).

Is it possible that it's something in the binary data of the file itself... something where a certain sequence of binary characters will screw up the flash pump firmware or the download.c code?

I know that sounds unlikely, but the old Sherlock Holmes mantra is running through my head now: When you have eliminated all other possibilities, whatever remains, however unlikely, must be the truth.

What other possibilities must we eliminate?

I guess it's time to start using Jemplode.

Thanks Tony for looking into this.

Used Jemplode, v300 loaded no problem.

note: well, even though i got the error, it appears that there is no problem using the player and hijack features for me.

The Empeg-supplied "download.c" also works perfectly (under Linux) with v300, so there's nothing wrong with serial kernel flashing. The error message people see is coming from (1) Windows or (2) logoedit, so those are the two places to look.

Cheers

The error message is from the Upload.exe program that is used with LogoEdit.

-ml

I haven't tried, but does it work with download.c?

Jemplode probably just uses ftp to upload the image to /proc/empeg_kernel, so it is not even going through the empeg's builtin flash programmer.

I looked at the download.c source and it looks like the programming actually should be ok, the player must have even ok'd the last 28 byte block.

Is the logoedit code identical to download.c compiled for windows?

It fails to relock the first page it tries to lock, but that the data sent for that operation is identical whether you're flashing v300 or v299. Maybe the timeout is too short and it normaly doesn't trigger? Or did that last 28 byte block write fail after all. Perhaps it is a combination of the two. As the last write is only for 28 bytes, perhaps the flash programmer is 'initializing' the rest of the relatively large flash page and that delays it long enough to miss the timeout, or it starts writing stuff too late so that flushrx didn't get a chance to actually get rid of the '?' (prompt that is sent by the bootloader).

Add a sleep(1); to the beginning of lockpage, or try to pad the image to a larger size, so that the last bytes aren't as close to the flash-page boundary anymore.

I looked over the source code for download.c (which is what LogoEdit uses a modified copy of), and the error is happening right at the very end, as the program tries to write-protect the kernel after is has been downloaded.

So.. it's all there at this point, just not completely write-protected..

-ml

Okay, so that eliminates the player flash-receipt code.

It's gotta be something windows-specific that the UPLOAD.EXE code doesn't like.

Attached is the Logoedit version of download.c. Anyone see anything that might cause the problem?

>I haven't tried, but does it work with download.c?

Yes, download.c works just fine under Linux at least.

And I double-checked to ensure that the unit I tried it on
has the same kind of flash that gives the error with LogoEdit.

-ml

Try this patch to upload.c and let us know what happens:

--- upload.c.orig       Thu Oct 17 12:32:25 2002

+++ upload.c    Thu Oct 17 12:38:35 2002

@@ -743,6 +743,7 @@

     printf("%3d%%\010\010\010\010",(done*100)/length);

     fflush(stdout);

   }

+  fsync(i);

   fclose(i);



   /* C3 flash? */

Why bother to fsync the file that is being read??

So I'm just adding the one "fsync" line, that's all? What does that do?

The only thing I can think of is that flushrx hasn't flushed all incoming characters. Maybe your machine is too fast This change should make it wait for up to a second for possible incoming data instead of simply returning right away.

static void flushrx()
{
- while(readbyte(0)>=0);
+ while(readbyte(1)>=0);
}

Well, I can't reproduce the error on my work PC even with the original code, so I won't be able to try this out until I get home and I'm doing it in an environment where I can reproduce the bug.

In the meantime, I'll solicit suggestions for LogoEdit improvements in another thread. The software hasn't been updated in almost two years, and I might as well take this opportunity to improve it.

Good point.. I got briefly confused.

Okay, my theory is that the final write operation is still in progress when the program begins trying to lock the pages again. Dunno why, but nothing else explains it nicely.

So, put a sleep(1) there instead of the fsync().

And modify the lockpage error message to actually dump out what it read back, instead of just blindly complaining.

Cheers

So, put a sleep(1) there instead of the fsync().

Interesting. That seems to have done it. Will do more testing to be sure, but that seems to have taken care of it.

THANK YOU!

(Had to use the Win32 version of that command, though. Capital S, and the value is in milliseconds so it was Sleep(100); but the point is that it worked.)

For anyone who doesn't want to wait until the full release of the next version of Logoedit, I have attached the fixed version of upload.exe here. Simply copy it over the original upload.exe in the logoedit installation folder, and you're all set.

While I'm at it, there were a couple of other threads a long time ago that complained of a similar error, but in the erase stage rather than the lock stage. Do you think it could be the same thing?

http://empeg.comms.net/php/showflat.php?Cat=&Board=bigs&Number=43878
http://empeg.comms.net/php/showflat.php?Cat=&Board=empeg_tech&Number=30144

If so, where would I put the Sleep command?

Here is an even newer one which also sleeps before checking for the echo back on the erase command.

Sigh, people just don't listen to me. If you had made that change to flushrx like I suggested you would automatically get the 'waiting for the prompt' sleep at every point a command is started.

If you want people to listen to you, patch a wav of yourself into gpsapp?

Well, that or patch in "flite", but that's not the same...

There's a slight difference though, it really just needs one single sleep after the final write, not after EACH write.. much quicker this way.

But of course you suggested it first!

Cheers

Sigh, people just don't listen to me. If you had made that change to flushrx like I suggested you would automatically get the 'waiting for the prompt' sleep at every point a command is started.

I did listen to you. But I understood more clearly what Mark's change was doing so I tried his version first. Also, as Mark said, I got the impression that your change would happen in more "places" during the process, so I actually did not want to do that (even though that's the very reason why you're saying it would be the better option).

I'm not completely clear on what's going wrong exactly, and I'm not able to reproduce every error, so I wanted to make the changes as small as possible.

True, and like Mark said, it will slow down every single operation by about a second. So it would add about a full minute to the whole erase, reflash cycle. On the other hand, when some one has a 2GHz cpu, it will still work reliably.

Ohhh, they already passed the 2.4GHz mark, well make that 4GHz then

>Had to use the Win32 version of that command,
>though. Capital S, and the value is in milliseconds
>so it was Sleep(100); but the point is that it worked.

If it's in milliseconds, then sleep(1) would translate to Sleep(1000) not 100.

Cheers

Oh yeah, you're right. Good point.

Okay, well, a 1/10 second delay seems to have fixed the bug fine, then.

I am getting a different error. I just upgraded to beta 13. All that worked fine, player is running fine. Tried to put hijack back in and this is what I am running into.

found empeg unit: entering program mode
manufacturer=0089, product=88c1
waiting for prompt
starting erase [Failed to echo-back on erase command.

Error: erasepage(10000) got code 1

Press the Enter key to continue.


Help. I am using LE 1.5 and trying to put any version of Hijack in.

Hm. Thought I'd taken care of that. Sure it's LE 1.5?

Does this one fix it? (File attached)

Save this file as upload.exe in your logoedit directory. Does that solve the problem?

Just downloaded logo edit this morning so I know it's 1.5. and the about says so.

Now I get Error: lockpage(20000,1) got code one.

But Hijack is now installed. It is fine to leave it this way? Someone posted about it being installed but not write protected or something.

Could you please reproduce this problem and post the entire screen of the error rather than just that one line?

I'm working on this actually right this moment and I'd like to sew this up as soon as possible.

Here goes.

found empeg unit: entering program mode
manufacturer=0089, product=88c1
waiting for prompt
starting erase [100%] erase ok
starting program at 0x10000 [Failed to get echo-back on lock/unlock command.

Error: lockpage(20000,1) got code 1

Press the Enter key to continue.

It programs to 100% then give this error. It does this with v300 or v269(latest one I have before 300). Using the latest file you posted(120420). Yes I know about having to rename it.

Okay. see if the attached version of upload.exe fixes the problem and let me know.

Save this file as upload.exe (remember you have to rename it) in your logoedit directory.

94Cobra, if you can catch me on ICQ (1228275) when you have a free minute, buzz me and we'll pound on it back and forth a bit.

I've got a new build of Logo Editor ready with AnnaVu/TuxMuch support, but I want to fix any remaining timing problems in upload.exe before releasing. Only I can't reproduce the problem on my machines so I need someone who CAN reproduce the problems.

Ok, I upgraded to v300 of Hijack, using jEmplode's auto update. It worked fine, so my post isn't really related to this thread, but I didn't think it deserved it's own thread. Anyway...

After installing and using v300 for a while, I'm experiencing noticeable hard drive delays when loading play lists, advancing songs and such. They may only be 2 - 3 times longer than the previous version, but they also sound repetitive, as if the hard drives are trying to read through bad sectors. No errors in playing or any other weirdness has happened to make me believe the HDs are actually going bad. Is there anything I can do to experiment/resolve this?

Has anyone else experienced any latency in HD operations under v300?

Should I try downgrading to v291?

Is there any way to fsck the drives?

Thanks!

Should have made a new thread, your problem sounds like it is completely unrelated to what we're discussing in this thread.

If you are getting the click of death on your hard disks, it is not likely related to the kernel software you've installed. Just to be sure, you're welcome to re-install the full beta13 .upgrade file (stock, without Hijack) and see if the problem goes away. I'll bet it won't.

Please click here to read about possible hard drive problems, and here to read about how to do an FSCK. Keep in mind that if you've got hard disk problems at the hardware level, FSCK isn't going to help you and in fact might cause trouble.

For further discussion on the subject, please start a new thread, I'd like to keep this thread solidly on the topic of fixing the flashing code in upload.exe.

Well, I finally got 94Cobra working.

And the only thing that did the trick was Jan's suggestion of waiting 1 second on every readbyte in the FlushRx call.

Yes, it did slow down the process. But it made it work on his system. Just like you said it would, Jan. And the slowdown isn't all THAT bad.

I humbly apologize for not trying your fix as the very first thing, Jan.

Logoedit 1.6 coming out, probably sometime today.

I knew I just had to wait until Moore's law made desktops fast enough for Murphy's law to kick in.

Didn't expect it to be within only a couple of days though. There must be something with the size of v300 that triggers a sort of worst case behaviour in the flash loader.

Heh, Moore's law && Murphy's law. Good one.

Thanks Tony, I'm not getting the Error: "lockpage(10000,1) got code 1" with this version of Upload now.

Phew.