Search results

Before anyone asks, yes, it can run ingress. But due to the display size, it's not usable. (although, having ingress installed means I get notifications, which is a bonus)

sorry - should have mentioned. It's nominally 240x240, ldpi.

Chainfire, I've just recently taken delivery of my Omate TrueSmart smartwatch - nice device so far... Anyway, the prompt dialog from SuperSU is 'too big', so I can't actually see the allow/deny buttons (See attached image). Would it be possible to create a reduced size dialog for small...

Roku Remote please?

Ahhh.. yes, I understand where you're coming from then. Here's another theory: buggy wear leveller hits a certain threshold where it starts overwriting critical blocks on the eMMC. The first few start to cause the behaviour you saw, until a few later, a super critical block is overwritten that...

Right - I assumed (probably incorrectly) that BL updates can be performed from OTA updates as well. Earlier, when you stated "WHAT'S THE PROBLEM" - this is it - we don't know if historic usage has any bearing on SDS. It either: 1) does and previous 'bad wear' cannot be corrected by a fix 2)...

Oranav, could you use the same read function that's used to fetch the firmware date to read the entire firmware (while in the vendor specific debug mode)? or is that what the code you've found does? How did you get on?

@rootSU: I'm not trying to pick on you, honest! I also don't think you can say that either. We know next to nothing about what the fix to the eMMC firmware does, and if it's a bug like Entropy512 describes, then your analogy falls down flat - it'd be like you are still being exposed to...

Right, I understood that, but the point still stands - we can't actually definitively say that there is more than one date on those chips - so it's safer to say "Unknown, but assume you're vulnerable.", rather than "some chips are not affected". Since we cannot (currently) retrieve the date in...

