yashsingh1/xdaforums huggingface dataset:
[Gen8 General] scholbert:
Hey vitalif!

... and without suitable bootloader ;)

Cool!!!

Nice work, will have a closer look at the sources.

Yupp i know. The device starts up normally, if there's no bootcode on mmc2. Maybe you realized that it takes little longer... OTP ROM loader is waiting for devices untill a timeout is reached.

You know what this mode is about?

Basically it should work... my device connected successfully in this mode.

The OMAP processor in USB peripheral boot mode tries to connect to host via MicroUSB connection on the Archos (USB0).

You'll need Flash tool from Ti and special driver installed to use it.

This driver could be found in the Flash tool package as well.

If you need more information, tell me!!

You mix things up.... please let me explain...

OMAP3630 got several USB interfaces working in different modes.

On A101IT it behaves like this:

1xUSB OTG interface (USB0 on MicroUSB, working for peripheral boot using Flash tool)

1xUSB host in serial mode (connected to TUSB2551A, used for touchscreen controller, OHCI only)

1xUSB host port in ULPI mode (connected to TPS65921, external Typ A connector, EHCI/OHCI)

If you need more information on that, please tell me..

Maybe i should make a blockdiagram of the A101IT mainboard someday :D

Maybe i find some time to do so. I'm not on 2.1.04, using 1.6 UD instead.

I guess i'll also try to own compile.

Impressive work, thanks a lot!!!

Regards,

scholbert
[Gen8 General] vitalif:
There is no need for the driver under Linux... Protocol is very simple and there is tool called "pusb" which does the work in omap-u-boot-utils. But before it could work, the TI USB device with VID:PID = 0451:D009 should appear on the bus... Basically, any device should appear on the bus :D

And it doesn't in my case...

The software boot config is definitely working - the device hangs if you specify just "usb", and the boot process takes longer by ~3sec when you specify "usb,mmc2". (as you know, mmc2 is the internal mmc interface of OMAP, mmc1 is the external SD card)

So there is some problem with USB boot, and I wonder what's this problem...

Most of module files are copied from the kernel source (arch/arm/mach-omap2/), sram34xx.S is also a copy with parts removed, and only the main softreboot.c is really mine. And it probably needs to be modified for later kernels...
[Gen8 General] vitalif:
I've found the problem: OMAP refuses to boot just from 'usb' for some reason... But it boots if you specify 'uart,usb' :) at least the ASIC ID is sent and the image downloads... But as you said, there is no proper bootloader by now, so it doesn't really BOOT :D

With the kernel module, things are also simpler than it seemed - here is the new, smaller version, and it will compile on your kernel more easily :)

Btw, what's the kernel version on UD 1.6? I can build a module for it also.
[Gen8 General] scholbert:
Hey vitalif!

Sure, i didn't knew that you know it all... sorry ;)

So pusb is a nice tool, to play around with.

Flash tool gives more opportunities though.

It uses some scripting to set up hardware registers and got loaders included to write code into SDRAM.

Very nice work.

Aaah i see... nice that you pointed this out!!

For bootloader, we should really think about migrating code from beagleboard-XM. Unfortunately there's no time for that right now...

maybe you might have a look ;)

It's all the same kernel version (still 2.6.29-omap1), but it had been patched by Sauron with increasing the revision number of the firmware.

Also kernel config slightly changed.

I guess your module should work on UD as well.

Nice hacking :cool:

scholbert
[Gen8 General] scholbert:
further research...

Hey fellas,

some updates at least...

I did not succeed with booting form external MicroSD with my modified stock loader.

Though there'd been some nice hint from alephzain,

who used modifed qemu to boot some Archos images during kexec development.

Here's what he got:

omap3_mmc_command: 41 type=0 rsp=2 arg= blk=0x00000000, fifo=0/0
SD: ACMD41 in a wrong state
omap3_mmc_read: STAT = 00018000
block 'mmcblk0p1' not registered
Mount failed
loading avboot failed

Sounds familiar doesn't it.

Well i did some research on the commands during initializing memory cards and found some interesting stuff as well.

First of all this site is the best to start (already for a few years now).

http://elm-chan.org/docs/mmc/mmc_e.html

Some guys at microcontroller forums also do wicked low level stuff and i stumbled over some interesting discussions.

This is the sequence for both commands.

CMD55 = (0x40 | 0x37), 0x00, 0x00, 0x00, 0x00, 0xff
CMD41 = (0x40 | 0x29), 0x00, 0x00, 0x00, 0x00, 0xff

Anyway i got little tired of disassembling proprietary code in the end and started to look more forward.

So please read my next thread and stay tuned...

Regards,

scholbert
[Gen8 General] scholbert:
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:

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
[Gen8 General] alex@debi:
Hi scholbert!

