Hacker News Reader

Comment by userbinator | Hacker News Reader

Given the compatibility between SD/MMC, one thing I'd like to see on the market, but haven't, is an Android phone which has no "internal storage" to speak of, but instead replaces the soldered-in eMMC with a microSD socket. That would make expanding, brick-recovery, as well as backing up and controlling access to the data very easy; like taking the hard drive out of a computer before giving it to someone else.

It's not difficult at all to do from the hardware perspective, but no one seems to have produced such a thing on the mass market.

View on HN

You dont need a hw mod, all you need is an Android phone with a sdcard slot and the option to do raw read/write to the embedded flash from the bootloader as you WILL fuck up many times during experimentation. Havent tried with qualcomm stuff, but successfully converted my Mediatek-based CAT B15Q to sdcard-only.

All you need to modify is /etc/fstab, /init.rc (or, in some cases, /init.XYZ.rc), split the sdcard into three partitions (OS, /data, /sdcard), copy the existing partitions from flash to the sdcard et voila.

Actually, now that I think about it, there was an Android Tablet that had some common mods to do this. The ASUS TF101 had incredibly slow internal storage.

A number of ROMs supported "inverted storage" that put the main OS onto the SD card for performance reasons.

To a lesser extent there is Link2SD:

https://play.google.com/store/apps/details?id=com.buak.Link2...

If you have rooted your device, and partition your SD card, it can mount one such partition so that it supplies the app storage.

and the option to do raw read/write to the embedded flash

To use PC bootloader terminology, that's chainloading. The SoC still starts from internal storage first, then switches to SD. My comment was about making a phone without internal storage at all, i.e. SoC boots directly from SD.

To continue that analogy, you still need a BIOS

All ARM SoCs to my knowledge know enough about their peripherals to get a bootloader off an SD card, so the BIOS/first-user-replacable-code-to-run could easily come from there instead of the storage that's soldered to the motherboard.

It's not magic -- the SoCs have code stored in ROM or some external peripheral for initialization.

Aha! Surely this turtle is the bottom!

I would love to read more about your experiments! any chance for a blog post?

If you have root, just replace init with something like that:

    #!/bin/sh
    mount /dev/mmcblk1p1 /root
    exec chroot /root /bin/init

although you probably want `|| sh`

It's spread somewhere either on xda or some obscure german board. Let me see if I can find it in the evening, I'll reply here when I find it.

Any idea if this could work on any of the hardware CopperheadOS supports (Nexus Pixel) in order to support dual booting easily with vanilla Android?

eMMC is actually really different than SD in ways that matter for mobile devices. For example, eMMC supports a very low level hardware booting sequence (boot ROMs on SoCs can clock in data without needing a driver to initialize the eMMC device). Software drivers for MMC and SD add a lot of complexity. They need to query the device determine if it is eMMC, MMC, SD and then query the card status and properties and support quirky cards. MMC and SD have different specifications and initialization state machines (even though there is some overlap). I am not even going to mention secure boot. This is way much more complex than you might think.

For example, eMMC supports a very low level hardware booting sequence (boot ROMs on SoCs can clock in data without needing a driver to initialize the eMMC device).

I know about that feature but the SoCs that use it are usually very primitive and not those in smartphones and the like, which have a much more featureful boot ROM. Keep in mind that even the Raspberry Pi can boot from SD, and that's not even a very powerful SoC. The MTK SoCs which I'm more familiar with have a boot ROM that supports booting from (e)MMC/SD, NAND, and USB/UART (for recovery). TI's OMAP series are similar:

http://processors.wiki.ti.com/index.php/OMAP-L138_Preparing_...

Freescale/NXP i.MX can too. The Novena has no soldered storage at all.

even if you get past all the issues that spicymaki mentioned, you'd still run into the issue that most sd cards have absolutely atrocious performance for being used as something like the boot drive for a computer. even the good micro sd cards are pretty terrible compared to the internal storage in your average smartphone.

if using a really slow tablet or phone appeals to you, roll your own tablet with a raspberry pi, touchscreen, battery, and micro sd card.

The problem is solved if you just put a signed verifying bootloader (incl. TPM) on one and use full disk encryption and the real disk for the rest.

Put in some normal install too and here you have a device that can be cursory checked by TSA.

The problem with this approach is that the flash chips that get used in SD / microSD cards are really bottom of the barrel stuff. It's going to be painfully slow and is practically guaranteed to crap out on you eventually if you use it as a primary volume for long enough. They're built to be as cheap as possible, and last a few hundred cycles of getting filled with images and erased, not thousands/millions of tiny writes.

Raspberry Pi users can probably attest to this.

I had a phone that (almost) worked like this way back in 2010. It wasn't an Android phone though, Dell Venue Pro running Windows Phone 7. All the user-facing storage was in the form of an SD card but there was actually a smallish amount of onboard storage that was used to flash the OS image when you inserted a blank card. There was also some sort of device-specific encryption key preventing you from moving cards between phones without reformatting.

That would solve the TSA search issue. Just carry two microsd cards.

I would happily buy such a device with cold hard cash, phone or tablet (or both!). I wonder how much more likely this would make devices easier to install alternate OS' on top of?

Funny to read this, as the original scheme for Android was the OS and apps on emmc, user data on SD card.

But then later some OEMs came up with partitioning the emmc and mounting one part in place of the SD card.

Later still Google codified this hack by mounting a vfat union mount on top of a directory in /data as if it was the SD card.

All in all Android storage is a tire fire of hacks.

The Dell Streak had an internal SD card. I've also seen some cheap Android tablets which do the same.

I would purchase one of these without hesitation.

On smaller or older computers I do all work in RAM via tmpfs and mfs. I only use removable external storage for storing bootloaders, kernels with embedded filesystem and a small archive of custom software.

If I have enough RAM I can chroot and install some distribution from the internet or from some larger capacity external media, but thats optional.

Reply on news.ycombinator.com