#318910 - 06/02/2009 23:09
Re: linux only hard drive upgrade?
[Re: tfabris]
|
journeyman
Registered: 29/12/2001
Posts: 99
Loc: Riverside, CA
|
wow, I'm glad this thread is continuing! It took a few days but I finally got my replacement serial cable. And my "cat /dev/ttyS0" stuff did work. All it did was print out some garbage which was enough to tell me that it's active. I couldn't get it to work via virtualbox so I grabbed the upgclient and yeah, that doesn't work either: $ ./upgclient Windows_Share/builder_bigdisk_v4.upgrade
empeg-car Upgrade client.
empegupgrade: Using upgrade file 'Windows_Share/builder_bigdisk_v4.upgrade' to device '/dev/ttyS0' (115200 baud)
Checking upgrade file integrity [100%]
Pumping player software
Finding unit [ 2%]
Upgrading flash (bootloader)
Erasing flash [ 0%]
ERROR: 8 Flash erase failed
Upgrade aborted due to errors [ 0%]
Upgrade failed :-(
Upgrade failed with error 0x80040057
Any ideas?
|
|
Top
|
|
|
|
|
#318911 - 06/02/2009 23:15
Re: linux only hard drive upgrade?
[Re: ajayrockrock]
|
addict
Registered: 01/03/2002
Posts: 599
Loc: Florida
|
I think you have to plug in the Empeg power when it says "Finding Unit", but I could be wrong.
_________________________
Chad
|
|
Top
|
|
|
|
|
#318912 - 06/02/2009 23:17
Re: linux only hard drive upgrade?
[Re: ajayrockrock]
|
journeyman
Registered: 29/12/2001
Posts: 99
Loc: Riverside, CA
|
just for the hell of it, I grabbed the v3alpha one that was posted and got similar results:
$ ./upgclient.static ../../Windows_Share/builder_bigdisk_v4.upgrade
empeg-car Upgrade client.
empegupgrade: Using upgrade file '../../Windows_Share/builder_bigdisk_v4.upgrade' to device '/dev/ttyS0' (115200 baud)
Checking upgrade file integrity [100%]
Pumping player software
Finding unit [ 1%]
Upgrading flash (bootloader)
connection_all.cpp: 155 (2000): Connection::FlushReceiveBuffer throwing away...0x84b843d: 0d 0a 30 30.39 61 32 33|30 34 0d 0a.33 61 37 61 ..009a2304..3a7a
0x84b844d: 38 33 65 39.0d 0a 34 35|31 38 61 62.36 30 2d 37 83e9..4518ab60-7
0x84b845d: 62 35 62 b5b
connection_all.cpp: 155 (2000): Connection::FlushReceiveBuffer throwing away...0x84b8439: 65 64 35 2d.33 64 64 37|61 66 30 38.2d 64 33 36 ed5-3dd7af08-d36
0x84b8449: 65 65 34 39.32 0d 0a 30|30 0d 0a 30.30 0d 0a 3f ee492..00..00..?
0x84b8459: 75 u
ERROR: 8 Flash erase failed
Upgrade aborted due to errors [ 0%]
Upgrade failed :-(
Upgrade failed with error 0x80040057
Same error code though... Do you guys know what 0x80040057 means? Google doesn't really give me any results except for this thread: http://empegbbs.com/ubbthreads.php?ubb=showflat&Number=46154
Edited by ajayrockrock (06/02/2009 23:20)
|
|
Top
|
|
|
|
|
#318915 - 07/02/2009 07:53
Re: linux only hard drive upgrade?
[Re: Attack]
|
journeyman
Registered: 29/12/2001
Posts: 99
Loc: Riverside, CA
|
I think you have to plug in the Empeg power when it says "Finding Unit", but I could be wrong. Yup, I waited until the "Finding Unit" prompt before I plugged in the power. --Ajay
|
|
Top
|
|
|
|
|
#318916 - 07/02/2009 12:57
Re: linux only hard drive upgrade?
[Re: ajayrockrock]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
This all means that you'll be needing a real hardwired serial port
with that software, rather than a USB serial adapter.
|
|
Top
|
|
|
|
|
#318923 - 08/02/2009 08:07
Re: linux only hard drive upgrade?
[Re: mlord]
|
journeyman
Registered: 29/12/2001
Posts: 99
Loc: Riverside, CA
|
Yeah, I have a real hardware serial adapter connected to my empeg. Any other ideas? --Ajay PS. I've had an empeg since 2002 and I'm so excited to be in a thread with mlord. 
|
|
Top
|
|
|
|
|
#319008 - 10/02/2009 04:27
Re: linux only hard drive upgrade?
[Re: ajayrockrock]
|
carpal tunnel
Registered: 19/05/1999
Posts: 3457
Loc: Palo Alto, CA
|
Hmm, I mean there's nothing particularly special about the protocol (timing-wise) - the only time critical bit is interrupting the bootloader at the right moment.
ISTR there is no problem driving the erase commands (etc) interactively... which points to a problem with the upgrader code which is making it susceptible to differences? Does anyone have the code unzipped so they can post the relevant section?
Hugo
|
|
Top
|
|
|
|
|
#319013 - 10/02/2009 10:32
Re: linux only hard drive upgrade?
[Re: altman]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Hmm, I mean there's nothing particularly special about the protocol (timing-wise) - the only time critical bit is interrupting the bootloader at the right moment.
ISTR there is no problem driving the erase commands (etc) interactively... which points to a problem with the upgrader code which is making it susceptible to differences? Does anyone have the code unzipped so they can post the relevant section? The main difference in Mark's "USB-compatible" version seems to be that it buffers up the outgoing data and then sends it in one system call -- the stock download.c sends it a byte at a time. The only theory I have as to how this could possibly make a difference, is if somehow the USB-to-serial adaptor can't saturate 115200bps transmit if it's only getting one byte per USB packet. (Perhaps, when driving it interactively, the terminal is line-buffered.) But actually I can't make the numbers for that add up, even for a USB-to-serial adaptor that's Low Speed 1.5Mbps. Peter
|
|
Top
|
|
|
|
|
#319014 - 10/02/2009 10:54
Re: linux only hard drive upgrade?
[Re: ajayrockrock]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Do you guys know what 0x80040057 means? *Sigh* Looking at the Emptool sources, 0x80040057 is UPG_E_SOMETHINGBAD, the associated error message being "Something bad happened".  Upgrader::ErasePage() has failed for some reason, but the exact error code (which would have allowed us to determine whether you have a connection problem, or a player problem) is thrown away and replaced by meaningless generic ones twice before being reported to the user.  Peter
|
|
Top
|
|
|
|
|
#319015 - 10/02/2009 11:58
Re: linux only hard drive upgrade?
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
The main difference in Mark's "USB-compatible" version seems to be that it buffers up the outgoing data and then sends it in one system call -- the stock download.c sends it a byte at a time. Yeah, without that buffering, downloads take *hours* rather than a minute or two. The other changes were to improve tolerance in delays on recept of ack's and the like from the empeg, though this obviously still needs work -- that's where the remaining timing dependencies still lurk. Cheers
|
|
Top
|
|
|
|
|
#319017 - 10/02/2009 12:16
Re: linux only hard drive upgrade?
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Yeah, without that buffering, downloads take *hours* rather than a minute or two. If that's the case, did your investigation ever reveal why? I'd love to know, however inefficient userland is, how come it's not saturating 115200bps over the serial link. On a modern PC, that's tens of thousands of CPU cycles per bit... Peter
|
|
Top
|
|
|
|
|
#319021 - 10/02/2009 14:28
Re: linux only hard drive upgrade?
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
It was years ago, and I didn't dig too deeply.
But my impression was, that sending one or two bytes at a time,
through a packetized transport (USB), and waiting for it to complete
before sending the next one or two bytes.. kinda made sense that
throughput would be slow.
I don't think the USB serial stack uses windowed transport
like TCP does.
EDIT: Mmm.. some memory is returning now..
I think it might have been the bluetooth
serial dongles here that were the slowest before those mods.
Cheers
Edited by mlord (10/02/2009 14:35)
|
|
Top
|
|
|
|
|
#319202 - 12/02/2009 16:40
Re: linux only hard drive upgrade?
[Re: mlord]
|
journeyman
Registered: 29/12/2001
Posts: 99
Loc: Riverside, CA
|
Update, I have since installed Windows on a spare box and upgraded my empeg (now have 300gigs across 2 drives).
I still would like a linux-only way to upgrade my empeg in the future. So if anyone has any tips on getting this to work I'd be more then willing to test anything.
--Ajay, shopping for a new empeg-friendly car...
|
|
Top
|
|
|
|
|
#319355 - 16/02/2009 04:40
Re: linux only hard drive upgrade?
[Re: peter]
|
carpal tunnel
Registered: 19/05/1999
Posts: 3457
Loc: Palo Alto, CA
|
Hmm, I mean there's nothing particularly special about the protocol (timing-wise) - the only time critical bit is interrupting the bootloader at the right moment.
ISTR there is no problem driving the erase commands (etc) interactively... which points to a problem with the upgrader code which is making it susceptible to differences? Does anyone have the code unzipped so they can post the relevant section? The main difference in Mark's "USB-compatible" version seems to be that it buffers up the outgoing data and then sends it in one system call -- the stock download.c sends it a byte at a time. The only theory I have as to how this could possibly make a difference, is if somehow the USB-to-serial adaptor can't saturate 115200bps transmit if it's only getting one byte per USB packet. (Perhaps, when driving it interactively, the terminal is line-buffered.) But actually I can't make the numbers for that add up, even for a USB-to-serial adaptor that's Low Speed 1.5Mbps. It's definitely not a line buffered type thing; the bootloader will wait forever for the next byte (no timeouts). My guess is that my possibly overzealous flushing of input buffers in the upgrader so as I don't have to parse the echo from the bootloader is falling over. Nobody ever does flush the way I like it (which is: zero the head/tail pointer at that instant) - which tends to get replaced by "read with zero timeout until you see empty" which I can see getting seriously upset by USB. With that in mind, can anyone nearer the code look? If not I will fire up gcc and compile it on my macbook, find a usb-serial adaptor, and see what happens  Hugo
|
|
Top
|
|
|
|
|
#319356 - 16/02/2009 04:42
Re: linux only hard drive upgrade?
[Re: mlord]
|
carpal tunnel
Registered: 19/05/1999
Posts: 3457
Loc: Palo Alto, CA
|
But my impression was, that sending one or two bytes at a time,
through a packetized transport (USB), and waiting for it to complete
before sending the next one or two bytes.. kinda made sense that
throughput would be slow. Depending on how janky the stack implementation is, the worst case could well be 1 byte per frame (1 millsecond). In reality, it should definitely get aggregated before that point, so even if the first byte takes a while millisecond to go out, the subsequent ones would at least fill a USB1 64-byte out packet. Still, you can't argue with what actually happens in real life Hugo
|
|
Top
|
|
|
|
|
|
Previous Topic
Index