Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,733,661 Members 45,110 Now Online
XDA Developers Android and Mobile Development Forum

A101it mainboard hacking and chipset information

Tip us?
 
alephzain
Old
#131  
alephzain's Avatar
Senior Member
Thanks Meter 1981
Posts: 117
Join Date: Sep 2010

 
DONATE TO ME
Quote:
Originally Posted by scholbert View Post
All looks o.k. to me, arch_number is setup to A101IT, but is not passed over to the kernel correctly.
Seems that something is not interpreted the way it should be...
If R1 really holds the arch_number during kernel pass over and at early kernel startup,
then u-boot has to pass it right before the jump to kernel code...
Little irritating, maybe i should disable TAG support in u-boot
I don't think disable TAG resolve issue since tags come right after lookup arch_number in arch/arm/kernel/head.S and it failed at __error_a
Code:
ENTRY(stext)
        msr     cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
                                                @ and irqs disabled
        mrc     p15, 0, r9, c0, c0              @ get processor id
        bl      __lookup_processor_type         @ r5=procinfo r9=cpuid
        movs    r10, r5                         @ invalid processor (r5=0)?
        beq     __error_p                       @ yes, error 'p'
        bl      __lookup_machine_type           @ r5=machinfo
        movs    r8, r5                          @ invalid machine (r5=0)?
        beq     __error_a                       @ yes, error 'a'
        bl      __vet_atags
        bl      __create_page_tables
Publish source code maybe could help to make things easier ...
 
wilsey
Old
#132  
Member
Thanks Meter 28
Posts: 96
Join Date: Jul 2009
Location: N Ireland

 
DONATE TO ME
Thanks for all your work with this, esp Scholbert

I think many like myself watch this post with great anticipation, but like myself haven't got a clue! And don't want to spam the board with stupid posts that piss the developers off.

Thanks again for all the work going into this and great respect for what you lot have accomplished!
 
scholbert
Old
(Last edited by scholbert; 23rd March 2012 at 02:14 PM.)
#133  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Quote:
Originally Posted by alephzain View Post
I don't think disable TAG resolve issue since tags come right after lookup arch_number in arch/arm/kernel/head.S and it failed at __error_a

Publish source code maybe could help to make things easier ...
Yeah, guess you're right...
BTW, today i think that this issue is not even related to TAGs.
Here's another snippet from Archos kernel (/arch/arm/kernel/head-common.S):
Code:
/*
 * Lookup machine architecture in the linker-build list of architectures.
 * Note that we can't use the absolute addresses for the __arch_info
 * lists since we aren't running with the MMU on (and therefore, we are
 * not in the correct address space).  We have to calculate the offset.
 *
 *  r1 = machine architecture number
 * Returns:
 *  r3, r4, r6 corrupted
 *  r5 = mach_info pointer in physical address space
 */
__lookup_machine_type:
        adr     r3, 3b
        ldmia   r3, {r4, r5, r6}
        sub     r3, r3, r4                      @ get offset between virt&phys
        add     r5, r5, r3                      @ convert virt addresses to
        add     r6, r6, r3                      @ physical address space
