Want a 64GB eMMC PineTab upgrade?

[Beagle]

A larger RAM capacity may be considered too, although very unlikely.

We've had similar feedback regarding the 64GB eMMC on Twitter, with approximately 80% of users agreeing selecting the 64GB option.
We'll let you know if its possible.

Personally, I agree that keeping the $99 price-tag is probably a better idea, but it seems that users are set to have more storage.

Thanks Luke for the open mind on specs.

I'm in the category where I'm keen on a portable device as spec'd out as possible. It would be great  to max out the SOC's RAM (which I understand is 3GB). Totally understand that this may not be a viable option, if you're trying to minimize cost and think this will impact take-up.

[InsideJob]

I'd rather have 16GB for OS development just because it's so much faster to backup and restore.

You can always make your partitions smaller and just block copy the individual partition devices.  As long as you make sure the partition table stays the same, things line up. 

A long time ago I used to do this to snapshot the bootblock, boot, and root partitions of some systems that had to be rebuilt frequently.  Since the layout never changed, I would just dd sda and set bs and count to copy to the end of the root partitions block.  As long as it was going back to the same device/block layout. recovery was just another dd call.

bs=512 always works since there's an abstraction layer between physical and logical, no math required. F2FS actually reports this after formating. Any number that's evenly divisible works when restoring and if you have plenty of free space at the end you can safely bs=1M or 4M (no math required again).

Anywho, I made an ARM64 build of Ubuntu 18.04 about a year ago for my Pi 3B and called it  PELinux64. I'll probably keep this one to myself though. 

Cya.

[z4v4l]

You can always make your partitions smaller and just block copy the individual partition devices.  As long as you make sure the partition table stays the same, things line up. 

A long time ago I used to do this to snapshot the bootblock, boot, and root partitions of some systems that had to be rebuilt frequently.  Since the layout never changed, I would just dd sda and set bs and count to copy to the end of the root partitions block.  As long as it was going back to the same device/block layout. recovery was just another dd call.

By the way, it's a very bad habit. It begs for troubles with GPT, that already is used by Rockchip for example (and broadly used on PCs). Partition table shouldn't "stay the same" on reinstantiations as per the specification, because every instantiation of a GPT partition should produce a unique GUID, not matching any other GUID on this planet. Once you reset the GUID, CRC changes etc. This is not the only reason, but it's enough to say that dd-ing is just lame here, and is the worst thing that one could think out. Because when you "snapshot" something and move it wherever, you put something else instead, and it will need to have the same GUIDs for partition IDs - wrong, or you need to change the GPT header and Partition Array (and their mirrors), which dd-ing of course doesn't do. It's easy to overlook this duplicating and end up with two systems having the same GUIDs for unique partition IDs. If you move on another SD card, things get even worse, well at least because GPT puts a duplicate of the GPT header and Partition Array on the end of the device. what dd-ing? While it looks rather innocent, sooner or later, it will give you lemons. Even now it's seen here, how people get their eMMCs "shrunk" "unrecoverably" because of stupid old utilities go nuts facing with GPT. One needs to either make "snapshotting" on the file hierarchy level or have some script/utility that would take care of proper reinstantiating partitions. Unfortunately, with this "just dd it" habit, it will be a long way to go until everybody gets these simple things.

[wood]

By the way, it's a very bad habit.

Acknowledged, I hadn't even considered that anything other than MBR partitioning would be used.  Thanks for the info.

[pine cone]

64GB is the absolute minimum.

[soupbowl]

Any more pictures of this tiny beast?

[Luke]

Any more pictures of this tiny beast?

Not yet, but I should have some soon.

[WilFree]

The value added by the increased memory is more than worth the small price increase. The 64 GB is needed to make this new product functional and competitive.

[Luke]

In case you haven't read: https://www.pine64.org/2019/06/06/june-2...d-pinetab/

Yes, the PineTab is getting an upgrade to 64GB eMMC at a slightly higher price (TBD).

[Watercourse]

We are considering upgrading the PineTab with 64GB eMMC. This would mean that it would mean it would retail for $99 ($118.99 with keyboard). Or would you prefer that we keep the original price of $79 with 16GB of eMMC ($99.99 with keyboard)?

Where do i sign up?
:-)