ts-7000
[Top] [All Lists]

[ts-7000] Re: ts7200 won't boot into redboot... I erased flash and kille

To:
Subject: [ts-7000] Re: ts7200 won't boot into redboot... I erased flash and killed it....
From: "yur_grampa" <>
Date: Wed, 07 Jun 2006 17:46:53 -0000
Chris:
Thanks for the response. Things just did not seem to add up.
Your post, though may help those users with the ts7250.
I have found out some more on not being able to use the serial_blaster
and in case you are interested here it is:

By using the fis erase -f 0x60000000 -l 1024

I truly did kill the ts7000. Here is my reasoning:

By preventing the board from going thru its normal boot up, the red
and green led's flash at a 2hz rate. This 2 hz rate is the same signal
that feeds the 4020 (U21 pin 3). This higher flash rate on a non
bootable board like mine means the board resets way before any
boot.bin file can be loaded. Attempting to remove pin 11 and tie it
high(on the 4020) has NO EFFECT on the blink rate, so I would venture
to say the only fix may be with the ts-9420 blaster board or sending
the board in. Unfortunately I do not want to have to send the board in
when I mess up.
I proved the hardwired watchdog "issue"  to myself by taking a scope
and measuring the pad where pin 11 touched still results in seeing a 2
hz signal. In effect, there is no easy way to disable the
watchdog timer on a ts7000(mine is rev B) and the watchdog still
appears to be in control of the boot process an prevents serial
blaster from loading the boot.bin file (even with jumper 1 on).
      On page 19 of the ts7000 manual it states that the watchdog can
be programmed for 1 sec-8 sec. My measurements (and what Curtis has
stated) is that the ts7000 has a faster timer expiration than the
ts7250. And on the ts7000 this is hard programmed into the board. And
if you create a problem in the bootflash like I did, you will not be
able to recover from it as easily as the ts7250 (no EEPROM). 
One interesting find I made is that in the technical reference manual
for the EDB9302 (videon central) they include a jumper to disable the
watchdog timer. This truly would be a nice feature to have included on
the ts-boards in my opinion(hey what about using one of the reserved
jtag jumpers?)

Another issue is lack of an EEPROM to store boot code (the EDB9302
also includes this). In the EDP9302 manual page 18 it states it
supports boot-up over a serial interface from its serial EEPROM and
this bootup is determined upon hardware reset. 
I noted that the ts7250 does have eeprom so I feel that overall the
ts7250 is superior to the ts7000 for the same price even though the
ts7250 does not include the compact flash adaptor.
I would be very interested in finding out if anyone with a ts7250 has
used the:
fis erase -f 0x60000000 -l 1024 
and then been able to recover using serial blaster. I am considering
purchasing one and try this out but if it fails then what?
Of course sending the board in to be reflashed would be an option or
purchasing the ts-9420 blaster board may work but killing a board for
the sake of killing is costly and if the engineers know the answer I
hope they will post it.

Well, thats my 2 cents worth and if anyone reading this thinks I
misrepresented anything please correct me....

 


--- In  Christopher Friedt <> wrote:
>
> Ack. I thought the board in question was a TS-7250 but I must have
misread.
> 
> Good luck yur_grampa!
> 
> ~/Chris
> 
> Curtis Monroe wrote:
> > I tried to serial boot my TS-7200 today. Its watchdog is set for 1
second. So 
> > it's impossible to serial boot it without hardware modifications,
(or a CPLD 
> > reprogram).
> > 
> > The EP9301 on my board downloads the serial boot program at
9600bps. It can 
> > only load 960 Bytes in one second. Not even half of the 2048 Bytes
needed to 
> > load the SerialBlaster Boot loader.
> > 
> > My board is a TS-7200 Rev B.
> > 
> > -Curtis.
> > 
> > 
> > On June 5, 2006 11:24 am, Christopher Friedt wrote:
> >> 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 <curtis@> 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 Links
> >>
> >>
> >>
> >>  
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> >
>





------------------------ Yahoo! Groups Sponsor --------------------~--> 
You can search right from your browser? It's easy and it's free.  See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/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/
 



<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU