Related
...............................
I'm not sure but I think it needs special tools... at least a lot of other PPCs do.
So it is possible??
I want to upgrade my 6700 to the 6800 but the lack of RAM has going for the Touch, I don't want to give up the keyboard and wifi but it seems worth the sacrifice. But if it is possible to upgrade the RAM on the 6800 well that changes everything.
Could someone with experience pls give some feedback on the matter.
Thanks
Yes it is posible everything is posible I'm not an expert means I'm not an ingenier but I'm IPC 610 Certified I Know A+ and Network + and more..I have work directly with ingeniers developing and designing all kinds of mother boards I kow the tools needed and I also know that may be we will need to buy a hi amount of chips to the fabric I am intereste in kowing if any one can tell me before boyding my waranty what it is the exact chip and who is the vendor so I can start working with some of my friends soldering and unpgrading the RAM...
you need to be able to reliably solder mBGA components and be able to modify the bootloader/kernel to use that amount of ram
I know How to soler SMT componets... that is not a problem I worked as QC inspector of SMT components....
how did you manage to transpose your accent in your post?
I think the possible destruction of your Device is not worth the hassle... but you're welcome to try.
Do tell if you manage to pull it off successfully
Yeah, it is possible. Since you seem to already know about SMT rework and have access to proper tools, there's a fair chance you actually succeed. To get the proper chip you would probably need to open up your device and see the part number of your current RAM chip and search for its datasheet. Based on that, you'll need to choose exactly the same kind (same memory type, same timings, same pinout, preferably the same manufacturer) of memory, but of bigger capacity.
There are even some companies offering PocketPC upgrade service (just run a google search for PocketPC RAM upgrade).
And as far as i know, WinMo will use the bigger ram chip without any bootloader/kernel modifications, just like your PC (at least a winCE 4 Simpad did) - but you'll need to do some more research here since i never tried it personally and can't guarantee anything.
Unfortunately, BGA chip type limits you to 128MB ram (as far as i know, it's the biggest capacity you'll get in a single chip). In case of SOT/TQFN memory it was possible to solder a second chip on top of the old one (however i don't remember the exact details), therefore doubling the RAM size. Obviously, it's not possible with BGA, and even if it was, there's simply no room for that inside a modern device
Hi,
as i wrote in another thread, i purchased a bricked A101.
There's no response from the system so i decided to start investigation on the hardware .
A101it chipset information:
Processor
• Ti OMAP3630 (515-pin CBB/P BGA package) ARM Cortex A8 at 1 GHz with DSP
• POWERVR SGX530 Graphic accelerator: 3D OpenGL ES 2.0
Memory
• 256MB LPDDR SDRAM (168-pin PoP BGA package) soldered on top of OMAP3630
• 8/16GB eMMC (169-pin BGA package) connected to OMAP3630 internal mmc2 interface
Interfaces
• USB slave 2.0 (OMAP3630 internal interface, MicroUSB connector)
• USB host interface (TPS65921 host interface, TYP A connector)
• Micro SD slot (OMAP3630 internal mmc1 interface, SDHC compatible)
Display subsystem
• ChiMei 10.1" TFT-Display N101L6-L02 (18Bit-LVDS interface)
• Ti SN75LVDS83B LVDS transmitter (56-pin BGA package)
Touchscreen subsystem
• Pixcir capacitiv touchscreen unit (TR16C0 controller, USB interface)
• Ti TUSB2551A USB transceiver (16-pin QFN package)
HDMI subsystem
• NXP TDA19989AET 24-Bit HDMI transmitter
• HDMI output (19-pin Mini HDMI connector)
Communication
• Ti WL1270/1 WiFi (802.11 b/g/n)
• Ti WL1270/1 Bluetooth 2.1 EDR
Miscellaneous
• Built-in speaker
• Built-in Microphone
• Freescale MMA7660FC G-sensor
• Omnivison OV7675 VGA camera (0.3M)
Power source
• Ti TPS65921 power management chip
• Intersil ISL9220 LiPo charger
• Internal: Lithium Polymer battery
• External: 5V/1A Power adapter/charger
To get some detailed informations about these chips, i made a sweet datasheet collection.
Grab the zip-file here.
TBC...
EDIT: The brick issue is solved.
The platform did not boot up due to a broken connection to onboard RAM.
This thread will present various hacks and other stuff a geek might have fun with
Read on for some more information.
So here's my first result:
I successfully located the sys_boot signals of the OMAP3630.
I made a first test by changing the default boot mode.
With sys_boot5 pulled high the boot order changes to peripheral boot first.
In other words you may use this tool to directly access the OMAP memory (e.g. RAM).
In theory it should alos be possible to boot the device form external microSD as well, but at factory default the microSD slot is covered by power management. In other words, power is switched off at boot time.
This could be hacked as well
My attempt will be to un-brick my device by using external boot mechanism.
Maybe i'll need some help at a later point!
EDIT: Peripheral boot modes had successfully been verifed.
It definitely works on the Archos 101. Perhaps this may be useful for some open bootloader project.
Aynway, i already discovered some other things, that might be helpful for hardware hackers. So if you are kind leave a comment or ask some questions.
Stay tuned!
scholbert
Oh, that's interesting ... I don't know anything about hardware hacking but I'd like to learn hope you will show us ... keep on the good effort ... and I'll keep an eye on this tread .... might come handy ... jejeje
sounds great, keep on rolling
peripheral boot
Hi,
thanks for your replies.
So as expected using peripheral boot over USB/UART is working (sys_boot5 pulled high).
At least the ASIC ID is send correctly and the initial communication starts.
See the screenshot attached.
Flash V1.6 also got a eMMC driver included.
So this could be the way .
Right now there's an error message:
Code:
Unknown status message 'dKAYd 2nd stdrted?' during peripheral boot (waiting for 2nd)
I guess the response should be: OKAY! 2nd started?
EDIT:
MMMh strange... i'll have to find out who is generating this message.
If it is comming from OMAP the SDRAM setup should be verified.
Seems that the LSB byte stuck @ 0x64.
Code:
dKAYd 2nd stdrted?
ascii = dKAY -> hex = 0x59414b64 (msb..lsb)
ascii = d 2n -> hex = 0x6e322064
ascii = d st -> hex = 0x74732064
ascii = drte -> hex = 0x65747264
ascii = d? -> hex = 0x00003F64
See the session log file for more details!
Anyway i justed started to play around... maybe some tweaks in the configuration are needed
Have fun!
scholbert
Pretty Cool
Thanks for attesting coolness
Made some further tests... though my time is really limited right now.
I found out that the message is send from 2nd loader which is used for Ti's Flash tool.
So this might indicate that there's something wrong with my memory or memory bus.
I re-checked the RAM setup sripts for the Ti tool again but could not find any error. Reduced the timing as well. Still got that message...
It's very strange that the pattern really seems to stick, which is unusual for damaged memory... i will report further findings.
Anyway this is open discussion, feel free to post
Cheers,
scholbert
Nice try. Can you tell us about the RAM, it's built in the mainboard or changable?
We already know that, it's built-in ^^
(some have opened their Archos before ^^)
trungvn1988 said:
Nice try. Can you tell us about the RAM, it's built in the mainboard or changable?
Click to expand...
Click to collapse
http://forum.archosfans.com/viewtopic.php?f=74&t=42806
Soldered on, not changable by anyone with home soldering tools. Very small ball soldering. I gave it an attempt, even got a replacement 1GB RAM module as a test piece... Didn't work out well for me.
I'll definitely be keeping an eye on this topic, seems like some good information might come of it.
.............yippie yeah it's working out!!!!
Thanks for the feedback
First i'll have to quote myself:
It's very strange that the pattern really seems to stick, which is unusual for damaged memory... i will report further findings.
Click to expand...
Click to collapse
Guess what...... it's fixed!!!!!
I really go crazy. See attached log file.
External boot over USB and 2nd loader started up successfully, using the Ti tool.
So RAM is working now!
This definitely saved my day...
What happened exactly?
As i pointed out, the data on memory bus stucked at 0x64, so i assumed there was an issue with DQM/DQS signals on PoP memory.
See some related documents about the function of these signals on RAM chips.
The DQM/DQS where not toggled in the right way because of bad soldering at the PoP memory chip.
See the attached pic for the excact position of these signals (marked in red).
The chip itself is soldered on top of the OMAP3630.
In the end i used a hot-air solder gun and soem soldering flux and fixed the broken connection. In fact i used this "technique" some time ago to fix a "No GSM" issue on HTC Hermes.
Though i'm very excited right know, i'll have to make a break for today, because i have a date
Harfainx said:
I'll definitely be keeping an eye on this topic, seems like some good information might come of it.
Click to expand...
Click to collapse
Yes i'll try my very best
Kind regards,
scholbert
Guy, it's so nice! Keep up the good work!
datasheet collection
Hey,
i was lucky last week. My device is up and running.
Fortunately the eMMC data structure was O.K. In the end my device refused to boot, because of that broken connection to the RAM.
So there'd been no need to fiddle around with eMMC for now.
Maybe i'll do some investigation at a later point.
Feel free to set up your device for peripheral boot and try the Ti Flash tool debugging possibilities.
Right now i decided to re-assemble the device and use it for a while.
I must assume that i know nothing about the internal structure of the firmware. So it would be essential to get some insights
I got some additional information about the eMMC/microSD data lines.
If there's some interest i might post further pics.
To get some background about the chips on the A101 mainboard, i collected some datasheets of the main components.
Grab the zip-file here.
Most of them are easy to find other's are not
Anyway, saves your time i guess.
BTW, is there any tool to unpack gen8 AOS files?
Regards,
scholbert
yes it would be great if we could find one, maybe we could find a way to get inside and change some things
scholbert said:
...
Most of them are easy to find other's are not
Anyway, saves your time i guess.
BTW, is there any tool to unpack gen8 AOS files?
Regards,
scholbert
Click to expand...
Click to collapse
As far as i know we can't extract aos files since they are encrrypted and we don't have they proper KEY - its saved inside the device somewhere
But good luck with going on! Rly sounds interesting who knows what it's good for in future
good news - check out:
http://forum.xda-developers.com/showthread.php?t=1214674
seems we got a way to extract soon
..... uuuh great!!!
FrEcP said:
good news - check out:
http://forum.xda-developers.com/showthread.php?t=1214674
seems we got a way to extract soon
Click to expand...
Click to collapse
Yupp, that's awesome. I just joined that thread.
In the meantime i disassembled my device again, because i want to spent some more time on research.
I found out some more details about the chips and the design in general.
The A101 seems a pretty neat device for extensive hacking, because archos did a good job and made a very clear design.
I started to prepare a pin map by looking at the kernel sources again.
Maybe i'll be able to find some other useful testpoints on the mainboard (e.g. UART2)
As you might know, the touchscreen is connected to USB using OHCI mode.
To attach it to the OMAP ports they also used a chip from Ti.
See this datasheet for more information:
http://focus.ti.com/docs/prod/folders/print/tusb2551a.html
If i'll find some time i'll try to make kind of a floor plan from the mainboard and post some pics as well.
P.S.: If someone knows the manufaturer of the speaker drivers, please tell me! The parts are marked as 8JAM892 and are located near the soldering points for the speaker.
Keep on hackin'
scholbert
What I would like to find out is what component it is that dies when the USB port fails (and it stops sleeping as well). Maybe it's replaceable (if you can do SMD soldering).
pbarrett said:
What I would like to find out is what component it is that dies when the USB port fails (and it stops sleeping as well). Maybe it's replaceable (if you can do SMD soldering).
Click to expand...
Click to collapse
Mmmh... without being affected by this issue it's hard to tell.
If the port dies, there could be many reasons of course.
Maybe the 5V power supply for Vbus is dying on these devices, due to "over-current" issue. I have not identified that part right now.
The signal lines itself usually won't be harmed... apart from injecting ESD pulses right to the connector.
The USB host port is directly connected to data lines of the USB PHY inside TPS65921 (Power Management chip).
OMAP3630 itself uses ULPI mode to connect to this part.
That's all i could say for now.
Regards,
scholbert
FrEcP said:
good news - check out:
http://forum.xda-developers.com/showthread.php?t=1214674
seems we got a way to extract soon
Click to expand...
Click to collapse
If we can't extract those AOS files - how are custom ROM builders such as $auron getting their hands on the upper layer of the firmware? I know I am not expressing myself technically correct, but what I understand is that for instance $auron's UrukDroid is a custom Linux kernel etc. with on top of it the modules, GUI etc of the official Archos packages...
you don't need to extract the aos file to get the filesystem of the archos android. you simply have to root your device or just install angstrom (which comes with SDE) and then you can copy the squashfs file to your computer so you can extract whatever you need. it's not encrypted but signed, you only have to skip the first 256 bytes (if I remember correctly) of the file to get a valid squashfs image.
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.
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
I have a DishTV s8100-zc, wich is the branded name of what I think is a msd7s75 board with a Mstar CPU.
What I want to do with it is to flash it with something that isn't the stock NZ firmware (locked to use freeview apps, which is now defunct), anything modular would do bsd running kodi for instance, but some flavour of android would be best. I know this board can run android TV because I've seen new devices with the same board being sold new with android on them (from alababa of course, so no useful information to be had there). It can be flashed via a rom file on a USB stick.
The first step here is to identify what the soc in this thing is - I know it's an Mstar, by after that I'm a bit stumped. Is there any way of finding out? Or is there a rom that works on all (or even most) Mstars I could try? I can't look directly at the chip because it has a heat-sink glued to it and I don't want to damage the chip trying to remove the sink.
Any thoughts would be apreciated - thanks!