Hardware: Difference between revisions
Line 59: | Line 59: | ||
The sernum daemon uses it to: | The sernum daemon uses it to: | ||
- create the DES and 3DES keys for the reciva:// protocol. (That protocol is e.g. used to get the playlists from the reciva servers) | - create the DES and 3DES keys for the reciva:// protocol using XTEA cipher. | ||
(That protocol is e.g. used to get the playlists from the reciva servers) | |||
- get the serial number of the device | - get the serial number of the device | ||
- reset the device (not tested yet) | - reset the device (not tested yet) | ||
Atmel is accessed via a simple serial protocol using these ports: | Atmel is accessed via a simple serial protocol using these ports: | ||
GPE11 - SACK (Atmel | GPE11 - SACK (ARM <- Atmel) | ||
GPE12 - SDAT ( | GPE12 - SDAT (ARM <-> Atmel) | ||
GPE13 - SCLK ( | GPE13 - SCLK (ARM -> Atmel) | ||
At startup the sernum daemon simply mmaps the memory area at 0x56000000 with size 0x100 to directly access the GPIO's at 0x56000040 and 0x56000044. | At startup the sernum daemon simply mmaps the memory area at 0x56000000 with size 0x100 to directly access the GPIO's at 0x56000040 and 0x56000044. | ||
Some standalone tool which access the Atmel and reads serial number, version and calculates some example challenges will soon be uploaded into the SVN repository. | Some standalone tool which access the Atmel and reads serial number, version and calculates some example challenges will soon be uploaded into the SVN repository. | ||
Another guess is that it controls the booting of the main processor. The big processors often have built-in boot loaders that are accessed by setting pins high or low at reset. This can be controlled with links, but using a tiny processor makes more sense. It could for instance invoke the boot loader at start-up and check for a few seconds to see if there is any communication. If there is some, it lets the boot continue. If there is none it resets the processor, set the links to run mode and the starts the processor. This is much easier than opening the box and setting links/switches! | Another guess is that it controls the booting of the main processor. The big processors often have built-in boot loaders that are accessed by setting pins high or low at reset. This can be controlled with links, but using a tiny processor makes more sense. It could for instance invoke the boot loader at start-up and check for a few seconds to see if there is any communication. If there is some, it lets the boot continue. If there is none it resets the processor, set the links to run mode and the starts the processor. This is much easier than opening the box and setting links/switches! |
Revision as of 02:47, 1 September 2008
Radios
The Barracuda is used in these radios.
If you think you can help build this public information resource, please create an accountand get involved.
Hardware Matrix
The radios contain slightly different internal hardware architectures, including different LCDs, Keypads and some different pin connections on the Barracuda module. A Hardware Matrix showing the differences, plus datasheets for the hardware has been compiled.
Barracuda hardware
The Barracuda module is a pretty straightforward, but very compact, board with CPU, flash, ram and some interfacing for audio, buttons and LCD display
The Processor board is marked 'Reciva' and 'IRM2' in the silk screen, and contains (mainly) three devices, all manufactured by Samsung.
The next row of images shows a board outline with pin numbers on the pads. These numbers are by no means official, but until we know the exact purpose of the pins, it's handy to give them a number so everybody is talking about the same thing.
Diagnostics
Diagnostic Captures have been taken to diagnose:
Main CPU
- The central one is the main processor,
Samsung S3C2410 for which a complete datasheet is available
The processor is running at 202.80MHz (MPLLCON=000a1031)
The CPU has the following on-board functions:
- ARM920T core
- PCM Sound device
- USB host/device interface
- TFT LCD/STN LCD Controller (16bit, 640x480 maximum)
- JTAG Port (is TRST Open Drain or Push Pull?)
- ...
Smally Tiny12 CPU
There's also an Atmel Tiny12L MCU onboard. There is only a rough idea what it is doing.
The sernum daemon uses it to:
- create the DES and 3DES keys for the reciva:// protocol using XTEA cipher. (That protocol is e.g. used to get the playlists from the reciva servers) - get the serial number of the device - reset the device (not tested yet)
Atmel is accessed via a simple serial protocol using these ports:
GPE11 - SACK (ARM <- Atmel) GPE12 - SDAT (ARM <-> Atmel) GPE13 - SCLK (ARM -> Atmel)
At startup the sernum daemon simply mmaps the memory area at 0x56000000 with size 0x100 to directly access the GPIO's at 0x56000040 and 0x56000044.
Some standalone tool which access the Atmel and reads serial number, version and calculates some example challenges will soon be uploaded into the SVN repository.
Another guess is that it controls the booting of the main processor. The big processors often have built-in boot loaders that are accessed by setting pins high or low at reset. This can be controlled with links, but using a tiny processor makes more sense. It could for instance invoke the boot loader at start-up and check for a few seconds to see if there is any communication. If there is some, it lets the boot continue. If there is none it resets the processor, set the links to run mode and the starts the processor. This is much easier than opening the box and setting links/switches!
Flash
- The top left device is the Reciva NAND Flash, which a K9F2808U0C: 16Mb*8 flash memory.
RAM
- the bottom left device is SDRAM 16M*16 (K4S561632E-TC75)
Schematic
This schematic (work in progress) is an amalgumation of information extracted from several disassembled radios, plus information extracted from the GPL'd source.
Source Data
Source files (schematic, drawings, etc...) can be found on the Source Files page.