A80G9 mainboard hacking and chipset information

Search This thread

scholbert

Senior Member
Aug 1, 2007
1,347
813
Hi,

it's me again... this time the victim of my surgery is my Archos 80 G9 tablet with 8GByte.
The device is working pretty nice, but it's always fun to start investigation on the hardware :D.

Some general words about the design:
It seems obvious that Archos engineers started developing with TI Blaze development platform.
There'd been some hints in the source code and the design looks pretty similar.
Unfortunately there's no schematics of this platform... but fortunately there's the PandaBoard :p.
This board is fully documented (schematics as well) and there are a lot of open development projects all over the web.

Basically the Archos Gen9 tablets share the same base chipset with the Pandaboard and that's why there are many similarities.
One thing notable is the fact, that Archos implemented a eMMC/SD card chipset on the mainboard, instead of using a fully integrated eMMC device as to be found on the Gen8 mainboards.
In other words they coupled an eMMC controller (Phison PS7000) together with raw NAND flash (64GBit MLC).
This subsystem then got connected to mmc2 interface and is used as boot media (eMMC raw boot).

The other thing we may observe, is that the A80G9 and the A101G9 mainboards look pretty much the same in form and shape.
I guess, there are only little differences in the design, if there are any at least ;).
EDIT2: Have a look over here...
http://forum.xda-developers.com/showthread.php?t=1449438
Harfainx did a great job and put down some high-res pics from his A101G9.

Anyway there might be a lot to report, but i think it'll be better to come back from time to time and add some details and information.
You may prepare for some pics as well :D

A80G9 chipset information:
Processor
• Ti OMAP4430/60 (547-pin CBS BGA package) ARM Cortex A9 dual-core at 1/1.5 GHz with DSP
• POWERVR SGX540 Graphic accelerator: 3D OpenGL ES 2.0

Memory
• 512MB/1024MB LPDDR SDRAM (216-pin PoP BGA package) soldered on top of OMAP4430/60
• 8/16GB NAND (52-pin VLGA package) with eMMC bridge chip (PS7000) connected on mmc2 interface

Interfaces
• USB 2.0 OTG (OMAP4430/60 internal interface, MicroUSB connector)
• USB 2.0 EHCI host interface (USB3322 ULPI phy, TYP A connector)
• Micro SD slot (OMAP4430/60 internal mmc1 interface, SDHC compatible)

Display subsystem
• ChiMei 8" TFT-Display EJ080NA-04B (24Bit-LVDS interface)
• Ti SN75LVDS83B LVDS transmitter (56-pin BGA package)

Touchscreen subsystem
• Capacitiv touchscreen unit (Cypress controller TMA340, I2C interface)

HDMI subsystem
• OMAP4430/60 internal 24-Bit HDMI transmitter
• HDMI output (19-pin Mini HDMI connector)

Communication
• Ti WL1271 WiFi (802.11 b/g/n)
• Ti WL1271 Bluetooth 2.1 EDR

GPS chipset
• Ti NL5550 AGPS connected to uart0

Audio chipset
• Ti TWL6040 multichannel audio codec

Miscellaneous
• Built-in speaker
• Built-in Microphone
• Aptina MT9M114 1/6" 720p HD camera (1.26M)

Sensors
• Freescale MMA8453Q G-sensor
• AsahiKasei AK8975 compass-sensor

Power source
• Ti TWL6030 power management chip
• Ti TPS62361 core voltage regulator
• Internal: Lithium Polymer battery
• External: 5V/1.5A Power adapter/charger

Again i did some web research and made a smart datasheet collection.
Grab this zip-file.
EDIT5:
Updated datasheet collection...
Read on for some more information.

So what's next:
I don't know yet...
will start some hacking because i got a damaged mainboard

EDIT1:
Added some low res pics of the mainboard...

EDIT3:
To consider the OMAP4460 variants i added some lines in the chipset spec.
Though i did not open one of these devices, it is likely that Archos did use the same mainboard and upgraded the CPU and PoP-Memory.
Search the Ti website for further information on that SoC.
There's also a document which clarifies the differences between OMAP4430 and OMAP4460.
I may put it here as well if you like :rolleyes:

EDIT4:
Some error corrections...

EDIT6:
Archos 3.0.8 kernel seems to be heavily based on this branch of Ti OMAP kernels:
http://git.omapzoom.org/?p=kernel/o...roid-omap-3.0-4470;hb=p-android-omap-3.0-4470
If you run a diff between these two you'll get a pretty good overview about the Archos specific changes.
Might be interesting for those who like to create a newer kernel for the Gen9 :)

Stay tuned!

scholbert
 

