ts-7000
[Top] [All Lists]

Re: [ts-7000] Recovery with SerialBlaster (was Re: NetBSD on a TS-7260)

To:
Subject: Re: [ts-7000] Recovery with SerialBlaster (was Re: NetBSD on a TS-7260)
From: Curtis Monroe <>
Date: Tue, 5 Sep 2006 19:04:41 -0400

On September 5, 2006 06:05 pm, Tom Hansen wrote:

> Well, I figured out why I was not able to boot with the standard TS

> boot code loaded into the eeprom. It was because the 16k

> flash-resident code had been trashed along with everything else and

> needed to be reloaded.

Thats correct TS-BOOTROM need the additional 16KB for the second half of its bootloader. SerialBlaster does it all in 2KB (But it expects RedBoot to pickup the slack, and do anything that can't fit in the 2KB)

>

> Once I did that (with a RedBott "load" followed by an "fis write" to

> 0x60000000) the board booted normally like it used to originally from

> the factory.

>

> I currently have the board configured with the TS stock bootrom and

> 16k boot code, and your modified RedBoot, and everything works.

>

My modified RedBoot dissables the automatic boot scripting that Redboot has. When recovering a board its nice skip RedBoots scripting. You may want to re-enable it. (see my patch file for the location)

> Unfortunately, I have not so far accomplished my original task, which

> was to get NetBSD booting on the board. I can load the kernel into

> RAM with TFTP and boot it, and it actually works, but it does not

> appear to be possible to load it from flash, since the uncompressed

> kernel will not fit in that open space between the RedBoot and RedBoot

> config. (The compressed kernel is hard-coded for TS7200 addresses.)

>

> Is it possible to rebuild RedBoot such that the "(reserved)" space is

> smaller? If it could be shrunk by just 3 megs or so, there'd be room

> for another FIS entry there that could house the NetBSD kernel.

>

The following may help, it gives the flash allocated on each board (Its not perfect but its a start):

//-----------------------------------------------------------------------------

// 0x6000-0000 to 0x60FF-FFFF range NOR FLASH TS-9420 BLASTER BOARD PRESENT

//-----------------------------------------------------------------------------

// 0x6000-0000 - 0x6061-FFFF : 6272 KB reserved

// 0x6000-0000 - 0x6001-FFFF : 128 KB TS-BOOTROM

// 0x6002-0000 - 0x6061-FFFF : 6144 KB LINUX

// 0x6062-0000 - 0x6065-FFFF : 256 KB RedBoot

// 0x6066-0000 - 0x6071-FFFF : 768 KB zimage

// 0x6072-0000 - 0x607B-FFFF : 640 KB

// 0x607C-0000 - 0x607C-0FFF : 4 KB RedBoot config

// 0x607C-1000 - 0x607D-FFFF : 124 KB

// 0x607E-0000 - 0x607F-FFFF : 128 KB FIS directory

// 0x6080-0000 - 0x60FF-FFFF : 8192 KB JFFS2 File System

//---------------------------------------------------------------------------

// TOTAL 16384 KB = 16 MB

// 0x60E2-0000 - 0x60E2-0003 = "SURC" (for 16MB flash)

// 0x607C-030A - 0x607C-030F = MAC ADDRESS (for 8MB flash)

// 0x60FC-030A - 0x60FC-030F = MAC ADDRESS (for 16MB flash)

//-----------------------------------------------------------------------------

// NAND FLASH TS-7250 32MB version (part # NAND256W3A0AN6 )

//-----------------------------------------------------------------------------

// 0x0000-0000 - 0x0000-3FFF : 16 KB "TS-BOOTROM"

// 0x0000-4000 - 0x01D0-3FFF : 29696 KB "Linux" (29 MB)

// 0x01D0-4000 - 0x01FF-FFFF : 3056 KB "RedBoot" (3 MB - 16 KB)

//---------------------------------------------------------------------------

// TOTAL 32768 KB = 32 MB

//-----------------------------------------------------------------------------

// NAND FLASH TS-7250 128MB version (part # NAND01GW3A0AN6 )

//-----------------------------------------------------------------------------

// 0x0000-0000 - 0x0000-3FFF : 16 KB "TS-BOOTROM"

// 0x0000-4000 - 0x07D0-3FFF : 128000 KB "Linux" (125 MB)

// 0x07D0-4000 - 0x07FF-FFFF : 3056 KB "RedBoot" (3 MB - 16 KB)

//---------------------------------------------------------------------------

// TOTAL 131072 KB = 128 MB

// General Memory map (by Dave)

//

//  Fxxx xxxx    SDRAM CHIP 4    Â

//  Exxx xxxx    SDRAM CHIP 3

//  Dxxx xxxx    SDRAM CHIP 2

//  Cxxx xxxx    SDRAM CHIP 1

//  Bxxx xxxx    --------DNU--------

//  Axxx xxxx    --------DNU--------

//  9xxx xxxx    --------DNU--------

//  8xxx xxxx    on chip i/o space

//  7xxx xxxx    CSn7

//  6xxx xxxx    CSn6

//  5xxx xxxx    --------DNU-------

//  4xxx xxxx    --------DNU-------

//  3xxx xxxx    CSn3      Â

//  2xxx xxxx    CSn2       Â

//  1xxx xxxx    CSn1       Â

//  0xxx xxxx    CSn0 or SDRAM CHIP 4 Â

> Alternatively, do you know if there is a way to do the reverse of "fis

> write" and copy from an arbitrary address range in flash to RAM? If

> that was possible, I'd be set, because I could just write the NetBSD

> kernel to an unused place in flash (which is most of it since NetBSD

> can't use the onboard flash anyway) and then, on boot, have a RedBoot

> script that would extract the kernel from that address in flash and

> run it.

>

fis load

RedBoot> help fis

Load image from FLASH Image System [FIS] into RAM

fis load [-d] [-b <memory_load_address>] [-c] name

you might need to specify the "-b" memory address to load the image into.

The "-d" option if for decompresing the image.

look in: (for the code.)

ecosroot/packages/redboot/current/src/flash.c

> I thought that a simply memcpy would work, but it doesn't-- and doing

> a "dump" from RedBoot of Flash memory addresses returns all "FF"'s

> even when I know there's something in flash at that address.

>

> Thanks.

>

>

> --- In Curtis Monroe <> wrote:

> >

> > WOW you made fast progress.

> >

> > A couple quick notes:

> >

> > .org 2048 @ ensures the file is 2k in size. (no more, no less)

> > .end

> >

> > The .org command is there to cause an error if you go over the 2048

> byte limit

> > of the eeprom. The EP9302 will only load 2048 bytes from the eeprom so

> > anything over will not be loaded at boot time.

> >

> > I've started working on a new version of the SerialBlaster that can

> boot from

> > an 8KB eeprom. I soldered off the 2KB eeprom and replaced it with a 8KB

> > eeprom (was easy to do). The new SerialBlaster boots in two stages.

> It first

> > boots the initial 2KB which then loads the additional 6KBs boot loader.

> >

> > You can get a version of the default TS eeprom and redboot images

> and burn

> > them using my serialblaster.

> >

> > -Curtis.

> >

> >

> >

> >

> > On September 2, 2006 01:20 pm, Tom Hansen wrote:

> > > I was able to get the board booting into Redboot from flash again by

> > > doing the following:

> > >

> > > ("Host" refers to the PC being used to rescue the board, "Board"

> > > refers to the board)

> > >

> > > 1. Host: Downloaded SerialBlaster from the Files section of this

> > > Yahoo group.

> > > 2. Host: Built it according to the included directions.

> > > 3. Board: Installed a jumper on JP1.

> > > 4. Host/Board: Booted the board using the newly-build SerialBlaster.

> > > 5. Host: Went into boot.S and changed it to boot in FLASH mode.

> > > and got rid of .org 4096 thing (yes it works anyway)

> > > 6. Host: make clean; make in serialblaster directory.

> > > 7. Host/Board: booted with SerialBlaster.

> > > 8. Above boot only loads boot.bin, then proceeds directly to the

> > > redboot loaded at the previous boot, since it is now in FLASH mode.

> > > 9. Board: Used the following commands on board:

> > >

> > > load -v -r -b 0x00200000 -m xmodem

> > >

> > > 10. Host: transmitted boot.bin to board with xmodem.

> > > 11. Board: burned boot to EEPROM with the following command:

> > >

> > > eeprom_write -b 0x00200000 -o 0 -l 2048

> > >

> > > 12. Board: Now system boots completely from flash.

> > >

> > >

> > > Some particular notes:

> > >

> > > a) Regarding step 5, I tried to retain the boot.bin as originally

> > > compiled, but it would never proceed to Redboot by itself, apparently

> > > staying in serial mode and trying to load Redboot from serial rather

> > > than from flash, thus requiring a rebuild after changing the

> > > definitions in boot.S to indicate FLASH mode. However it then

> > > complained about going backwards (or some such) with the .org 4096

> > > thing. I did see a post by Curtis in which he said the org 4096 thing

> > > was required. I tried very hard to retain it, but in the end I left

> > > it off and it just worked.

> > >

> > > b) All attempts to reflash original TS components (EEPROM and Redboot)

