yashsingh1/xdaforums huggingface dataset:
[Gen8 General] scholbert:
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
[Gen8 General] rplc790222:
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
[Gen8 General] chrulri:
sounds great, keep on rolling :cool:
[Gen8 General] scholbert:
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:

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.

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
[Gen8 General] aaronmy:
Pretty Cool :D
[Gen8 General] scholbert:
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
[Gen8 General] trungvn1988:
Nice try. Can you tell us about the RAM, it's built in the mainboard or changable?
[Gen8 General] eagleofdeath13:
We already know that, it's built-in ^^

(some have opened their Archos before ^^)
[Gen8 General] Harfainx:
http://forum.archosfans.com/viewtopic.php?f=74&t=42806

Soldered on, not changable by anyone with home soldering tools. Very small ball soldering. I gave it an attempt, even got a replacement 1GB RAM module as a test piece... Didn't work out well for me.

I'll definitely be keeping an eye on this topic, seems like some good information might come of it.
[Gen8 General] scholbert:
.............yippie yeah it's working out!!!!

Thanks for the feedback :D

First i'll have to quote myself:

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 :)

Yes i'll try my very best :rolleyes:

Kind regards,

scholbert
[Gen8 General] eagleofdeath13:
Guy, it's so nice! Keep up the good work!
[Gen8 General] scholbert:
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
[Gen8 General] aaronmy:
yes it would be great if we could find one, maybe we could find a way to get inside and change some things:D
[Gen8 General] FrEcP:
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 ;)
[Gen8 General] FrEcP:
good news - check out:

http://xdaforums.com/showthread.php?t=1214674

seems we got a way to extract soon
[Gen8 General] scholbert:
..... uuuh great!!!

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
[Gen8 General] pbarrett:
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).
[Gen8 General] scholbert:
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
[Gen8 General] blawoef:
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...
[Gen8 General] chrulri:
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.
[Gen8 General] pbarrett:
Sigh - If it's part of the TPS65921 that dies, it looks like this is a 120-pin package with the leads underneath for wave-soldering or something. Not replaceable by even a determined hardware hacker.
[Gen8 General] scholbert:
Please read carefully... i don't think that the PHY got damaged on those devices.

I really think, that:

a) the dc-dc regulator for Vbus is dying

b) the mosfet switch for USB power management is dying

From what i read so far, many people tried to attach external harddisk... what could i say... it makes sense to me, if the port is dying in the end.

I read about the USB host being specified to deliver not more than 200mA, which too less power for external hdd.

If it would be a PHY issue, the same would be on Beagleboard or any other board using this approach for USB host connection (TPS65291, TPS65950,...) .

I think i'll prepare some pics...

Best regards,

scholbert
[Gen8 General] FrEcP:
just a dumb question:

to prevent usb-host from dying (if it's current related) - can't we just bypass our usb pins 1 and 4 with a diode?

Battery -> diode -> usb-port

and just a cable for ground backwards (if this is needed at all....)

or would we face any problems? As usb devices noramly negotiate the current-use in begin of connection as i read...

I'm reall interested in - as one of the reasons for my 101 was the usb host for hd ;)
[Gen8 General] scholbert:
O.K. to sum it up... you may use external power supply at any time for devices connected to the USB port (remember external 3.5" hdd got their own power supply).

No need to connect the Vbus supply to the archos device and you won't need the diodes either.

Just make sure you got that ground connection.

In other words D+, D- and GND is needed for the interface to work.

O.k., i suggest the following...

1) Contact Archos support team and ask for the specified current of the USB host.

2) Use a self-powered external harddrive only

...

Regards,

scholbert
[Gen8 General] FrEcP:
yy - sure i know that - but I just own those nice litte 2,5" hdds. and they dont have external power supply (ofc they have a Y-cable and i could use: an usb-powerplug + an extension usb cable + y cable and then plug it in - but do i really want that?!?! no)

casue I bought this device casue of portability and this also sound more like a workaround)

That's why the diode-thing came into my mind.

1 Time short soldering and the problem might be gone!?!?
[Gen8 General] FrEcP:
yy - sure i know that - but I just own those nice litte 2,5" hdds. and they dont have external power supply (ofc they have a Y-cable and i could use: an usb-powerplug + an extension usb cable + y cable and then plug it in - but do i really want that?!?! no)

casue I bought this device casue of portability and this also sound more like a workaround)