Attachments

  • bottom_battery_s.JPG
    bottom_battery_s.JPG
    144.9 KB · Views: 1,683
  • bottom_ps7000_s.JPG
    bottom_ps7000_s.JPG
    130.4 KB · Views: 1,608
  • bottom_testpoints_s.JPG
    bottom_testpoints_s.JPG
    147.3 KB · Views: 1,549
  • tft_back_id_s.JPG
    tft_back_id_s.JPG
    67.6 KB · Views: 1,435
  • tft_touchcontroller_s.JPG
    tft_touchcontroller_s.JPG
    74 KB · Views: 1,479
  • top_cpu_s.JPG
    top_cpu_s.JPG
    134.7 KB · Views: 1,487
  • top_middle_s.JPG
    top_middle_s.JPG
    132.2 KB · Views: 1,457
  • top_nand_s.JPG
    top_nand_s.JPG
    123.6 KB · Views: 1,387
  • usb_host_s.JPG
    usb_host_s.JPG
    100.7 KB · Views: 1,384
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
813
Maybe you would do some work with OMAP 4460 versions? Most new ones are 4460 now
Yupp i know, but i use to focus on the devices i personally own.
There's no need for me to buy one of these newer ones as i won't spent all my money on the latest stuff :p

Cheers scholbert
 

scholbert

Senior Member
Aug 1, 2007
1,347
813
tweaking bootmode... success!!!!!

Hey

just a short update for the geeks out there...
Started to find the bootmode signals... not yet finished, but as you see it's obvious where to search :p
EDIT:
Hoho... got it!!!
See the new attachment.
I successfully tweaked bootmode to send ASIC ID over usb first.
This way it is posssible to get low level access to the platform.
With some additional work we might also recover bricks :rolleyes:
Here's my first log:
Code:
» OMAPFlash v4.15 (Aug 12 2011)

» -v
» Entering parameter file:Targets\Projects\archos\usb_sdram.txt at line: 1
»     -omap 4
»     -t 600
»     -p SEVM_MDDR_ELPIDA_4G
»     -2
»     chip_download SDRAM C:\Projects\OMAPflasher\OMAPFlash\test_data\pattern_1k.bin
» Leaving parameter file:Targets\Projects\archos\usb_sdram.txt
» @Targets\Projects\archos\usb_sdram.txt
» Looking for device (omap usb)
» Please turn on device
» Waiting for device (omap usb)
» Found device (omap usb)
» Requesting ASIC id
» AsicId items 05
» AsicId id             01 05  01  44 30 07 04
» AsicId secure_mode    13 02  01  00
» AsicId public_id      12 15  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
» AsicId root_key_hash  14 21  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
» AsicId checksum       15 09  01  9C 66 9A D9 00 00 00 00
» Searching 2nd for: SEVM_MDDR_ELPIDA_4G 443007 04 GP
» Loading second file Targets\2nd-Downloaders\dnld_startup_omap4_gp_4g.2nd
» Entering parameter file:omapflash2nd.txt at line: 28
»     -pheriphalboot_reopen
» Reading board configuration file Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
» Reading definition file .\targets\definitions\definitions_omap4.txt
»     -board_config Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
» Leaving parameter file:omapflash2nd.txt
» Sending size of second file (0x00007804 bytes)
» Transferring second file to target (0x7804 bytes)
» Closing boot connection
» Found device (omap usb)
» Waiting for 2nd
Unfortunately the 2nd loader does not respond the way it should... :confused:
I found out that there's some trouble caused by the USB cable serving power to the board.
I guess this might be the reason for the interrupt of the transfer (the platform gets a soft reset at this point and does not return properly).
So i'll have to modify the cable for the next step.
Stay tuned!!!

Another thing is serial console... unfortunately no success yet, though i can tell there's something behind these marked testpoints.
I attached some logic and got some data, but nothing readable yet.
I tried with baudrates of 115200 and 1000000 (very common on Archos boards).
Nothing useful :rolleyes:
I don't even know if it is connected to ttyO2 (uart3).
EDIT:
There's some news!!
Please see this post http://forum.xda-developers.com/showpost.php?p=27741653&postcount=22

EDIT2:
Just for your information:
JTAG debug pins had been identified in the meantime.
If you need low level debug features send me PM!

Anyway, i thought it would not harm to put it down here.

Cheers,

scholbert
 

Attachments

  • top_cpu_bootmode_pins_id.jpg
    top_cpu_bootmode_pins_id.jpg
    172.5 KB · Views: 1,011
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
813
OMAP4430 resource table

Hey,

first of all thanks for the positiv feedback.

I started stepping through some kernel code and hardware docs to collect information for low level programming :D
Just to give an overview of the internal resources here's how it looks like:
Code:
BASIC OFFSETs (stock loader)
=========================================================
loader offset           0x40300000      (SRAM)
avboot offset           0x87e80000      (SDRAM)
framebuffer base        0x9c000000      (SDRAM)

ACCELEROMETER
=========================================================
accel-interface         i2c_3           (addr 0x1c)
accel_int1              gpio_45         (pin  B20, mode3)
accel_int2              gpio_174        (pin  H25, mode3)

AUDIO
=========================================================
audio-interface         abe_pdm
                        abe_clks        (pin AH26, mode0)
                        abe_pdm_ul_data (Pin AG25, mode0)
                        abe_pdm_dl_data (pin AF25, mode0)
                        abe_pdm_frame   (pin AE25, mode0)
                        abe_pdm_lb_clk  (pin AF25, mode0)
audio_power_on          gpio_127        (pin AA27, mode3)
audio_irq               sys_nirq2       (pin  AF6, mode0)

CAMERA
=========================================================
camera interface        csi21
                        csi21_dx0       (pin  R26, mode0)
                        csi21_dy0       (pin  R25, mode0)
                        csi21_dx1       (pin  T26, mode0)
                        csi21_dy1       (pin  T25, mode0)
camera_reset            gpio_62         (pin  B23, mode3)

COMPASS
=========================================================
compass-interface       i2c_3           (addr 0x0C)
compass_data_ready      gpio_51         (pin  C21, mode3)

eMMC
=========================================================
emmc-interface          mmc2 (8bit I/O)
                        sdmmc2_clk      (pin  B11, mode1)
                        sdmmc2_cmd      (pin  B12, mode1)
                        sdmmc2_dat0     (pin  C12, mode1)
                        sdmmc2_dat1     (pin  D12, mode1)
                        sdmmc2_dat2     (pin  C13, mode1)
                        sdmmc2_dat3     (pin  D13, mode1)
                        sdmmc2_dat4     (pin  C15, mode1)
                        sdmmc2_dat5     (pin  D15, mode1)
                        sdmmc2_dat6     (pin  A16, mode1)
                        sdmmc2_dat7     (pin  B16, mode1)

GPS
=========================================================
gps-interface           uart0
gps_enable              gpio_41         (pin  A18, mode3)

HDMI
=========================================================
hdmi_pwr                gpio_37         (pin  D18, mode3)
hdmi_hpd                hdmi_hpd        (pin   B9, mode0)

POWER MANAGEMENT
=========================================================
twl6030-interface       i2c_0

tps62361_vsel0          gpio_wk7        (pin  AC2)	

1v8_pwron               gpio_34         (pin  C17, mode3)
vcc_pwron               gpio_35         (pin  D17, mode3)
5v_pwron                gpio_36         (pin  C18, mode3)

TFT
=========================================================
lcd_pwon                gpio_38         (pin  C19, mode3)
lvds_en                 gpio_39         (pin  D19, mode3)
lcd_rst                 gpio_53         (pin  C22, mode3)
lcd_stdby               gpio_101        (pin  A24, mode3)
lcd_avdd_en             gpio_12         (pin   N2, mode3)
bkl_en                  gpio_122        (pin AH24, mode3)
bkl_pwm                 dmtimer8_pwm_evt(pin  G27, mode1)

TOUCHSCREEN
=========================================================
tsp-interface           i2c_1
tsp_irq_gpio            gpio_112        (pin AD25, mode3)
tsp_pwr_gpio            gpio_110        (pin AD27, mode3)
tsp_shtdwn_gpio         gpio_0          (pin  J27, mode3)

USB OTG
=========================================================
vbus_musb_pwron         gpio_111        (pin AD26, mode3)
vbus_flag               gpio_113        (pin AC28, mode3)
vbus_detect             gpio_48         (pin  C20, mode3)
id                      gpio_49         (pin  D20, mode3)

USB EHCI
=========================================================
ehci_enable             gpio_42         (pin  B18, mode3)
3g_enable               gpio_40         (pin  B17, mode3)

WIFI/BT
=========================================================
wifi/bt	control         uart1
wifi-interface          mmc4 (SDIO)
                        sdmmc4_clk      (pin AE21, mode1)
                        sdmmc4_cmd      (pin AF20, mode1)
                        sdmmc4_dat0     (pin AF21, mode1)
                        sdmmc4_dat1     (pin AH19, mode1)
                        sdmmc4_dat2     (pin AG20, mode1)
                        sdmmc4_dat3     (pin AE20, mode1)
wifi_irq                gpio_102        (pin  B24, mode3)
wifi_power              gpio_103        (pin  C24, mode3)
bt_power                gpio_104        (pin  D24, mode3)

This table will get updated form time to time.
EDIT:
- added eMMC resources (mmc2 pins)

In the end this will result in a header file for x-load, u-boot or similar stuff :cool:

Have a nice day!

scholbert
 
Last edited:
  • Like
Reactions: trevd

mprasa

New member
May 7, 2012
2
0
The GPS chipset information shows it has a FM interface as well. Does it mean that Archos can be used as a FM radio receiver ? Sorry I am not such an expert in hardware. Is there an app that we can install if it is possible to make this work as a radio runer ?
 

