Hello yur_grampa,
I had the same problem. I edited serialblaster, turned off the
verbosity, stopped serialblaster from flushing the tty buffer every
byte, and then recompiled it. The error your getting stems from the
watchdog timer on the ts-7xxx boards. With the flushing as it is now, it
takes approximately 10 x longer to send the actual bin.
the key line was # 186 which says not to flush the buffer unless the
number of chars written (x) was a multiple of 1024... Note: There is a
lot of other junk in there, but don't get confused w/ it... the key line
is "WriteByte(fd, ch, ((x%1024) == 0) );"
Here's a diff if it helps...
--- serial_blaster.c 2005-08-31 21:24:26.000000000 +0000
+++ serial_blaster_modified.c 2006-06-05 15:16:30.000000000 +0000
@@ -167,27 +167,28 @@
{
if(bverbose)
{
- printf("%0.2x", (unsigned char )ch);
+ //printf("%0.2x", (unsigned char)ch);
fflush(stdout);
out_count += 2;
-
- WriteByte(fd, ch, TRUE);
+
+ WriteByte(fd, ch, FALSE);
+ //WriteByte(fd, ch, TRUE);
}
else
{
if((x%1024) == 0)
{
- printf(".");
+ //printf(".");
fflush(stdout);
out_count++;
}
-
+ //WriteByte(fd, ch, FALSE );
WriteByte(fd, ch, ((x%1024) == 0) );
}
if(out_count >= LINE_LENGTH)
{
- printf("\n");
+ //printf("\n");
out_count = 0;
}
@@ -451,6 +452,7 @@
printf("\n");
printf("waiting for '>'\n");
+
WaitForChar( fd, '>', 10);
printf("found '>'\n");
@@ -459,10 +461,48 @@
cfsetispeed(pnewtio, B115200);
tcsetattr(fd,TCSANOW,pnewtio);
tcflush(fd, TCIFLUSH);
-
+
ProcessRequests(fd, 10);
}
+void BootFromFile(int fd, const char* file_name, struct termios* pnewtio )
+{
+
+ printf("waiting for '<'\n");
+ WaitForChar( fd, '<', 10);
+ printf("found '<'\n");
+
+ printf("\n");
+ printf("--------- SENDING 2K BOOT FILE: \"%s\" ---------\n",
file_name);+// OutputFile(fd, "ts-preboot-ts9.bin", 2048, TRUE);
+// OutputFile(fd, "boot.bin", 2048, TRUE);
+ OutputFile(fd, file_name, 2048, FALSE);
+ printf("--------------------------------------------------\n");
+ printf("\n");
+
+
+
+ printf("waiting for '>'\n");
+
+
+
+ WaitForChar( fd, '>', 10);
+ printf("found '>'\n");
+
+
+
+ //tcflush(fd, TCIFLUSH);
+ //cfsetospeed(pnewtio, B115200);
+ //cfsetispeed(pnewtio, B115200);
+ //tcsetattr(fd,TCSANOW,pnewtio);
+ //tcflush(fd, TCIFLUSH);
+
+ //SendFileToTS72XX(fd, "redboot.bin");
+
+ //ProcessRequests(fd, 50);
+}
+
+
//=============================================================================
int main(int argc, char *argv[])
{
@@ -478,6 +518,7 @@
bzero(&newtio, sizeof(newtio));
newtio.c_cflag = B9600 | CRTSCTS | CS8 | CLOCAL | CREAD;
+ //newtio.c_cflag = B115200 | CRTSCTS | CS8 | CLOCAL | CREAD;
newtio.c_iflag = IGNPAR;
newtio.c_oflag = 0;
@@ -490,11 +531,13 @@
cfmakeraw(&newtio);
tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&newtio);
-
+
// GetEP93XXAboutInfo(fd);
// RequestEP93XXSerialTest(fd);
-// BootFromFileAndProcessRequests(fd, "ts-preboot-ts9.bin", &newtio );
BootFromFileAndProcessRequests(fd, "boot.bin", &newtio );
+// BootFromFileAndProcessRequests(fd, "boot.bin", &newtio );
+// BootFromFile(fd, "boot.bin", &newtio );
+// DumpMemoryFromTS72XXToFile(fd, "memory_dump.bin");
tcsetattr(fd,TCSANOW,&oldtio);
yur_grampa wrote:
> Thank you for the info Curtis.
> I get the message:
> waiting for '>'
> ERROR!!! Expected '>' but found '<'
>
> Unless I change the boot.s file from:
> .org 2048 @ ensures the file is 2k in size. (no more, no less)
>
> to
> .org 2040 @
>
> and recompile....
>
> Then I get:
> 000000000000000000000000000000000000000000000000boot.bin: Success
>
> ***Exiting***
> ***********************
>
> I really do not know how Success shows up(must be sent from the TS7000 )
> because entering:
> linux:/usr/local/opt/sb # find /usr/local/opt/sb -type f -print |xargs
> grep -n "Success"
> linux:/usr/local/opt/sb #
>
> yields nothing.... from serialblaster.c or any of the other support
> files...
>
> I can only guess that the ts7000 responded with a Success due to file
> transfer.... unfortunately nothing else happens -- it never gets to the:
> waiting for '>'
> found '>'
>
> so it does not go to the next function of serial blaster code which as
> you know is
> 1.open the bootloader
> 2.wait for length acknowlegement
> 3.send redboot.bin
> 4. execute redboot...
>
> obviously something is not going correctly so I am left with taking
> the messages received and try to make sense of them-which in this case
> will take me some time, but with help I hope it is possible...
>
> This kind of troubleshooting can frustrate me but I find the
> application very worthy of looking into at great depth, for my own sake..
> I feel lucky that such an interesting application is even offered as
> open source...
> If I get it to work, I will feel more at ease in being dangerous with
> commands I do not know much about... and will want to get another
> model ts7xxx to mess around with....
>
>
>
>
>
>
>
> --- In Curtis Monroe <> wrote:
>> You don't need to "pad" to boot file!!!
>> The ".org 2048" does that for you.
>>
>> You just can't go over 2048 Bytes. (or you get the error I put in to
> warn you)
>> Boot.S should easily fit in the 2048 Byte limit. Boot.S is only
> really tight
>> when you are making an EEPROM image. The EEPROM image contains the
> NAND ECC
>> routines. The TS7200 does not have a NAND chip, so you don't need
> that code.
>> And it doesn't even have an EEPROM, it boot directly from NOR Flash.
>>
>> If you are not getting a message that says:
>>
>> waiting for '>'
>> found '>'
>>
>> Then you failed to load the 2048 Byte boot code before the watchdog
> reset. The
>> boot code is never executed till you get this message.
>>
>> Are you getting this message?
>>
>> -Curtis.
>>
>>
>>
>>
>>
>>
>> On June 2, 2006 08:42 pm, yur_grampa wrote:
>>> Bucky2090 in previous post mentioned pg 61 from the Cirris
>>> EP9301_User_Guide:
>>> cpu outputs a ">" to signify 2048(decimal) characters from UART1 have
>>> been read.
>>> That really helped. I did not know how that happened. So I
>>> took the screen output of the boot.bin file that serial blaster sends
>>> to the ts7200 and noted that it was around 2640 characters. Looking
>>> into boot.s
>>> (that eventually compiles to boot.bin) I noted that near the end a ck
>>> for size is done:
>>> .org 2048@ ensures the file is 2k in size. (no more, no less)
>>> I then realized that the compiled size of boot.bin must be too large
>>> even though I did nothing to it but change the value of 32 to 16 on
>>> one line of code!
>>> So now a new adventure begins, to try and determine how to get a
>>> workable boot.bin that is 2048 and not 1 character more or less...
>>> Wow! What trickster thought up this one!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Protect your PC from spy ware with award winning anti spy technology. It's free.
http://us.click.yahoo.com/97bhrC/LGxNAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|