ts-7000
[Top] [All Lists]

Re: [ts-7000] serial blaster - tcdrain behaviour

To:
Subject: Re: [ts-7000] serial blaster - tcdrain behaviour
From: Curtis Monroe <>
Date: Thu, 18 May 2006 12:54:11 -0400
My goal in designing the SerialBlaster was to make a utility to restore a
TS-7200 board that had a bad EEPROM or flash image.

But, I also wanted to make my own boot loader. So I made the SerialBlaster
compilable as a burnable image, that can replace the existing 2KB EEPROM
image.

The philosophy of my boot loader is a little different than the TS boot
loader.

The TS boot loader does the following:


- The ARM THUMB machine language PRE-BOOT image from EEPROM executes, and:
---Configures and tests SDRAM
---Loads a 16KB TS-BOOTROM from the beginning of NAND flash to location
0x00300000 with no error correction. (This should not be a problem as the
flash chip guarantees the first block [16KB] is shipped in a valid state. But
it could go bad over time.)
---Executes the TS-BOOTROM in ARM mode.

- The TS-BOOTROM does the following:
--- Configure EP9302 settings
--- Retests Memory
--- A CRC Check of itself to make sure it isn't corrupt. (I guess it could
crash if the corruption happened before the code executed the CRC).
--- Configures all connected TS PC-104 boards
--- Loads 256KB Redboot image from flash to 0x00008000 without error
correction. This is dangerous as NAND flash should always have error
correction.
--- Executes RedBoot.


The SerialBlaster bootloader takes a different strategy. It needs to be
compiled for the specific board that it will be used on. The amount of SDRAM
and NAND flash is compiled into the executable. It is written in hand
optimized ARM assembly language, and moves all configuration of the system to
RedBoot. It doesn't load a 16KB image from Flash, It loads Redboot directly.
It have flash error correction so Redboot is loaded error free. Redboot need
to be modified to perform all the functions that that 16KB TS-BOOTROM did. I
think Redboot is a more appropriate place for these functions. It means the
bootloader simply focuses on loading Redboot.

Unfortunately I haven't time to add that functionality to RedBoot and I don't
have the PC-104 cards to test it. So anyone looking to use the SerialBlaster
as a bootloader should add the functions to redboot that they intend to use.
You can look at a commented disassembled copy of the TS-BOOTROM included with
the SerialBlaster source as a starting place for adding this functionality.

-Curtis.




On May 17, 2006 10:48 pm, chris dewbery wrote:
> Hi!
>
> I have been experimenting with the serial_blaster tool, looks like a very
useful
> tool. :)
>
> I did have one problem getting it running, receiving the following error.
>
> $ ./serial_blaster
> START
> waiting for '<'
> found '<'
>
> --------- SENDING 2K BOOT FILE: "boot.bin" ---------
> 4352555301da8fe202c1a0e3d300a0e300f029e100f069e12c0000ebc20000eb310000e
> <snip>
> 0000000000000000
> 2048 Bytes in 22 seconds.
> --------------------------------------------------
>
> waiting for '>'
> ERROR!!! Expected '>' but found '<'
>
> After comparing my output with the expected output from the readme file
> I noticed that the time taken to send the boot.bin file was substantially
> longer than the example.
>
> After a bit of digging in the serial_blaster.c file I found the following
section.
>
> line 169:
>
>       if(bverbose)
>       {
>               printf("%0.2x", (unsigned char  )ch);
>               fflush(stdout);
>               out_count += 2;
>
>               WriteByte(fd, ch, TRUE); <<-- by setting this to true the 
> WriteByte
function
>       }                                     calls tcdrain() for every byte. 
> this
behaviour
>                                             differs from the !bverbose path 
> which only calls
>                                             tcdrain() every 1024 bytes.
>       else
>       {
>               if((x%1024) == 0)
>               {
>                       printf(".");
>                       fflush(stdout);
>                       out_count++;
>               }
>
>               WriteByte(fd, ch, ((x%1024) == 0) );
>       }
>
> I found that if I changed the WriteByte(fd, ch, TRUE) line to read
WriteByte(fd, ch, ((x%1024) == 0) );
> everything works as expected.
>
> This is most probably a mis-configuration on my behalf however I have
attached a patch with my change
> just incase others have the same issue.
>
> my system configuration consists of:
>
>       debian unstable, 2.4.32 kernel, gcc version 3.3.6 (Debian 1:3.3.6-12)
>
>
> regards
>
>
> Chris.
>
>
>
> 
> Yahoo! Groups Links
>
>
>
> 
>


------------------------ Yahoo! Groups Sponsor --------------------~-->
Home is just a click away.ï Make Yahoo! your home page now.
http://us.click.yahoo.com/DHchtC/3FxNAA/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