yashsingh1/xdaforums huggingface dataset:
[Gen8 General] scholbert:
No need to hurry, take your time... this is fun stuff :D

I'll have a look today... find something like a flag would be nice indeed, but i'm not sure if there's anything else than error messages comming out on 1st stage.

AFAIK "loader" has no console mode.

This is different in avboot though.

Anyway, if i won't succeed with stock binaries, it would be worth a try with x-load & u-boot.

Should be no big deal to tweak some code from beagleboard-XM and get it to work for the Gen8.

There's no need for a full board setup, if we need it just for kernel startup.

You're a good programmer aren't you?

Some structures of assembler code are bit strange though... it's low level :p

EDIT:

It's bit clearer already...

1st stage loader seems to check the disk identifier before granting access to the partition structure.

It has to be set to 0x00000000 (same as internal eMMC) to register the block device correctly.

This value could also be changed in a structure field... inside loader.

No time for testing now, but i will report my results.

Have fun!

scholbert
[Gen8 General] letama:
Oh, you're right, loader is not that chatty.

Well, good, hum, I don't know :). I did some assembly on z80, 8086, but arm is confusing me a bit. I'm getting there, but it's still not as fluent as I'd like.

Nice Job!
[Gen8 General] scholbert:
Thanks!

Just gave it a try. Aaargh... still the same message. Would have been to simple.

Had to digg little deeper i guess :o

Maybe loader itself does not support FAT boot method (but should accept FAT filesystem for avboot, params, etc.)

... RAW boot method is more tweaky, so i'd like to avoid that.

Lets see what's next...

Regards,

scholbert
[Gen8 General] FrEcP:
Hi scholbert,

recenty i tried to figure out why my archos 101 drains the battery so hard (12h = 50%).

After doing some tests I remembered the powerlight to be always on.

In former times I ignored it and thought it's affected by some service/apps keeping the device awake.

After downgrading and doing the same tests with a fresh FW the problem still wasn't gone. Power light remains on all the time no matter what I do.

After some googeling I found out that several poeple have this problem and it relates the the dead usb-host problem.

Thanks to your thread I saw that it's indeed the same chip being responsible for usb & powermanagement (how ever some engineer came to that brilliant idea;) )

To figure out how the failure can be affected I had a short look into the datasheet of the TPS65921 (thanks for the great collection btw). Since I didn't find anything like an eeprom,.... here are my questions:

1. does the chip have an own FW?

2. or is it just controlled by I2C? Sry I don't know much about this - maybe stupid question!??!

3. Can u imagine how the failure can be affected?

And the point wich confuses me most...

4. if this device has no eeprom and no internal FW why those chips stoped working for MANY people, it seems NOT to be affected by the archos firmware "directly" as a downgrade doesnt help. Why archos on the other side was able to recover it partialy in the latest FW.

5. Could it be an hardware failure still? Or do you think its software related?

6. Can it be unsoldered and exchanged (even its a 120pin package I remeber something about ironing ;) ) ? Or does it have to be programmed / initialised before?

Hope u can bring a bit light into this - datasheets still confuse me ;)

Edit2:

Just found the earlier post about that again #22, didn't knew what u were talking about that day apparently ;) Anwayway could ugive me some advices on how to check what could be broken?

regards

FrEcP

Btw: since I just downgraded to 2.0.54 - I noticed the light sensor is working quite well - even it's a bit delayed - while adding the option to UD 1.6 didn't work for me -> the option showed up but it didn't work propper

Edit: You could add the dimensions and the mA to the Battery informations - if u got them - wans't it 3200mA?
[Gen8 General] scholbert:
Hey FrEcP,

first of all thanks for your post.

Though i'm little limited in time (like always ;)) i'll try to give some short statements.

O.k. understand, though battery drain in general seems to be very mystic on our mobile devices. People often forget the complexity of these gadgets and that thousands of register sets and logic parts (hardware) have to interact correctly to make everything work properly.

But normally it's logic relationship and no voodoo rhythm :p

So let's see if we could find out something.

Nice research so far!

These chips where born to build up cost effective and small boards.

They simply put in everything mostly needed on embedded platforms.

O.K. to the questions...

AFAIK no!

The chip is something like a very complex state machine.

