yashsingh1/xdaforums huggingface dataset:
[HTC One S] Sneakyghost:
Little Pitfall with dd'ing the 2.21 Radio

Hello Guys,

i just adapted this method (Thank you mate for pointing this out) to the new 2.21 Base Radio and it did not accept it since the HBOOT 1.13 (introduced with RUU 1.78) does not allow for flashing radios with bad signature anymore. Somehow the signature of this new radio is not good for flashing.

I ended up with only wcnss.img and adsp.img flashed and that in return led to the RUU 1.78 failing to install completely. It left me with a semi-brick. I managed to flash back the respective two images of the 1.78 RUU and now i could also reflash the RUU.

But this is a bit dangerous and you should know how to help yourself when trying this.

Please be careful with this.

[UPDATE]

After flashing the 1.78 RUU and running the OTA for 2.21 with SuperCID i got a successful flash but then i noticed that the new radio still did NOT install.

Something weird is going on here. I will try again.

[UPDATE 2]

Second try flashing the OTA 2.21 succeeded from locked, stock 1.78 SuperCID Firmware including the Radio.
[HTC One S] smurfb:
Does Cayniarbs method work with the new firmware aswell?
[HTC One S] v3n3:
Well, I cant write the radio :-/
[HTC One S] dc211:
No Hboot 1.13 & 1.14 can't update the radio.
[HTC One S] Sneakyghost:
Not quite true. Those hboot's can, but not directly. Users with that have to go through a CID change and install as OTA via the stock RUU 1.78.
[HTC One S] dc211:
It actually is true, but may have been unclear. I just want to make it clear because I saw no information about losing the ability to flash a new radio by moving to a newer Hboot before I did. So let this be a warning to others.

If you use a RUU or OTA that updates your rom to 1.78 or higher. You WILL lose the ability to flash radios by any unofficial method at this time. If you have hboot 1.13 or 1.14 you CANNOT flash a new radio using Cayniarbs method or flashing a new radio using TRWP's recovery. You also lose the ability to flash boot.img files in recovery. So you are stuck having to flash boot.img files in fastboot only. This make is much more annoying switching roms because a computer is almost always required.

I suggest that if you currently have an older hboot to avoid updating! Do not use a RUU or update using a OTA!
[HTC One S] roakes:
I have a 1.13 HBOOT and currently using the Modaco ROM, I really want the new radio so would the best process be...

Nandroid Backup

fastboot oem lock

Install RUU which will assumedly wipe my current ROM?

Restore nandroid backup?
[HTC One S] Pheroh:
You'd have to unlock your device again after RUU and yes it does wipe out everything but that's about right.
[HTC One S] teh_pwnrer:
So if I have hboot 1.09 then I CAN flash radios in recovery? cause that's what I did and it says my baseband is 1.06es.50 but still poor signal strength, I went to the hospital and had no connection at all when my friend had 2 bars on his one s stock

Tmo US I live in a big city where I used to constantly have 4g
[HTC One S] ungraphic:
I just bought a used HTC One S4 Ville that's rooted, unlocked, hboot updated to 2.15, S-Off and SuperCID. The ROM on it is CyanogenMod 11s v2. The radio on it appears to have been flash to 1.13.50.05.31. I'm with Wind Mobile in Canada (AWS, same network as T-Mobile). Here's the problem: I'm not getting a consistent signal with my carrier, it rarely picks it up and shortly after (mere seconds) it drops completely and there's no signal at all. However, if I try a different SIM card that's GSM (Fido) it works fine and I get a full 5 bars.

I have a second (older) HTC One S4 Ville that's using an older radio, version 0.17.31501S.10_2. This works completely fine.

Questions:

1) Is it possible to copy the radio from my old One S4 and flash the radio onto the new one?

2) Would going to my carrier and asking for a new SIM card alleviate the problem? I heard something about older ones being faulty/unreliable. Mine is either 2 or 3 years old.
[Galaxy Y GT-S5360 General] xxwhy:
do u do a cwm wipe then flash the rom in or just without clearing any data or cache and straight away flash the zip folder in? pls reply thank you very much
[Galaxy Y GT-S5360 General] Robin h00d:
for gods sake.There are instructions and how to's

Why does everyone keep opening a new thread for each rom?

