Skip to main content
Topic: Flashrom extension development (Read 21535 times) previous topic - next topic

Re: Flashrom extension development

Reply #15
The UART buffer has 3 bytes. The first is command and number of bytes, which is processed right away, then one byte to send, then CS, then setup long and send... I think you can bundle that because the only bottleneck is the one byte sent over SPI, as long as 3 more bytes don't arrive over the UART in the time it takes to send that one SPI byte it should be OK.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #16
I just noticed that r461 removed UART1TX(1). Was this intentional or did you just want to move it down a bit? Moving it down might have speed advantages, but removing it completely is a problem if flashrom wants to differentiate between an error return and the response from a flash chip.

Mental note to self: flashrom expects to read the full length of a success response even in the error case. Fix that to avoid eternal delays in the error case.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashrom extension development

Reply #17
Yes, I removed it because I thought it would speed things up, and other commands that return reads don't ack with a 0x01, but it is needed on the no read write or it looks like nothing happened. I've added it back in and recompiled. You can get the latest version from SVN here:

http://the-bus-pirate.googlecode.com/sv ... e-v5.5.hex
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #18
[quote author="ian"]
The UART buffer has 3 bytes.
[/quote]
Ouch. Is that the buffer of the Bus Pirate or the buffer of the FT232 chip?
The FT232R documentation suggests that it has "256 Byte receive buffer and 128 Byte transmit buffer".

[quote author="ian"]
I think you can bundle that [...].
[/quote]
Thanks for confirming.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashrom extension development

Reply #19
That is the hardware buffer of the PIC UART for incoming and outgoing bytes (3 each). It's actually pretty good, most uCs have 1 bytes (none) only.

We have another software buffer in the PIC. The FTDI chip has it's own buffer too.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #20
[quote author="ian"]
Yes, I removed it because I thought it would speed things up, and other commands that return reads don't ack with a 0x01,
Strange. In my copy of the firmware, the 0b0001xxxx command (SPI read/write) does return an ack. I'll have to check if my copy is corrupt.

[quote author="ian"]
but it is needed on the no read write or it looks like nothing happened. I've added it back in and recompiled. You can get the latest version from SVN here:
[/quote][/quote]
Thanks!

I am very sorry that somehow it seems we don't understand each other in the ack case. AFAICS the problem I'm trying to tell you about was created by r461, and r462 doesn't fix it. I'll try to explain.

flashrom sends 0b00000100 writelen.hi=0 writelen.lo=1 readlen.hi=0 readlen.lo=1 one_byte_of_data=READ_STATUS_REGISTER

In the error case (writelen/readlen too long),
Bus Pirate returns 0x00

The flash chip responds with 0x00 to the READ_STATUS_REGISTER command.

In the success case with r461,
Bus Pirate returns 0x00 and there is no way to differentiate between an error and the response from the flash chip which just happens to be zero for that command.

In the success case with r462,
Bus Pirate returns 0x00 0x01 and there is no way to find out if the first byte of the response (0x00) is an error code or the first byte of data, so flashrom has no idea whether it should continue reading.

AFAICS the Ack would be best placed directly before the loop which transmits buffer contents over the UART. Another thing is CS# timing with regards to the UART. May I suggest a slightly modified code flow? I moved SPICS changes directly before the write-from-buf and directly after the read-to-buf. Besides that, the Ack response is now sent before the buffer is returned, but after all the timing critical stuff is done. This means that once the Ack is in, flashrom knows that the write/read operation is over, and all that remains is fetching the response from the chip. I also killed case 0b0101 and case 0b0110.
Code: [Select]
                                        case 0b0100: //write-then-read
                                                //get the number of commands that will follow
                                                while(U1STAbits.URXDA == 0);//wait for a byte
                                                fw=U1RXREG; //get byte
                                                fw=fw<<8;
                                                while(U1STAbits.URXDA == 0);//wait for a byte
                                                fw|=U1RXREG; //get byte

                                                //get the number of reads to do
                                                while(U1STAbits.URXDA == 0);//wait for a byte
                                                fr=U1RXREG; //get byte
                                                fr=fr<<8;
                                                while(U1STAbits.URXDA == 0);//wait for a byte
                                                fr|=U1RXREG; //get byte


                                                //check length and report error
                                                if(fw>=TERMINAL_BUFFER||fr>=TERMINAL_BUFFER){
                                                        UART1TX(0);
                                                        break;
                                                }

                                                //get bytes
                                                for(j=0; j<fw; j++){
                                                        while(U1STAbits.URXDA == 0);//wait for a byte
                                                        bpConfig.terminalInput[j]=U1RXREG;
                                                }
                                              
                                                SPICS=0;
                                                for(j=0; j<fw; j++){
                                                        spiWriteByte(bpConfig.terminalInput[j]);
                                                }

                                                for(j=0; j<fr; j++){ //read bulk bytes from SPI
                                                        bpConfig.terminalInput[j]=spiWriteByte(0xff);
                                                }
                                                SPICS=1;

                                                UART1TX(1);//send 1/OK

                                                for(j=0; j<fr; j++){ //send the read buffer contents over serial
                                                        UART1TX(bpConfig.terminalInput[j]);
                                                }

                                                break;