There's at least an internal EEPROM to save some setup values

See first answer, as the device got no firmware most things are done by I2C.

In fact the there's something like autonomous control logic which is set up by external pins and settings in the internal EEPROM.

No, got no idea at the moment.

This is the part further research should be spend

Could be both... it's guessing at the moment.

To swap this chip might be a pretty difficult task.

It could be done, but only with some professional tools... perhaps McGyver could do it with a hair dryer :D

I don't think it needs to be pre-programmed.

Yeah, datasheets are sometimes very confusing...

I'll have a look around,

maybe someone may contact the beagleboard forum, if someone ever realized problems with dying USB (related to TPS65950, which is pretty much the same chip... the TPS65921 has no audio codec)

I would change my comment on that a little, because we found out that it's not power related. Writing those lines i assumed this could be the reason.

Someone might check the changes Archos did to the firmware, maybe htis points us in the right direction.

Nice information!!

The sensor did not work in UD 1.6. for me neither.

Yupp might do that next time when i open up my case :p

Cheers,

scholbert
[Gen8 General] FrEcP:
Same here im facing my exams ;)

as I expected it - thanks for the clearance

Hmm seems there are McGyvers out there ;)

But i don't own any of those nice hot-air-guns atm :( even I tought about getting one several times yet ;)

Nice hint - see what i found here in 2min... im about reading it...

Did they release the source meanwhile? some days ago I read that they are still missing atm. Anyway as i know nothing about android sourcecode and compiling,... yet the comes a lot of work to me as it seems ;D

next reseach topic ;) to be done... AFTER
[Gen8 General] divx118:
I know it must be something in the kernel voltage settings, driver...., because when booting original firmware with the openaos kernel USB host still doesn't work.

I also think it is more of a workaround then a real fix.

Sources are still not released. I already poked them a bit, but there answer was "One day". It could be that it is proprietary issue or it is a really ugly fix.

See if I can find some more info at beagleboard.

On a side note: I once had problems with the usb host ports on my notebook. They only wanted to work on USB 1.1 speed on linux. On windows it was a real pain to get them at least to work. Then I did a really simple thing, removed the power cord and removed the battery placed them back and the problem was gone. Ports worked at normal speed on windows and linux ever since. I wonder if anyone tried this with his A101 and a broken usb host.

divx118
[Gen8 General] letama:
Well, they somehow blocked all kernel source releases, we had 3 firmware upgrades for gen9, few for gen8 and completely unreleased kernel for it2 in froyo and honeycomb.

Hopefully they will go back to good habits soon, I'd be very interested to see 2.6.35 kernel source for gen8v2 and of course 3.0.
[Gen8 General] letama:
Hi Scholbert,

So, I tried for few hours and I gave up. I don't know if this is because of bad material or not skilled enough, but no way to solder the wires on the serial converter, too small and I probably killed it trying to.

Oh well, I tried... Thanks for your help anyway!

Cheers,

LeTama
[Gen8 General] FrEcP:
Home you will find something usefull.

The tread I found was from 2009/2010 still not sure if the board revision they had was the same chip...

Anyway they also played around with several parameters and voltage setting wich partialy fixed the porblem.

Just de- and resoldered the bat+ for testing but -> no changes

Maby I had the time in between too short (maby the capacitives have to run out of energy) before resoldering.. not sure - maby I test again tomorrow.

Some new thing I noticed:

When powering the device the 1st time usb works - untill u power it off with no device attached (what we knew already)

But somehow it seems to be the same with standby - except:

boot up -> turn off -> green light turns off after 3s.... (device seems to be in sleep)

boot up -> (usb device attached) -> power off button -> screen turns off but green light stays on + usb also still seems to get power (light at usb stick on) -> turn on -> (remove usb stick) -> turn off -> green light goes off -> turn on -> turn off -> green light stays on

So it seems to be the same problem as with usb indeed, that the sleep + the usb port just work till it's powered off the 1st time.

While an attached usb device seem to keep it awake but also saves it from failure.

Btw anyone of u knows what this command does? If it exists ;)

ro.board.USB_HOST_SUSPEND

Found it in the usb host failure thread - but JUST there

