A101it mainboard hacking and chipset information

Search This thread

scholbert

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

as i wrote in another thread, i purchased a bricked A101.
There's no response from the system so i decided to start investigation on the hardware :D.

A101it chipset information:
Processor
• Ti OMAP3630 (515-pin CBB/P BGA package) ARM Cortex A8 at 1 GHz with DSP
• POWERVR SGX530 Graphic accelerator: 3D OpenGL ES 2.0

Memory
• 256MB LPDDR SDRAM (168-pin PoP BGA package) soldered on top of OMAP3630
• 8/16GB eMMC (169-pin BGA package) connected to OMAP3630 internal mmc2 interface

Interfaces
• USB slave 2.0 (OMAP3630 internal interface, MicroUSB connector)
• USB host interface (TPS65921 host interface, TYP A connector)
• Micro SD slot (OMAP3630 internal mmc1 interface, SDHC compatible)

Display subsystem
• ChiMei 10.1" TFT-Display N101L6-L02 (18Bit-LVDS interface)
• Ti SN75LVDS83B LVDS transmitter (56-pin BGA package)

Touchscreen subsystem
• Pixcir capacitiv touchscreen unit (TR16C0 controller, USB interface)
• Ti TUSB2551A USB transceiver (16-pin QFN package)

HDMI subsystem
• NXP TDA19989AET 24-Bit HDMI transmitter
• HDMI output (19-pin Mini HDMI connector)

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

Miscellaneous
• Built-in speaker
• Built-in Microphone
• Freescale MMA7660FC G-sensor
• Omnivison OV7675 VGA camera (0.3M)

Power source
• Ti TPS65921 power management chip
• Intersil ISL9220 LiPo charger
• Internal: Lithium Polymer battery
• External: 5V/1A Power adapter/charger

To get some detailed informations about these chips, i made a sweet datasheet collection.
Grab the zip-file here.

TBC...

EDIT: The brick issue is solved.
The platform did not boot up due to a broken connection to onboard RAM.
This thread will present various hacks and other stuff a geek might have fun with :D
Read on for some more information.

So here's my first result:
I successfully located the sys_boot signals of the OMAP3630.
I made a first test by changing the default boot mode.

With sys_boot5 pulled high the boot order changes to peripheral boot first.
In other words you may use this tool to directly access the OMAP memory (e.g. RAM).

In theory it should alos be possible to boot the device form external microSD as well, but at factory default the microSD slot is covered by power management. In other words, power is switched off at boot time.
This could be hacked as well ;)

My attempt will be to un-brick my device by using external boot mechanism.
Maybe i'll need some help at a later point!

EDIT: Peripheral boot modes had successfully been verifed.
It definitely works on the Archos 101. Perhaps this may be useful for some open bootloader project.

Aynway, i already discovered some other things, that might be helpful for hardware hackers. So if you are kind leave a comment or ask some questions.

Stay tuned!

scholbert
 

Attachments

  • A101_sys_boot.JPG
    A101_sys_boot.JPG
    92.8 KB · Views: 1,504
Last edited:
  • Like
Reactions: Quallenauge

rplc790222

Senior Member
Dec 10, 2010
65
7
San Francisco del Rincón, Gto
Oh, that's interesting ... I don't know anything about hardware hacking but I'd like to learn hope you will show us ... keep on the good effort ... and I'll keep an eye on this tread .... might come handy ... jejeje
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
peripheral boot

Hi,

thanks for your replies.
So as expected using peripheral boot over USB/UART is working (sys_boot5 pulled high).
At least the ASIC ID is send correctly and the initial communication starts.
See the screenshot attached.
Flash V1.6 also got a eMMC driver included.
So this could be the way :).

Right now there's an error message:
Code:
Unknown status message 'dKAYd 2nd stdrted?' during peripheral boot (waiting for 2nd)
I guess the response should be: OKAY! 2nd started? :confused:
EDIT:
MMMh strange... i'll have to find out who is generating this message.
If it is comming from OMAP the SDRAM setup should be verified.
Seems that the LSB byte stuck @ 0x64.
Code:
dKAYd 2nd stdrted?