[Please excuse the excessive quoting, but I think it's needed for context] Try reading Entropy512's post on this subject. Basically, the wear will still occur, but at a certain point, the amount of wear will not trigger a bug in the eMMC firmware with the soft-fix applied.

Where did you get that idea? ---------- Post added at 07:54 PM ---------- Previous post was at 07:39 PM ---------- I don't think you can actually say that - I find it hard to believe that a given FW Rev would have more than one internal date - or that this bug only existed for one potential...

Fw Rev Fx1 is not valid. The revision is in hexadecimal, which is represented by the characters 0-9 and A-F. The first two characters are usually "0x", which helps to disambiguate between hex and another number base. (for example, "23" vs. "0x23"). So, to answer your question, the...

Yes. Same key combination to enter stock recovery as custom recovery. It's the bootloader that does that (starts recovery or download based on key combinations)

Oh, good point. So, we'll need an updated sboot at some point, or it'll be a risky endeavour to upgrade the OS via non-OTA means.

Certainly possible that the fix in the stock kernels has been through a few revisions before getting to ELLA/Update7.. probably need to trawl the whole thread to try and find definitive examples of SDS on previous kernels. Personally, I think that this 'fix' isn't the one we're looking for...

yeah - from byte 0 up to (but not including) the gzip header of the resulting boot.img-kernel file generated by split-bootimg.pl. You can just edit boot.img directly as explained by Rob if you wish. Basically the boot.img file is a combination of a compressed kernel and an initrd (also...

If it was a random/probability thing as you suggest, then failures would be seen infrequently from day one, at a fairly steady pace. Since failures are coming thick and fast now, it's more likely to be a bug in the wear leveller as described by Entropy512. This would mean that your last...

As has been said MANY times already, Charging has nothing to do with SDS. It's common for it to happen during charging because it holds a wakelock, and your phone can be active while charging (so, in essence, it's busier while charging than when you're using it). This is what I've been telling...

I think you should both read this post carefully

You've completely missed the point - it's not to avoid upgrading, it's to find out if the fix has been in place for longer than we thought. This could mean that the fix doesn't actually solve the problem.

Did you check the model/fwrev of the emmc chip?

No worries, I was actually a bit confused about why you got that muddled, so you don't need to back up your experience ;)

I think you're confusing sboot with boot.img. sboot is the bootloader, which is largely irrelevant - boot.img is the image used to flash the boot partition, which contains the kernel and initrd for your phone for day to day use. recovery.img contains a kernel and very cut down initrd with the...

What's your reasoning for saying that? ---------- Post added at 10:10 AM ---------- Previous post was at 10:07 AM ---------- No. It makes small changes to the firmware when the eMMC is initialised at power on and resume. Nothing more.

Good.. I think the patch is complete too, but my concern is that we just don't know if this is addressing SDS, another fault, or just part of SDS and there is actually more to the problem than what this patch is "fixing". I only say this due to finding the strings in the patch in older...

It appears the fix is in some older kernels too, but there has definitely been instances of SDS on those, so it's possible that the fix found in update 7 is not the whole story.

Yep, I'm sadly thinking the same thing. I've PM'd both AndreiLux and Entropy512 bringing this to their attention.

It's deep within the code for the fix: date = ((data_buf[327] << 24) | (data_buf[326] << 16) | (data_buf[325] << 8) | data_buf[324]); if (date != 0x20120413) { err = -1; return err; } ---------- Post added at 11:47 PM ---------- Previous post was at 11:47 PM...

Same process as I. Good stuff. ---------- Post added at 11:44 PM ---------- Previous post was at 11:43 PM ---------- Then says he had a Siyah kernel 3 posts later: http://forum.xda-developers.com/showpost.php?p=36390137&postcount=2445

Absolutely not, I'm saying that it has the strings associated with the supposed SDS fix. Given this, I don't think this fix will help, or - perhaps - the date restriction in the code is too restrictive, and more than that date of the firmware revision is affected. Only samsung knows for sure...

The Kernel is compressed - so you need to extract it out of the boot.img file so you can decompress it, and then search. I don't know if you did this, but my recent check suggests that XXALF5 won't have it anyway.

Ok, both XXELKC and XXELL5 from perka's file stash have the strings associated with the patch. The only other kernel there is XXDLJ5, and it doesn't have the strings. If anyone can provide me with the boot.img file from anything in between XXDLJ5 and XXELKC, I can check them.

No, because I don't have copies handy. But good point. I'll see if I can find a couple and check.

The patch to the MMC driver discovered in the Update 7 sources released by Samsung performs a procedure that is nearly identical to the fix for another mmc firmware bug in a different samsung device. The patch also includes some character strings which can be searched for in the binary kernel...

No, VTU00M / 0xf1 is what matters. You are vulnerable. You only need to get an updated recovery if you plan to use it for flashing or making nandroid backups/restores. For day to day usage of your S3, XXELLA should be fine.

F and f are the same thing in hex. So yes, you're affected.

No, it looks like ELLA has the fix. It certainly contains the strings used in the patch applied to Perseus.

I'd hazard a guess that it does - but I'd certainly like someone like Entropy to weigh in.

I've just done this, and can confirm that the XXELLA kernel does include this string.

Yes, I'd say you could assume that. Although it's highly unlikely that other chips are affected.

Recoveries have kernels too, so that kernel needs the patch.

Just FYI to the thread, by my reading of the Update 7 sources, It's definitely the VTU00M/0xf1 chip that's affected.

No, not if the fix is a workaround in the mmc driver, or a run-time patch of the firmware (that needs to be applied at every powerup).

Occam's razor.

Right - I probably will, but first waiting to see what he commits to his git repository! And I was really referring to the timeline from when Samsung initially acknowledged the problem, not from when I posted. Exciting times!

eMMC dev permissions makes no sense, as it's exynos-mem permissions, which isn't to do with the eMMC. He was referring to SDS as well, as the fix is likely to be kernel based, not bootloader. There's no evidence that the fix will be from the bootloader (and why would it? the function of the...

Oh, I don't believe they are either - just a conceivable theory, that's all.

Yes. My condolences.

Sure, they managed to mix it up - but I guess it's conceivable that the two are actually linked - that SDS is the result of some malware that's using the exynos-mem exploit. My curiosity around this theory is the injection vector. It is entirely possible that all those that have experienced SDS...

I will wait a day or two, possibly until I get a random reboot. But yes, I will report back when/if I do.