A101it mainboard hacking and chipset information

Search This thread

grim-a101

Senior Member
Mar 19, 2012
55
7
Well, glad to know that the warranty is still valid even if SDE was installed.

For what I remember, on the download page of the SDE on archos website, it says something like the device is watermarked after the SDE installation (no matter what you do, even reinstalling the device) so that they will know you've installed it.

Of course, if you take it appart (with or without soldering anything) there is no questionning about the warranty at this point
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
one step further, but far from beyond...

Hey,

thanks for the feedback so far... :rolleyes:
I'm fiddling with the u-boot setup and it seems i'll have to sort out all these offset addresses and get some understanding how things should be arranged to make it work.
I created some suitable kernel images but unfortunately the kernel seems not to start up or the message is not passed to the serial console.
Here's where i stuck at the moment:
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.12 (Mar 21 2012 - 18:19:53)

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

3148308 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-2.6.35.7
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3148244 Bytes = 3 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using existing atags at 0x80000100
There's nothing afterwards... must be something with the load address or something... or console output :confused:

Whatever, this was just a short try... without some more background knowledge on the setup in general, i'll stick with wonderful u-boot and the serial console :p

If someone knows more about using ATAG (especially ARCHOS_TAGs) and u-boot setup, you're welcome!
I guess there'll be something useful soon...

Have a nice day!

scholbert
 
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
821
Hey grim-a101!
I wish I could help you, but this is way out of my knowledge :(
At least one person following my posts... ;)
Just kidding... it's all for fun.

So every day a little step further...
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.12 (Mar 21 2012 - 18:19:53)

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

2014100 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-2.6.29-recovery
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2014036 Bytes = 1.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using existing atags at 0x80000100
Uncompressing Linux.............................................................
........................................................................ done, b
ooting the kernel.

Still no message after uncompressing... i guess i'll have to check the power domains in u-boot. Maybe there's some essential part missing.

Another thing maybe, that PLL setup get's f**ked up on early init of kernel.
We'll see :p

EDIT: Mmmh just another idea...
You know that Archos decided to use this bloody extrabaud setting in kernel cmdline.
I really don't like this and decided to use standard rate for x-loader, u-boot and kernel instead.
So maybe with defualt kernel the u-boot cmdline is ignored and kernel default is always used.
Will have to check the kernel setup as well... anyway, normally there should be even some rubbish data on the serial line then...
I'll do some code digging tonight.

Cheers,

scholbert
 
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
821
Hey CalcProgrammer1!
Look at the CONFIG_CMDLINEX options, the default cmdline is ignored on stock Archos kernel. See archos-fixup.c.
O.k. i knew about this file... wasn't truly aware though :rolleyes:
So thanks for the hint!!

If i understand it correctly kernel "looks" only at the machine number and sets the cmdline accordingly.
So bootloader cmdline gets overriden... am i right?

This would conclude that if i boot stock environment the built in cmdline residing in avboot is not used as well...

I compile new kernel, when i'm at home!

Regards,

scholbert
 

CalcProgrammer1

Senior Member
Oct 8, 2007
650
756
Kansas City
Correct, archos-fixup.c sets the command line to one of the CONFIG_CMDLINEX cmdlines based on machine type (using machine_is_xxx() functions).

CONFIG_CMDLINE0 - A43, A70s
CONFIG_CMDLINE1 - A70h
CONFIG_CMDLINE2 - A28
CONFIG_CMDLINE3 - A35
CONFIG_CMDLINE4 - A101, A70s2
CONFIG_CMDLINE5 - A32, A32sd, A35dm, A35de
CONFIG_CMDLINE6 - A70h2

These appear to completely override the default CONFIG_CMDLINE as well as any cmdline passed in from a bootloader. I've tried setting CONFIG_CMDLINE_FORCE off so that I could set cmdline with a bootloader (kexecboot/kboot) but it doesn't seem to do anything.

You could get rid of this file and the custom cmdline's if you wanted to pass boot arguments with the bootloader, the 2.6.37 kernel I'm working on doesn't use this custom cmdline system.
 

letama

Senior Member
Feb 13, 2008
1,689
2,324
At least one person following my posts... ;)
Just kidding... it's all for fun.

Tss, tss, tss, I'm reading! ;)

Using existing atags at 0x80000100
Uncompressing Linux.............................................................
........................................................................ done, b
ooting the kernel.

Wow, you're very close!
 

alephzain

Senior Member
Sep 29, 2010
117
2,822
These appear to completely override the default CONFIG_CMDLINE as well as any cmdline passed in from a bootloader. I've tried setting CONFIG_CMDLINE_FORCE off so that I could set cmdline with a bootloader (kexecboot/kboot) but it doesn't seem to do anything.

You could get rid of this file and the custom cmdline's if you wanted to pass boot arguments with the bootloader, the 2.6.37 kernel I'm working on doesn't use this custom cmdline system.

To pass command line, did a return to avoid cmdline var to be overwritten.

Code:
diff --git a/arch/arm/mach-omap2/archos-fixup.c b/arch/arm/mach-omap2/archos-fixup.c
index 0df71d6..78ac3ea 100644
--- a/arch/arm/mach-omap2/archos-fixup.c
+++ b/arch/arm/mach-omap2/archos-fixup.c
@@ -39,7 +39,7 @@ void __init fixup_archos(struct machine_desc *desc,
        } else if (machine_is_archos_a35()) {
                *cmdline = command_line[3];
        } else if (machine_is_archos_a101it() || machine_is_archos_a70s2()) {
-               *cmdline = command_line[4];
+               return; //*cmdline = command_line[4];
        } else if (machine_is_archos_a32() || machine_is_archos_a32sd() || machine_is_archos_a35de()) {
                *cmdline = command_line[5];
        } else if (machine_is_archos_a70h2()) {
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
Hey folks,

thanks for your replies.
In the meatime i fiddled around with my u-boot setup and used the u-boot console for some debugging of certain memory areas.
I'm not sure, but apart form kernel cmdline issue, there might be something wrong with the ATAGs passing to the kernel, still investigating.
If things are not placed correctly, e.g. machine_type booting might fail at this point.

I'm just compiling a new kernel with low-level debug support and changed the cmdline to match baudrate as well.
If the image is ready, i will try to follow this:
http://processors.wiki.ti.com/index.php/FAQ_for_DaVinci_Linux#No_kernel_output_after_U-Boot_load

EDIT:
Tadaaah.... :p
Got it, see this:
Code:
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
Using existing atags at 0x80000100
Uncompressing Linux.............................................................
................................................................................
..................................................... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00000003).

Available machine support:

ID (hex)        NAME
0000139c        Archos A28 board
0000139d        Archos A32 board
000013a4        Archos A32SD board
000013a5        Archos A35 board
000013a6        Archos A35DM board
000013a7        Archos A35DE board
0000139e        Archos A43 board
000013a0        Archos A70S board
000013a1        Archos A70H board
000013ac        Archos A70S2 board
000013ad        Archos A70H2 board
000013a3        Archos A101IT board

Please check your kernel config and/or bootloader.

Should be solvable i guess, but it's already late today and i'm off for the weekend.
Maybe i digg in u-boot code for a while...
EDIT2: Enabled u-boot debugging as well...

Code:
U-Boot 2011.12 (Mar 23 2012 - 00:29:33)

U-Boot code: 80008000 -> 800393AC  BSS: -> 8006B2E8
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
Archos 101IT Gen8 + LPDDR/MMC
I2C:   ready
monitor len: 000632E8
ramsize: 10000000
TLB table at: 8fff0000
Top of RAM usable for U-Boot at: 8fff0000
Reserving 396k for U-Boot at: 8ff8c000
Reserving 1280k for malloc() at: 8fe4c000
Reserving 24 Bytes for Board Info at: 8fe4bfe8
Reserving 120 Bytes for Global Data at: 8fe4bf70
New Stack Pointer is: 8fe4bf60
RAM Configuration:
Bank #0: 80000000 256 MiB
relocation Offset is: 0ff84000
dram_bank_mmu_setup: bank: 0
monitor flash len: 00035E14
Now running in RAM - U-Boot at: 8ff8c000
MMC:   OMAP SD/MMC: 0
Using default environment