ascii = dKAY -> hex = 0x59414b64 (msb..lsb)
ascii = d 2n -> hex = 0x6e322064
ascii = d st -> hex = 0x74732064
ascii = drte -> hex = 0x65747264
ascii = d?   -> hex = 0x00003F64

See the session log file for more details!

Anyway i justed started to play around... maybe some tweaks in the configuration are needed :p

Have fun!

scholbert
 

Attachments

  • Flash_a101.jpg
    Flash_a101.jpg
    72.1 KB · Views: 727
  • a101_log.txt
    1.7 KB · Views: 55
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
821
Thanks for attesting coolness :D

Made some further tests... though my time is really limited right now.
I found out that the message is send from 2nd loader which is used for Ti's Flash tool.
So this might indicate that there's something wrong with my memory or memory bus.
I re-checked the RAM setup sripts for the Ti tool again but could not find any error. Reduced the timing as well. Still got that message...

It's very strange that the pattern really seems to stick, which is unusual for damaged memory... i will report further findings.

Anyway this is open discussion, feel free to post ;)

Cheers,

scholbert
 

Harfainx

Retired Forum Moderator
Apr 10, 2010
1,658
1,803

scholbert

Senior Member
Aug 1, 2007
1,347
821
.............yippie yeah it's working out!!!!

Thanks for the feedback :D

First i'll have to quote myself:
It's very strange that the pattern really seems to stick, which is unusual for damaged memory... i will report further findings.
Guess what...... it's fixed!!!!!
I really go crazy. See attached log file.
External boot over USB and 2nd loader started up successfully, using the Ti tool.
So RAM is working now!
This definitely saved my day...

What happened exactly?
As i pointed out, the data on memory bus stucked at 0x64, so i assumed there was an issue with DQM/DQS signals on PoP memory.
See some related documents about the function of these signals on RAM chips.
The DQM/DQS where not toggled in the right way because of bad soldering at the PoP memory chip.
See the attached pic for the excact position of these signals (marked in red).
The chip itself is soldered on top of the OMAP3630.

In the end i used a hot-air solder gun and soem soldering flux and fixed the broken connection. In fact i used this "technique" some time ago to fix a "No GSM" issue on HTC Hermes.

Though i'm very excited right know, i'll have to make a break for today, because i have a date :)

I'll definitely be keeping an eye on this topic, seems like some good information might come of it.
Yes i'll try my very best :rolleyes:

Kind regards,

scholbert
 

Attachments

  • a101_log_success.txt
    1.9 KB · Views: 81
  • PoP-Memory-MT46H64M32LFMA-6.jpg
    PoP-Memory-MT46H64M32LFMA-6.jpg
    54.2 KB · Views: 708

scholbert

Senior Member
Aug 1, 2007
1,347
821
datasheet collection

Hey,

i was lucky last week. My device is up and running.
Fortunately the eMMC data structure was O.K. In the end my device refused to boot, because of that broken connection to the RAM.
So there'd been no need to fiddle around with eMMC for now.
Maybe i'll do some investigation at a later point.

Feel free to set up your device for peripheral boot and try the Ti Flash tool debugging possibilities.

Right now i decided to re-assemble the device and use it for a while.
I must assume that i know nothing about the internal structure of the firmware. So it would be essential to get some insights :D

I got some additional information about the eMMC/microSD data lines.
If there's some interest i might post further pics.

To get some background about the chips on the A101 mainboard, i collected some datasheets of the main components.
Grab the zip-file here.

Most of them are easy to find other's are not ;)
Anyway, saves your time i guess.

BTW, is there any tool to unpack gen8 AOS files?

Regards,

scholbert
 
Last edited:
  • Like
Reactions: sistux

FrEcP

Senior Member
Jul 29, 2006
369
72
...

Most of them are easy to find other's are not ;)
Anyway, saves your time i guess.

BTW, is there any tool to unpack gen8 AOS files?

Regards,

scholbert

As far as i know we can't extract aos files since they are encrrypted and we don't have they proper KEY - its saved inside the device somewhere

But good luck with going on! Rly sounds interesting who knows what it's good for in future ;)
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
..... uuuh great!!!

good news - check out:
http://xdaforums.com/showthread.php?t=1214674
seems we got a way to extract soon
Yupp, that's awesome. I just joined that thread.

In the meantime i disassembled my device again, because i want to spent some more time on research.
I found out some more details about the chips and the design in general.
The A101 seems a pretty neat device for extensive hacking, because archos did a good job and made a very clear design.

I started to prepare a pin map by looking at the kernel sources again.
Maybe i'll be able to find some other useful testpoints on the mainboard (e.g. UART2)

As you might know, the touchscreen is connected to USB using OHCI mode.
To attach it to the OMAP ports they also used a chip from Ti.
See this datasheet for more information:
http://focus.ti.com/docs/prod/folders/print/tusb2551a.html

If i'll find some time i'll try to make kind of a floor plan from the mainboard and post some pics as well.

P.S.: If someone knows the manufaturer of the speaker drivers, please tell me! The parts are marked as 8JAM892 and are located near the soldering points for the speaker.

Keep on hackin'

scholbert
 

pbarrett

Senior Member
Sep 11, 2009
145
11
Plano, TX
What I would like to find out is what component it is that dies when the USB port fails (and it stops sleeping as well). Maybe it's replaceable (if you can do SMD soldering).
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
What I would like to find out is what component it is that dies when the USB port fails (and it stops sleeping as well). Maybe it's replaceable (if you can do SMD soldering).
Mmmh... without being affected by this issue it's hard to tell.
If the port dies, there could be many reasons of course.

Maybe the 5V power supply for Vbus is dying on these devices, due to "over-current" issue. I have not identified that part right now.

The signal lines itself usually won't be harmed... apart from injecting ESD pulses right to the connector.
The USB host port is directly connected to data lines of the USB PHY inside TPS65921 (Power Management chip).
OMAP3630 itself uses ULPI mode to connect to this part.

That's all i could say for now.

Regards,

scholbert
 

blawoef

Senior Member
Jul 6, 2011
72
1
good news - check out:
http://xdaforums.com/showthread.php?t=1214674
seems we got a way to extract soon

If we can't extract those AOS files - how are custom ROM builders such as $auron getting their hands on the upper layer of the firmware? I know I am not expressing myself technically correct, but what I understand is that for instance $auron's UrukDroid is a custom Linux kernel etc. with on top of it the modules, GUI etc of the official Archos packages...
 

chrulri

Senior Member
Dec 7, 2010
895
275
you don't need to extract the aos file to get the filesystem of the archos android. you simply have to root your device or just install angstrom (which comes with SDE) and then you can copy the squashfs file to your computer so you can extract whatever you need. it's not encrypted but signed, you only have to skip the first 256 bytes (if I remember correctly) of the file to get a valid squashfs image.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    ... A101IT booting u-boot

    Hey guys,

    i know Gen9 devices are becoming more and more famous these days,
    but i could not resist to do some hacks and spent some more time on open development for Gen8 :D

    So here it is!!!
    First proof of concept for a true open bootloader, a.k.a. u-boot on A101IT Gen8:

    Code:
    Texas Instruments X-Loader 1.5.1 (Mar  7 2012 - 00:07:18)
    Found 0256 MB
    Testing memory, please wait...
    DRAM: 0253 MB OK
    Memory Test success!
    Archos Gen8
    PRM_CLKSEL         = 0x00000003
    PRM_CLKSRC_CTRL    = 0x00000040
    CM_CLKSEL1_PLL     = 0x08a60c00
    CM_CLKSEL2_PLL     = 0x0481b00c
    CM_CLKSEL3_PLL     = 0x00000009
    CM_CLKSEL1_PLL_MPU = 0x0011f40c
    CM_CLKSEL2_PLL_MPU = 0x00000001
    dpll_param_p = 0x40200c94
    Reading boot sector
    Loading u-boot.bin from mmc
    Done!
    
    
    U-Boot 2011.09 (Mar 19 2012 - 23:58:12)
    
    OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
    Archos 101 internet tablet + LPDDR/MMC
    I2C:   ready
    DRAM:  256 MiB
    MMC:   OMAP SD/MMC: 0
    Using default environment
    In:    serial
    Out:   serial
    Err:   serial
    Die ID #144800029ff800000160a4bb18027009
    Hit any key to stop autoboot:  0
    reading boot.scr
    
    ** Unable to read "boot.scr" from mmc 0:1 **
    reading uImage
    
    ** Unable to read "uImage" from mmc 0:1 **
    Booting from nand ...
    Unknown command 'nand' - try 'help'
    Wrong Image Format for bootm command
    ERROR: can't get kernel image!
    A101IT #

    The errors are there because i die not place the files on card yet :rolleyes:

    The work i've done so far, is pretty straight forward, though the code will need some clean up and i'm planning to implement more cool features (e.g. graphics and probably a boot menu)
    Right now A101It is just booting into u-boot, that's it.
    Pretty sure it would start a kernel already, but i'd like to do some more tweaks on low level ;).
    As soon as it will get useful, i'll put all the source down at gitorious.
    Might take some time though...

    So stay tuned, don't throw away your Gen8 device and leave some comments...

    Have fun!

    scholbert
    3
    x-loader port for A101IT

    O.k. if you my previous post, you might realize that there'd been some difficulties
    to make the external boot process work with the stock loader.

    Being fed up with digging in boot code disassemby i started to port the well known x-loader to the A101IT.
    At first this seemed to be no big job and i started with two different bootloader sources:

    x-loader 1.41 for Nook
    There's some similarity to our device and Zoom3 is also included.
    Seemed to be the best starting point first, but after digging around for a while i stucked at some point.
    There'd been no output and it seems there's some basic problem here.

    x-loader 1.5.1 from https://gitorious.org/x-loader/x-loader
    This is a more recent one and the code is in a good shape.
    So i started with the beagleboard-xm setup and modified muxing stuff to match the Archos.

    To make a long story short:
    After reading many many pages of the OMAP HWR, dumping many registers values, calculating hex and tweaking the code...
    It's booting!!!

    I implemented few additional things to have some debugging and check whether the DRAM is working or not.
    See the output:
    Code:
    Texas Instruments X-Loader 1.5.1 (Mar  7 2012 - 00:07:18)
    Found 0256 MB
    Testing memory, please wait...
    DRAM: 0253 MB OK
    Memory Test success!
    Archos Gen8
    PRM_CLKSEL         = 0x00000003
    PRM_CLKSRC_CTRL    = 0x00000040
    CM_CLKSEL1_PLL     = 0x08a60c00
    CM_CLKSEL2_PLL     = 0x0481b00c
    CM_CLKSEL3_PLL     = 0x00000009
    CM_CLKSEL1_PLL_MPU = 0x0011f40c
    CM_CLKSEL2_PLL_MPU = 0x00000001
    dpll_param_p = 0x40200c94
    Reading boot sector
    Done!
    u-boot.bin not found or blank nand contents - attempting serial boot . . .
    ## Ready for binary (kermit) download to 0x80008000 at 115200 bps...

    What is working so far:
    - initial A101IT board setup
    - 256MB DDR memory init
    - print boot messages using UART3 at 115200bps
    - serial kermit download of ARM binaries to 0x80008000
    - sending debug information....

    What's next:
    - clean up code and some fine-tuning
    - starting to port u-boot
    - deliver the source code

    I may provide the MLO binary... but you know you'll need serial console tweak and at least the kernel module from vitalif to change boot mode to external.

    P.S.: It would be no big deal to change setup for 512MB support using this bootcode. You just need to assemble a bigger PoP memory chip :p

    Cheers,

    scholbert
    2
    partly there...

    Hi again,

    as pointed out i stepped back to u-boot 2011.09 for now... and it seems this was a good decision :D

    Code:
    U-Boot 2011.09 (Mar 23 2012 - 18:53:39)
    
    OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
    Archos 101IT Gen8 + LPDDR/MMC
    I2C:   ready
    DRAM:  256 MiB
    MMC:   OMAP SD/MMC: 0
    Using default environment
    In:    serial
    Out:   serial
    Err:   serial
    Die ID #144800029ff800000160a4bb18027009
    Hit any key to stop autoboot:  0
    reading boot.scr
    
    ** Unable to read "boot.scr" from mmc 0:1 **
    reading uImage
    
    2987000 bytes read
    Booting from mmc ...
    ## Booting kernel from Legacy Image at 82000000 ...
       Image Name:   Linux-2.6.29-omap1
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    2986936 Bytes = 2.8 MiB
       Load Address: 80008000
       Entry Point:  80008000
       Verifying Checksum ... OK
       Loading Kernel Image ... OK
    OK
    
    Starting kernel ...
    
    Uncompressing Linux.............................................................
    ................................................................................
    ..................................................... done, booting the kernel.
    <6>Initializing cgroup subsys cpu
    <5>Linux version 2.6.29-omap1 (scholbert@thinkpad) (gcc version 4.4.1 (GCC) ) #1
     PREEMPT Thu Mar 22 23:59:34 CET 2012
    CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
    CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
    Machine: Archos A101IT board
    fixup_archos: [console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/linuxrc d
    ebug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0 mmc_block
    .split=0.0001:512M]
    Memory policy: ECC disabled, Data cache writeback
    <7>On node 0 totalpages: 65536
    <7>free_area_init_node: node 0, pgdat c05fd368, node_mem_map c06a5000
    <7>  Normal zone: 512 pages used for memmap
    <7>  Normal zone: 0 pages reserved
    <7>  Normal zone: 65024 pages, LIFO batch:15
    <4>L2 CACHE is enabled in bootloader
    <6>OMAP3630 ES1.2
    <6>DIE ID: 144800029FF800000160A4BB18027009
    <6>FEATURE_STATUS: 00000c00
    <6>SRAM: Mapped pa 0x40200000 to va 0xfc800000 size: 0x100000
    <6>Reserving 4915200 bytes SDRAM for VRAM
    Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
    <5>Kernel command line: console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/
    linuxrc debug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0
    mmc_block.split=0.0001:512M
    <3>Unknown boot option `androidboot.console=ttyGS0': ignoring
    <3>Unknown boot option `omapdss.debug=0': ignoring
    <6>Clocking rate (Crystal/DPLL/ARM core): 26.0/166/600 MHz

    No problem with machine ID here... but now there's the PLL again.
    It stucks at this point trying to find nice settings for SDRC.
    Here's the same message with stock setup using avboot loader:
    Code:
    ...
    Clocking rate (Crystal/DPLL/ARM core): 26.0/332/600 MHz
    Reprogramming SDRC
    GPMC revision 5.0
    ...
    As you see the DPLL value differs. I already corrected this in x-loader, but it seems that u-boot changes this value back (26.0/166/600 MHz seems to a default for beagleboard&Co.)
    EDIT:
    Not correct... Beagleboard-XM uses 26.0/332/600 MHz.
    Reviewed my Archos specific hacks in x-load and went back to defaults.
    Now PLL seems to be setup correct.

    Whatever no more digging the next days, i'm off for the weekend.
    I'll post some sources next week.

    Some thoughts about u-boot 2011.12 on Archos:
    Seems there are some code parts not matching well with the Archos device.
    There are several sources floating around based on this, but with more or less hacks to be found in the code. So it's hard to point it all out and get a clean starting point.
    Grabbed the mainline sources form git.denx and got some problems with mmc initializing correctly, so again might be not completely bugfixed or causing some incompatibilities.

    Maybe i'll check u-boot 2012.09 mainline, because right now i'm using a modified source for a DM3730 board from technexion.
    Not the cleanest to start from to be honest... :rolleyes:

    Have fun and drink some beer!!!

    scholbert
    2
    hi letama!
    :) Well, I've been soldering long times ago, but never that small. When I was at school, surface mounted where not that common.
    If you start with SMD stop drinking coffee that day :D

    Multimeter, I have (cheap one, not sure how it behaves with low voltage).
    Oscilloscope, niet!
    Multimeter is all you need.

    Ok, got it now.. When you were saying that mmc got shifted and messed up urukdroid, I thought it was coming from kernel.
    Ah now i remember what i wrote down. Yeah sure i made an attempt to start from external, and the mmc got "shifted", but i realized that the slot has to be powered all the time obviously. It is switched off by default (after reset).

    Well, I was thinking about using Archos bootloader and rawfs partitions mechanism, we'll see.
    Yeah sure i'm talking about the stock bootloader. We gonna hack this code :p

    Ok, do you have any reference of something that is 1.8 ready? The less I have to play with, the better, so even if it's a little more expensive, it's worth it for me. My first goal is to have console as I expect error message on the bootloader with it, it would at least confirm that I have a chance to do something. And maybe boot from serial would be easier ? Could be interesting...
    Yepp agreed, console should give some message at early boot.
    For the adaptor there's nothing reallymade but this one would be capable to manage 1.8V levels on chip-level:
    http://www.digitus.info/fr/produits...isseurs/adaptateur-usb-serie-usb-20-da-70156/

    This one's inside:
    http://www.ftdichip.com/Products/ICs/FT232R.htm

    I'd prepare a pic from the PCB, but right now i could not find this bloody thing...
    EDIT: O.k. found it...
    This is also little fiddly but might be the easiest way because no additonal logic is needed.
    You might find better soldering points for RX, TX and please remind the directions:
    Code:
    Transceiver  Archos board
    TX     ->    RX
    RX     <-    TX
    Yes, completely new and very interesting! I have some basic electronic knowledge, it's so far ago that I forgot most of it, so that's why I said consider me as a complete noob.

    I won't do much more damage than the state it is right now, it won't go to rma with what I did to it.
    Yeah no problem... let's kick that OMAP :p

    Interesting option too. Well, first, let's try console, if it goes smooth there, we'll see.
    Using this method there's no need for extensive soldering and stuff (apart of change the bootmode of course).
    We connect to host using the microUSB port. The tool then listens for OMAP boot strings and kicks in the internal ROM bootcode.
    You than are able to initiate SDRAM and run everything you like...

    Anyway, we should start with the console as you said.

    Regards,

    scholbert
    1
    datasheet collection

    Hey,

    i was lucky last week. My device is up and running.
    Fortunately the eMMC data structure was O.K. In the end my device refused to boot, because of that broken connection to the RAM.
    So there'd been no need to fiddle around with eMMC for now.
    Maybe i'll do some investigation at a later point.

    Feel free to set up your device for peripheral boot and try the Ti Flash tool debugging possibilities.

    Right now i decided to re-assemble the device and use it for a while.
    I must assume that i know nothing about the internal structure of the firmware. So it would be essential to get some insights :D

    I got some additional information about the eMMC/microSD data lines.
    If there's some interest i might post further pics.

    To get some background about the chips on the A101 mainboard, i collected some datasheets of the main components.
    Grab the zip-file here.

    Most of them are easy to find other's are not ;)
    Anyway, saves your time i guess.

    BTW, is there any tool to unpack gen8 AOS files?

    Regards,

    scholbert