Please read before posting or just post in the rom's thread
[Galaxy Y GT-S5360 General] kurotsugi:
that rom is not finished...don't install them if you're not a tester or a dev who want to fix the bug. most of the phone funtion isn't work. you can't use it in daily life.
[General Questions and Answers] kgoosie:
Need screenshot guide of enabling USB debugging on a Stratosphere due to the phone being dropped and screen is black but still recognizes touch. New phone coming today. Trying to back it up before activating new one by viewing phone on computer via androidscreencast.
[General Questions and Answers] ruscan.calin:
this is why I was always thinking about.. all phones should have USB debugging activated by default ...

I think no chance to activate usb debugging from PC

better find a custom recovery and flash by fastboot mode
[Gen9, Gen10 General] DarkhShadow:
Maybe you would do some work with OMAP 4460 versions? Most new ones are 4460 now

Sent from my ice cream powered Nexus S
[Gen9, Gen10 General] scholbert:
Yupp i know, but i use to focus on the devices i personally own.

There's no need for me to buy one of these newer ones as i won't spent all my money on the latest stuff :p

Cheers scholbert
[Gen9, Gen10 General] scholbert:
tweaking bootmode... success!!!!!

Hey

just a short update for the geeks out there...

Started to find the bootmode signals... not yet finished, but as you see it's obvious where to search :p

EDIT:

Hoho... got it!!!

See the new attachment.

I successfully tweaked bootmode to send ASIC ID over usb first.

This way it is posssible to get low level access to the platform.

With some additional work we might also recover bricks :rolleyes:

Here's my first log:

» OMAPFlash v4.15 (Aug 12 2011)

» -v
» Entering parameter file:Targets\Projects\archos\usb_sdram.txt at line: 1
» -omap 4
» -t 600
» -p SEVM_MDDR_ELPIDA_4G
» -2
» chip_download SDRAM C:\Projects\OMAPflasher\OMAPFlash\test_data\pattern_1k.bin
» Leaving parameter file:Targets\Projects\archos\usb_sdram.txt
» @Targets\Projects\archos\usb_sdram.txt
» Looking for device (omap usb)
» Please turn on device
» Waiting for device (omap usb)
» Found device (omap usb)
» Requesting ASIC id
» AsicId items 05
» AsicId id 01 05 01 44 30 07 04
» AsicId secure_mode 13 02 01 00
» AsicId public_id 12 15 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
» AsicId root_key_hash 14 21 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
» AsicId checksum 15 09 01 9C 66 9A D9 00 00 00 00
» Searching 2nd for: SEVM_MDDR_ELPIDA_4G 443007 04 GP
» Loading second file Targets\2nd-Downloaders\dnld_startup_omap4_gp_4g.2nd
» Entering parameter file:omapflash2nd.txt at line: 28
» -pheriphalboot_reopen
» Reading board configuration file Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
» Reading definition file .\targets\definitions\definitions_omap4.txt
» -board_config Targets\Configurations\configuration_evm4430es2.0_elpida_4g.txt
» Leaving parameter file:omapflash2nd.txt
» Sending size of second file (0x00007804 bytes)
» Transferring second file to target (0x7804 bytes)
» Closing boot connection
» Found device (omap usb)
» Waiting for 2nd

Unfortunately the 2nd loader does not respond the way it should... :confused:

I found out that there's some trouble caused by the USB cable serving power to the board.

I guess this might be the reason for the interrupt of the transfer (the platform gets a soft reset at this point and does not return properly).

So i'll have to modify the cable for the next step.

Stay tuned!!!

Another thing is serial console... unfortunately no success yet, though i can tell there's something behind these marked testpoints.

I attached some logic and got some data, but nothing readable yet.

I tried with baudrates of 115200 and 1000000 (very common on Archos boards).

Nothing useful :rolleyes:

I don't even know if it is connected to ttyO2 (uart3).

EDIT:

There's some news!!

Please see this post http://xdaforums.com/showpost.php?p=27741653&postcount=22

EDIT2:

Just for your information:

JTAG debug pins had been identified in the meantime.

If you need low level debug features send me PM!

Anyway, i thought it would not harm to put it down here.

Cheers,

scholbert
[Gen9, Gen10 General] Shano56:
Mr scholbert

I love your detailed descriptions and photos! good work!
[Gen9, Gen10 General] cajl:
Great

Buzz in France

http://www.jbmm.fr/2012/05/que-de-chose-dans-un-archos-gen9-8
[Gen9, Gen10 General] mprasa:
The GPS chipset information shows it has a FM interface as well. Does it mean that Archos can be used as a FM radio receiver ? Sorry I am not such an expert in hardware. Is there an app that we can install if it is possible to make this work as a radio runer ?
[Gen9, Gen10 General] DarkhShadow:
I think someone already looked into it and found while it does have one its not connected to anything

