yashsingh1/xdaforums huggingface dataset:
[Gen9, Gen10 General] scholbert:
Hi kr0m!

Would be nice to know which device?

There's a package for a Samsung Galaxy Nexus (a.k.a. tuna) floating around.

Do a web search for OMAPFlash_tuna.zip.

You might find a second loader for HS devices in this package.

Though it might completely fail to load on "non-Nexus" devices because of signature missmatch.

BTW, fortunately all OMAP's inside the Archos tablets are GP :D

(we got no phone at least...)

Good luck for your unbricking attempt!

scholbert
[Gen9, Gen10 General] scholbert:
Geek stuff...

Hi hardware freaks,

i just decided to put down some information about my latest investigations.

First i edited my first post, but i don't want it to get bloated.

The background for the research is, that i started to port linaro u-boot stable to support the Archos G9 series :D.

So i had to look for differences and similarities between kwown platforms and do a little reverse engineering again.

Some words on the power supply on our mainboards...

As i wrote down in my first post the device's main supplies are powered by a combination of TWL6030 and TPS62361.

This in fact is very similar to Pandaboard ES powered by OMAP4460.

See this schematic as a reference:

http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-schematic.pdf

After stepping through some lines of code (x-loader, u-boot, kernel), it gets more clearer how things work out on the Archos devices.

I assume that due to cost reduction Archos engineers decided, to build a mainboard which supports all devices using the same base layout (apart form the HDD devices of course).

This results in a design which supports OMAP4430 and OMAP4460, and has enough power to increase RAM size as well.

Because the OMAP4460 has higher recommendations concerning VDD_MPU they choose the TWL+TPS approach for the main supply.

See the attached pic giving you a geek's map of the power supply area.

This is how it works out for the OMAP4430:

TPS62361 VOUT -> VDD_MPU (~1.375V)

TWL6030 VCORE1 -> VDD_CORE (~ 1.200V)

TWL6030 VCORE2 -> VDD_IVA (~ 1.188V)

TWL6030 VCORE3 not used.

The values vary during operation especially VDD_MPU depends heavily on clock settings. There are some power management rules behind this and Ti is speaking of the smartreflex mechanism.

These base voltages also depend on the type of CPU, the values for OMAP4460 are little different.

Anyway, enough technical talk...

Have a nice day!

scholbert
[Gen9, Gen10 General] Shano56:
Hey there Mr scholbert,

I had a question, and I didn't want to start a whole new thread for a quick question, so I'll ask here.

The DC jack (or the eqivelant of a DC jack for the tablet?? not sure what it's called) got ripped straight off the motherboard, and I want to take it apart to solder it back on. I would just do an RMA, however I think it would be a hassle to do ANOTHER RMA, explain to them what happened, wait for replies, wait for shipping, hope they don't bug me about the SDE menu.

Anyways, you had posts on how to safely and correctly disassemble the casing, could you point me to that thread? I can't find it.

Edit: okay nvm, I found a youtube video, and finally got it open. God that was a pain in the ass. I see there are 3 tiny tiny tiny pins for the jack. Do those have to be soldered on the individual points? O_O
[Gen9, Gen10 General] scholbert:
Mmmh not sure which part you are talking of... AFAIK only the HDD models have a dedicated DC-connector all flash models are charged via micro-USB connector.

So i guess you're talking about the HDD model, right?

O.k. nice that you made it. Would you mind to post a little pic with the connector?

Anyway, most parts got only two electrical contacts (DC_IN and GND) but are soldered with three pins. Sometimes GND could be found at two pins or there is an additional switch contact. So basically yes, you'll have to solder all pins.

A pic could help though...

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
Yes, pics please. I'm interested if external power connectro can be added to the flash model (power management chips are the same in both cases so it *should* work)
[Gen9, Gen10 General] scholbert:
Basically this should work of course. It's more a mechanical issue, where to place this connector.

If you look at the mainboard you may recognize there's a little fuse near the micro-USB. Unfortunately this detail is missing in the pics of my first post.

Anyway, the component is marked with a "T" on top.

This is the "entry-point" for charging current on the flash based models. If you solder some wire at this point and attach it to a DC connector you're done.

Of course you'll need GND connected as well.

To disable slow charging you'll need a DC connector with a switch and connect it as well...

Soldering skills will be required!!!

Regards,

scholbert
[Gen9, Gen10 General] scholbert:
u-boot booting kernel... progress so far

Hi,

there'd been not much sparetime at the weekend, but i slightly modded kernel code to give me early boot message over serial line.

See this log:

U-Boot SPL 2012.04.01 (Jul 06 2012 - 15:19:30)
OMAP4430 ES2.3
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img

U-Boot 2012.04.01 (Jul 06 2012 - 15:19:30)

CPU : OMAP4430 ES2.3
Board: Archos A80S
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0
Using default environment

In: serial
Out: serial
Err: serial
Battery Voltage: 3912 mV
checking for preEnv.txt
reading preEnv.txt

** Unable to read "preEnv.txt" from mmc 0:1 **
Hit any key to stop autoboot: 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

4268544 bytes read
Booting from mmc0 ...
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.0.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4268480 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

EDIT:

The kernel output is now attached as dmesg-extboot.txt

Kernel is booting to rootfs now. Some tweaks had been necessary though!

This is a breakthrough for an open bootloader on our devices.

Some additional info...

State of u-boot port:

- basic functions work very well, there's some issue with the reset command though

- full support for mmc1 (microSD) and mmc2 (internal eMMC)

- using kernel default command line for now

- only serial console at the moment

Required kernel tweaks:

- enable serial console on ttyO0, enable low level debugging on ttyO0 as well

- modified some board depended files to ignore feature tags

- setup the board with default values, taken from the tags file for now

- modify default kernel cmdline to work properly with angstrom test image

Info about the test rootfs:

- build with online build server for angstrom using omap4430-panda configuration

- barebone console only image

- placed on second partition (ext3) of the microSD

- due to Archos board setup kernel handles microSD as mmcblk1

- internal eMMC gets mounted on /media/mmcblk0p1..4

- no graphics, no bluetooth, no wifi with this image

(it's just used as a proof of concept now)

So to make it clear again... the system is booted up without any resources from the internal eMMC. No Archos stuff, except kernel of course.

This is a complete GPL'ed approach, not limits but geek stuff at the moment.

If you ask: Why should we do it?

...Please refer to the kindle fire forum what could be done with an open bootloader.

There's more work to be done... but no need to hurry i guess :laugh:

Cheers,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
No problem, it shouldn't be a problem finding a suitable place

Can you explain a bit more? Or is it marked in datasheet?

No problem:
[Gen9, Gen10 General] Shano56:
Hmm oh yeah I was talking about the micro-USB port sorry I was tired last night and couldn't think of the name
[Gen9, Gen10 General] scholbert:
O.k. i see you've tweaked some hardware already ;)

No, the fuse is not part of any datasheet, it's a component on the mainboard marked with a "T" on top.

Unfortunately i got no camera at hand... see the pic attached (stolen from harfainx's thread).

You might solder a wire at the "input" of the fuse, which is connected to the microUSB. This area is covered by the camera holder...

To replace the microUSb is not an easy task, because on the backside you'll find the microSD slot. Unsolder the connector would be evil, i guess.

Will take some detailed pics of this area... soon.

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
It's not the first and not the last one ;)

Fuse part is crystal clear but what did you mean by

I know that data lines are shorted in the power adapter, did you mean that switch in a DC connectro should short them?
[Gen9, Gen10 General] scholbert:
No i guess this won't work, because the DC conectors i've seen so far, have a simple switch contact to switch either to VIN or GND.

I'm not sure 100%, but i assume Archos devices additionally use the ID pin on the microUSB slot to differentiate between wall charger or host PC.

Could also be, that HDD got slightly different hardware regarding the power supply to make the DC connector work.

AFAIK there's no slow charge mode over USB on these devices.

There's a feature flag to tell the kernel wether the device is equipped with DC connector or not. You may have a look at the feature_list.h file in the kernel source.

Anyway, good luck for your mod!!!

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
ID pin is rather used to distinguish Archos made cable from a generic one. For sure USB host adapter uses it (ID shorted to GND).

Wall charger has D+ and D- tied together.

Datasheet says that TWL6030 has both types of power input available- USB and DC adapter but both have also separate sense inputs (look at Figure 1 in "TWL6030 Battery Charging" pdf)

There may be no charging at all over USB

I'll check sources.

Anyway before I'll mod anything I'm considering to RMA the tablet due to ICS problems (system hangs, device runs hot all the time = worse battery life than 3.2.80 etc) and not working charger.
[Gen9, Gen10 General] Copp:
An awful lot of ll this is going wayyyy over my head but I have a question I've posted elsewhere in the G9 forums here:

I have a G980 1.5 gz Turbo. Sorry, I consistently get lock within 60 seconds, I am 10-12 feet from nearest window (but small skylight over me).

But, regarding cigarette lighter problem:

When I first got the tablet, back before running Surdu_Petru's rooted ROM 4.06, (and possibly the OTA ICS update as well!), my G9 accepted all manner of 1.5-2 amp chargers, and topped off my battery quickly. Now, it will

only

slow charge. I have no idea where my original charger got off to. I have a 4 outlet USB 2 amp (each port) charger I got from Meritline.com. This is an essential bedside fast charger for my Droidx, my wife's IPad, my G9 and Pandigital reader/tablet.

Meritline also carries a low profile IPad charger for cigarette lighters. IPad chargers require 2 amps to charge, the standard .5 cigarette lighter charger for phones doesn't cut it at all. It too used to normally charge my tablet quickly.

However, nothing seems to normally charge this tablet anymore. (Really wish I had the original now to see if it would work). Does anyone know what, if anything, was done by Archos to limit the acceptable charger input? Because 2 amps will charge the unit AND run a GPS or most anything else I want to do, be it my Droidx or this G9...at least normally. Lack of a fast charge is driving me nuts.
[Gen9, Gen10 General] scamlist:
GPS

I presume you have seen the various threads on GPS problems.

Do you know how you would go about attaching a socket for an external antenna ?

Many thanks for your information and photos.
[Gen9, Gen10 General] gen_scheisskopf:
I'm afraid GPS problems are software related- it worked much better on Honeycomb
[Gen9, Gen10 General] scamlist:
Thanks

Is there any way of getting back to honeycomb?

All I can find is download links to ICS
[Gen9, Gen10 General] scholbert:
Hmmm strange stuff.

As stated before...

The two USB data lines of the stock cable get shortened if plugged into Archos wall-charger (-> quick charge). So in fact the dat lines inside the type A connector of the wall charger are shortened. You might have to tweak your car-adaptor this way.

On some types of car-chargers there are no data lines at all. Only VCC and GND are connected to the microUSB connector.

These adaptors will never identify themself.... always slow charge

Just to add this...

On a host PC the data lines are used as data lines :D (-> slow charge).

Additionally the ID pin at the Micro-USB is used to identify stock cable.

Please read carefully ;)

Yupp seems a software issue...

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

Should i say more...

I never downgraded, got no idea if it will work.

You should do a full format of your device in the Recovery menu though (all data will be lost then).

Use the search function of the forum to gather further information...

Anyway some hints of what i found out while fiddling around with the GPS:

- disable Automatic date&time in the date&time settings

- disable Google's location service in the Location service settings

- enable GPS sattelites in the Location service settings

- if you use GPS status from EclipSim:

- in the tools delete AGPS data

- in the settings disable Auto-download of AGPS data (set to never)

- reboot

- start GPS status & wait

Have fun!

scholbert
[Gen9, Gen10 General] ciariello:
hi men first of all congratulations for your great job...

i need help....can someone confirm if the PS7000 emmc controller has the same pinout of the PS8005?

i can't find PS7000 datasheet if someone could help me....

Thank you very much
[Gen9, Gen10 General] scamlist:
Anyway some hints of what i found out while fiddling around with the GPS:

- disable Automatic date&time in the date&time settings

- disable Google's location service in the Location service settings

- enable GPS sattelites in the Location service settings

- if you use GPS status from EclipSim:

- in the tools delete AGPS data

- in the settings disable Auto-download of AGPS data (set to never)

- reboot

- start GPS status & wait

Have fun!

scholbert

The above worked for me.

Unfortunately I had visitors just as I had gone through the above process. My unit was left on the window sill with the mains adapter connected.

I came back to it about three hours later and I had a fix!! 11 satellites in view, 10 in use

I did a reboot and by the time GPS status had started it had a fix - 11 satellites in view, 10 in use.

I did this several times with similar results.

Overnight came the test. I turned the unit off !

In the morning it was turned on and we were back to just 1 or 2 satellites in view and no fix.

I left it on and had a fix in 35 minutes.

So I have proof that everything is working. Just need to remember to switch it on before having breakfast when setting of on a journey !!

Not very satisfactory.

I may try a bluetooth GPS receiver whilst awaiting an update that MAY provide a proper solution.

Many thanks scholbert

P.S.

In the status bar I have a circle with a dot in it, showing the GPS is on and has a fix whilst viewing an app using it such as GPS Status.

With no fix the icon is a circle without a dot in it.

There is NO icon on the Home Page when switching to it from GPS Status and knowing a fix is achieved.

There IS an icon on the Home Page when switching to it from NavFree (navmii)

Is this because NavFree will still be running in the background, whereas GPS Status will not ?

Many thanks again
[Gen9, Gen10 General] scholbert:
Hi,

thanks for appreciation :D

No i could not confirm that the pinout is exactely the same.

While i examined the hardware i traced some lines to the chip, the PS7000 seems little different to the PS8005.

I did not find any datasheet neither, but decided to put down the PS8005 into my datasheet archive, which has a lot of similarities.

It would possible to trace most of the pins... It's all there... the eMMC interface and the NAND interface as well.

Would be little time consuming though and i won't have the time in the next weeks.

What is your intention with the PS7000?

I'm glad that it worked out.

I observed the same behaviour of the GPS in general.

Anyway have not used NavFree yet, but i guess it's the background process which causes it.

GPS on Archos might not be the best one, but it works most of the time for me.

To use it for car navigation, i would recommend a external GPS mouse.

There'd been a lot of threads out there, just use the search function.

... but keep cool, while reading some posts... some people seem to believe in voodoo and/or mix things up terribly.

Some facts i found out about the GPS subset:

- from a hardware point of view the chipset itself is working O.K.

Though the antenna could be more powerful

- sometimes the GPS firmware seems to get confused by power management

Might be a kernel driver issue...

The device needs to be rebooted then

- the GPS chipset uses uart1, which is also used for some bootloader messages. This may confuse the chipset in some situations.

Maybe this is the cause for voodoo behaviour ;)

Maybe there's some version of bootloader which causes issues... voodoo!!!

- the assisted data of some tools out there, do not work together with the internal protocol. In other words the data set is useless or confuses the internal stack. You'll need long time for a fix, or fix is impossible.

The application needs to be stopped and assisted data has to be deleted.

Most of the time, the device will need to be rebooted then

That's it by now.

Have fun!

scholbert
[Gen9, Gen10 General] scamlist:
I have found MapFactor Navigator which is running smoothly at the moment. It's on the market.

I am still getting satellite fixes OK

It is also relatively easy to install your own POIs into Navigator so all is good at the moment

Thanks again
[Gen9, Gen10 General] ciariello:
thanks for your reply...i am doing some "experiments" on xbox corona mainboard and there is onboard the same Phison controller but the documentation misses...
[Gen9, Gen10 General] vicencb:
Hi scholbert,

I've been following this thread since it started and it helped me a lot!! Thanks for it.

I started hacking with my A80G9 with the purpose of installing a native linux.

The first thing that improved development speed was your posting about the CONFIG pull-up resistors, so started to boot from USB.

Then USB booted a modified version of barebox, first stage and second stage. Barebox worked fine: I could send commands and receive responses, mount the SD card and read and write files, ... Almost everything worked fine.

After that tried to boot the Android kernel because it's an already tested kernel and it works ok. But couldn't make it work. It may be because barebox does not support android, but don't know.

So, to debug my problem I've set up the serial port.

When Androig boots it prints some text (at 1000000-8n1) and from Android with picocom text can be sent to the PC.

The problems are:

Can't transmit text from PC to tablet.

And can't make it work from barebox (following the instructions from OMAP datasheet only get garbled data).

You've mentioned some changes were required for the serial port: "There's some power issue with the input though, but this is easy to fix (fixed in hardware already)."

Wich changes are these? can this explain my problems? or can be related to the GPS sharing the uart?

Thanks again scholbert, you have already helped me very much.

vicencb.
[Gen9, Gen10 General] scholbert:
Hi vicencb!

It's always nice to read that :)

Cool... so yet another bootloader for our tablets.

Did you realize that i got a working port of u-boot in the meantime?

I guess i already know what is wrong...

You can not boot the stock kernel with non-stock bootloader without doing some tweaks to the kernel code. It has nothing to do with Android at this point.

I will prepare a small patch for stock kernel to initialze the hardware correctly, even without stock bootloader.

Mmmh this is little irritating... you first wrote that you could send commands and receive responds... so this was over USB then???

The serial port needs to get initiated by the bootcode of course.

So please make sure there are some lines for the UART inside barebox.

As you know i posted a pic with the test points for the UART.

There's a testpoint for VIO1.8 if i remember correctly.

Unfortunately this voltage is present with activated GPS...

...on the other hand the UART then is blocked by GPS.

So to make this connection work you'll need:

- a low voltage UART2USB converter capable to run at 1.8V

- find another power source for 1.8V

(there are several capacitors beneath the CPU, carrying this voltage)

Anyway you might use the alternate function of the USB-OTG pins as well to get serial console output... this is the way Archos does it for debuggging.

Have a look i the kernel sources for the board file. There's some information about it :D.

Cheers,

scholbert
[Gen9, Gen10 General] vicencb:
Hi scholbert,

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.

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.

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.

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!

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.

Do you have any recomendations or work done on booting a vanilla kernel?

Thanks,

vicencb
[Gen9, Gen10 General] gen_scheisskopf:
And why shouldn't it work underclocked? :)

Does slower system_clk make any difference for the hardware?
[Gen9, Gen10 General] vicencb:
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.

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.