You mean you flashed a new loader in place of Archos native one? Or the tablet boots completely from some external media (via those UART pins)?
[Gen8 General] scholbert:
Hi alex@debi,

to get a better understanding what had happened in the last weeks, i recommend reading the last posts. It all started by tweaking the boot mode signals... ;)

No, not yet... but if the new bootloader will be finished, bugfixed and tested...

it would be no problem to replace the stock one.

But this is far away yet and not my intention at first sight.

We later might need some kernel patches as well.

Mainly to overide some parameters handed over from stock loader and patch some offsets to match new bootcode... to early to think of it :rolleyes:

Yes, the tablet boots completely from external media (MicroSD).

The internal eMMC is completely skipped. It could be mounted at a later point of course.

Those UART pins are just needed as a console to get some information about the boot process and to print some debug messages during development.

Have fun!

scholbert
[Gen8 General] letama:
WOW! Nice job!

What was the problem then ?

On my side, nothing... I found some pre-made cables that should work as-is here, seems perfect for me.

If you manage to boot a kernel, let me know and I order right away :)
[Gen8 General] scholbert:
Thanks! Yeah maybe this is the start for AOB... Archos Open Bootloader ;)

What do you mean... the problem with stock loader... i don't know.

See my previous post, i simply was tired to step through undocumented assembler routines.

If you refer to my work on the x-loader, there'd been some problems to get the various PLL's setup correctly. Archos engineers did choose some other setup or whatever.

The values from beagleboard or similar hardware did not match and it was hard to debug at low level.

I ended up in dumping essential register setups, tweak the values to match and make the RAM initializing correctly :cool:

Awesome, these FTDI guys rock. This cable is exactely what you'll need.

Yeah, sure... need some time though.

Just started to evaluate some sources to match best. There are several options.

I guess the best would be to to start hacking with most recent code.

There are some good matching code bases, but some are little outdated.

At least it seems that u-boot code got some clean ups and re-arrangements last year.

As stated the kernel to boot might need some tweaks as well.

E.g. Archos board revision gpio's... still haven't found out how this is parsed from the bootcode in detail. There's something like a memory field which get's interpreted.

There are many more parts that seem to depend on bootcode and hidden partitions.

Let's see...

Best regards,

scholbert
[Gen8 General] letama:
I see.. Yes, I was refering to xloader changes. I may (it's a big "may") play with it with gen9, I was curious about where Archos deviates.

Probably yes, at least for a fully functional kernel.

For what i have to do, not that much, I'd be happy to have it boot up to serial and work my way from there.
[Gen8 General] scholbert:
... 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:

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
[Gen8 General] CalcProgrammer1:
This is awesome, so now gen8's are practically unbrickable if this is enough to boot a kernel. I really want to get a serial console on my A43 but don't want to take it apart under warranty, might buy a used gen8 for hacking around with as they are nice devices to hack. I'd also like a serial terminal for kernel porting (especially since A43 has a painful LCD to work with).
[Gen8 General] grim-a101:
Great work, congrats!

This could be really usefull for unbricking gen8 devices.

If I remerber well, installing the SDE already breaks the warranty isn't it?
[Gen8 General] CalcProgrammer1:
Only if you screw it up by using the SDE. My A43 touch panel broke and I got it replaced under warranty, I uninstalled the SDE and reformatted it before I sent it in, but I'm pretty sure they don't care about SDE unless you somehow brick your device using it or are warrantying it because you deleted Android and don't know how to reinstall it yourself.

Taking it apart voids the warranty no matter what, especially if you go soldering in additional hardware.
[Gen8 General] grim-a101:
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
[Gen8 General] scholbert:
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:

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
[Gen8 General] grim-a101:
I wish I could help you, but this is way out of my knowledge :(
[Gen8 General] scholbert:
Hey grim-a101!

At least one person following my posts... ;)

Just kidding... it's all for fun.

So every day a little step further...

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
[Gen8 General] CalcProgrammer1:
Look at the CONFIG_CMDLINEX options, the default cmdline is ignored on stock Archos kernel. See archos-fixup.c.
[Gen8 General] scholbert:
Hey CalcProgrammer1!

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
[Gen8 General] CalcProgrammer1:
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.
[Gen8 General] letama:
Tss, tss, tss, I'm reading! ;)

Wow, you're very close!
[Gen8 General] alephzain:
To pass command line, did a return to avoid cmdline var to be overwritten.

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()) {
[Gen8 General] alephzain:
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

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 ...
[Gen8 General] wilsey:
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!
[Gen8 General] scholbert:
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):

/*
* 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
[Gen8 General] letama:
Hi Scholbert,

Nice progress!

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.
[Gen8 General] scholbert:
Mmmh, guess you're right, should look like this:

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