Destroy Hash Table: 8ffbddcc table = (null)
Create Hash Table: N=150
INSERT: table 8ffbddcc, filled 1/151 rv 8fe4c5e4 ==> name="bootcmd" value="if mmc rescan 0; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else; fi; fi; else; fi"
INSERT: table 8ffbddcc, filled 2/151 rv 8fe4c56c ==> name="bootdelay" value="2"
INSERT: table 8ffbddcc, filled 3/151 rv 8fe4c674 ==> name="baudrate" value="115200"
INSERT: table 8ffbddcc, filled 4/151 rv 8fe4c6c8 ==> name="loadaddr" value="0x82000000"
INSERT: table 8ffbddcc, filled 5/151 rv 8fe4c998 ==> name="console" value="ttyS2"
INSERT: table 8ffbddcc, filled 6/151 rv 8fe4c374 ==> name="video_mode" value="debug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0"
INSERT: table 8ffbddcc, filled 7/151 rv 8fe4c698 ==> name="mmcroot" value="/dev/mmcblk0p2 rw"
INSERT: table 8ffbddcc, filled 8/151 rv 8fe4c4d0 ==> name="mmcrootfstype" value="ext3 rootwait"
INSERT: table 8ffbddcc, filled 9/151 rv 8fe4c548 ==> name="mmcargs" value="setenv bootargs console=${console},115200n8 ${video_mode} root=${mmcroot} rootfstype=${mmcrootfstype} ${extra_options}"
INSERT: table 8ffbddcc, filled 10/151 rv 8fe4c7d0 ==> name="loadbootscript" value="fatload mmc 0 ${loadaddr} boot.scr"
INSERT: table 8ffbddcc, filled 11/151 rv 8fe4c62c ==> name="bootscript" value="echo Running bootscript from mmc ...; source ${loadaddr}"
INSERT: table 8ffbddcc, filled 12/151 rv 8fe4c3e0 ==> name="loaduimage" value="fatload mmc 0 ${loadaddr} uImage"
INSERT: table 8ffbddcc, filled 13/151 rv 8fe4c680 ==> name="mmcboot" value="echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}"
INSERT: free(data = 8fe4c008)
INSERT: done
In:    serial
Out:   serial
Err:   serial
Die ID #144800029ff800000160a4bb18027009
### main_loop entered: bootdelay=2
Nothing special here, but now it gets clear where code exactly lives.

Next the kernel placement:
Code:
...
2987000 bytes read
Booting from mmc ...
## Current stack ends at 0x8fe4baf8 *  kernel: cmdline image address = 0x82000000
## 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
   kernel data at 0x82000040, len = 0x002d93b8 (2986936)
## No init Ramdisk
   ramdisk start = 0x00000000, ramdisk end = 0x00000000
## No Flattened Device Tree
   Loading Kernel Image ... OK
OK
   kernel loaded at 0x80008000, end = 0x802e13b8
## Transferring control to Linux (at address 80008000) ...
Looks fine as well.

Now at u-boot console i typed bdinfo:
Code:
A101IT # bdinfo
arch_number = 0x000013A3
boot_params = 0x80000100
DRAM bank   = 0x00000000
-> start    = 0x80000000
-> size     = 0x10000000
baudrate    = 115200 bps
TLB addr    = 0x8FFF0000
relocaddr   = 0x8FF8C000
reloc off   = 0x0FF84000
irq_sp      = 0x8FE4BF70
sp start    = 0x8FE4BF60
FB base     = 0x00000000
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 :confused:

No need to hurry i guess, but i'd like to find a solution and i really enjoy your comments.
Thanks!!!

See ya,

scholbert
 
Last edited:
  • Like
Reactions: bnborg

alephzain

Senior Member
Sep 29, 2010
117
2,822
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 :confused:

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

Senior Member
Jul 31, 2009
100
33
43
N Ireland
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

Senior Member
Aug 1, 2007
1,347
821
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
 
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
821
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
 
Last edited:
  • Like
Reactions: bnborg and letama

letama

Senior Member
Feb 13, 2008
1,689
2,324
Hi Scholbert,

Nice progress!

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.
 

scholbert

Senior Member
Aug 1, 2007
1,347
821
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
 
Last edited:

scholbert

Senior Member
Aug 1, 2007
1,347
821
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 :rolleyes:

Regards,

scholbert
 
Last edited:
  • Like
Reactions: k1nk33

MarkY972

Member
Apr 23, 2012
24
2
Tel Aviv
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

Senior Member
Aug 1, 2007
1,347
821
Hey Marky!
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://xdaforums.com/showthread.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
 
  • Like
Reactions: MarkY972

scholbert

Senior Member
Aug 1, 2007
1,347
821
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://xdaforums.com/showpost.php?p=16274855&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
 
Last edited:
  • Like
Reactions: MarkY972

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