DarkhShadow

Senior Member
Sep 25, 2011
1,808
268
Essex
The GPS chipset information shows it has a FM interface as well. Does it mean that Archos can be used as a FM radio receiver ? Sorry I am not such an expert in hardware. Is there an app that we can install if it is possible to make this work as a radio runer ?

I think someone already looked into it and found while it does have one its not connected to anything

Sent from my ice cream powered Nexus S
 

scholbert

Senior Member
Aug 1, 2007
1,347
813
The GPS chipset information shows it has a FM interface as well. Does it mean that Archos can be used as a FM radio receiver ? Sorry I am not such an expert in hardware. Is there an app that we can install if it is possible to make this work as a radio runer ?
To be more precisely... the datasheet is about the NL5500, while on the Archos Gen9 a NL5550 is used.
The only difference is, that NL5550 is GPS only.
No FM in this chipset.

I think someone already looked into it and found while it does have one its not connected to anything
The truth is that WL1271 has FM capabilites, but unfortunately Archos decided to leave that out.
Cajl had contact to one of the developers, telling him that essential parts are not connected (e.g. FM antenna).
So no FM on Gen9 :rolleyes:

Regards,

scholbert
 
  • Like
Reactions: scamlist

scholbert

Senior Member
Aug 1, 2007
1,347
813
add the missing mechanic...

Hey folks,

it's so silent here... yeah the summer hits europe :p
Anyway, here's another pic from my temporarily disassembled A80G9.

You know this already from openaos.org:
Code:
Vibra is not built into all units, but if yours has a vibra motor you can turn it on by issuing:

  echo ro.board.has_vibrator=yes >> /data/local.prop

As they said...
The vibrator is not assembled in my device at least... will search in my toy box for a mating part ;)

Regards,

scholbert
 

Attachments

  • vibrator_area_s.jpg
    vibrator_area_s.jpg
    90.6 KB · Views: 482

gen_scheisskopf

Senior Member
Feb 22, 2009
1,128
248
Poznań
Hey folks,

it's so silent here... yeah the summer hits europe :p
Anyway, here's another pic from my temporarily disassembled A80G9.

You know this already from openaos.org:
Code:
Vibra is not built into all units, but if yours has a vibra motor you can turn it on by issuing:

  echo ro.board.has_vibrator=yes >> /data/local.prop

As they said...
The vibrator is not assembled in my device at least... will search in my toy box for a mating part ;)

Regards,

scholbert

Not in ICS- ro.board.has_vibrator=no is present in model specific .rc files (which are parsed before .prop files). Unfortunately changing to 'yes' doesn't work. It seems that I've mised something in system permissions or Archos removed haptic feedback from system entirely

Tapatalked from my Archos 101 G9
 

scholbert

Senior Member
Aug 1, 2007
1,347
813
Not in ICS- ro.board.has_vibrator=no is present in model specific .rc files (which are parsed before .prop files).
Good to know, i'll also try it...

Unfortunately changing to 'yes' doesn't work. It seems that I've mised something in system permissions or Archos removed haptic feedback from system entirely
Maybe your device got no vibrator motor as well... or do you mean that the setting for haptic feedback is missing even after changing the .rc file :confused:

I use hacker's keyboard on my other tablet and there's a setup for haptic feedback (though there's also no vibro hardware inside...).

Maybe i'll find something...
Thanks for the comment!

Regards,

scholbert
 

gen_scheisskopf

Senior Member
Feb 22, 2009
1,128
248
Poznań
My device has vibrator installed (haptic feedback works like a charm on Homeycomb). Changes in .rc files only enabled haptic options in keyboard settings (Thumb Keyboard) but I didn't check files in /system/etc/permissions

Tapatalked from Xperia Arc S
 

realismo

Senior Member
Sep 24, 2010
82
13
My device has vibrator installed (haptic feedback works like a charm on Homeycomb). Changes in .rc files only enabled haptic options in keyboard settings (Thumb Keyboard) but I didn't check files in /system/etc/permissions

Tapatalked from Xperia Arc S

I checked the Honeycomb and yes haptic is working like a charm.

I don't know who cares, but I miss haptic feedback in ICS. Finding a solution could be a very good thing.
 

scholbert

Senior Member
Aug 1, 2007
1,347
813
Some insights concerning hardware...

While fiddling around with my experimental device and stepping deeper into the tags file (see this http://forum.xda-developers.com/showthread.php?t=1711864) there's some conclusion to be drawn for the hardware.

First there's a bunch of devices floating around which are equipped with the high performance OMAP4430 and don't make use of it.

I disassembled at least two A80S standard tablets with the high performance OMAP4430 soldered on the mainboard.
Additionally both got a silicon pad at the bottom of the mainboard PCB to dissipate the heat from the CPU.

Both make use of the TPS62361B core voltage regulator, beeing capable to power even the OMAP4460 at 1.5GHz.

So looking at the hardware design there's no reason why these were sold as standard and clocked at 1GHz.
The revisions of A80S could easily run at 1.2GHz.

While stepping through some the tags from other user's devices i also realized that some of the A101S seem to be powered by the TWL6030 only and don't make use of the additional core regulator.
At least the FTAG for the TPS62361B is missing on these devices, which leds me to the conclusion the chip is not soldered on the mainboard.
Could be an older release though...

I guess this is the main reason for instability on the A101S while overclocking.
The CPU might do it, but the core voltage could drop at some point and freeze your tablet.
I thought this would be of interest.

Anyway, stay clean ;)

scholbert
 
Last edited:
  • Like
Reactions: Shano56

scholbert

Senior Member
Aug 1, 2007
1,347
813
Can we get any additional information regarding the touchscreen controller?
If i find something i'll post it here.
It's all closed behind thick walls :rolleyes:

On my G9 80 Turbo (4460 1.5 GHz 1GB) the touch screen can only recognize around 227*227 touch points (more info: http://forum.xda-developers.com/showpost.php?p=27650004&postcount=4 ).
Yeah, nice information. Not sure about the touchpoints value though.

Is this a hardware limitation (low-resolution capacitive matrix), configuration issue or just bad drivers?
Not sure about that.
These Cypress chips are not that bad usually, maybe it's the touchscreen glass itself which leds to this restriction.
If you look carefully, you might see this grid on the A80's screen.

I'll try to do some more investigation on this, though i'm not sure if there's anything to find in the open web :p

Regards,

scholbert
 

neur0mans3r

Senior Member
Jun 3, 2012
61
16
I got the approximate touch resolution by noting how much the XY values change when moving a single finger slowly on the screen in Input Benchmark multi-touch test.

Since the program returns a pixel coordinate you can work out an approximate resolution like this (landscape orientation):
- vertical: 768/3.37335 = 227.667
- horizontal: 1024/4.4978 = 227.6668
This probably means that the touchscreen resolves 256 points horizontally and vertically, but maybe those extra points are not evenly distributed, or are located under the black frame surrounding the screen.

However, sometimes you can get a touch point XY value in between the values you usually get (exactly between the values you usually get), but then the next value is still off by 3.3 or 4.5 pixels. I think this means that the hardware supports at least twice the current resolution, but the driver has aggressive input filtering that reduces touch resolution.

I'll write a test application that shows the raw touch data, and calculates the approximate resolution of the touchscreen.

[UPDATE]

I wrote a simple test and found that the touchscreen resolution is 2048*2048 (G9 80 Turbo 4460).
However when moving the finger along the screen horizontally or vertically you only get touch events for every 9 touch points (the numbers I provided above still stand) for that direction. In the other direction you get the full resolution (if you move the finger almost horizontally, you get poor horizontal resolution and full vertical resolution, but since in this case horizontal resolution is more important this isn't ideal).
 

Attachments

  • TouchResolutionTest.apk
    38.6 KB · Views: 32
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 11
    Hi,

    it's me again... this time the victim of my surgery is my Archos 80 G9 tablet with 8GByte.
    The device is working pretty nice, but it's always fun to start investigation on the hardware :D.

    Some general words about the design:
    It seems obvious that Archos engineers started developing with TI Blaze development platform.
    There'd been some hints in the source code and the design looks pretty similar.
    Unfortunately there's no schematics of this platform... but fortunately there's the PandaBoard :p.
    This board is fully documented (schematics as well) and there are a lot of open development projects all over the web.

    Basically the Archos Gen9 tablets share the same base chipset with the Pandaboard and that's why there are many similarities.
    One thing notable is the fact, that Archos implemented a eMMC/SD card chipset on the mainboard, instead of using a fully integrated eMMC device as to be found on the Gen8 mainboards.
    In other words they coupled an eMMC controller (Phison PS7000) together with raw NAND flash (64GBit MLC).
    This subsystem then got connected to mmc2 interface and is used as boot media (eMMC raw boot).

    The other thing we may observe, is that the A80G9 and the A101G9 mainboards look pretty much the same in form and shape.
    I guess, there are only little differences in the design, if there are any at least ;).
    EDIT2: Have a look over here...
    http://forum.xda-developers.com/showthread.php?t=1449438
    Harfainx did a great job and put down some high-res pics from his A101G9.

    Anyway there might be a lot to report, but i think it'll be better to come back from time to time and add some details and information.
    You may prepare for some pics as well :D

    A80G9 chipset information:
    Processor
    • Ti OMAP4430/60 (547-pin CBS BGA package) ARM Cortex A9 dual-core at 1/1.5 GHz with DSP
    • POWERVR SGX540 Graphic accelerator: 3D OpenGL ES 2.0

    Memory
    • 512MB/1024MB LPDDR SDRAM (216-pin PoP BGA package) soldered on top of OMAP4430/60
    • 8/16GB NAND (52-pin VLGA package) with eMMC bridge chip (PS7000) connected on mmc2 interface

    Interfaces
    • USB 2.0 OTG (OMAP4430/60 internal interface, MicroUSB connector)
    • USB 2.0 EHCI host interface (USB3322 ULPI phy, TYP A connector)
    • Micro SD slot (OMAP4430/60 internal mmc1 interface, SDHC compatible)

    Display subsystem
    • ChiMei 8" TFT-Display EJ080NA-04B (24Bit-LVDS interface)
    • Ti SN75LVDS83B LVDS transmitter (56-pin BGA package)

    Touchscreen subsystem
    • Capacitiv touchscreen unit (Cypress controller TMA340, I2C interface)

    HDMI subsystem
    • OMAP4430/60 internal 24-Bit HDMI transmitter
    • HDMI output (19-pin Mini HDMI connector)

    Communication
    • Ti WL1271 WiFi (802.11 b/g/n)
    • Ti WL1271 Bluetooth 2.1 EDR

    GPS chipset
    • Ti NL5550 AGPS connected to uart0

    Audio chipset
    • Ti TWL6040 multichannel audio codec

    Miscellaneous
    • Built-in speaker
    • Built-in Microphone
    • Aptina MT9M114 1/6" 720p HD camera (1.26M)

    Sensors
    • Freescale MMA8453Q G-sensor
    • AsahiKasei AK8975 compass-sensor

    Power source
    • Ti TWL6030 power management chip
    • Ti TPS62361 core voltage regulator
    • Internal: Lithium Polymer battery
    • External: 5V/1.5A Power adapter/charger

    Again i did some web research and made a smart datasheet collection.
    Grab this zip-file.
    EDIT5:
    Updated datasheet collection...
    Read on for some more information.

    So what's next:
    I don't know yet...
    will start some hacking because i got a damaged mainboard

    EDIT1:
    Added some low res pics of the mainboard...

    EDIT3:
    To consider the OMAP4460 variants i added some lines in the chipset spec.
    Though i did not open one of these devices, it is likely that Archos did use the same mainboard and upgraded the CPU and PoP-Memory.
    Search the Ti website for further information on that SoC.
    There's also a document which clarifies the differences between OMAP4430 and OMAP4460.
    I may put it here as well if you like :rolleyes:

    EDIT4:
    Some error corrections...

    EDIT6:
    Archos 3.0.8 kernel seems to be heavily based on this branch of Ti OMAP kernels:
    http://git.omapzoom.org/?p=kernel/o...roid-omap-3.0-4470;hb=p-android-omap-3.0-4470
    If you run a diff between these two you'll get a pretty good overview about the Archos specific changes.
    Might be interesting for those who like to create a newer kernel for the Gen9 :)

    Stay tuned!

    scholbert
    4
    Have it!!
    as you said it could be a single line and it was a single line.
    I know it must work on a panda board which uses uart3. So looked for differences between uart3 and uart1:
    the uart3 has a flag to forbit it being resseted!!
    Once the console was working there were other problems wich now are all solved.

    Now is time to start backporting android drivers to linux, starting with voltages, clocks and gpios.

    Regards,
    vicencb

    @scholbert: you asked for it, you have it ;) See: http://lists.infradead.org/pipermail/barebox/2012-October/010384.html

    If any one is interested here are the steps to reproduce:
    patch linux-3.6.1 with http://rcn-ee.net/deb/sid-armhf/v3.6.1-x2/patch-3.6.1-x2.diff.gz
    patch with archos.diff
    make omap2plus_defconfig
    patch with cfg.diff
    kernel done

    prepare an initrd with the contents of http://us.mirror.archlinuxarm.org/os/omap/ArchLinuxARM-2012.08-omap-smp-rootfs.tar.gz
    with this changes:
    sed -i 's#^DAEMONS=(hwclock syslog-ng network netfs crond sshd)$#DAEMONS=()#' /mnt/etc/rc.conf
    mv /mnt/etc/inittab.pacnew /mnt/etc/inittab
    sed -i -e 's#ttyO2#ttyO0#g' -e 's#38400#115200#g' /mnt/etc/inittab
    rm /mnt/etc/locale.gen*
    echo 'en_US.UTF-8 UTF-8' > /mnt/etc/locale.gen
    initrd done

    Boot it!
    3
    tweaking bootmode... success!!!!!

    Hey

    just a short update for the geeks out there...
    Started to find the bootmode signals... not yet finished, but as you see it's obvious where to search :p
    EDIT:
    Hoho... got it!!!
    See the new attachment.
    I successfully tweaked bootmode to send ASIC ID over usb first.
    This way it is posssible to get low level access to the platform.
    With some additional work we might also recover bricks :rolleyes:
    Here's my first log:
    Code:
    » OMAPFlash v4.15 (Aug 12 2011)
    
    » -v
    » Entering parameter file:Targets\Projects\archos\usb_sdram.txt at line: 1
    »     -omap 4
    »     -t 600
    »     -p SEVM_MDDR_ELPIDA_4G
    »     -2
    »     chip_download SDRAM C:\Projects\OMAPflasher\OMAPFlash\test_data\pattern_1k.bin
    » Leaving parameter file:Targets\Projects\archos\usb_sdram.txt
    » @Targets\Projects\archos\usb_sdram.txt
    » Looking for device (omap usb)
    » Please turn on device
    » Waiting for device (omap usb)
    » Found device (omap usb)
    » Requesting ASIC id
    » AsicId items 05
    » AsicId id             01 05  01  44 30 07 04
    » AsicId secure_mode    13 02  01  00
    » AsicId public_id      12 15  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    » AsicId root_key_hash  14 21  01  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    » AsicId checksum       15 09  01  9C 66 9A D9 00 00 00 00
    » Searching 2nd for: SEVM_MDDR_ELPIDA_4G 443007 04 GP
    » Loading second file Targets\2nd-Downloaders\dnld_startup_omap4_gp_4g.2nd
    » Entering parameter file:omapflash2nd.txt at line: 28
    »     -pheriphalboot_reopen
    » Reading board configuration file Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
    » Reading definition file .\targets\definitions\definitions_omap4.txt
    »     -board_config Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
    » Leaving parameter file:omapflash2nd.txt
    » Sending size of second file (0x00007804 bytes)
    » Transferring second file to target (0x7804 bytes)
    » Closing boot connection
    » Found device (omap usb)
    » Waiting for 2nd
    Unfortunately the 2nd loader does not respond the way it should... :confused:
    I found out that there's some trouble caused by the USB cable serving power to the board.
    I guess this might be the reason for the interrupt of the transfer (the platform gets a soft reset at this point and does not return properly).
    So i'll have to modify the cable for the next step.
    Stay tuned!!!

    Another thing is serial console... unfortunately no success yet, though i can tell there's something behind these marked testpoints.
    I attached some logic and got some data, but nothing readable yet.
    I tried with baudrates of 115200 and 1000000 (very common on Archos boards).
    Nothing useful :rolleyes:
    I don't even know if it is connected to ttyO2 (uart3).
    EDIT:
    There's some news!!
    Please see this post http://forum.xda-developers.com/showpost.php?p=27741653&postcount=22

    EDIT2:
    Just for your information:
    JTAG debug pins had been identified in the meantime.
    If you need low level debug features send me PM!

    Anyway, i thought it would not harm to put it down here.

    Cheers,

    scholbert
    3
    1000th post

    Hi,

    great development with the GEN9 is starting up these days :D
    Open bootloader development and community driven Android distributions in the Android section.
    Nice times and my 1000th post here :p
    So i'm already lookin' forward to a golden autumn with nice featured Archos tablets.

    ...back to technical stuff:
    yes, already know you have u-boot up and working, but I started to play with barebox before this thread. Anyway, two bootloaders better than one.
    Sure, i love the freedom of choice as well.
    Though if you'd opened up a thread about it... i might have helped out with some issues.

    About the kernel: nice to know it's not a problem of the bootloader, now I'll try to boot a vanilla kernel.
    Let us know about your progress regarding booting android from other bootloaders.
    I will certainly do that... once i start over with development!
    At the moment there are more outdoor activities, because weather tries to be fine in Germany :laugh:

    Yes, all the development done with barebox was without a serial port, all throught usb:
    1.- boot OMAP from usb
    2.- the first stage the reuses the usb connection as a console and requests the second stage
    3.- send second stage
    4.- the second stage reuses the connection as a console
    5.- the second stage boots kernel
    6.- communications lost, no more debugging possible.
    O.k. i see. Wich version of OMAP tool did you use for USB booting?
    The TI stock one or the one for the Tuna platform?
    ...or even opensource project (usbboot, a.k.a omap4boot)?

    So, as step 7 I've set up the serial port and after some (already mentioned) headaches I finally got it working this weekend!!!
    There were three problems:
    1.- The supply voltage as you mentioned. I've solved it setting gpio34 to 1, this is enabling 1v8.
    2.- The gps sharing the uart signals. Solved setting gpio41 to 0, this disables the gps.
    3.- And the most awkward: I've reused most of the panda board code which uses a system_clk of 38.4MHz, but the archos uses one of 19.2MHz, so the serial port (and everything else) was working at half speed. This explains the garbled data.
    What's unbelievable is that almost everything worked fine with a halved clock!
    Yeah cool, indeed... and it seems that you really read my post carefully.
    I once wrote about these GPIO, but never tried it myself because lack of time.
    I just soldered my wire at one of those capacitors for VIO1.8.
    Pretty cool that it worked out like this!!!

    About the clocking... i knew that, because i had similar problems at the beginning.
    I just looked at the mainboard again, and it became obvious pretty fast.
    So i adjusted the clock setup accordingly.

    I didn't know that of reassigning the USB-OTG pins. Now am understanding the meaning of "uart3_on_usb" and "CONFIG_ARCHOS_UART3_ON_DPDM". It's another way to go to have serial port without opening the tablet, good to know.
    In any case the tablet has to be opened to change the boot order.
    I found this pretty early by stepping through kernel code.
    Once had a little conversation with Letama about it.
    Concerning boot order, you won't even need to open the case for that.
    If your tablet is rooted and boots up to Android you could tweak the boot order in software as well.
    You need to change content of SAR-RAM by using a command line utility or kernel module. Afterwards the platform needs a soft reset and comes up with new boot order.
    See this page as an introduction for this technique:
    http://sed.free.fr/archos/

    There's also a detailed description in the OMAP4430 TRM.

    Do you have any recomendations or work done on booting a vanilla kernel?
    I could not answer this question in short.
    For a vanilla kernel you'll some essential tweaks to start up the board.
    Afterwards it depends on your requirements.
    If you like to get the hardware working well, you'll need to implement mostly anything Archos has added to the kernel.
    In fact it should not be too much to add if you start with the pandaboard kernel.

    And why shouldn't it work underclocked? :)
    Does slower system_clk make any difference for the hardware?
    Certain clocks do have big influence on the systems behaviour.
    Regarding the CPU it get's underclocked if there's nothing to do.
    Depends on the governor...
    Some of the base clocks have to match though to get things working properly.
    UART clock is derived from one of the base PLL's though and it needs to match.
    The clock domain of OMAP4 is quite extensive and there are many differnent clocks for the whole system of course. Too much to write it down in a few sentences.

    Because the DDR2 SRAM has very tight timings tailored at each working frequency, but I now assume that the timings may be relative to the main frequency.
    And also for the refresh rate, the dynamic memory must be refreshed at least at some minimum frequency.
    Basically this is right... you'll need a base setup for some of the PLL's to match the timing of the LPDDR.
    Though these modern RAMs are self refreshing and capable of running at lower clock as well.

    The other thing that was not working was the usb port (the same used for booting). I had to disable the code that set up it's dll settings to be able to maintain the usb link.
    O.k. this might be worth looking into.
    Right now i have no USB implementation in my u-boot code.

    Anyway, seems that you like these kind of hacking as much as i do.
    So maybe we should share some further information.
    As soon as i'll find some time i will put my u-boot code to gitorious.
    Maybe MUX setup in barebox needs some adjustment :p

    Don't know, if it is of interest, but i was able to trace the JTAG lines as well.
    Normally this is not needed, but if someone needs hardcore debugging feature, tell me.

    ...uuuups, long posting :)

    P.S.: Just saw that someone voted for this thread... if you don't mind join in i appreciate it!!

    Hack on!!!

    scholbert
    3
    Serial console found... finally!!!

    Hey geeks,

    what should i say... sometimes things behave little stupid, even or perhaps also because you are used to fiddle around with electronics.
    So stupid me, i was there weeks ago already but acted a little blindly and never changed RX and TX pins and tried again with my UART adaptor.

    Anyway, here we are...
    See the attached pic for the new assigment on the testpoints TP49..52 on the mainboard of the A80S ;)
    EDIT:
    Here's the assignment:
    TP49 -> GND
    TP50 -> VIO1.8
    TP51 -> UART1_RX
    TP52 -> UART1_TX

    Connected to a UART2USB converter with 1.8V logic level shifter it all get's clear with a baudrate of 1000000, 8N1.
    Here's the log:
    Code:
    loader (c) Archos 2010
    OMAP4430 Rev. ES2.3
    
    verify_stage2 - disabled
    
    signature check ok
    rawfs driver already in use
    Cannot mount mmcblk0p1 of type rawfs
      AvBoot Version 5.5.3
    Developer edition found, disconnect
    bat overtemp
    stop charging
    exit low batt state voltage: 3969mV
    size of params: 32768
    magic: 6fc59ae8, ret: 0, size: 32768
    
    verify_kernel - disabled
    
    signature check ok
    Just to mention this:
    This was captured on my A80S device with bootmode changed to peripheral mode.

    EDIT:
    Some additional words on uart1...
    The GPS chipset is also connected to this UART, that's why i got confused a little bit while doing measurements with an oscilloscope.
    The GPS chipset get's initialized at a later point when Android is up.
    The CPU uses a hexadecimal protokoll at this point, that's why i could not get something useful out of it.

    What's next:
    - try to boot from microSD
    - try to enter avboot console mode

    Have a nice day :D

    scholbert