I'm not much at serial port programming. Hell, I'm not much at programming at all. But this one's got me baffled.

I'm trying to get download.c to work under Solaris, and it's not being cooperative. (That antecedent is indefinite on purpose. )

What I've gotten to now is that it's sent the Ctrl-A at boot to get into upgrade mode, and it's read the appropriate stuff (manufacturer and product codes, the `?' prompt), but when it goes to write `u' and the page address to unlock, it expects for its `u' to be echoed back. It never sees it come back.

I've attached to the empeg via tip and done the same things to that point by hand and I do see the `u' echoed back.

Even though I'm fairly confident that the program that's being run on the empeg at that point is supposed to be echoing the `u' back, especially since none of the following characters are echoed back, I feel like I've done something wrong, like set the serial port parameters incorrectly or something.

Notably, I had to make a cfmakeraw(), as that seems to be a Linux-only function. I've cribbed what it does from a Linux machine's cfmakeraw man page.

Does anyone have any ideas? I suppose I could try to comment out that check, but I don't know if it'll try to insert that `u' in somewhere important later.

the download.c code has always been hit/miss. I believe there's a timing issue involved somewhere. Sometimes it works on Linux, sometimes it fails on a different machine with otherwise identical software. Ditto for windows.

And especially ditto for the Linux upgclient, which does not work at all on my newer laptop, but works on all of my other machines. It is based on the same code as in download.c

Someday I suppose I'll rev-eng the protocol and write a replacement or something, one that will also work with a Hijack kernel on DC-power.

Cheers

The thing is that it I've looked through the code, and it's not doing anything hard at all to this point. All it's done is open the serial port O_RDWR, write some data to reboot (my addition -- thanks for the help, Tony), read a good amount of data, write one character, and then try to read that one character back, and somewhere it isn't seeing the character. A system trace shows it polling the serial port and not seeing anything, but I can verify that it does if I use a ``terminal emulator''. I don't see how the system could be not seeing it if it were sent, so I have to assume that it's not being sent, but I can't see why that would happen reproducibly with one program but not another.

Aargh. Maybe I'll just rewrite it in Perl. I'm tired of all this proprietariness.

We had to add a bunch of "wait" statements in the win32 version of the code to prevent errors on certain systems. Perhaps it's as simple as doing that in your version of the code?

Could be. I'll give it a shot when I get back to work. (Unfortunately, the Sparc I have at home is old and its serial ports won't do 115200.)

MOTHERFUCKER!!!

I now remember that upload.exe problem you had before, I went and looked at it and it's almost exactly the same problem. Why, oh, why, would I assume that no one had ever seen this before?

Still can't fix and test it until tomorrow, though. Or come back with another expletive, which seems likely.

Jeez... you didn't have to call Tony a Mofo over it.

That was an expression of disgust (mostly with myself), not a pejorative. Sorry.

On the other hand, I put those sleep calls in there, and it didn't help.

Yup. I've got sleep statements all over the place with no improvement at all.

The fact that the empeg echoes back that `u' but not anythin gafter it provides athe facility for some testing. I set the download program to exit just before and just after it sends the `u'. If it exits before it sends it and I then connect to the empeg and type `u', I get an echo back. If it exits after it sends it (and before it tried to read the echoback) and I connect and type a `u', I get nothing.

So it seems to be successfully sending the ...

Hang on.

It may be that that output stream isn't getting flushed....

Nope. It doesn't look like that was it, either.

Any more ideas?

So the last write that 'succeeded' was the cr to get a prompt back and we actually got the prompt? My guess is that your 'cfmakeraw' isn't setting everything up entirely right and the serial port is actuall translating the <cr> into <cr><lf>.

What is reported by stty -a < /dev/ttyS0 (or whatever your serial port is). Here is what my serial port is set to right after reinstalling hijack.

$ stty -a < /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

So the last write that 'succeeded' was the cr to get a prompt back and we actually got the prompt?

That seems to be correct. A system trace shows that it thinks that it's writing the `u', but nothing past that.

Unfortunately, it looks like Solaris may reset port parameters when the port is closed (the baud rate was back at 9600 after the program was finished). Maybe I can grab them while the program is running.... Yup. I feel like crap, so I'm just going to post it here and get back to it later.:

% stty -a < /dev/ttya
speed 115200 baud;
rows = 0; columns = 0; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
min = 4; time = 0;
intr = ^c; quit = ^\; erase = ^?; kill = ^u;
eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
-parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc
-ixon -ixany -ixoff imaxbel
-isig -icanon -xcase -echo echoe echok -echonl -noflsh
-tostop echoctl -echoprt echoke -defecho -flusho -pendin -iexten
-opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3

Okay the differences seem to be:

You have the following settings that I don't have:
bs0
cr0
ff0
nl0
tab0
vt0

I have the following settings that you don't have:
-flusho
-loblk
-parext
-pendin
tab3

You have these set that I have unset:
clocal
hupcl
ignbrk

You have these unset that I have set:
echoctl
echoe
echok
echoke
imaxbel
onlcr (It looks like this may be it.)

Again, I'll come back to what this means.

Thanks for pointing out stty to me. I don't know why it didn't occur to me before.

You're right, closing a serial port possibly does affect some settings, so I reran my stty while download.c was waiting for an empeg to connect to.

My guess it is the 'min = 4', which in compination with -icanon blocks your read until there are at least 4 characters in the buffer. But you probably also want to turn off the nl -> crnll conversion (onlcr). As well as imaxbel, which flushes the buffer when a ^G character is sent.

For the rest I can't really quickly find anything else that might affect things.

That was an expression of disgust (mostly with myself), not a pejorative. Sorry.

Oh, I took no offense... I often exclaim similar things when I do that kind of stuff, so I laughed out loud when I saw the post.

Hey, Bitt, when you *do* get it working on Solaris, post the fixed source code somewhere permanent and I'll link it from the FAQ.

My guess it is the 'min = 4'

Aha! That was 100% correct!

I never realized what that setting was for. I probably would have eventually figured it out once I figured to look at stty stuff, but you prodded me to the right thing in both cases.

Thanks a lot!

Now I have hijack installed!

(Tony, I'll clean it up and let you have it in a few.)

Hey, Bitt, when you *do* get it working on Solaris, post the fixed source code somewhere permanent and I'll link it from the FAQ.

And, if you're willing, we'll roll it into future releases.

Peter

It seems like the major problem was depending on cfmakeraw() to DTRT. That's a glibc extension, AFAICS. On top of that, it appears that GNU's cfmakeraw manpage is incomplete as to what it does.*

Add to that my lack of prowess with serial programming (and, as I said, lack of programming prowess in general), and it became very complicated.

Regardless, despite the time it took me to make it work, it's not a complicated fix. I don't really think you'd need my permission to fix it anyway, as you could just steal GNU's code, but you have my permission, nonetheless.


* Here's what the man page says:

cfmakeraw sets the terminal attributes as follows:

           termios_p->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP

                           |INLCR|IGNCR|ICRNL|IXON);

           termios_p->c_oflag &= ~OPOST;

           termios_p->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);

           termios_p->c_cflag &= ~(CSIZE|PARENB);

           termios_p->c_cflag |= CS8;

Here's the code from glibc-2.3.2 termios/cfmakeraw.c:

/* Set *T to indicate raw mode.  */

void

cfmakeraw (t)

     struct termios *t;

{

  t->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);

  t->c_oflag &= ~OPOST;

  t->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);

  t->c_cflag &= ~(CSIZE|PARENB);

  t->c_cflag |= CS8;

  t->c_cc[VMIN] = 1;            /* read returns when one char is available.  */

  t->c_cc[VTIME] = 0;

}

Fine work, GNU guys!

Okay. Here it is. I tidied it up a lot more. Removed global variables, made the coding style more consistent, used getopt() for argument processing, etc. It could still be a lot better, but it at least works now and should be easier to modify in the future.

Feel free to use this as you see fit (other than to sue me).

There's one potential problem with the program above. I'm reuploading it here with a one-line fix (plus two lines of comments). There's also a minor fix to prevent specifying multiple files. This is not a show-stopper, as it would only deal with the first one, but it's nice to not have arguments completely ignored.

Also, some usage would help since the command line options have changed.

empeg-download -p /dev/ttya -a 10000 kernel_file.zImage

`-p' specifies the device to use. It's a required option.

`-a' specifies the address to erase and replace with the given file. 10000 is the correct address for replacement kernels.

The other argument is for the file to upload. There should be only one file.

You can also specify a `-d' option to assume that the empeg is already in program mode. This was already in the original download.c, activated by specifying anything after the filename. Now it's a little more obvious, if not much more useful.

It also now tries to reboot the empeg on its own, just like Tony's upload.exe for Win32. It also tries to reboot it afterwards. These reboot attempts can be elided by specifying `-i' and `-r', for the initial reboot and the ending reboot, respectively. Using them could potentially be useful for uploading multiple things to the empeg's flash, as during upgrades, for example. Using the `-d' flag assumes the `-i' flag.

Kewl.

For completeness, I'm uploading my Win32 version of the code here to this thread, and linking it from the FAQ right next to yours.

FAQ entry should be updated in just a few minutes.

Copied from General since Tony's linked to this thread:

I got empeg-download to work under OpenBSD. (It would have gone faster if I hadn't spent hours trying to figure why /dev/tty02 wouldn't talk to a device hooked to /dev/tty01.)

I did encounter the same problem Tony had with upload.exe, though, and I added some code to add some delays to the process. It's accessible via the `-s' option.

Source code attached.

So I should link this one, then?

Oh. I didn't realize that you'd linked directly to the file.

A few suggestions. While it's true that I made it work specifically for Solaris, it was intended to work under any Unix OS, since the official one only worked under Linux. This one should work under Linux, too. You might want to point that out.

It took me a few minutes to find the appropriate FAQ entry. The one I found first was ``How Do I Install Hijack'', which doesn't reference my new code. You Might want to put something there.

In the off chance that I need to modify something again, why don't you link to my web server, where I have more control over what will be downloaded? I haven't put anything up there yet, but give me a few.

It took me a few minutes to find the appropriate FAQ entry. The one I found first was ``How Do I Install Hijack'', which doesn't reference my new code. You Might want to put something there.

I was about to say "Not my monkey", but then thought that Loren probably wouldn't mind a tiny edit to that section of his FAQ, so I went ahead and did it. You don't mind, do you, Loren?

Hope this doesn't mean it's now my monkey. (It's not a Monkey I want right now, I've got plenty thank you. )

why don't you link to my web server

Okay, I will. Let me know when something is up to link to.

Preliminary ``page'' at http://www.beaglebros.com/empeg/download/.

(Sorry it took so long. I had to convert SCCS to RCS, which meant installing one or the other on one or the other of my machines, and right as I was about to install a version of SCCS on the one machine, after searching for it for a while, it occurred to me that it would be more useful to have RCS on the other machine, and ... well, you know.)

Anyway, that page will be fleshed out in the (hopefully near) future.

Oh, and I could have sworn that that was part of your FAQ. Sorry.

Okay, updated.

Hey, that wouldn't happen to run on OS X, too, would it?

that wouldn't happen to run on OS X, too, would it

Not exactly. Serial support is very iffy under OS X as there are only two machines that officially run OS X that even have serial ports (Beige G3 and XServe). Anyway, I tried it and it compiled fine, but it took several tries to flash the kernel. Most of the time the empeg just reboots and it never gets flashed. Of the times when it tried to flash it most of them failed and the one that finally succeded ended up with my computer crashing when it completed. Anyway, I wouldn't recommend it and it probably isn't worth worrying about since most macs don't have serial anyway.

-Mike

-d is useful for two reasons:

- If you're flashing multiple areas in the same session
- If you just realise you've flashed 0000 (the protected bootblock, with the prot link fitted) with junk and need to flash something sensible in there before removing power and hence requiring you to desolder the flash chip...

Hugo

If you're flashing multiple areas in the same session

I saw that one, and is why I put in the flags for not rebooting, but it doesn't seem to actually work for me. Every time I tried it, I got an unexpected response from the empeg. I'd assume that it's me, but I didn't touch that part of the code.

If you just realise you've flashed 0000

Experience?