At http://elinux.org/BeagleBoard the common problems are listed - they had one EHCI problem (what I found yesterday) + some voltage drop failure - check it out (just search for host on the side)
[Gen8 General] divx118:
ro.board.USB_HOST_SUSPEND is a prop like many used in java code, probably to detect if it is suspended. You can set props on the commandline. By typing "setprop ro.board.USB_HOST_SUSPEND <state>".

If you type "getprop" you can see all the props that are set in the android environment.

I don't think however it has something todo which could solve the usb host problem.

I already read through the messages. However I didn't notice anything that would fix the host problem for us, the problem seems also a bit different then ours. That doesn't mean it isn't related. Tomorrow I have some more time and see if I maybe missed something.

Best thing that could happen is that archos pushed there "fix" to the git. Then I just need to update the openaos kernel and I can have USB host also on Gingerbread. Normally they are very quick with keeping the gpl up to date atleast for gen8. Everything is pushed only this last firmware update not. Maybe they need approval from TI or something...

divx118
[Gen8 General] FrEcP:
Well I fear since this might just be a workaround they have atm - since it still fails after 1st power off - it's the quickanddirty version... wich might affect the hold back of the source.

Well lets hope for the latest patch soon so we can analyse...

Anyway even if we got this - we still need a propper fix for getting it work all the time. As my 101 atm is out of battery each 24h (without usage)... wich is quite annoying and kills it's portability 100%
[Gen8 General] scholbert:
Hi guys!

Yeah that's the McGyver method... also made it this way, but you need lucky hands ;)

Haven't found the time to read it all... i keep my eyes open though.

I think we'll have to be little patient for the sources (the team is working hard for ICS release, i guess).

Archos is bounded to the GPL and they will release it sooner or later.

If you like me to do it for you, send me PM.

We might find a way to get the console work for you...

You're always welcome :D

@divx118: Thanks for your comments on the prop settings.

Regards,

scholbert
[Gen8 General] scholbert:
Progress on external boot mechanism...

Hi,

some short report again...:p

As already stated my A101IT device already boots from external MicroSD.

To make it work it is required to tweak the hardware:

- change boot mode to external

- pull up enable pin on LDO permanently

To make it short...

