Built-in serial port losing characters

[dschmenk]

The latest kernel (Feb 26th) is losing characters at 115K baud (the only rate I've tried). The Feb 12th kernel worked fine.

512MB Model B.

[popcornmix]

I assume it is the Feb 23rd firmware. Can you confirm this.
sudo rpi-uddate 8ddfa1f9eba8a207724644b22255597757dbcb75
would be expected to be the latest kernel that works.
sudo rpi-update cc47954caf69dbf60bcd8d2580029469e70bc77b
would be expected to be the first kernel that fails.

Are you seeing this with console output, or are you using the uart for file transfer.
Do you have a good way of demonstrating the bug?

[dschmenk]

Confirmed the Feb 23rd breaks: 9e69b79f484fe005d7eca698962f3ee27fa00aaf

(I couldn't find the commit for: cc47954caf69dbf60bcd8d2580029469e70bc77b)

And 8ddfa1f9eba8a207724644b22255597757dbcb75 works.

I am using a custom protocol between the RPi and an Apple II (yep). If you have an Apple II, I can help set you up - but the failure is right off the bat. I can send the relevant serial port settings, if that helps.

[popcornmix]

This is the likely commit which changed behaviour: 2c54213
I use uart for serial console at 115K baud and that works without issue.

Please post any info on how you set up the uart from the linux end. I'm afraid I don't have an Apply II to hand.

[dschmenk]

This is the relevant code that inits the serial port and begins the communication protocol. It will sometimes make the initial sync, but nothing after.

    /*
     * Open serial port.
     */
    prlog("a2pid: Open serial port\n");
    a2fd = open(devtty, O_RDWR | O_NOCTTY);
    if (a2fd < 0)
        die("error: serial port open");
    tcflush(a2fd, TCIFLUSH);
    tcgetattr(a2fd, &oldtio); /* save current port settings */
    bzero(&newtio, sizeof(newtio));
    newtio.c_cflag     = BAUDRATE /*| CRTSCTS*/ | CS8 | CLOCAL | CREAD;
    newtio.c_iflag     = IGNPAR;
    newtio.c_oflag     = 0;
    newtio.c_lflag     = 0; /* set input mode (non-canonical, no echo,...) */
    newtio.c_cc[VTIME] = 0; /* inter-character timer unused */
    newtio.c_cc[VMIN]  = 1; /* blocking read until 1 char received */
    cfsetispeed(&newtio, B115200);
    cfsetospeed(&newtio, B115200);
    tcsetattr(a2fd, TCSANOW, &newtio);
    prlog("a2pid: Waiting to connect to Apple II...\n");
    iopkt[0] = 0x80;  /* request re-sync if Apple II already running */
    write(a2fd, iopkt, 1);
    if (read(a2fd, iopkt, 1) == 1)
    {
        if (iopkt[0] == 0x80)   /* receive sync */
        {
            prlog("a2pid: Connected.\n");
            iopkt[0] = 0x81;  /* acknowledge */
            write(a2fd, iopkt, 1);
        }
        else if (iopkt[0] == 0x9F)     /* bad request from Apple II */
        {
            prlog("a2pi: Bad Connect Request.\n");
            tcflush(a2fd, TCIFLUSH);
        }
        else
        {
            prlog("a2pi: Bad Sync ACK\n");
            state = RESET;
        }
    }
    newtio.c_cc[VMIN] = 3; /* blocking read until 3 chars received */
    tcsetattr(a2fd, TCSANOW, &newtio);

From: https://github.com/dschmenk/apple2pi/blob/master/src/a2pid.c

So perhaps the way I set the blocking to 1 or 3 characters is causing problems with the uart commit. That would explain why my daemon is waiting forever for characters to send/receive.

[popcornmix]

There does appear to be a new version of the uart patch:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/394950

Here is a kernel with the updated patch:
https://dl.dropboxusercontent.com/u/3669512/temp/kernel_uart.zip

Can you test it?

[dschmenk]

Hurray! That patch got it working again. Apple II Pi says "Thanks!".

http://schmenk.is-a-geek.com/wordpress/?p=151

https://www.youtube.com/watch?v=OpevIc3_H1g&list=PLlPKgUMQbJ7_bSF7wZ7aHwHC-JularURb&index=3

Dave...

[popcornmix]

Great. Next official firmware update will include this version.

[popcornmix]

This is in latest firmware update.

[dschmenk]

Ran it through it’s paces and looks good from here. Thanks,

Dave…

On Mar 3, 2015, at 9:12 AM, popcornmix [email protected] wrote:

This is in latest firmware update.

—
Reply to this email directly or view it on GitHub #854 (comment).