Sent from my ice cream powered Nexus S
[Gen9, Gen10 General] scholbert:
To be more precisely... the datasheet is about the NL5500, while on the Archos Gen9 a NL5550 is used.

The only difference is, that NL5550 is GPS only.

No FM in this chipset.

The truth is that WL1271 has FM capabilites, but unfortunately Archos decided to leave that out.

Cajl had contact to one of the developers, telling him that essential parts are not connected (e.g. FM antenna).

So no FM on Gen9 :rolleyes:

Regards,

scholbert
[Gen9, Gen10 General] scholbert:
Sorry to interrupt you...

There's some news:

http://xdaforums.com/showpost.php?p=25919128&postcount=4

Hihi :p

Cheers scholbert
[Gen9, Gen10 General] scholbert:
add the missing mechanic...

Hey folks,

it's so silent here... yeah the summer hits europe :p

Anyway, here's another pic from my temporarily disassembled A80G9.

You know this already from openaos.org:

Vibra is not built into all units, but if yours has a vibra motor you can turn it on by issuing:

echo ro.board.has_vibrator=yes >> /data/local.prop

As they said...

The vibrator is not assembled in my device at least... will search in my toy box for a mating part ;)

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
Not in ICS- ro.board.has_vibrator=no is present in model specific .rc files (which are parsed before .prop files). Unfortunately changing to 'yes' doesn't work. It seems that I've mised something in system permissions or Archos removed haptic feedback from system entirely

Tapatalked from my Archos 101 G9
[Gen9, Gen10 General] scholbert:
Good to know, i'll also try it...

Maybe your device got no vibrator motor as well... or do you mean that the setting for haptic feedback is missing even after changing the .rc file :confused:

I use hacker's keyboard on my other tablet and there's a setup for haptic feedback (though there's also no vibro hardware inside...).

Maybe i'll find something...

Thanks for the comment!

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
My device has vibrator installed (haptic feedback works like a charm on Homeycomb). Changes in .rc files only enabled haptic options in keyboard settings (Thumb Keyboard) but I didn't check files in /system/etc/permissions

Tapatalked from Xperia Arc S
[Gen9, Gen10 General] realismo:
I checked the Honeycomb and yes haptic is working like a charm.

I don't know who cares, but I miss haptic feedback in ICS. Finding a solution could be a very good thing.
[Gen9, Gen10 General] scholbert:
Some insights concerning hardware...

While fiddling around with my experimental device and stepping deeper into the tags file (see this http://xdaforums.com/showthread.php?t=1711864) there's some conclusion to be drawn for the hardware.

First there's a bunch of devices floating around which are equipped with the high performance OMAP4430 and don't make use of it.

I disassembled at least two A80S standard tablets with the high performance OMAP4430 soldered on the mainboard.

Additionally both got a silicon pad at the bottom of the mainboard PCB to dissipate the heat from the CPU.

Both make use of the TPS62361B core voltage regulator, beeing capable to power even the OMAP4460 at 1.5GHz.

So looking at the hardware design there's no reason why these were sold as standard and clocked at 1GHz.

The revisions of A80S could easily run at 1.2GHz.

While stepping through some the tags from other user's devices i also realized that some of the A101S seem to be powered by the TWL6030 only and don't make use of the additional core regulator.

At least the FTAG for the TPS62361B is missing on these devices, which leds me to the conclusion the chip is not soldered on the mainboard.

Could be an older release though...

I guess this is the main reason for instability on the A101S while overclocking.

The CPU might do it, but the core voltage could drop at some point and freeze your tablet.

I thought this would be of interest.

Anyway, stay clean ;)

scholbert
[Gen9, Gen10 General] neur0mans3r:
Locures one

Can we get any additional information regarding the touchscreen controller?

On my G9 80 Turbo (4460 1.5 GHz 1GB) the touch screen can only recognize around 227*227 touch points (more info: http://xdaforums.com/showpost.php?p=27650004&postcount=4 ).

Is this a hardware limitation (low-resolution capacitive matrix), configuration issue or just bad drivers?
[Gen9, Gen10 General] scholbert:
If i find something i'll post it here.

It's all closed behind thick walls :rolleyes:

Yeah, nice information. Not sure about the touchpoints value though.

Not sure about that.

These Cypress chips are not that bad usually, maybe it's the touchscreen glass itself which leds to this restriction.

If you look carefully, you might see this grid on the A80's screen.

I'll try to do some more investigation on this, though i'm not sure if there's anything to find in the open web :p

Regards,

scholbert
[Gen9, Gen10 General] neur0mans3r:
I got the approximate touch resolution by noting how much the XY values change when moving a single finger slowly on the screen in Input Benchmark multi-touch test.

Since the program returns a pixel coordinate you can work out an approximate resolution like this (landscape orientation):

- vertical: 768/3.37335 = 227.667

- horizontal: 1024/4.4978 = 227.6668

This probably means that the touchscreen resolves 256 points horizontally and vertically, but maybe those extra points are not evenly distributed, or are located under the black frame surrounding the screen.

However, sometimes you can get a touch point XY value in between the values you usually get (exactly between the values you usually get), but then the next value is still off by 3.3 or 4.5 pixels. I think this means that the hardware supports at least twice the current resolution, but the driver has aggressive input filtering that reduces touch resolution.

I'll write a test application that shows the raw touch data, and calculates the approximate resolution of the touchscreen.

[UPDATE]

I wrote a simple test and found that the touchscreen resolution is 2048*2048 (G9 80 Turbo 4460).

However when moving the finger along the screen horizontally or vertically you only get touch events for every 9 touch points (the numbers I provided above still stand) for that direction. In the other direction you get the full resolution (if you move the finger almost horizontally, you get poor horizontal resolution and full vertical resolution, but since in this case horizontal resolution is more important this isn't ideal).
[Gen9, Gen10 General] scholbert:
Hey neur0mans3r,

cool stuff!!!

Thanks a lot for contributing your test program.

If it's opensource you might put the sources down as well...

Cheers,

scholbert
[Gen9, Gen10 General] scholbert:
Serial console found... finally!!!

Hey geeks,

what should i say... sometimes things behave little stupid, even or perhaps also because you are used to fiddle around with electronics.

So stupid me, i was there weeks ago already but acted a little blindly and never changed RX and TX pins and tried again with my UART adaptor.

Anyway, here we are...

See the attached pic for the new assigment on the testpoints TP49..52 on the mainboard of the A80S ;)

EDIT:

Here's the assignment:

TP49 -> GND

TP50 -> VIO1.8

TP51 -> UART1_RX

TP52 -> UART1_TX

Connected to a UART2USB converter with 1.8V logic level shifter it all get's clear with a baudrate of 1000000, 8N1.

Here's the log:

loader (c) Archos 2010
OMAP4430 Rev. ES2.3

verify_stage2 - disabled

signature check ok
rawfs driver already in use
Cannot mount mmcblk0p1 of type rawfs
AvBoot Version 5.5.3
Developer edition found, disconnect
bat overtemp
stop charging
exit low batt state voltage: 3969mV
size of params: 32768
magic: 6fc59ae8, ret: 0, size: 32768

verify_kernel - disabled

signature check ok

Just to mention this:

This was captured on my A80S device with bootmode changed to peripheral mode.

EDIT:

Some additional words on uart1...

The GPS chipset is also connected to this UART, that's why i got confused a little bit while doing measurements with an oscilloscope.

The GPS chipset get's initialized at a later point when Android is up.

The CPU uses a hexadecimal protokoll at this point, that's why i could not get something useful out of it.

What's next:

- try to boot from microSD

- try to enter avboot console mode

Have a nice day :D

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
I don't like the part "signature check ok" ;)

BTW "batt overtemp; stop charging" means that avboot does have some charging procedures onboard?
[Gen9, Gen10 General] scholbert:
Yeah, signatures suck... but as far as i'd been told by LeTama singature check is kind of by-passed, and this would always result in a "ok" message.

At least we now that the signature is ignored for recovery, because unsigned custom ones had succesfully been used already.

We don not know for sure about the init (stock Android kernel) located in rawfs.

No one tried to replace the init file with a custom kernel+initramfs yet.

There are some hints that avboot may support charging.

It's little different here, because this log has been captured form my experimantal board, which actually get's powered by a laboratory supply.

In other words there's no battery attached to this hardware.

Also the NTC to measure the battery's temperature is not attached to the board.

Some research has to be done on this topic.

Regards,

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
IIRC kernel+initramfs (init) is signed but signature may not be checked by bootloader. Aos_parser checks .aos file before unpacking (check is initiated by recovery but should be easy to bypass- look into recovery_lib.sh) and possibly also for each unpacked file before it's flashed, second check just to make sure that file is intact (this is my guess).

I hope signature checks are used only for aos files ;)

But I guess power is attached to the battery terminals?

And that's why there is "bat overtemp" message- DAC input is just tied to Vcc or Gnd (depends on design).

I'm afraid charging related messages may be just leftovers or some experimental (not cleaned before release) code- twl6030 is able to condition a fully depleted battery by itself (thus "leave it charging overnight" hint for reviving "depleted" units) but main charging procedure requires external control. In our case kernel controls it but I don't know why charge_loop (present in ICS init files) is not used.
[Gen9, Gen10 General] neur0mans3r:
First I have to write it properly and add more functions. I just wrote a couple of lines of code to make it easier to see that there is a problem with the touchscreen.

I think I found the reason this issue happens. Old Cypress touchscreen drivers had a variable CY_ACT_DIST that was used to set the reporting frequency for gesture touch events. The default value was set by CY_ACT_DIST_DFLT = 8, and supported values were from 0 10 15. CY_ACT_DIST was used to trigger another gesture touch event only after the distance between the current touch event and previously reported touch event is higher than CY_ACT_DIST value. This was later incorporated into code that, I think, checks for valid operational mode in the driver's interrupt handling sequence.

Reference:

http://lkml.indiana.edu/hypermail/linux/kernel/1011.2/02535.html

This explains why we keep seeing 9 touch points difference when we drag slowly along one axis. Since a touch event gets triggered only if the distance between two touch points is larger than a certain distance, it looks like there is a constant set that prevents us from getting more precise touchscreen response. If that constant is 8 and distance must be larger than the constant then we have an explanation for the 9 touch points difference between touch events in a single gesture.

Also, if you try dragging you finger diagonally in my test app, you can see that you cannot get, for example, 6 and 6 touch points difference, but only 9 and 6.

I think that the controller is using a simple algorithm like this:

if (max(abs(newX-oldX), abs(newY-oldY))>CY_ACT_DIST){
service_irq(data);
}

to perform the decision should the event be reported.

Since most of interaction we have with our devices are gesture based, setting a value this high does not make much sense. So, we need a way to configure the touch controller to use a shorter distance in the reporting process (maybe even 0, to report all gesture events).
[Gen9, Gen10 General] scholbert:
Yupp, that's how it might be...

That's what i supsect as well.

The stock recovery is also signed, but could be replaced without any issues with a customized one (at least if you know how to replace).

Right!

Yupp, should be like that.

BTW, i started to disassemble avboot, but right now there's not much to "read" from the assembler code.

Some messages are still without any reference. Unfortunately just the interesting ones :rolleyes:

Anyway thanks a lot for your comments!!

Best regards,

scholbert
[Gen9, Gen10 General] scholbert:
You might have a look at the kernel code as well:

http://gitorious.org/archos/archos-...er/drivers/input/touchscreen/cypress-tma340.c

BTW, the driver is dated 17/03/2011.

No time tom get any deeper into this code right now, but might be some interesting hack to improve the touch unit.

Keep on rockin'

scholbert
[Gen9, Gen10 General] trevd:
[EDIT:] The info below applies to the A101G9 which is obviously a completely different screen.... Must read thread titles more closely :p [/EDIT]

This is some excellent work going on here, I've been having touchscreen issues myself, It goes from complete failure to having a mind of it's own :). I just plug a mouse and keyboard in to work around it and sometimes remove the touchscreen kernel driver :laugh:

I had a quick look at the touchscreen driver a month or so back just out of interest, Not looked at the new archos sources but I will say It is a massively different codebase when you compare a standard linux 3.0.8 (current archos kernel ) version to the 3.2.x line (a probably 3.4.x aswell) , they seemed to have merged/moved a lot of stuff in the input drivers section from what I recall . But backporting might make a "fun" project and maybe a line of investigation. I was thinking about having a go with backporting the new one myself but I've been a little busy with modems and RIL's at the moment :p and I'm in 2 minds whether that's my real issue..... because I've had the device open, I'm never quiet sure if it's something I've done when it comes to hardware issues :) Still not got my hardware hackings wings fully inflated :(

I'll have to read the rest of the thread properly because it's got many topics going on here. all good though

Thanks for the info and sharing
[Gen9, Gen10 General] kr0m:
Hi, scholbert!

I have killed device with same ID ( 01 05 01 44 30 07 04 ).

Have You found the second loader and configuration file for omap4430 4 HS ?