by using the more simple FAT boot method the device stucks in loader (1st stage) :( .

Background:

The 1st stage loader seems to have problems to identify the structure of the card correctly.

By looking at the disassembled loader code i found out that there,

are some checks which are related to the structure of the first blocks on the card.

As i'm not the ARM assembler guru, it's little hard to understand every step and to apply the required hacks.

Another problem is that some things are not to be found in the disassembly on the first sight

(e.g. stack pointers, RAM based variables).

What i know already is:

- The internal ROM loader of OMAP may boot form SD card using FAT or RAW boot mode

- The internal eMMC on A101IT is using raw boot method with special structure in sector 0.

- There is FAT filesystem support in loader and avboot as well

So my next steps will be:

- Prepare the card for RAW boot method (TOC table and loader in first sectors)

- use FAT instead of RAWFS and place avboot & stuff in this partition

In the end this will be pretty close to the internal structure of the eMMC used by default on the device.

I know that these experiments are not of much practical use for most of you

and it seems only a few might do the tricky soldering on the mainboard.

Anyway this is fun for me and maybe there's some interest by the techies :D

Cheers,

scholbert
[Gen8 General] alex@debi:
Hi, scholbert

Didn't you notice if wifi chip in 101 is by LSR or Jorjin? It seems like there exist two slightly different chips there: http://processors.wiki.ti.com/index...eless_Connectivity#Module_related_Information

Thanks!
[Gen8 General] scholbert:
Hi alex@debi!

The pages refers to ready to use embedded modules based on the Ti chipset. These modules were integrated in the desing of the evaluation boards.

AFAIK, Archos soldered the chipset directly to the mainboard.

Maybe they used one of these modules as reference...

In fact it's simply a one chip solution with a HF frontend.

Though it's not completely verified, i think the A101IT uses WL1271.

What are your intentions?

Regards,

scholbert
[Gen8 General] scholbert:
... so what?

Hi,

i made some further experiments, to handle the external boot

Quoting myself:

I followed this path, the result is still the same.

I tried it with two different cards, loader still stucks with the message:

block 'mmcblk0p1' not registered
Mount failed
loading avboot failed

Today i made a final attempt:

- built up raw image from one of my dumps

- integrated patched loader and avboot into the file structure

- made a raw write to my card

As a result the card showed exactely the same partition layout.

The internal structure of the first blocks including rawfs all the same.

To make it short this is barely a clone from the mmcblk0p1 content of the internal memory.

Unfortunately the routine which mounts the partition still responds:

block 'mmcblk0p1' not registered

This is weird :confused:

I even found the assembler lines in loader and tried to understand what is happening.

Apart from having difficulties to really understand what's done, i'm having issues with unknown stack pointers and undefined variables involved.

So in fact i got no clue what is wrong at this point.

If someone would be willing to help me digging in the disassembly, please tell me.

Maybe the scratchram inside omap has to be cleaned up :confused:

I'm at a point to say it makes no sense to do further hardcore assembly digging and it might be better to write some bootcode form scratch.

As i stated before work could begin with code for the Beagleboard-XM and maybe this might lead to an open bootloader for general purpose.

Sticking and proprietary bootcode in 1st stage sucks :cool:

Have fun!

scholbert
[Gen8 General] letama:
Hi Scholbert,

I took a brief look, it seems that the code location that displays this message is really a mount command. Rough guess from the message label would be that partition table has not been read properly previously and therefore partition devices are not present. I'll try to locate where the partition is read to see if I can figure what it's done there.

Did you build your sd image from a mmcblk0 dump, or only the rawfs mmcblk0p1 partition ?

I'd try to write a dump of mmcblk0 as-is if this is not what you did already.
[Gen8 General] scholbert:
Hi letama!

Thanks for helping out and looking into the code.

The partition table is the same as internal.

Perhaps this was little missleading... structure eMMC and my MicroSD are the same now (minor tweaks in the code itself) form the beginning (sector 0).

Yeah, sure i did that already and of course i dumped from the beginning... see comments above. I'm starting to dream of hex and assembly :D

Here's my guess:

I found something like a setup field in the loader code.

I tweaked the mmc offset value in this area, to init mmc1 first (at least i guess so :rolleyes:)

By integrating such area you might configure the boot code after compiling for slightly different board setup, without re-compiling.

I've seen similar practice in other bootcodes before.

Maybe there's some specific area for the card type or boot media (CID of MicroSD and eMMC differs) or something else checks partition type to not be valid...

I assume that the slot is successfully initialized, because there i found some other debug messages reporting if something went wrong at this early stage.

The best would be to find something like a debug flag to make the loader more verbose.

Whatever, i'll have to go on with my business... but if you find something don't hesitate to tell me.

I guess i will prepare some x-loader code sooner or later ;)

Best regards,

scholbert
[Gen8 General] alex@debi:
Hi! Nothing special actually... I've just got curious about that original tiwlan.ini file (i.e. that of Android image) sets Ref Clock value option to 4 (i.e. like Jorjin), not to 2 (i.e. LSR). Anyway, I tried both options, but didn't notice any difference...
[Gen8 General] vitalif:
Hi scholbert, maybe the use mmc0 is just hardcoded into bootloader ? :) Can you show me what area in the bootloader you are talking about (give idb)?
[Gen8 General] scholbert:
Hey vitalif!

Mmmh maybe, but i don't think so. There are many routines handling mmc and everytime i found both base addresses (mmc1 and mmc2 register offset).

The only section is the mentioned area (in particular offset 0xbc78 in loader) where i changed the register offset value to point at mmc1 registers.

Please se the attachement... by comparing loader_org.bin and loader_mmc1_nosec_signed.bin you easily find the area i was talking about.

Concerning idb file:

Mine is quite huge now, because i put loader, avboot and some registers and stuff into one project file.

Basically this work is all based upon the idb you once gave me :D

You might find the related sections easily by searching for mmc register offset values (0x480b4000, 0x4809c000).

Please see the attachment as well. I enhanced some useful scripts (initially started by xvilka) to setup register space and offsets for omap.

This way you got pretty good idea about some parts of code.

Of course you did a great job with the initial disassembly!!!

Thanks for helping out ;)

Best regards,

scholbert
[Gen8 General] letama:
So you patched both loader and avboot this way ? I saw that avboot has exactly the same error message behaving the same way as in loader. If you only patched loader, you could be in avboot already and message could come from it ?

And basically, it changes device numbering right, meaning that mmc0blkp1 is still the valid device name, right ?

As far as I remember, mmc init differs for mmc1/2, doing only base is enough ?

I guess you tried patching the mount command with mmc1blkp1 (offset aa51) before trying this, it's a no go ?
[Gen8 General] scholbert:
Hey letama!

Yes i patched both 1st and 2nd stage... but i think it stuck in loader, because the message ends with "loading avboot failed".

If loading avboot failed, how could it execute avboot already :confused:

Makes no sense to me.

Yeah, by changing to initiate mmc1 first, the numbering should always start at mmcblk0p1 for the first partition, if registering the device is ok.

Bootloader than passes the numbering to the kernel at a later point.

Yes i think it would be enough, but maybe it isn't.

Concerning the differences:

While all mmc interfaces on OMAP start in 4bit data mode after reset, mmc2 is additonally checked for having 8bit data lines attached (in the case of using 8bit data line eMMC), while mmc1 is always initated as 4bit data line interface.

At least that's what i read form the code :rolleyes:

EDIT:

As a reference x-loader intializes the corresponding interfaces by reading the boot mode register.

It then uses this interface and 2nd loader refers to mmcblk0 (e.g. in u-boot).

No i did not, because i think the numbering should not change this way.

See my comments above.

Maybe i try to change some debugging message, this way i'll find out where it really stucks :cool:

Cheers,

scholbert
[Gen8 General] letama:
Hi Scholbert,

Ah, right! Forgot that you had this message, so yes, probably stuck on first loader.

Yes, that's what I was remembering...

:) ok.

Well I would have tried it first, after all, if things are bit hard-coded in Archos bootloaders, it could be that simple...

I should start looking at x-loader and u-boot, I'm sure it's good for my education :) And maybe buy a panda or beagle board someday.
[Gen8 General] vitalif:
scholbert, thank you for information, i'm now trying to utilize OMAP Software Booting Configuration (26.4.4.4 in the manual) to try USB boot without any soldering :) although it's not convenient to try without being able to see output from UART :(

I made a kernel module which sets boot configuration based on things written to a procfs entry and immediately calls software reset.

Software boot configuration is written to OMAP scratchpad memory which is not lost after soft reset, and OMAP processor prefers it to hardware sys_boot configuration.

So you can set any boot device order without hardware modifications, all you need is:

insmod omap_softreboot.ko
echo usb,uart,mmc1,mmc2 > /proc/omap_softreboot

I'm attaching module source and .ko built for 2.1.04 kernel.

Setting boot configuration definitely works on my A101 - for example, it hangs if there is only one 'usb' device in boot sequence (until power button is pressed for 10sec), and it still boots successfully if you specify 'mmc2'.

But USB peripheral booting doesn't work - the OMAP device doesn't appear on the bus (I'm using MicroUSB->USB cable). I suspect this is because some USB chip is left in mode not suitable for such boot...

So I have a question - what's the exact USB hardware configuration of Archos?

OMAP3630 has one USB port

There is USB touchscreen and OMAP always sees it, no matter is the rest of USB in host or slave mode. But if there is just one USB port and it's connected directly to MicroUSB, how can OMAP see the touchscreen?

There is TPS65921 (if I understand correctly it has a TWL4030 inside) and it has USB host functionality

OMAP manual says that its HSUSB system is derived from musb_hdrc, is multimode and can be in ULPI, host, or slave mode. And the musb_hdrc driver is used in Android... So is it switching OMAP usb modes? But if they are switched, how can it still see the touchscreen?

So, OMAP USB is always in host mode, it has some hub attached to it, touchscreen and TPS65921 are connected to the hub, and we are switching the host/slave modes of TPS?

UPD All this is probably incorrect as section A.16 of OMAP manual says there are 2 controllers on OMAP, EHCI + OHCI. So one of them is probably connected directly to MicroUSB and second one is connected through TPS65921... But why USB booting doesn't work, then?

+ Can you also test my module? (if you still are on 2.1.04)