That's why the diode-thing came into my mind.

1 Time short soldering and the problem might be gone!?!?

(Btw just found that: http://www.usb.org/developers/whitepapers/power_delivery_motherboards.pdf - seems noramly use SHOULD be bypassed by a capacitor for avoiding voltage drop)

So what we realy need to know for now is 1.)

Then we can decide if the problem is the static current or just peak related.

(Just to give some values here: my Fujitsu 120GB IDE HDD tells 5V 0.6A but i reaed about some HDDs taking up to 1A (dunno it's true) wich would be definetly TOO much for a singe USB port)
[Gen8 General] eagleofdeath13:
I remember to have seen somewhere (can't remember) a current about 200 mA or 500mA (not sure, but think it's the first one) for the A70S
[Gen8 General] fzelle:
std is 100mA on the A70S

Sibere made a kernel that allows up to 500mA minus the display.
[Gen8 General] eagleofdeath13:
Thanks for correcting :)
[Gen8 General] scholbert:
For reference:

http://xdaforums.com/showpost.php?p=14391057&postcount=1311

Here's what he did:

http://gitorious.org/archos-buildroots/gen8-kernel/commit/77f645422129902b574a2d23987f3963bfa73874

Of course kernel tweak is no voodoo...

...in the end it's the hardware that sets the limit.

Regards,

scholbert
[Gen8 General] FrEcP:
Well any informations about the 101?

As this is the device with frequent dying USB-Ports and as far as i know has no "software" limitaion.

Wrote to Archos this morning:and got an answer back - sady the are not willing to hand data out, nor they know the source of the problem as it "seems".

original:

"leider ist dem Support die Ursache für das beschriebene Verhalten nicht bekannt. Unser ENtwicklerteam beschäftigt sich bereits mit der Angelegenheit, aber hier habe ich keine Infos vorliegen, die ich Ihnen geben dürfte."

Anyway +1 for Archos for the fast answer ;)
[Gen8 General] divx118:
scholbert: You know the uart connection on gen8 http://www.openaos.org/archives/714?

Just mention it if you mist it.

You may also checkout irc channel #openaos on freenode. (webchat http://www.openaos.org/chat )

Maurice :cool:
[Gen8 General] scholbert:
Yeah sure...

Please don't get me wrong. All i wanted to say is, that hardware must be capable to deliver enough current.

During USB enumeration the device "tells" the host how much current it would consume during full operation.

If the kernel responds that it would drive 500mA, but the hardware is not able to do so, it may result in faulty behaviour.

The power switch or DC/DC converter might get damaged in this case.

Apart from that i totally agree, that if i buy a device with a standard USB port, it should fulfill the specs :rolleyes:

O.K. that's really an interesting answer.

Thanks for this information :)

Best regards,

scholbert
[Gen8 General] scholbert:
The UART hack

Yepp i knew about it.

Guess it's time for some pics again... see attachments.

Thanks for inviting me... unfortunately my sparetime is very limited to join the channel.

Anyway maybe i'll should give it a try ;)

Some words to the hack i documented in the pics.

There are two main problems you might run into:

1. The 1.8V logik level of UART3 of OMAP

2. The not standard baud rate of output

See next post for some comments on that!
[Gen8 General] scholbert:
The UART hack pt.2

Here's the log of the bootloader output and kernel message from the very start.

To connect to my Host-PC i used a DLP-USB232M USB Adapter.

To convert the 1.8V level, i used two SN74LVC1G07 single gates.

To achieve the non-standard baud rate of 1000000 8N1 you'll need to tweak the driver for DLP-USB232M.

Replace the following lines in ftdiport.inf:

...
[FtdiPort.NT.HW.AddReg]
HKR,,"UpperFilters",0x00010000,"serenum"
HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,71,02,00,00,38,41,00,00,9C,80,00,00,4E,C0,00,00,34,00,00,00,1A,00,00,00,0D,00,00,00,06,40,00,00,03,00,00,00,00,00,00,00,D0,80,00,00
HKR,,"MinReadTimeout",0x00010001,0
HKR,,"MinWriteTimeout",0x00010001,0
HKR,,"LatencyTimer",0x00010001,16
...

After tweaking the ConfigData entry, you will need to update the driver.

You might also manipulate your hosts registry manually.

With your terminal program you'll have to choose 921600 as your baudrate.

In fact the tweaked data sets the USB adaptor to the needed rate of 1000000.

Here's some related documentation as well :D

There's not much practical use for this hack right now.

As you might realize the output is pretty much the same as calling dmesg, apart from the first lines.

Next would be getting an idea of the CLI interface (if there is one) of the avboot bootloader and how to get into it :rolleyes:

If anyone knows anything about it, please join the thread!!!

Credits: Special thanks to av500 who discovered the UART testpoints!

Have fun!

scholbert
[Gen8 General] FrEcP:
just to mention here for anyone who ever bricks his device :D

UnBrickable needs some dead devices with Cortex A8 for research

or schollbert also can find this pin? without destroying it?
[Gen8 General] scholbert:
Thanks for this info... :rolleyes:

The UnBrickable is a quite nice project.

Please read the intro... it is for the Samsung Hummingbird SoC.

Our Archos tablets use Texas Instruments OMAP.

Both got a Cortex-A8 core but are different architectures.

So please don't mix it up!!!

I published these pins already in my first post :rolleyes:

In fact the UnBrickable guys traced the Boot mode pins used by the Hummingbird SoC to identify the boot mode.

OMAP -> sys_boot0..5

Hummingbird -> XOM0..5

They change this setup to boot external media. That's the basics.

Next step will be to examine all the mainboards listed in their post to make use of this feature.

Maybe i should also push things the way they do, but it's not my way...

I am also missing time to start a project for an open bootloader.

Anyway it's nice to see some projects like this and i really appreciate it.

So thanks for pointing out FrEcP!!!

Regards,

scholbert
[Gen8 General] FrEcP:
Oh didnt know that before- thoguht its the same and they just didnt list our device eventualy as its not so popular ;)

im not that into hardware yet...

Well anyway perhaps we someday can make it possible here too.

And y my sapre time is also quite at its end atm - have to go for exams atm to find an end for my study some day.
[Gen8 General] scholbert:
Obviously you didn't get me right...

The UnBrickable project and the things i point out here are different playgrounds. The only thing in common is the procedure of external booting.

I located the boot mode pins for OMAP SoC on the Archos 101IT.

By pulling sys_boot5 high we are able to use external booting... in fact this makes the Archos 101 unbrickable in the same way.

Though some further experiments have to be done.

E.g. using the eMMC driver of the Ti flash tool i already mentioned in the first posts. With these tools at hand, the internal eMMC of the Archos could be re-written from scratch, even if bootloader got corrupted.

As soon as i'll find some time i will do more testing. Right now i prepare for holiday... so no time for fiddling around with this now.

Anyway, maybe some guys out there will get inspired and jump in ;).

Have fun!

scholbert
[Gen8 General] scholbert:
What about hacking Wifi/BT on Archos?

Hi geeks,

i found an interesting wiki page at LSR Research covering the Wifi/BT chipset used in our Archos devices.

http://wiki.lsr.com/TiWi.ashx

Archos implemented the same chipset into our tablets and i wonder if some additionally features could be activated (see attachment as well).

The chipset consists of WL1271 (wifi) and BL6450 (bluetooth & fm radio)

Basically the BL6450 is capable to receive FM radio as well, but this feature seems not to be implemented in firmware (TIInit_7.2.31.bts).

Also it is unknown, if the signals are wired in hardware.

I know that there'd been some discussion here at XDA about this feature.

But maybe there's still something to explore.

For example, there are many alternative firmware packages at TI's developer page.

https://gforge.ti.com/gf/project/wilink_drivers/

Anyway, feel free to check out the links, might be an interesting playground :p

Regards,

scholbert
[Gen8 General] FrEcP:
>Obviously you didn't get me right...

>The UnBrickable project and the things i point out here are different playgrounds. >The only thing in common is the procedure of external booting.

no no mate i got u right - just was pointing to the thing u mentioned below (and doing something similar)

>I located the boot mode pins for OMAP SoC on the Archos 101IT.

>By pulling sys_boot5 high we are able to use external booting... in fact this makes >the Archos 101 unbrickable in the same way.

>Though some further experiments have to be done.

Well anyway u found out some nice things again - radio on our archos - would be really a nice playground ;)

but actualy i dont know anything about how to get it started...

EDIT: just zapped through the links - looks promising- DAMN I got exmas soon - ohoh :(

Btw where are u working as u know all this stuff? Or is it just your basic knowledge of an electical engineer...