If I'm seeing problems where there are none, please tell me.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashrom extension development

Reply #21
Sounds great. I replaced the routine and uploaded a new nightly compile. Save URL as my previous post.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #22
You're right about the ack to 0xa0 + bytes, it does ACK in SPI. I forgot about that. The new PIC modes don't do that, I'm trying to make everything a little faster.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #23
Have you had a chance to test the new command? Just let me know if there's anything I can tweak for you.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #24
Not yet. The problem is that if I upgrade my Bus Pirate, I don't have a way to test new flashrom against old Bus Pirate firmware anymore. From a support perspective, that would be unwise since people expect flashrom to continue working just fine even if their Bus Pirate is at an ancient revision.
I could post my patch to the flashrom mailing list and take you in CC so you (or anyone else interested) can test. I also know a few people who own a Bus Pirate and might be interested in testing a new firmware together with the patch.
What do you think?
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashrom extension development

Reply #25
If you have a pickit or icd (or any pic24 programmer) you could always revert to an older version (bootloader). If you don't have any we could write a bootloader v2 installer for you.

Re: Flashrom extension development

Reply #26
What version are you currently at? You can install any v4+ firmware with the v4+ bootloader, going back to v3.6 or earlier is a problem.

To make a universal version, the first time you send the new flashrom command, do a short pause, and then check for 0x00 (unknown command). If you get 0x00, the command is unknown, fall back to the old method and remind the user to upgrade for better speed.

I'm curious about the speed increase. Lots of people have complained about really long read/write times, I think this extension will help a ton. When I went from short packets to bulk reads in the PIC programming support, reads went from an hour to seconds.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashrom extension development

Reply #27
I actually tried autodetection with the old firmware and it had spectacular side effects. You see, checking for availability of a command is nice in theory, but in practice it goes like this:

Send 0x04 0x00 0x00 0x00 0x00 (newSPI, writelength 0, readlength 0)
The new Bus Pirate responds with 0x01 (Ack). Good.
The old Bus Pirate responds with 0x00 0x42 0x42 0x49 0x4f 0x31 0x42 0x42 0x49 0x4f 0x31 0x42 0x42 0x49 0x4f 0x31 0x42 0x42 0x49 0x4f 0x31  (Nack, BBIO1, BBIO1, BBIO1, BBIO1). Slightly inconvenient. This also means that if I try anything besides writelength=0, readlength=0 the bitbang mode will interpret them as commands and end up in some random (well, dependent on writelength/readlength) mode and random code execution in that mode.

Just sending the first byte of the new command and looking for Ack/Nack won't work either: The Nack (old firmware) comes immediatedly (good). The Ack (new firmware) is only sent after writelength and readlength have been shifted in, so I can either wait a predefined time (which is unreliably by definition) for a Nack before I decide to continue, or I simply hope that a stream of 0x00 in SPI mode will always (for all future generations) exit SPI mode and end up in BBIO mode.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashrom extension development

Reply #28
how about changing the modestring (SPI1) to SPI2?

No more secrets handshakes with uncertain outcomes... ;)

Re: Flashrom extension development

Reply #29
Quote
so I can either wait a predefined time (which is unreliably by definition) for a Nack before I decide to continue, or I simply hope that a stream of 0x00 in SPI mode will always (for all future generations) exit SPI mode and end up in BBIO mode.

No worries then, I guessed you already had a function with a timeout for checking for ack/nack that you were comfortable with. The Bus Pirate does return the NACK 'immediately', as in there's no bus operations that delay it, but I get that that's not predictable enough.

I'm hesitant to change the version string because other apps (AVRdude) would have to be updated even though their commands were not effected. If mode is SPI1, 0x00 will always exit SPI and end up in BBIO.

If this is the only thing in the way of a speedier protocol, I'm willing to add an alternate command that simply replies 0x01, but will fail 0x00 in older versions. Or we could add something that prints the version string in BBIO mode, then you could judge which protocols are supported.
Got a question? Please ask in the forum for the fastest answers.