1:      ldr     r3, [r5, #MACHINFO_TYPE]        @ get machine type
        teq     r3, r1                          @ matches loader number?
        beq     2f                              @ found
        add     r5, r5, #SIZEOF_MACHINE_DESC    @ next machine_desc
        cmp     r5, r6
        blo     1b
        mov     r5, #0                          @ unknown machine
2:      mov     pc, lr
ENDPROC(__lookup_machine_type)
The hand over is done by R1 as we see... u-boot should pass it to R1 as well...

Got some ideas...
- Will compile u-boot again without CONFIG_OF_LIBFDT (new in u-boot 2011.12)
This has been set for beageboard, but might not be o.k. for Archos.

- Will step back to u-boot 2011.09 because some related parts in bootm.c look better here.

Concerning source code:
Guess it's to early to put things down at gitorious.
I got two source bases i work with... so let me sort out some things on Sunday first (i'm little busy).
I then might provide some patches or similar early next week...

Thanks for helping out.

Regards,

scholbert
 
scholbert
Old
(Last edited by scholbert; 27th March 2012 at 12:01 PM.)
#134  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Default 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

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...

Have fun and drink some beer!!!

scholbert
The Following 2 Users Say Thank You to scholbert For This Useful Post: [ Click to Expand ]
 
letama
Old
#135  
Recognized Contributor
Thanks Meter 2310
Posts: 1,679
Join Date: Feb 2008

 
DONATE TO ME
Hi Scholbert,

Nice progress!

Quote:
Originally Posted by scholbert View Post
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
This is suspicious too. I don't have a 2.6.29 running, but shouldn't it be only one only ? On msm, it was a symptom that something went wrong during early init phase.
Sony Xperia S (Boot Manager, JB AOSP 4.2.2, JB AOSP 4.3)
Archos A70IT2 Honeycomb model (SDE and rooted firmware)
Archos A101 G9 (SDE enabling, SDE root firmware , G9 ICS Alpha 0 )
Want to buy me a beer? Here is my donation link.

"I herd you like updates so we put an update in yo update so you can update while u update" g.revaillot (Archos)
 
scholbert
Old
(Last edited by scholbert; 27th March 2012 at 12:02 PM.)
#136  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Quote:
Originally Posted by letama View Post
This is suspicious too. I don't have a 2.6.29 running, but shouldn't it be only one only ? On msm, it was a symptom that something went wrong during early init phase.
Mmmh, guess you're right, should look like this:
Code:
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Will have to check if the caches are enabled correctly in u-boot.
Maybe it's just a simple CONFIG_... Option.
EDIT: Caches are enabled in u-boot.
Seems that this issue was caused by wrong PLL setup.
Now fixed!

If not some more intensive debugging will be necessary.
As i said, i'll prepare some sources next week

Cheers,

scholbert
 
scholbert
Old
(Last edited by scholbert; 27th March 2012 at 12:12 PM.)
#137  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Default PLL fixed, but kernel still stucks...

Hey,

just a short post about the state:
- Fixed PLL by using more default values
- Clean up some code is urgently required

Code:
Texas Instruments X-Loader 1.5.1 (Mar 26 2012 - 20:41:11)
Found 0256 MB
Testing memory, please wait...
DRAM: 0253 MB OK
Memory Test success!
Archos Gen8
PRM_CLKSEL         = 0x00000003
PRM_CLKSRC_CTRL    = 0x00000080
CM_CLKSEL1_PLL     = 0x094c0c00
CM_CLKSEL2_PLL     = 0x0483600c
CM_CLKSEL3_PLL     = 0x00000009
CM_CLKSEL1_PLL_MPU = 0x0011f40c
CM_CLKSEL2_PLL_MPU = 0x00000001
dpll_param_p = 0x40200d34
Reading boot sector
Loading u-boot.bin from mmc
Done!


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: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
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/332/600 MHz
As you see x-load PLL values now differ from my very first post.
I know used the standard setup for beagle.
Seemed that i missed some part earlier... and also assumed that Archos uses the same setup the very beginning of boot untill Android is reached.
This definitely is not the case.
Now i'm even closer to the beagleboard track again.

Booting is pretty fine (even early boot message) up to the point when kernel is trying to re-initialize SDRC...
EDIT:
O.k. enabled PM and clock debugging in my test kernel as well:
Code:
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered wkup_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered iva2_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered mpu_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered neon_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered core_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered cam_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dss_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered per_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered emu_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered sgx_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered usbhost_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dpll1_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dpll2_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dpll3_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dpll4_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: registered dpll5_pwrdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: associating clockdomain cm_clkdm with powerdomain core_pwrdm
<7>clockdomain: registered cm_clkdm
<7>powerdomain: associating clockdomain prm_clkdm with powerdomain wkup_pwrdm
<7>clockdomain: registered prm_clkdm
<7>powerdomain: associating clockdomain virt_opp_clkdm with powerdomain wkup_pwr
dm
<7>clockdomain: registered virt_opp_clkdm
<7>powerdomain: associating clockdomain mpu_clkdm with powerdomain mpu_pwrdm
<7>clockdomain: registered mpu_clkdm
<7>powerdomain: associating clockdomain neon_clkdm with powerdomain neon_pwrdm
<7>clockdomain: registered neon_clkdm
<7>powerdomain: associating clockdomain iva2_clkdm with powerdomain iva2_pwrdm
<7>clockdomain: registered iva2_clkdm
<7>powerdomain: associating clockdomain sgx_clkdm with powerdomain sgx_pwrdm
<7>clockdomain: registered sgx_clkdm
<7>powerdomain: associating clockdomain d2d_clkdm with powerdomain core_pwrdm
<7>clockdomain: registered d2d_clkdm
<7>powerdomain: associating clockdomain core_l3_clkdm with powerdomain core_pwrd
m
<7>clockdomain: registered core_l3_clkdm
<7>powerdomain: associating clockdomain core_l4_clkdm with powerdomain core_pwrd
m
<7>clockdomain: registered core_l4_clkdm
<7>powerdomain: associating clockdomain dss_clkdm with powerdomain dss_pwrdm
<7>clockdomain: registered dss_clkdm
<7>powerdomain: associating clockdomain cam_clkdm with powerdomain cam_pwrdm
<7>clockdomain: registered cam_clkdm
<7>powerdomain: associating clockdomain usbhost_clkdm with powerdomain usbhost_p
wrdm
<7>clockdomain: registered usbhost_clkdm
<7>powerdomain: associating clockdomain per_clkdm with powerdomain per_pwrdm
<7>clockdomain: registered per_clkdm
<7>powerdomain: associating clockdomain emu_clkdm with powerdomain emu_pwrdm
<7>clockdomain: registered emu_clkdm
<7>powerdomain: associating clockdomain dpll1_clkdm with powerdomain dpll1_pwrdm

<7>clockdomain: registered dpll1_clkdm
<7>powerdomain: associating clockdomain dpll2_clkdm with powerdomain dpll2_pwrdm

<7>clockdomain: registered dpll2_clkdm
<7>powerdomain: associating clockdomain dpll3_clkdm with powerdomain dpll3_pwrdm

<7>clockdomain: registered dpll3_clkdm
<7>powerdomain: associating clockdomain dpll4_clkdm with powerdomain dpll4_pwrdm

<7>clockdomain: registered dpll4_clkdm
<7>powerdomain: associating clockdomain dpll5_clkdm with powerdomain dpll5_pwrdm

<7>clockdomain: registered dpll5_clkdm
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/600 MHz
<7>clockdomain: clkdm core_l4_clkdm: clk omapctrl_ick now enabled
<7>clockdomain: core_l4_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>clockdomain: clkdm core_l3_clkdm: clk l3_ick now enabled
<7>clockdomain: core_l3_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>clockdomain: clkdm cm_clkdm: clk core_ck now enabled
<7>clockdomain: cm_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>clockdomain: clkdm dpll3_clkdm: clk dpll3_m2_ck now enabled
<7>clockdomain: dpll3_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>clockdomain: clkdm prm_clkdm: clk sys_ck now enabled
<7>clockdomain: prm_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>clockdomain: clkdm dpll5_clkdm: clk dpll5_ck now enabled
<7>clockdomain: dpll5_clkdm does not support forcing wakeup via software
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: setting next powerstate for sgx_pwrdm to 0
<7>clockdomain: enabling automatic idle transitions for sgx_clkdm
<7>powerdomain: completed transition in 7 loops
<7>powerdomain: setting next powerstate for dss_pwrdm to 1
<7>clockdomain: enabling automatic idle transitions for dss_clkdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: setting next powerstate for cam_pwrdm to 1
<7>clockdomain: enabling automatic idle transitions for cam_clkdm
<7>powerdomain: completed transition in 0 loops
<7>powerdomain: setting next powerstate for per_pwrdm to 1
<7>clockdomain: enabling automatic idle transitions for per_clkdm
Then it stucks...
Perhaps i'll need to power up some more domains in u-boot already.
Not sure though...
EDIT: Default domains are powered up already after reset.
The PM chip has to be in active state though, but this is obviously the case.
There are some differences between TWL4030 and TPS65921 regarding additional power domains.
E.g. VAUX3, VPPL2 is missing on TPS65921, VAUX2 and VPLL1 seems to be used instead.
Should be no issue here, but need to check this again.

Unfortunately there's no more debug message after the per_clkdm...
So i guess i will need to insert some printk's to get a clue where it actually stucks.
Hopefully the kernel then may give me some information where to fix up u-boot or what needs to be added at early stage.

I hope you're not bored about log postings

Regards,

scholbert
The Following User Says Thank You to scholbert For This Useful Post: [ Click to Expand ]
 
MarkY972
Old
#138  
Junior Member
Thanks Meter 1
Posts: 19
Join Date: Apr 2012
Unhappy Archos 101it brick after deleting a loader partition

Hello guys,

I have installed lxde version of linux on my rooted Archos and with my stupidity i tried to increase the swap file with Gparted prog and i guess that i deleted a first partition (30mb) that is on the nand mem. After reboot i got a black screen and nothing but the green light is on, brick. Any one with idea how can i restore the bootloader or do a hardd reset and install the original aos file?
The Pc is not recognizing the archos when i connect him thrue the usb port...

Thank's in advance
Marky
 
scholbert
Old
#139  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Hey Marky!
Quote:
Originally Posted by MarkY972 View Post
I have installed lxde version of linux on my rooted Archos and with my stupidity i tried to increase the swap file with Gparted prog and i guess that i deleted a first partition (30mb) that is on the nand mem. After reboot i got a black screen and nothing but the green light is on, brick. Any one with idea how can i restore the bootloader or do a hardd reset and install the original aos file?
The Pc is not recognizing the archos when i connect him thrue the usb port...
Right now, there's no easy way to restore bricks like this from scratch.
BTW, which model you are speaking of?

If you are curious and have good skills in soldering and hacking code, you might find a way though. It needs development...

As i wrote down, it is possible to tweak the hardware and boot the device with an external MicroSD card.
I used GPL'ed bootloader code to start and ported it to work on the A101 G8.
See this thread for the sources:
http://forum.xda-developers.com/show....php?t=1572506

You may find a way to enhance u-boot and gain access to the internal eMMC.
You might then restore the internal structure from within u-boot console.
This could be a long way...
So if you're a geek and like research and development, you can do it.
It's up to you...

Cheers,

scholbert
The Following User Says Thank You to scholbert For This Useful Post: [ Click to Expand ]
 
scholbert
Old
(Last edited by scholbert; 25th April 2012 at 03:10 PM.)
#140  
Senior Member - OP
Thanks Meter 630
Posts: 1,263
Join Date: Aug 2007
Quote:
Originally Posted by MarkY972 View Post
The Pc is not recognizing the archos when i connect him thrue the usb port...
O.k. we might try something...
If your device is really bricked (e.g. partition table is corrupt) it won't start any code on the eMMC.
Though it might load the signature file in the very first sector of the eMMC, we might try the following:
Please read this first:
http://forum.xda-developers.com/show...55&postcount=4

I used a tool from TI which could be downloaded here:
https://gforge.ti.com/gf/project/flash/frs/
It is known to work well on Windows XP. Haven't tested on other OS yet.

Download this package, unpack the zip file to a folder of your choice and install the program.

Make sure your Archos tablet is completely powered off (press power button for at least 10 sec.).
Connect the MicroUSB cable to your Archos device and connect it to your computer.
Power up your Archos tablet and step into the Device Manager on your PC.
Is there an unknown device in the list?

If yes, go on:
Included in the package you'll find windows driver.
Select the unknown device and install this driver manually.

Tell me what's happening?

Regards,

scholbert

The Following User Says Thank You to scholbert For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes