Computing desk
< October 24	<< Sep \| October \| Nov >>	October 26 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 25

Softcombing (Kuzhicombing), The Most Systematic Software Reverse Engineering Method

I wrote an article on "softcombing" and tried to put the article in Wikipedia. I could not find references. So the article is going to be discarded. How can I get references from the internet? There is a video clipping in YouTube on softcombing. But it is not acceptable to Wikipedia. Do I have to write a book on softcombing? Can someone else give references for me?

George Peter Kuzhikompil (talk) 09:33, 25 October 2014 (UTC)[reply]

If you invented this technique, then you should know if anything is published on the topic. For this kind of topic, a publication in a peer reviewed academic journal is where to write. But we would also expect that there is more than one writing on the topic to pass the notability criterion. Perhaps it has already been described by another name. By the way the draft is no where near deletion, Normally it would have to be abandoned for 6 months to be chopped. Graeme Bartlett (talk) 10:58, 25 October 2014 (UTC)[reply]

I sounds to me like what people have been doing since year dot in decompilers. You make a list of possible entry points and start disassembling from the first one till you get to a jump putting any new targets into the list as one goes. Rinse repeat. You need to do more though like spotting jump tables and method functions and function addresses passed as parameters for example to sort, and in old code there may even be overwritten code or there may be inline data after a call that the subroutine jumps over. Dmcq (talk) 15:42, 25 October 2014 (UTC)[reply]

External Memory

Why is it that some devices only support a limited amount of external memory? I have two 64GB SD cards, and neither of them works in my phone (Samsung Galaxy SIII mini) or my wearable action camera I use for cycling. They bot have to use a 32GB one. KägeTorä - (^影_虎) (Chin Wag) 15:34, 25 October 2014 (UTC)[reply]

Everything needs a software driver! Even the RAM on today's microscopic computer-on-a-chip needs a software driver, as mind-blowing as that is for most people who program computers! Storage devices like SD cards also need software support: the main computer cannot talk to it unless somebody programs in the specific language that the peripheral understands.

In this specific instance, the system doesn't speak the right language - but only for very large SD cards. The most likely culprits are either the file system or the device driver for the SD card interface. It is also possible that the storage configuration is malformed for this device, at a higher level of abstraction. Most probably, your devices do not support the SDXC protocol that is used for most cards with greater than 32 GB. Suffice to say, one or more software pieces are broken, but the exact nature of this problem is difficult to diagnose without deep inspection of the software and hardware on this device. This kind of software work isn't commonly accessible or fixable by nonprofessionals - even when the source-code is available!

As an example of the complexity, you can take a look at a free software implementation of an SD card driver, and try to decipher its inner workings. (I had an easier time finding good documentation and reference code for SD card drivers on Windows than for Linux or Android! And Apple makes a USB mass storage driver (with SD card support) available in source-code form, even though I'm not aware of any iOS devices that have an SD card slot!)

Instead of trying to fix it yourself, a better strategy would be to file a detailed bug report to your hardware vendor, so that they can actually track its occurrence and make a decision to prioritze a fix schedule.

Nimur (talk) 16:13, 25 October 2014 (UTC)[reply]

There's no SDXC protocol. The only difference between SDHC and SDXC is the file system (FAT32 vs exFAT). FAT32 supports volume sizes up to 2 TB at least, so there's no good reason for an SDHC-only device to reject a 64GB card if it's formatted with FAT32 (which is not to say they won't reject it anyway). If those cards are exFAT-formatted, you might even get them to work by reformatting them as FAT32. See this old thread for more.

RAM doesn't have drivers in a conventional sense. Main memory access is too much of a bottleneck to be implemented in software. Memory controllers are programmed by software, but that's nothing new. -- BenRG (talk) 21:37, 25 October 2014 (UTC)[reply]

The SD Association (the industry consortium that publishes standards for SD cards) publishes an SDXC standard. In addition to the file system, SDXC also has an entire set of new physical layer specifications, bus protocols, and software abstractions. These are summarized on the SD Association's website. Technical details for this standard are not available unless you join the consortium.

Regarding RAM: if you use any new hardware, it's probably standardized by the JEDEC. For example, the JEDEC standard for DDR3 is available at no cost to the general public: JESD 79-3D. That standard document explains the DDR3 specification for memory, including the mechanical and electrical design, and the standard software abstractions. Chapters 3, 4, and 5, standardize the software control for DDR3 RAM. Intel even published a white-paper showing a portion of their memory software architecture: Intel XMP white-paper, including a cartoon diagram of their software stack on both the MCH and the main CPU. This is but one of many software technology platforms that are common today. Depending on the type of computer and its operating system, those software pieces might appear totally opaque and invisible to the user - you might even choose to call them "hardware" if you don't know how they're programmed or where their software lives. But some of us do enjoy getting up to our elbows in system program software, recreationally and professionally!

Do you simply enjoy being contradictory, BenRG? I don't mind nitpicks - I'm a stickler for detail, and if I am wrong, I always appreciate that somebody corrects me... but when I am not wrong, I don't see why you choose to nitpick anyway. Nimur (talk) 23:43, 25 October 2014 (UTC)[reply]

Can you provide links (or at least info on how to get) to where the SD Association summarises the differences between SDXC and SDHC? I had a look at the link you provide and I couldn't find any mention of it. Actually all the info I saw supported what BenRG said which also concurs with my understanding of the situation. To be clear, I'm not saying you're definitely wrong, but if you're going to claim that there is a difference and the difference is mentioned somewhere other than only in details only available under certain conditions, it would be good if you could provide the evidence.

In any case, I won't comment on the rest, but it seems to me that BenRG had a very good point if they were correct and it's a point I myself have mentioned before, possibly somewhere on wikipedia but if not elsewhere. If the only real difference between SDXC and SDHC is the file system and capacity, then there's no particular reason why most SDHC devices can't support a SDXC card formatted with FAT32. Definitely it's known that many devices which only advertise SDHC support have no problem with FAT32 formatted SDXC cards. (To be clear, these devices don't necessarily support SDXC, as they may not be able to work with exFAT. Although some do, so you could say they are apparently compatible even if not officially compatible.)

This isn't to suggest devices can't have problems. Technically since the SDHC standard says the card size must be limited to 32GB, a device could either either not understand or simply refuse to work with such a card (although IIRC last time I checked, the standard also doesn't seem to say it has to). And there may be other reasons relating to the implementation why a device wouldn't work with such a card (e.g. the software was limited to working with 32GB partitions).

And while there have been numerous reports of devices working with SDXC cards despite only officially supporting SDHC, IIRC there have also been reports of some devices which wouldn't even when the card was FAT32 formatted.

It's perhaps also worth considering other factors. I believe some devices seem to have problems with newer high speed cards, e.g. UHS-II. While this is part of both the SDXC and SDHC standard, its introduction postdated the SDHC standard by a while so it's perhaps not so suprising some devices can't handle them (and I think history in many areas has show theoretical backwards compatibility doesn't always translate to practice). I think you're much more likely to get a SDXC card in such a speed, so you're unsurprisingly also likely to encounter problems (although it wouldn't be accurate to say the device doesn't support SDXC cards per se, since technically you can have a SDXC card that's speed class 2.

Incidentally, a significant counterpoint here is SD(SC) and SDHC. SDHC introduced a different way of reporting capacity etc rather than simply using more bits to allow a larger capacity. Therefore it's hardly surprising that a large percentage of SD(SC) devices don't work with SDHC cards. I believe there is some similarity with 4GB SDSC cards in that if you follow the 1.01 version of the standard, there's no reason why you can't have 4GB cards, except that the standard says they're limited to 2GB. (Note that there is an added complexity on that devices only supporting 1.00 may not work with 2GB or 4GB cards. As I understand it, this isn't simply the standard limiting the maximum, but a feature wasn't even implemented yet so there was no reason for devices to be expected to support it.)

Getting back to the OPs original question, even if it turns out BenRG and me are wrong about the standard, I stick by my other claim which was also mentioned by BenRG. Many devices which don't claim SDXC compatibility but only SDHC will have no problem with a FAT32 formatted card. Note an important point here, some devices, even though normally capable of formatting cards, may refuse or otherwise be unable to do so with a exFAT or SDXC card. So if the OP hasn't tried formatting the card in a computer or similar first, they may want to do so and confirm it doesn't work after formatting. (Since Windows refuses to format FAT32 partitions larger than 32GB, the OP will need to find ways how.) The fact that the device is nominally incompatible with SDXC or even the differences between SDXC may not be so important to the OP if their devices can actually work with the card, they just haven't worked out how.

I had a look around. It's difficult to find much since I'm getting a lot of stuff relating to the non mini (which I think official supports SDXC or at least 64GB cards). I did find [1] which may sound disappointing, but if you read the last post it sounds like they may have eventually gotten it working. Some more searching using quotes found [2] and h4wkst3p [3] find other reports of it working in a stock situation. (Unfortunately I still got a lot of junk posts such as people saying it doesn't officially support it so it won't work. Or the S2 which doesn't officially support it either has been tested to work with SDXC cards so it's better than the S III mini despite no evidence the the person has even looked for reports of the S III mini and SDXC cards.)

Nil Einne (talk) 14:52, 26 October 2014 (UTC)[reply]

Sure. Look at the Simplified SD specification. Chapter 3.6 includes the state machine for card identification. See how the state machine differs for various card types? That means a different set of commands are valid only for certain "types" of card. So, while "XC" refers loosely to capacity, its file system is not the only difference: the cards follow a different initialization sequence, and the controller must support extra capabilities in software and hardware.

Some enthusiasts have made SDXC cards "work" by formatting their file system differently. This is moot: some enthusiasts have powered a Corvette on vegetable oil. Almost anything is possible, but it isn't necessarily always going to work, so it's probably not the right choice for the user, nor is it necessarily good or sustainable long-term damage-free strategy for the machine!

As I mentioned earlier, the best thing that our OP can do is to send a bug-report to his hardware vendor with as many details as possible. Nimur (talk) 15:34, 26 October 2014 (UTC)[reply]

That's version 2 of the spec, which predates SDXC. If you look at version 3 (Part A2 Simplified from here), the flowchart box that said "High Capacity Ver.2.00 Card" has been relabeled "SDHC SDXC". There's no logic to distinguish between them. Searching for SDXC in the rest of the spec, I do see one potential source of incompatibility at the host controller level: SDXC cards are allowed to take 500ms for write operations, versus 250ms for SDHC. Normal write times are far shorter, but if a card did occasionally exceed 250ms, it could lead to timeouts and write failures on an older controller. -- BenRG (talk) 22:34, 30 October 2014 (UTC)[reply]