Database Users

Internal Ram Upgrade

Hi all,
I upgraded internal RAM of my xda and others (my friends) from 32MB to 64MB by myself and intend to do 128MB memory upgrade.
I'm not sure whether the xda internal hardware along with its installed OS can handle 128MB internal memory, but its worth to try.
The chips (SDRAM) for this purpose (128MB memory upgrade) is difficult or should I say impossible to get within my country.
I have contacted the memory manufacturer distributor, their minimum order is 1000 pcs, this is too many for experiment. XDA needs only two of this chips.
I guess, I have to keep on waiting.
Other option is to stack the memory and lift the top chips CS pin and wired to pin L14 (//RAS_2/SDCS_2) of strong arm processor. Offcourse I need to make a software driver to have the OS recognize this new memory mapping address and mounted as perhaps a folder in the root directory.
Writing a software driver is a new challenge for me who happen to be a new programmer.
The problem on the second option is to find the path on the PC board that connected to pin L14 of strong arm processor.
Can anybody point where this path on PC board located ?
Best Regards,
James

Where did you get the chips to upgrade from 32 to 64, and how much were they?
Do you have the chip ID?
Any/All info here please.

memory upgrade
look at :
http://www.ipaqupgrade.de/
Sorry, it's an german side... but:
the 2 chips 4 64 MB without inbuild 75-Euro
If u want to upgrade to 128 MB- u must have the driver.
the only company that can handle this at this time is in America, and
they don't sell the driver... :twisted:
Stevie

With this extra memory, have you been able to increase the colour depth of the XDA?
I was looking into it for this reason. But as we can't use a microdrive etc with the XDA my want for watching full length quality moves on the XDA still goes on . . .
Martin

Which chips did you use? I plan upgrading as well (by myself), but I don't know if all SDRAM chips are compatible... I was thinking about buying an ordinary SDRAM memory for PC and using the chips (2x 128Mbit), but can't find any with Winbond chips in...

All,
You may use 2x SDRAM chip with spec below:
- 256 Mbit with configuration 4M x 16bit x 4 banks
- LVTTL
- TSOP II-54 pin
- Freq 133Mhz (PC133) or 100Mhz (PC100)
The most important thing is the pin layout must macth with Intel Strong Arm SA1110 Development board schematic, you may download this schematic for free from Intel website. Samsung and micron has put this chips on mass production, I myself use samsung.
This upgrade won't do any effect on the colour depth of XDA. Colour depth is taken care by VGA and LCD circuit, not the memory.
Most memory distributor won't let you order this chips in small quantity. Each PocketPC needs only 2 of the chip. So the only way to get the chips is to seek SDRAM memory module utilize the chips for this upgrade.
I still have some of the chips incase of somebody need my help to upgrade their XDA.
Cheers,
James

RAM UPGRADE
Hi!
Can U detail the type of SDRAM?
-> The 'normal' Size of the SDRAM
-> The Speed in ns?
-> The Company of the type you used?
-> The detailed Code on the sdram?
Thanx
Stevie

you positive
jamesthrs said:
......This upgrade won't do any effect on the colour depth of XDA. Colour depth is taken care by VGA and LCD circuit, not the memory.....
Click to expand...
Click to collapse
I was lead to believe that due to the 32meg ram the XDA has limited colour depth, 4096? So you then get 64MB and you end up with 16bit colour depth..
I can't remember where I read this. I think it may have been a memory selling site. And they mentioned that upon returning the device you would have better colour depth....
I'll to look into this a little more
Martin

That is completely untrue.

128 MBRAM Upgrade
First of all: excellent site.
But: :!:
1. A section about DIY RAM upgrades incl. manual ´d be helpful as long as many users want to DIY (incl. me…)
2. (more important…) Is anyone of your team on the job about isolating the driver needed to run XDAs with 128 MB RAM? Just got answer from PocketPc.com:
Dear Doesn´t matter,
We do not ship the chips out. the 128MB upgrade also requires our proprietary driver. The XDA is one of the most difficult upgrades that we do and it is not user installable.
Best Regards,
blablabla
I think I gonna handle getting to other sources of chips, but the driver-situation is a REAL problem...
Thanxx in advance, Krusty :wink:

PocketPCtechs Upgrade
Hey all,
I had the upgrade to 128M completed on my T-Mobile recently and it's well worth it. I'm using the t2t driver to access the upper 64M. The driver is serialized to only work on my phone though (using last four digits of serial number).
It is fabulous! I'm now trying to figure out how to cram the driver into the mkrom program (as well as pocket informant, fonix voice dial, and a couple other packages).
T-Mobile PocketPC Phone
128M Running OS 1.1 (a bit tweaked)

Hey rdm128 !
It is good idea !
Can you send me the driver ?
Thx,
Sebi

Tracing wires on the board...
I was planning to do a write-up soon on how at least some of the JTAG pads on the board were located. As it is only the pictures are available, but as you can see we removed the BGA chips, and we trace paths on the board now. So we may be able to locate an easy spot for you to pick up L14 (//RAS_2/SDCS_2) on the ARM.
In case you're wondering: it took an oven, and some careful manipulation. Images and work courtesy of W4XY.
http://xda-developers.com/jtag

In case you're wondering: it took an oven, and some careful manipulation.
Click to expand...
Click to collapse
Crazy bastards. I wish I was close enough to come out for some of these hacking sessions. Makes me miss the early days of getting together to hack up Heathkit computers (my first one in 1979 had 4k of RAM) and their OS.

Hi XDA developer !
I was planning to do a write-up soon on how at least some of the JTAG pads on the board were located. As it is only the pictures are available, but as you can see we removed the BGA chips, and we trace paths on the board now. So we may be able to locate an easy spot for you to pick up L14 (//RAS_2/SDCS_2) on the ARM.
Click to expand...
Click to collapse
Can you send me where is the location in the PCB of L14 on the StrongArm processor ?
Best regards,
Sebi

Hi XDADevelopers !
I was planning to do a write-up soon on how at least some of the JTAG pads on the board were located. As it is only the pictures are available, but as you can see we removed the BGA chips, and we trace paths on the board now. So we may be able to locate an easy spot for you to pick up L14 (//RAS_2/SDCS_2) on the ARM.
Click to expand...
Click to collapse
What about this think ?
Regards,
Sebi

Hi,
About the L14 trace: It looks like it goes to both RAM IC's on the RAS pin. I measure about 35 Ohms so it is not a direct connect. I can't trace any of the other RAS pins, so who knows what the configuration should be?

Re: PocketPCtechs Upgrade
rdm128 said:
Hey all,
I had the upgrade to 128M completed on my T-Mobile recently and it's well worth it. I'm using the t2t driver to access the upper 64M. The driver is serialized to only work on my phone though (using last four digits of serial number).
It is fabulous! I'm now trying to figure out how to cram the driver into the mkrom program (as well as pocket informant, fonix voice dial, and a couple other packages).
T-Mobile PocketPC Phone
128M Running OS 1.1 (a bit tweaked)
Click to expand...
Click to collapse
Hi rdm128,
Can you send the driver to me?
Thanks,
James

yea realy! i mean... cant we CHANGE our serial # to mach that driver?
(incase we want to do our OWN upgrades )

Any suggetions for memory installation technique?
Hey,
how did you guys remove old chips and installed the new ones? I am fairly experienced in this stuff, but want tot make sure I don't screw up my precious XDA...
Thanks all!

Need some USB HOST driver dev help

I have a problem that I hope some of the code gurus here can help me with. I have an HTC PDA that was codenamed Colorado. The Colorado is actually the Dell Axim X50 series. I have a thread on Aximsite http://www.aximsite.com/boards/showthread.php?t=140071 where I am trying to add a USB host hardware interface to the PDA. I have done quite a bit of hardware reverse engineering of the X50v device (I'm a old-time hardware hacker) and have been able to bring out the PXA270 USB host port1 interface to the outside world via two unused pins on the sync connector.
I originally noticed that the X50v A02 ROM had the OHCI driver included, so I rolled back to that release on my test PDA and have been attempting to get the interface operational. In my quest, I have determined that I need the usbd.dll driver as well as any client device drivers for HID, mass storage, etc.
I've used a number of the great utilities I've found on this site (thank you very much) to grab a copy of the Axim ROM and pull it apart. I consider myself great at working on hardware but my software skills have become rusty over the years (hey - I started by building this system a 'few' years ago: http://www.sol20.org/ )
What do I need?
I would appreciate getting some guidance on how to dissassemble the ohci.dll module so I can see if in fact, it was designed for the X50 or if it was left in by accident by HTC as the later ROM updates for the X50 series had the ohci.dll module replcaed with one named peripheral.dll which was about 1/5th the size.
Also, I'm wondering if either the ohci or usbd drivers require the irq and/or the membase of the PXA270 USB host port1 interface and if so, how do I determine those.
My original idea was to use a simple 2 port hub to bring out the interface. Unfortunately, I recently discovered that a hub requires a hub client driver. Because of that, I will settle on getting a USB flash memory key to interface directly as the drivers are already available. One of the problems I have is interfacing the 3v USB host lines on the PDA to the 5v data signals that may be present on the client device. The PXA270 USB host lines are already terminated on the PCB with 15K resistors. All that is needed is a transient protection chip and/or port driver chip.
I have installed the free Microsoft WinCE dev environments which I thought contained the source for the generic ohci driver, but I can't find it anywhere so I guessing it's not included in the free dev s/w.
Although this is only my 2nd post here, I do hope to be able to contribute technical information going forward. What I'm doing on the Aximsite is quite advanced as far as hardware hacking goes and I hope to be able to simplify it so a few others can 'play'.
Thanks in advance for any help and I wish everyone here a great New Year!

Wow. Well this is a bit over my head, but does sound great.
I will try pointing you toward a couple of useful tools:
1st is IDA probably the most powerful disassembler for ARM code. The free evaluation works fine, but won't save and closes about every 30 min. Still should do the trick if you just want to look at the code.
2nd to get sample driver code, you need Platform Builder. Not sure if that is what you downloaded, but try the provided link. Evaluation version contains all the source code MS is willing to give, it just has some limitations on ROM compilation (which you should not care about).
The only problem is, it's a real b*** to install. Takes hours even if you have a goo internet connection.
Hope this helps.

Thanks for the quick reply.
Do you know if there is anyone who knows a little on how the low level device drivers actually interact with the hardware ports?
Also, I assume that with just the ohci and usbd drivers, if the port is actually activated by pulling one of the data lines high, I should get the popup box asking for the name of the device driver. correct?

how to determine I/O base offset?
In trying to reverse engineer the ohci driver for a couple for the HTC units, I need to figure out where the I/O register base starts.
Are there any memory dump utils, like dumprom, that would indicate that?
I've installed platform builder and want to try compiling the standard ohci driver, but I need to know how to determine the start of the I/O registers on a given WM2003SE platform.
Any assistance would be greatly appreciated.
thanks

[SGH-T589] Finding/reading the UART

I've hit a wall in my quest to improve the Samsung Gravity Smart (SGH-T589). The kernel source that Samsung released for it doesn't quite work right (no wifi, broken touchscreen drivers). I'm trying to do something about it, but my test kernels hang before ADB is able to detect and connect to the phone.
The phone is powered by the Qualcomm MSM 7227 (S1 Snapdragon @800Mhz), which I understand is supposed to have a debug UART. How do I access it?

Reading the Google Nexus i9250 thread, I took a closer look at the system board. I've highlighted what I suspect is the JTAG header (see attachment).
However, I lack both the tools and expertise to determine if that is the header, and what the pinout is (most jtag pinouts I see pictures of online are in 2-column layout).
But, I might not need that. If I understand the discussion in the i9250 thread correctly, what I need is a combination of this miniUSB breakout kit, a 619Kohm resistor, and the FTDI Friend to use to connect the UART to my PC. I'm not quite sure where I go from there, but I expect that Windows will detect the serial port and give me something to connect to via SecureCRT or the like.
Is this correct? I'd kinda like to know before I spend any money on parts
Alternately, if anyone wants to take a crack at wiring up the JTAG port, I have a spare (broken) phone I can ship out. Screen doesn't work, but it still boots which will make it perfect for testing with!

Now, if you had bothered to SEARCH you'd have found THIS post in this thread with this picture!

I actually did come across that thread, however that particular post would not have come up in a search and you'll forgive me for missing a post in a 25-page thread However, I appreciate your help nonetheless.
Next question: I have 2 conflicting schematics for wiring an LPT JTAG cable. One shows TDO wired to pin 13, the other has it wired to pin 11. Which is correct? Or should I just try it both ways?

Try both. Shouldn't happen anything bad until you connect it to 12V or so.

I'm banging my head against a wall here, trying to figure things out but not finding clear instructions.
Is it true that, in order to perform JTAG, I need to use some kind of adapter (i.e. RiffBox), or can I connect it directly to the LPT port of my PC? If I can use my PC, what software do I use to read the debug output? I'm less concerned with recovering from hard brick than I am with getting the early debug output.
I'm thinking a hacked USB approach might be simpler and less expensive. My problem is lack of tools. If anyone else has made such a cable, could I buy it off you for a reasonable price?

Hello, i have a semi bricked Samsung Galaxy S5770 Mini/Pop/Next. It is a Qualcomm MSM7227 board. I have tryied the usb UART approach, but the only thing i can get from it is AST-POWERON, and it repeats (i think it bootloops)
I am trying to find UART on board, there are some little pads around the CPU.
Sent from my GT-I9003 using XDA

Ah my TDO is wired to pin 11. You don't need riffbox if you make a LPT JTAG adapter such as the Wiggler (low voltage variant 3.3V).
There are many softwares that can handle the wiggler, such as H-JTAG, openocd and urjtag.
I used "H-JTAG" and "NoICE for ARM" on windows. It's easy to setup H-JTAG for the wiggler and you don't have to do anything from the command line.
The msm7227 platform is multi-cpu (modem cpu, applications cpu).
With the JTAG port you saw, you can access the modem cpu, which is a ARM926ej-s.
Sent from my GT-I9003 using XDA

tanks for you

Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.

Rebellos said:
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Click to expand...
Click to collapse
The issue here is that I'm trying to backport the MXT224 driver because the driver that's in the Samsung release is butchered beyond repair--the orientation is wrong, the resolution is wrong, the alignment is wrong.
My backported driver either fails to recognize the hardware (which is odd, because the init code uses the exact same kernel calls as the FUBAR driver for the I2C transfers), or locks up the boot process too early to get any useful debug output.
Anyway, I have the parts I need on order, all I need is for the orders to show up and a decent soldering iron and I should be in business.

Ah! The MXT224. I know this one pretty well, aswell as messup that Samsung does, configuring it in hundreds of different ways, with usually same result.
I think you don't need to port anything there. There's parameter table passed to MXT224 during init, that's probably only one thing you need to setup. You might want to reverse driver from some stock kernel, or adjust it experimentally, or simply request Samsung for proper parameter table.
There are many helping examples in various kernel arounds, sometimes it's called MXT224, and sometimes it's QT602240. This is in fact 100% same thing.
I'm not sure if any datasheet is publicily available. Though setup structures explaination should be enough, there it is:
https://bitbucket.org/gokhanmoral/s.../drivers/input/touchscreen/qt602240.h#cl-4848
For example flipping it would be changing "orient" byte in T9 structure. Probably all othere parameters you need to change are also in T9.

Thanks for the link. I managed to figure out the correct "orient" value by trial-and-error, but the screen alignment is screwed up. On a stock kernel, the top-left is 0,0. On a compiled kernel, top-left doesn't even register properly (none of the edges do). I've tried a few experimental things but nothing helped so far. I'll check out that link when I get home and hopefully find something useful.

You might also want to look into mach_aries.c and mach_herring.c files from I9000 and I9020 kernel sources. These shows pretty good how very similiar results can be done in pretty different set of T9 parameters.

I appreciate your input. I'm experimenting with different T9 values. I found a partial datasheet that shed a little light into some of the parameters.
I've managed to strip out the "piggy" (uncompressed vmlinux) from the stock kernel. Is there anything I can do with that to somehow find out what T9 parameters are used by the actual stock kernel (as opposed to what Samsung released)? I did some searching for kernel disassembly but didn't find anything that looked promising.

Can you upload it somewhere? I'd take a look into it.

Sure thing. I'll upload it tonight when I get home. Thanks!

Here it is, gzipped:
http://min.us/mrUKEtr7W

Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.

Rebellos said:
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Click to expand...
Click to collapse
It's not on github at the moment. I'm just working from the kernel sources posted on opensource.samsung.com for the SGH-T589. I'll start an account tonight when I get home and upload what I have. I'll get the map file you're after uploaded too.

EMMC Bug Electronics Engineer point of view

Well as far as my point of view as electronics engineer understanding goes.. im bringing you the following scheme.
In conclussion what Samsung told to Entrophy in my opinion was bullshyt because this .. the flash memory chip allows 2 erase methods
1. the regular(slow method) wich works with the CAP_ERASE disabled in the kernel
2. the fast method wich happen to cause damage in some memory sectors.
To make it simple the procedure should be something like this:
User/process performs a wipe (no matter the recovery cwm/stock/from the OS loaded) so
if wipe instruction then
cap_erase (generates a I2C frame to perform a "fast format" serial binary string)
else (if cap_erase dissabled)
slow erase (generates a I2C frame to perform a slow format serial binary string)
end if
As it shows no matter what its loaded in the OS(root or not, cwm or not, stock or not) and no matter what the kernel its the I2C frame needed to perform a format in the flash memory chip gotta be the same no matter what.. it DOES NOT depends on OS/KERNEL/RECOVERY, ITS HARDWARE LEVEL AND PURE BINARY STRINGS(UNIQUES)
Wich i beleave its either if GB kernels has the cap_erase enabled the process itself does not calls the fast format instruction...
As result ICS full stock or not WILL brick because the flash memory chip used by samsung in the Note cant handle the fast format command.. and that said there are 2 ways of making a safe kernel, dissabling cap_erase or not calling it at all in the wipe process..
Samsung wont admit this befcause they gotta replace every Note in the streets(remember Toyota calling all the COROLLAS owners to replace for free the breaking system).. and instead they said all that Bullshyt to entrophy so they wont assume the cost of it.
Just my 2 cents about the issue

it means our note is not fixable from the emmc bug
Sent from my GT-N7000 using xda premium

Don't worry op, some of the ignoramuses amongst us will still believe that Samsung's stock software is safe on ICS. lol.

Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium

abhijit038 said:
Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Here comes one......

I actually think that's a good explanation. Understanding a bit of software programming, it makes sense. But of course, I take caution as I don't know software development that much and fear I might do something wrong.....
Sent from my GT-N7000 using Tapatalk 2

Lets just be grateful that we live in a technological age and at least have a Note

As a fellow electronics engineer let me tell you that you are wrong and seeing it way too simple.
The I²C bus, invented in the late 80's, by Philips, is a serial highspeed bus.
You could see it as the grandfather of USB.
So why in heavens name would the 2 binary strings have to be exact the same, and therefore not capable of causing different actions on the memory chip ??
Aren't you able to send multiple and different commands over your usb port ????
Now all the coding and action is done INSIDE the Emmc chip by it's internal algorithms, stored inside it's own firmware. The I²C just tells it 'do your job',
by calling the erase function either in the fast or the slow way.
And the I²C serial string is issued by the kernel driver for the serial bus.
So it is definitely Kernel related..
In GB Google NEVER issued a Format command when wiping, it just cleared the File allocation tables

abhijit038 said:
Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Don't need to cite anything.. I'm a electronics engineer with 10 years experience not a random rookie
friedje said:
As a fellow electronics engineer let me tell you that you are wrong and seeing it way too simple.
The I²C bus, invented in the late 80's, by Philips, is a serial highspeed bus.
You could see it as the grandfather of USB.
So why in heavens name would the 2 binary strings have to be exact the same, and therefore not capable of causing different actions on the memory chip ??
Aren't you able to send multiple and different commands over your usb port ????
Now all the coding and action is done INSIDE the Emmc chip by it's internal algorithms, stored inside it's own firmware. The I²C just tells it 'do your job',
by calling the erase function either in the fast or the slow way.
And the I²C serial string is issued by the kernel driver for the serial bus.
So it is definitely Kernel related..
In GB Google NEVER issued a Format command when wiping, it just cleared the File allocation tables
Click to expand...
Click to collapse
I think you don't get the whole picture.. In the main board the processor and periferics communicate each other via I2C data bus they are connected with Cooper vias serialy and the protocol they use to "talk" its I2C and that's has nothing to do with kernel or usb
We got processor architecture Wich means the processor share a serial data bus with all the periferics.. The memory its not embedded as it is not a microcontroller
The kernel tells the processor to send a wipe command to the flash memory chip and kernel CAN NOT talk directly to the chip.. Assambler compilatior translates kernel languages into pure binaries that can be handled by the processor..
Sent from my GT-N7000 using xda premium

msedek said:
Don't need to cite anything.. I'm a electronics engineer with 10 years experience not a random rookie
I think you don't get the whole picture.. In the main board the processor and periferics communicate each other via I2C data bus they are connected with Cooper vias serialy and the protocol they use to "talk" its I2C and that's has nothing to do with kernel or usb
We got processor architecture Wich means the processor share a serial data bus with all the periferics.. The memory its not embedded as it is not a microcontroller
The kernel tells the processor to send a wipe command to the flash memory chip and kernel CAN NOT talk directly to the chip.. Assambler compilatior translates kernel languages into pure binaries that can be handled by the processor..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Read up a bit : http://www.samsung.com/global/business/semiconductor/product/flash-emmc/overview
it is not just a memory chip, it has it's controller hardware built in controlled by it's own Firmware.
Now let me tell you i engineered microcontroller boards communicating over I²C when you were still in diapers probably. Whether or not the serial bus uses copper , wood , or pigeons is of no interrest.
The Kernel tells the processor to issue a binary string over the I²C to the memory controller telling it what to do. without the Kernel the processor will never tell the I²C anything. Not even that it loves a juicy steak...
Taking your opening post in a nutshell you are saying :
No matter whatever OS, Kernel, Recovery or what is loaded, if you send a fast format command to the Emmc Chip, in some cases it will brick..
Samsung has no way of fixing it, and so they say it is a marginal problem that doesn't need a callback, we will just replace the faulty motherboards.
You are perfectly right, but we already knew that thanks to entropys involvement

friedje said:
Read up a bit : http://www.samsung.com/global/business/semiconductor/product/flash-emmc/overview
it is not just a memory chip, it has it's controller hardware built in controlled by it's own Firmware.
Now let me tell you i engineered microcontroller boards communicating over I²C when you were still in diapers probably. Whether or not the serial bus uses copper , wood , or pigeons is of no interrest.
The Kernel tells the processor to issue a binary string over the I²C to the memory controller telling it what to do. without the Kernel the processor will never tell the I²C anything. Not even that it loves a juicy steak...
Click to expand...
Click to collapse
You are not saying anything new.. I already stated that.. The kernel its who sends the command to the hardware, memory its slave either if it has a embedded processor with its own firmware or not.. The processor it's who gets the message from the kernel and send the command..
The flash memory chip(with its super ultra mega embedded procesor and own firmware) can perform at least (that we know of) 2 kinds of erases cap_erase(faster) and regular(slower) there are differents commands for both.. The kernel as I said it's who sends the type of commands and I already said that the chip CAN NOT handle the fast erase.. So I said the only way I see to get safe its disabling the cap erase command from kernel wich developers already did but the problem it's Samsung won't do it as they won't accept the fact because it implies a lot of money
Sent from my GT-N7000 using xda premium

friedje said:
Taking your opening post in a nutshell you are saying :
No matter whatever OS, Kernel, Recovery or what is loaded, if you send a fast format command to the Emmc Chip, in some cases it will brick..
Samsung has no way of fixing it, and so they say it is a marginal problem that doesn't need a callback, we will just replace the faulty motherboards.
You are perfectly right, but we already knew that thanks to entropys involvement
Click to expand...
Click to collapse
I know but I want to put it in graphical and friendly way so everyone can see what really happens and how it works
Sent from my GT-N7000 using xda premium

Amen

I'm also an EE with quite a bit of experience (10 years since college graduation too), and I can tell that you have zero experience with eMMC since you're talking about I2C. I admit I didn't have much eMMC experience until a few months ago, but since you're trying to talk about eMMC and spouting BS about I2C, it's pretty obvious that you are making random speculation with no specific knowledge of the issue.
NOWHERE in the eMMC interface is I2C used. Some MMC/SD devices can use a basic "fallback" mode where they present a SPI interface, but I believe many eMMC chips don't support this, and I can tell you without a doubt, this is not used in any way by our phones.
I suggest that you read the JEDEC eMMC standard - see http://www.jedec.org/standards-documents/results/taxonomy:2940 . Specifically read the sections governing erase commands.
Secure erase is known to trigger internal bugs in the wear leveller of the chip itself. It is suspected due to reports of damage in stock recovery that non-secure erase/trim can also do damage, however Samsung is certain it won't. I don't think we'll ever know for sure until Samsung releases the update they're planning which will block secure erase but permit non-secure erase.
And there is no "regular slow method" of erase... When MMC_CAP_ERASE is not used, the device simply never erases cells unless it must do so in order to complete a write operation. In this case, the complete system behaves similar to an old-school magnetic disk - if you delete a file or format a partition, the references to content are removed but the content itself remains. On magnetic media, this isn't a problem for performance as it takes the same time to rewrite a previously written sector as one that is blank. With flash, memory can only be written one block at a time - if you want to modify just part of a block, you must read it, modify it, erase the underlying memory, and rewrite the modified data. Most modern flash chips have an internal wear leveler such that a logical block is mapped to different physical blocks (so that if one logical location is written to over and over again, it will get written to multiple physical locations, so one particular block doesn't have too many write cycles.) So the memory is just not erased - yes, having the media full leads to slow write performance over time, but there is no "slow erase" involved.
In kernels where MMC_CAP_ERASE is disabled, the flash is treated in the same manner as legacy magnetic media (don't explicitly erase the chip when deleting/formatting) - this is not optimal as it eventually leads to slower write performance (but the performance degradation will "level off" once all cells on the flash memory are used), but it's also perfectly safe.
BTW, the difference between secure erase and nonsecure erase is whether the erase command deletes ALL copies of the data (see above at the wear leveller - it is possible that when writing to a block, the underlying wear leveller will read one physical block, modify it per the write command, then write it to a free block elsewhere.) ior just the current copy.

Entropy512 said:
I'm also an EE with quite a bit of experience (10 years since college graduation too), and I can tell that you have zero experience with eMMC since you're talking about I2C.
NOWHERE in the eMMC interface is I2C used. Some MMC/SD devices can use a basic "fallback" mode where they present a SPI interface, but I believe many eMMC chips don't support this, and I can tell you without a doubt, this is not used in any way by our phones.
I suggest that you read the JEDEC eMMC standard - see http://www.jedec.org/standards-documents/results/taxonomy:2940 . Specifically read the sections governing erase commands.
Secure erase is known to trigger internal bugs in the wear leveller of the chip itself. It is suspected due to reports of damage in stock recovery that non-secure erase/trim can also do damage, however Samsung is certain it won't. I don't think we'll ever know for sure until Samsung releases the update they're planning which will block secure erase but permit non-secure erase.
And there is no "regular slow method" of erase... When MMC_CAP_ERASE is not used, the device simply never erases cells unless it must do so in order to complete a write operation. In this case, the complete system behaves similar to an old-school magnetic disk - if you delete a file or format a partition, the references to content are removed but the content itself remains. On magnetic media, this isn't a problem for performance as it takes the same time to rewrite a previously written sector as one that is blank. With flash, memory can only be written one block at a time - if you want to modify just part of a block, you must read it, modify it, erase the underlying memory, and rewrite the modified data. Most modern flash chips have an internal wear leveler such that a logical block is mapped to different physical blocks (so that if one logical location is written to over and over again, it will get written to multiple physical locations, so one particular block doesn't have too many write cycles.) So the memory is just not erased - yes, having the media full leads to slow write performance over time, but there is no "slow erase" involved.
In kernels where MMC_CAP_ERASE is disabled, the flash is treated in the same manner as legacy magnetic media (don't explicitly erase the chip when deleting/formatting) - this is not optimal as it eventually leads to slower write performance (but the performance degradation will "level off" once all cells on the flash memory are used), but it's also perfectly safe.
Click to expand...
Click to collapse
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
And once again I'm trying to put things simple.. No matter if I can understand what your saying in the end it's a hardware problem and most people can picture what's wrong and General how's everything conected
By the way being polite its a virtue not everyone have.. And being humble makes us better humans I'm not in anyways being rude to anyone here but seems like you can not stop yourself from being such a horrendous person
Sent from my GT-N7000 using xda premium

msedek said:
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I2C used for every peripheral on the CPU? You've got to be kidding me, it's suited only to low-bandwidth peripherals like sensors. Read the datasheet of any modern mobile CPU - there are a pile of interfaces including, but not limited to, USB Host, MIPI DSI, MIPI CSI, UARTs, and SPI. I2C is used in our devices, but not for ANYTHING related to storage interfaces in any way, shape, or form.
It's pretty clear you're lying about being an EE with 10 years of experience if you think a 400 kilobit/second bus like I2C is capable of supporting storage that typically transfers tens of megabytes/second of data. People who misrepresent themselves like you clearly are do not deserve politeness.
eMMC/MMC/SD uses a dedicated interface designed specifically for storage devices like this. Again - read the JEDEC standard, since it explicitly describes this interface. It describes MMC command 38 (used for all forms of erase) in detail, and how it is supposed to work and be used.
The problem, at its simplest, boils down to our chips not being JEDEC compliant and not properly handling secure erase/trim properly if they are treated as a JEDEC compliant chip. Not only do they implement the command improperly, they suffer permanent damage as a result. This is not new information, and has been known for over two months.

msedek said:
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
And once again I'm trying to put things simple.. No matter if I can understand what your saying in the end it's a hardware problem and most people can picture what's wrong and General how's everything conected
By the way being polite its a virtue not everyone have.. And being humble makes us better humans I'm not in anyways being rude to anyone here but seems like you can not stop yourself from being such a horrendous person
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
If you look at the g-note schematics, the memory is connected to the cpu using a normal parallel data and address bus, they are not communicating over I²C.
http://img84.imageshack.us/img84/6856/gnotemem.jpg
(c) Samsung Electronics

friedje said:
If you look at the g-note schematics, the memory is connected to the cpu using a normal parallel data and address bus, they are not communicating over I²C.
Click to expand...
Click to collapse
RAM is connected in this way I think, the flash memory is connected via an MMC/SD interface implemented by a dedicated storage controller in the CPU. (One of at least 3-4 such interfaces - One for internal eMMC, one for external SD, and one SDIO interface for wifi)

Msedek... I think you should leave it there bud... Your picking a fight with the wrong dude. Entropy512 clearly knows what he's talking about... No offense but your making yourself look adolescent
Sent from my GT-N7000 using xda app-developers app

Entropy512 said:
I2C used for every peripheral on the CPU? You've got to be kidding me, it's suited only to low-bandwidth peripherals like sensors. Read the datasheet of any modern mobile CPU - there are a pile of interfaces including, but not limited to, USB Host, MIPI DSI, MIPI CSI, UARTs, and SPI. I2C is used in our devices, but not for ANYTHING related to storage interfaces in any way, shape, or form.
It's pretty clear you're lying about being an EE with 10 years of experience if you think a 400 kilobit/second bus like I2C is capable of supporting storage that typically transfers tens of megabytes/second of data. People who misrepresent themselves like you clearly are do not deserve politeness.
eMMC/MMC/SD uses a dedicated interface designed specifically for storage devices like this. Again - read the JEDEC standard, since it explicitly describes this interface. It describes MMC command 38 (used for all forms of erase) in detail, and how it is supposed to work and be used.
The problem, at its simplest, boils down to our chips not being JEDEC compliant and not properly handling secure erase/trim properly if they are treated as a JEDEC compliant chip. Not only do they implement the command improperly, they suffer permanent damage as a result. This is not new information, and has been known for over two months.
Click to expand...
Click to collapse
I can quote wiki (parts you didnt) too..
Come on dude.. this its not a knowledge war.. you know more things than me in certain fields and i know more than you in others.. any day ill swap everything i know with everything i ignore.. thi its about making things simple for average user
I ² C bus is a serial communications. Its name comes from the Inter-Integrated Circuit (Inter-Integrated Circuit). The 1.0 version dates from 1992 and version 2.1 in 2000, its designer is Philips. Speed ​​is of 100Kbits per second in standard mode, it also allows speeds of 3.4 Mbit / s. A bus is widely used in industry, mainly to communicate microntroladores and peripherals in embedded (Embedded Systems) and generalizing more integrated circuits to communicate with each other that normally reside in the same printed circuit

Hacking & Reverse Engineering of Tata Sky HD STB ( Technicolor : DSI729TAT )

I have a "Tata Sky HD" Set-top Box and I was about to throw this in garbage but before I want to know what is happening under the hood.
I search on internet and I found nothing except this. I'm noob so sorry for if say something silly.
I found this specifications.
Product : TATA SKY HD
Original Maker : Technicolor
Product Model Number : DSI729TAT
Chipset : STiH237 BHKB B3L
Type : ST40 -32 BIT
Architecture : RISC
RAM : 2GB [ SK Hynix H5TQ2G63FFR H9C
Storage : 1GB [ Spanison ML01G100
Power : 12v DC
Software: busybox 1.18.2 , mtdwrap, uclibc, Linux Kernel 2.6.32.59_stm24_0211, ST drivers: embx.ko, embxmailbox.ko, ics.ko, ics_user.ko, lxload.ko, mme.ko, mme_user.ko, LZO Decompression Library 2.03, Decompression Utility
PORTS : 1 HDMI 1.2/1.3/1.4, 1 USB 2.0, SAT-IN & 2 Audio 1 Video Out , 1 Optical S/PDIF (for Dolby Digital Plus Audio ), 1 Digi Card.
I Found 1 UART PORT Which would be used while extraction of Firmware.
AFTER SOME REASEARCH I FOUND THAT IT HAS SIMILAR TO ARM-CORTEX-A9 AND MALI-400 GPU. (MAYBE I'M WORNG)
IDEA : It has a a Good processor and ram which can run as raspberry-pi os.
so we can repurpose it as a Media Center, Gaming Console, NAS, Smart Home, Small Server or a Mini Computer.
storage is low so we have to add some storage. I'm not sure how this is possible. except swapping the NAND flash Chip.
GOAL 1 : Extract Firmware and Extract Paid Decryption key which is use to verify the sat-in signals. ( a stb which don't required subscription to watch any tv channel )
i think they modified the software which capture the unencrypted signal and if we have a signal receiver then we are good to go. but for big companies wants to earn money so they added these barriers which needs decryption. and if the satellite is sending encrypted signal then we need to find the key. ( i know it's hard that's why we are here. I'll love to hear you thoughts on these)
GOAL 2: Change the Firmware and install Linux.
Goal 3: Find a way to use it as media server with increased storage and add a wireless module for WIFI access.
I'm not sure it is possible or not. but i think its possible. just think about it a small hardware can collect signal from satellite and decrypt the signals in HD with Dolby HD audio. we just need to find a way to access this.
I SHARED MY IDEA AND I DON'T KNOW MUCH ABOUT THESE.
PROBLLY I'M GOING TO ACCESS THIS WITH UART INTERFACE AND TRYING TO ACCESS THE BOOTLOADER.
OR MAYBE DESIGN A CUSTOM KERNAL.
I'M SEARCHING FOR COMPATIBLE FIRMWARE WHICH I CAN MODIFY AS I NEED.
EXTRA : I FOUND A SIMILAR STB WHICH USED IN RUSSIA "NTV PLUS SET TOP BOX" HAS SIMILAR PROPERTIES LIKE TATASKY HD BUT WITH EXTRA I/O PORTS.
THANK YOU. IF YOU HAVE ANY ADDIONAL IDEA THEN I'LL LOVE TO HEAR THAT.
Links Used For Gathering Information
Chipset : https://www.st.com/en/digital-set-top-box-ics/stih237.html
RAM : https://www.electronicsdatasheets.com/manufacturers/sk-hynix/parts/h5tq2g63ffrh9c
OS information : https://www.technicolor.com/node/1899
Storage : https://www.qdatasheet.com/search.jsp?sWord=ML01G100&page=2&op=i
RISC BASED TOOLS AND APPS : https://www.riscosopen.org/content/downloads/common

This is probably the UART. You will most likely get a shell and U-Boot logs provided that it's not fused-off (ST microcontrollers can have debug interfaces fused off during flashing at the manufacturer)
How to find the pinout:
GND will have continuity with metallic parts of the board (heatsinks, HDMI ports, etc)
VCC will measure 1.8-5V DC depending on logic level
RX will not measure very much voltage
TX will go crazy during boot on an oscilliscope.
Try baudrate 115200 8n1

$cronos_ said:
This is probably the UART. You will most likely get a shell and U-Boot logs provided that it's not fused-off (ST microcontrollers can have debug interfaces fused off during flashing at the manufacturer)
View attachment 5877483
How to find the pinout:
GND will have continuity with metallic parts of the board (heatsinks, HDMI ports, etc)
VCC will measure 1.8-5V DC depending on logic level
RX will not measure very much voltage
TX will go crazy during boot on an oscilliscope.
Try baudrate 115200 8n1
Click to expand...
Click to collapse
Well i don't have oscilloscope yet, soon I will try your guide, thanks for guidance. I will try to update upcoming experiments.

dyal96 said:
IDEA : It has a a Good processor and ram which can run as raspberry-pi os.
so we can repurpose it as a Media Center, Gaming Console, NAS, Smart Home, Small Server or a Mini Computer.
storage is low so we have to add some storage. I'm not sure how this is possible. except swapping the NAND flash Chip.
GOAL 1 : Extract Firmware and Extract Paid Decryption key which is use to verify the sat-in signals. ( a stb which don't required subscription to watch any tv channel )
i think they modified the software which capture the unencrypted signal and if we have a signal receiver then we are good to go. but for big companies wants to earn money so they added these barriers which needs decryption. and if the satellite is sending encrypted signal then we need to find the key. ( i know it's hard that's why we are here. I'll love to hear you thoughts on these)
Click to expand...
Click to collapse
I think we can utilize the usb port on the back to add the external storage, as the usb port is used for storing the TV recording (as far as I can recall), and for the uart part, we can also use it for accessing root shell in the initial step, to figure out the operation method and framework.
I don't have any idea about the encryption keys, it would be cool if there's a way for that.
I have the same STB, would love to repurpose the old box, what's your progress on this so far ?

If you have a multimeter, you can check if the pins are for UART, RX voltage would be very low, TX voltage would be fluctuating upon boot, check continuity for GND with any grounded part like the HDMI port shield or the AV port silver port, VCC would be 3.3 or 5 volts