> > > have failed. This is a slight problem because the SerialBlaster

> > > version of Redboot doesn't appear to initialize USB correctly, and

> > > that's where my root NetBSD filesystem is. The failure to reflash the

> > > original components probably has to do with differences between the

> > > 7250 for which SerialBlaster was written, and the 7260 which I have.

> > >

> > > c) Apparently the SerialBlaster versions of EEPROM/Redboot do not make

> > > such extensive use of the "(reserved)" area of flash, because I was

> > > able to write (but not successfully boot from) a NetBSD kernel into

> > > the reserved space without crashing the board. The board still booted

> > > into RedBoot after I did that.

> > >

> > >

> > > I'll post further developments as they occur.

> > >

> > >

> > > --- In Curtis Monroe <curtis@> wrote:

> > > >

> > > > You might try my SerialBlaster utility (search old posts).

> > > >

> > > > I built it for a TS-7250 but it might still work for the TS-7260.

> > > >

> > > > Or you can send it back to TS for a reflash.

> > > >

> > > > -Curtis.

> > > >

> > >

> > >

> > >

> > >

> >

>

>

>

>

>

__._,_.___


SPONSORED LINKS
Single board computer Hardware Computer running slow
Linux os Single board


YAHOO! GROUPS LINKS

  •  Visit your group "ts-7000" on the web.
     
  •  To unsubscribe from this group, send an email to:
     =Unsubscribe
     
  •  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



__,_._,___
<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