Mathias Dietz Weblog

Next Steps:

Hi Mathias.
On Mon, Aug 15, 2005 at 09:20:40AM +0200, Mathias Dietz wrote:
>          jtag> detect
>          IR length: 5
>          Chain length: 1
>          Device Id: 01101001001001100100000000010011
>            Manufacturer: Intel
>            Part:         PXA250
>            Stepping:     PXA255A0
>            Filename:     /usr/local/share/jtag/intel/pxa250/pxa250c0

>          jtag> discovery
>          Detecting IR length ... 5
>          Detecting DR length for IR 11111 ... 1
>          Detecting DR length for IR 00000 ...         <<------- the board
>          is resetted and turned off  

During EXTEST (00000) the previous content of the BSR is transferred to the
PXA255 pins. While standard usage (as flash programming) we are using
SAMPLE/PRELOAD to set default BSR bit values, but during 'discovery' the
internal defaults are used because 'discovery' has no knowledge about
SAMPLE/PRELOAD instruction code.

It looks like your board has a feature that perfoms reset (or turn-off) of the
board when some value (probably 0) is present on a GPIO (or another pin) of the
CPU. In that case it looks like a bad board design for me. Anyway, if that is
your case you should not use the 'discovery' command. To enable flash
programming you could adjust BSR bit defaults as needed for your board.

Regards.

On 8/15/05, Mathias Dietz  wrote:

> But when I start the detectflash or dicovery command, the board resets and
> turns off.

I don`t know your specific hardware, but I`m guessing that something
in the bus driver for the PXA series parts is triggering the behaviour
you see.  Most bus drivers work by shifting in a series of bits that
apply to /all/ the I/O for the CPU and repeating this over and over to
produce valid external read/write signals to the flash.  If this
series of bits happens to set the bits that control a reset/power
off/watchdog for your system, then you would see the behavior
you`re getting.

Hardware, n.:
        The parts of a computer system that can be kicked.

cfi.c (Common Flash Interface)
function cfi_detect(...)
line #104
write1( CFI_CMD_QUERY_OFFSET, CFI_CMD_QUERY );

Hi,
I try to flash my pxa255 based board using a selfmade Xilinx DLC5 cable.
The detect and print command runs fine:
jtag> cable parallel 0x378 DLC5
Initializing Xilinx DLC5 JTAG Parallel Cable III on parallel port at 0x378
jtag> detect
IR length: 5
Chain length: 1
Device Id: 01101001001001100100000000010011
  Manufacturer: Intel
  Part:         PXA250
  Stepping:     PXA255A0
  Filename:     /usr/local/share/jtag/intel/pxa250/pxa250c0
jtag> print
 No. Manufacturer              Part                 Stepping Instruction          Register
++-------------------------------------------------------------------------------------------++
   0 Intel                     PXA250               PXA255A0 BYPASS               BR

Active bus:
*0: Intel PXA2x0 compatible bus driver via BSR (JTAG part No. 0)
        start: 0x00000000, length: 0x04000000, data width: 32 bit, (Static Chip Select 0)
        start: 0x48000000, length: 0x04000000, data width: 32 bit, (Memory Mapped registers (Memory Ctl))
But when I start the detectflash or dicovery command , the board resets and turns off.
I have to turn it on the use any JTAG command.
jtag> detectflash
jedec_detect: mid ffffffff, did ffffffff			<<-- the board is resetted and turned off 
Flash not found!
jtag> discovery							<<-- manually turned on the board again
Detecting IR length ... 5
Detecting DR length for IR 11111 ... 1
Detecting DR length for IR 00000 ...				<<-- the board is resetted and turned off 
Some additional infos (might help):
jtag> instruction SAMPLE/PRELOAD
jtag> shift ir
jtag> shift dr
jtag> dr
1001110011111111111111111000000111000000111111110110000000101101111111110000001111111111101101000001100110000100010010110110011111010011001110000110001100000000000
1111100000011110011111110000000000000000000000111000000111100010110000000101001000000100000001101111111100101000000000000000100010010010110001010000000000000111101
111111110110000001011111110011111111101010111100110011001000101100111100010111000000
jtag> get signal BOOT_SEL[0]
BOOT_SEL[0] = 1
I tried jtag tools 0.51 and the current CVS version.

For testing purposes, you need to download the boot loader itself before you build an operating system (OS) image. Prior to this procedure, you must create
a boot loader .bib file, which produces Eboot.nb0. Eboot.nb0 is a raw memory boot loader image suitable for writing directly to flash memory through JTAG.
The .bib file also produces Eboot.bin, which is a record-based boot loader image suitable for download from Platform Builder over Ethernet. For more
information about creating the Boot Loader .bib file, see Creating the Boot Loader .bib File.
Note:Creating a test .bin file for download overwrites the currently executing RAM boot loader image. The results are unpredictable if the download
boot loader image does not match the running boot loader image. To prevent the currently executing RAM boot loader image from being overwritten, 
build a test copy of Eboot.bin that resides at a different location in RAM.
To create a test .bin file for download
	1. Create a backup file of your Eboot.bib file.
	2. In the test file, change all memory locations to prevent conflicts with the boot loader currently stored on the device.
	3. At the command prompt, enter the following command to build the new boot loader.

I've tried to analyze the protocol used for the WLAN synchronizations , but I don't have success, yet.

The WLAN synchronization uses the UDP protocol at the beginning, and after some kind of handshake TCP is used to transfer the data.

It doesn`t look like a well known protocol, seems to be a Aireo specific protocol.

This is send as an answer from the Soniqcast software (bt[xx] identifies the array position):

//inoSsaCq
bt[0]=105; bt[1]=110; bt[2]=111; bt[3]=83; bt[4]=115; bt[5]=97; bt[6]=67; bt[7]=113;
//91ce2d 00
bt[8]=-111; bt[9]=-50; bt[10]=45; bt[11]=0;
//MAC of the PC
bt[12]=0; bt[13]=(byte)0xDD; bt[14]=0xf9; bt[15]=(byte)0xcf; bt[16]=0x8b; bt[17]=(byte)0xb2;
//cmd or cc cc as answer
bt[18]=(byte)0xcc; bt[19]=(byte)0xcc;
//8x 00 (as answer)
bt[20]=0; bt[21]=0; bt[22]=0; bt[23]=0; bt[24]=0; bt[25]=0; bt[26]=0; bt[27]=0;
//32byte name (00 terminiert) rest cc as answer
bt[28]=77; bt[29]=97; bt[30]=116; bt[31]=122; bt[32]=101; bt[33]=66; bt[34]=66; bt[35]=66; bt[36]=101; bt[37]=111; bt[38]=65;
bt[39]=0; bt[40]=(byte)0xcc; bt[41]=(byte)0xcc; bt[42]=(byte)0xcc; bt[43]=(byte)0xcc; bt[44]=(byte)0xcc; bt[45]=(byte)0xcc; bt[46]=(byte)0xcc;
bt[47]=(byte)0xcc; bt[48]=(byte)0xcc; bt[49]=(byte)0xcc; bt[50]=(byte)0xcc; bt[51]=(byte)0xcc; bt[52]=(byte)0xcc; bt[53]=(byte)0xcc; bt[54]=(byte)0xcc;
bt[55]=(byte)0xcc; bt[56]=(byte)0xcc; bt[57]=(byte)0xcc; bt[58]=(byte)0xcc; bt[59]=(byte)0xcc; bt[60]=0;
//mac aireo
bt[61]=(byte)0x1a; bt[62]=(byte)0xa2; bt[63]=(byte)0x18; bt[64]=(byte)0x78; bt[65]=(byte)0x33; //as answer2x cc bt[66]=(byte)0xcc; bt[67]=(byte)0xcc;
//as answer 01 and 11x 00
bt[68]=01; bt[69]=0; bt[70]=0; bt[71]=0; bt[72]=0; bt[73]=0; bt[74]=0; bt[75]=0; bt[76]=0; bt[77]=0; bt[78]=0; bt[79]=0;
//as answer rest is cc
bt[80]=(byte)0xcc; bt[81]=(byte)0xcc; bt[82]=(byte)0xcc; bt[83]=(byte)0xcc; bt[84]=(byte)0xcc; bt[85]=(byte)0xcc; bt[86]=(byte)0xcc; bt[87]=(byte)0xcc;
bt[88]=(byte)0xcc; bt[89]=(byte)0xcc; bt[90]=(byte)0xcc; bt[91]=(byte)0xcc; bt[92]=(byte)0xcc; bt[93]=(byte)0xcc; bt[94]=(byte)0xcc; bt[95]=(byte)0xcc;
bt[96]=(byte)0xcc; bt[97]=(byte)0xcc; bt[98]=(byte)0xcc; bt[99]=(byte)0xcc;

After mounting the Aireo it is possible to copy files to it using the cp command. But to utilize the the playlist function, I wrote my own command line

tool which copies the mp3 files and creates the corresponding playlist (spl).

AireoCreator

Syntax: Creator <playlist name> <aireo_mount_point> <mp3files...>

Read the ID3 tags of the mp3 files, copies them to the Aireo and creates a playlist file.

AireoRemover

Syntax: Remover <playlist name> <aireo_mount_point>

Delete the playlist file and all contained mp3 files.

AireoConverter

Syntax: Converter <aireo_mount_point> <m3u playlist.....>

Read the ID3 tags of the mp3 files in the m3u playlist, copies them to the Aireo and creates a playlist file.

If you are interested in my programs incl. source code, feel free to contact me.

The HY57V561620C is a 268,435,456bit CMOS Synchronous DRAM, ideally suited for the main memory applications which require large memory density
and high bandwidth. HY57V561620C is organized as 4banks of 4,194,304x16. HY57V561620C is offering fully synchronous operation referenced to a positive edge of the clock.
All inputs and outputs are synchronized with the rising edge of the clock input. The data paths are internally pipelined to achieve very high bandwidth.
All input and output voltage levels are compatible with LVTTL.
Programmable options include the length of pipeline (Read latency of 2 or 3), the number of consecutive read or write cycles initiated by a single control command 
(Burst length of 1,2,4,8 or full page), and the burst count sequence(sequential or interleave).
A burst of read or write cycles in progress can be terminated by a burst terminate command or can be interrupted and replaced by a new
burst read or write command on any cycle. (This pipelined design is not restricted by a `2N` rule.)

SSP Pins
SSPSCLK/                             Pulled High -           ICOCZ Synchronous serial port clock. (output)                       Note [3] GPIO[23]
SSPSFRM/                             Pulled High -           ICOCZ Synchronous serial port frame. (output)                       Note [3] GPIO[24]
SSPTXD /                             Pulled High -           ICOCZ Synchronous serial port transmit. (output)                    Note [3] GPIO[25]
SSPRXD/                              Pulled High -           ICOCZ Synchronous serial port receive. (input)                      Note [3] GPIO[26]
SSPEXTCLK/                           Pulled High -           ICOCZ Synchronous serial port external clock. (input)               Note [3] GPIO[27]

JTAG and Test Pins
                    JTAG test interface reset. Resets the JTAG/debug port.
                    If JTAG/debug is used, drive nTRST from low to high
                    either before or at the same time as nRESET. If JTAG is    Input In p u t
nTRST           IC
                    not used, nTRST must be either tied to nRESET or tied
                    low.
                    JTAG test data input. (input) Data from the JTAG
TDI             IC  controller is sent to the PXA255 processor using this pin. Input In p u t
                    This pin has an internal pull-up resistor.
                    JTAG test data output. (output) Data from the PXA255
TDO             OCZ processor is returned to the JTAG controller using this    Hi-Z  Hi-Z
                    pin.
                    JTAG test mode select. (input) Selects the test mode
TM S            IC  required from the JTAG controller. This pin has an         Input In p u t
                    internal pull-up resistor.
                    JTAG test clock. (input) Clock for all transfers on the
TCK             IC                                                             Input In p u t
                    JTAG test interface.
TES T           IC  Test Mode. (input) Reserved. Must be grounded.             Input In p u t
TESTCLK         IC  Test Clock. (input) Reserved. Must be grounded.            Input In p u t

Some results from my investigations (unstructured):

-There are no common TCP ports open to access the Aireo

-The Aireo does not send any WLAN packages on boot , so a remote boot seems to be not possible. But the

eboot.bin contains strings like "TftpReceiver, port: 0x%X, wkp: 0x%X\n\r" which indicates that it has a way

to receive something (firmware?) over network (maybe IP over USB ,not the WLAN).

- I tried RNDIS but I can`t get is running. Also a USB Monitor doesn`t show any bootp, tftp, debug or log messages.

- Eboot.bin Aireo.bin contains the firmware , eboot.bin seems to be basically the same for all WinCE devices

The Soniqcast Aireo mp3 player is a very nice thing , but unfortunately the required software to manage the Aireo is only for windows :-(.

So I´ve planned to do some research with the following goals:

1) write a application to manage the Aireo with Linux (using java)

• command line tools for creating playlists (done)

• copy mp3 files via USB under Linux (done)

• copy mp3 files via WLAN (todo)

• Full featured GUI for Aireo management (in progress)

2) replace the Aireo firmware with a Linux based firmware

• examine the Aireo hardware (done)

• find a way to boot an other system (in progress)

• find a way to flash an other bootloader using jtag(in progress)