rmoriz
-
Posts
28 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by rmoriz
-
-
On 5/12/2018 at 3:18 PM, jock said:
Backup:
First we determine the size of the eMMC flash memory
./rkdeveloptool rfi Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 7393 MB Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash<0>
in my case the size of the memory is 7393 Megabytes, so you can the command to retrieve the data:
./rkdeveloptool rl 0x0 $((7393 * 2048)) backup.data
this will download the original firmware in backup.data file in less than five minutes.
Restore the original firmware:First we have to restore the original bootloader. Running these commands will do the job:
./rkdeveloptool db ../rk32/rk3288_ubootloader_v1.01.06.bin Downloading bootloader succeeded. ./rkdeveloptool ul ../rk32/rk3288_ubootloader_v1.01.06.bin Upgrading loader succeeded. ./rkdeveloptool wl 0x0 backup.data Write LBA from file (100%)
How one can backup the existing bootloader? Where does "rk3288_ubootloader_v1.01.06.bin" come from?
-
16 hours ago, wdtz said:
I have H96 max+,32gb, board is same, wifi is sv6051, no bluetooth
Like you, most of the dtb give root fs not found, no /dev/block/mmc.... ,, or
for the android versions a black screen, serial shows only a few lines of kernel load (<5)
--edit--
you can make it work by writing image to both a uSD card and a usb stick,
it will probably find the stick and run from it. The uSd can be small and slow
Not so good with only 2 usb sockets
They are not the same, as my 64GB version has another radio chipset. There are at least two hardware versions out there, and there are different android firmware releases. One is "SSV6051_RTL8189" the other one is "HS2734".
-
H96 Max+ (4/64) (Original Posting)
- UART (see Image)
- serial output default booting android firmware: https://gist.github.com/rmoriz/6b01009ea62edfa9e58c5b9729eeabd2
I've found some stock firmware upgrade files, trying to squeeze some usable stuff using "binwalk".
-
Hi,
got a H96 Max+ with 4GB and 64GB eMMC today (https://www.banggood.com/H96-Max-Plus-RK3328-4GB-RAM-64GB-ROM-Android-8_1-USB3_0-5G-WIFI-TV-Box-Support-HD-Netflix-4K-Youtube-p-1335810.html?ID=533601). It's booting Android 8.1 with a kernel 4.4.120, build date 2018-12-18.
I opened it using a GB-5A opening tool. Attached are some pictures.
1. PCB is labelled as "RK3328_8D4_V1.1" with date "20180703"
2 .Wifi/BT chip seems to be:
HS2734A V15628 98MA
3. eMMC seems to be Samsung:
SEC525 B031 (unreadable due to QA marks)
I flashed Armbian_5.68_Rk3328-tv_Ubuntu_bionic_default_4.4.154_20190110.img from your mega account to an microSD card.
Tried all rk3328 FDTs in extlinux.conf
# Result: LABEL=ROOTFS does not exists + drop to busybox
rk3328-box-trn9.dtb
rk3328-box-z28.dtb
rk3328-box.dtb
rk3328-evb-100m.dtb
rk3328-evb.dtb
rk3328-mx10.dtb
rk3328-roc-cc.dtb
rk3328-rock64-android.dtb
rk3328-rock64.dtb
rk3328-rockbox.dtb# Result: black screen/crash?
rk3328-box-liantong.dtb
rk3328-evb-android.dtb
rk3328-t9-android.dtbThanks
Roland
-
On 2/6/2019 at 10:54 AM, Igor said:
This https://lkml.org/lkml/2019/2/3/422 was just included. Perhaps it will solve those problems?
Happy New Year!
Just built and tried Armbian_5.75_Orangepizeroplus2-h5_Debian_stretch_next_4.19.20.img using U-Boot 2019.01 but had no luck. Still hanging after "Trying to boot from MMC2"
-
@martinayotte custom built Armbian_5.74_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.19.17.img with U-Boot 2019.01 sadly hangs at the same point as the 2018.11 release:
U-Boot SPL 2019.01-armbian (Jan 30 2019 - 13:08:51 +0000) DRAM: 512 MiB Trying to boot from MMC2
@Igor I've contacted "zhao_steven" via mail today at 13:05 UTC providing a screenshot of my AliExpress order and a summary of the thread including a link.
-
47 minutes ago, martinayotte said:
Strange issue ... Could you provide picture of the eMMC ?If it differ from the one on all forum members's boards, like mine, it is maybe a new eMMC chip not supported yet by U-Boot, but still strange since it is working on a already booted kernel.
I think this is the eMMC:
upper side just for reference (says V 1.0)
Thanks!
-
I've built a custom image using the docker method (result was named Armbian_5.73_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.19.17.img), etched it to SD, booted and installed it to eMMC.
Result:
U-Boot SPL 2018.11-armbian (Jan 28 2019 - 23:02:45 +0000) DRAM: 512 MiB Trying to boot from MMC2 (hangs, no LED, serial output)compared to the behaviour of the release image (as mentioned in my opening post already)
U-Boot SPL 2018.05-armbian (Jan 12 2019 - 18:49:16 +0100) DRAM: 512 MiB Trying to boot from MMC2 (looping) "Synchronous Abort" handler, esr 0x8a000000 elr: 0000000000016895 lr : 0000000000016895 x 0: 0000000000017718 x 1: 0000000000000500 x 2: 0000000000000001 x 3: ffffff80ffffffc8 x 4: 0000000000000001 x 5: 000000000000004a x 6: 000000004fdffba8 x 7: 000000000000000a x 8: 0000000000000044 x 9: 800303d600000000 x10: 9419820400000000 x11: 000000000000000c x12: 4028177e0007fffe x13: 02042420a1fe8820 x14: 1c4401836c41c200 x15: 0012010004200000 x16: 102520254a2c0844 x17: 0c03fc405001bb46 x18: 000000004fdffe80 x19: 0000000000000022 x20: 00000000ffffffc8 x21: 000000004fdff0f0 x22: 000000000001717b x23: 000000000001717b x24: 000000004fdff0b0 x25: 000000004fdff5f1 x26: 000000004fdff0b1 x27: 0000000000000030 x28: 5e0f2289281c052c x29: 000000004fdff410 Resetting CPU ... resetting ... (/looping)PS: Yes, I've set verbosity=7 and console=both as before, by manually mounting the emmc filesystem and chaging /boot/armbianEnv.txt. There is sadly no change in outcome/output.
-
3 hours ago, guidol said:
To be sure I did compile this evening the actual (of today) DEV-version:
Armbian_5.73_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img
Flashed it to sdcard via etcher - and after a little bit configuring - I transfered it (using a Samsung EVO 32GB) to the eMMC
without problems:
ARMBIAN 5.73 user-built Debian GNU/Linux 9 (stretch) 4.20.2-sunxi64 Linux opi-zero-plus2-h5 4.20.2-sunxi64 #5.73 SMP Mon Jan 28 20:12:49 +03 2019 aarch64 GNU/Linux Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf udev 178024 0 178024 0% /dev tmpfs 49292 2308 46984 5% /run /dev/mmcblk2p1 7370336 1268920 5707308 19% / tmpfs 246448 0 246448 0% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 246448 0 246448 0% /sys/fs/cgroup tmpfs 246448 4 246444 1% /tmp /dev/zram0 49584 3136 42864 7% /var/log tmpfs 49288 0 49288 0% /run/user/0
Did you remove the SD card? Does it boot without the SD-Card?
-
4 hours ago, martinayotte said:
I hope you don't use the same method used for installing eMMC using a Non-Armbian image with Armbian one which is "nand-sata-install".
As I said earlier, on my OPiZeroPlus2-H5, I've installed Armbian on eMMC successfully several times since years and last time was 2 weeks ago with 4.20.y.
Did you have done what I suggested, first :
Then, for the fourth time, did you have done :
If really Yes, what was the results ? When rebooting without SDCard inserted, do you see any u-boot activity ? Is it starting booting the kernel ? if Yes, what is the output just before it abort and reboot in loop ?
Does it says that it can't find RootFS with proper UUID ? Did you check if UUID are properly set in both /boot/armbianEnv.txt and /etc/fstab of the eMMC (not the one from SDCard) ?
None of the above, since it works for all of us, and you seems to be the only one to get such failure ...
I know, I posted a lot, so I'll summarize it quickly for you:
The remaining issue with Armbian is the "CPU reset" loop after a nand-sata-install immediately after power-up. There is no need to increase kernel verbosity because the kernel gets never loaded. U-Boot is broken. -
8 minutes ago, martinayotte said:
Maybe, but you are mixing symptoms and issues and refuse to do what we suggested ...
As I said twice, and now a third time, did you do :
If the RootFS on eMMC is Ok, and only refuse to boot directly from eMMC, then it is U-Boot that needs to be recovered ...
I did that ~25 times using 4 different Armbian builds without success however the year old OrangePI Ubuntu image does successfully install to eMMC *and* boot after. After checking the eMMC integrity successfully, there are two possibilities left:
A. It never worked with Armbian
B. It worked in an old Armbian release which is not available anymore.
C. something changed in BROM (or whatver this is called with Allwinner) with my late 2018 board. This is very unlikely because the year old OrangePI image works.
If A): Ok, I'll accept and stop
If B): Tell me which version worked so I can do a bisect manually and debug.
Thanks
-
20 minutes ago, 5kft said:
Sure, but it is rather difficult to solve a problem if you don't try to debug it
Why not put a little more effort into this, it certainly is an interesting and strange problem...!
If you read this thread, you already see that I put some effort into it. Given that there is no documentation about the source of the overlay and u-boot files in Armbian, there is little to debug. It should be easy for you to tell me e.g. which u-boot patches your image uses or at least which git ref you build
-
5 minutes ago, guidol said:
Sorry, I cant because of the flaky slow 0,7MBit Upload-Speed of my DSL.
A dowload URL isnt available, because the images are only created via the armbian-build-system.But with Virtualbox you could easily create the armbian-build-system with VirtualBox and a minimal ubuntu-image:
https://docs.armbian.com/Developer-Guide_Build-Preparation/But this does not deliver an exact version build. I have many builds that don't work, another one will not help me. That's why I'm asking for exact versions.
-
4 minutes ago, 5kft said:
Likewise - I have always used the eMMC exclusively on all of my Orange Pi Zero Plus2 H5 boards (I have multiple) and have never seen anything like this... (It's also always worked for my NEO Core 2 boards, NEO Plus 2 boards, etc.)
In order to try narrowing the problem down, perhaps try @guidol's suggestion above (https://forum.armbian.com/topic/9440-orange-pi-zero-plus2-h5-install-to-emmc-bricked-device/?tab=comments#comment-71034). It could be that Armbian's partition layout is such that it exacerbates a H/W problem with your particular board? E.g., it'd be interesting to see if you still have problems if you layout the image to start at 1GB rather than at zero.
I already did a full eMMC test
-
3 minutes ago, guidol said:
Yes - on my OPi Zero Plus2 H5 I installed Armbian_5.72_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img
- which I did compile with the armbian-build-system -
without problems to eMMC
Also my DEV-compile before was successfully installed to eMMC:
Armbian_5.67_Orangepizeroplus2-h5_Debian_stretch_dev_4.19.4.imgCould you share the images or provide me an URL to download? That would be great!
-
FYI: Ordered my Orange Pi Zero Plus 2 H5 (Set 4) on January 10th, 2019 from Seller "Shenzen Xunlog Software". Received it last week.
Q5 is still unpopulated. PCB still says "Version 1.0". There's also a sticker on it.
-
Yesterday evening I also tried the oldest Armbian releasess I was able to find:
Armbian_5.59_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.14.65.img
Armbian_5.69_Orangepizeroplus2-h5_Debian_stretch_next_4.19.13.img
nand-sata-install in that versions does not work either.
Has someone of you actually managed to get a full eMMC based installation working with nand-sata-install on the Orange Pi Zero Plus2 H5?
-
IMHO eMMC is fine. Here is an attempt to prove it:
# dump the entire eMMC to get its size: $ dd if=/dev/mmcblk2 of=emmc 15269888+0 records in 15269888+0 records out 7818182656 bytes (7.8 GB, 7.3 GiB) copied, 537.777 s, 14.5 MB/s # create a new file on the sd card with the exact size, filled with random data $ dd if=/dev/urandom of=emmc.new bs=7634944 count=1024 1024+0 records in 1024+0 records out 7818182656 bytes (7.8 GB, 7.3 GiB) copied, 513.515 s, 15.2 MB/s # checksumming $ sha512sum emmc.new b94f6133d5843418a036ed0d405ae78a5058759265e677d3c6c1a60397a383bc4e39b08449b0dab0bf564a422599ecb1bd05150e70c5841cd6c309adfdabec3a emmc.new # writing the file to the eMMC $ dd if=emmc.new of=/dev/mmcblk2 bs=7634944 count=1024 1024+0 records in 1024+0 records out 7818182656 bytes (7.8 GB, 7.3 GiB) copied, 327.95 s, 23.8 MB/s # again dump the entire eMMC to sd: $ dd if=/dev/mmcblk2 of=emmc.readback 15269888+0 records in 15269888+0 records out 7818182656 bytes (7.8 GB, 7.3 GiB) copied, 532.28 s, 14.7 MB/s # verify $ sha512sum emmc.readback b94f6133d5843418a036ed0d405ae78a5058759265e677d3c6c1a60397a383bc4e39b08449b0dab0bf564a422599ecb1bd05150e70c5841cd6c309adfdabec3a emmc.readback # both shasums are identical -
ext2 does not work either. CPU reset loop.
I wish I would understand more details of the boot process i.e. how the SoC "knows" where U-boot is.
-
6 minutes ago, martinayotte said:
This image is NOT from Armbian !!! So no support ...
There is no support needed for that image. I just wanted to provide insights.
-
I couldn't sleep and tried another approach: I learned that OrangePI ships at least their (shady, outdated) Ubuntu 16.04 Image with an "install to eMMC" script. The image is called "ubuntu_server_zeroplus2_H5_V0_1.img" and available from http://www.orangepi.org/downloadresources/orangepizeroplus2H5/orangepizeroplus2H5_adce81482f863b39.html
I flashed it with Etcher but it didn't successfully boot, as it *requires* an already partitioned and formatted eMMC (I wiped it with dd prior that attempt) to successfully finish the boot process.
So back to Armbian SD boot: fdisk the emmc, create 2 partitions, mkfs (first ext2 and second ext4 as required by the systemd unit of the shady 16.04 Image).
The OrangePI 16.04 image then booted successfully (from SD) and I was able to execute their "OrangePi_Settings" script (sudo OrangePi_Settings) and choose the Install to eMMC option. After the installation finished, I powered off the device, removed the SD card, and powered it up again: It booted successfully from eMMC.
Device names are different than with Armbian: mmcblk0=eMMC, mmcblk1=SD. (Kernel "3.10.65+").
Ubuntu 16.04.1 LTS Orangepi ttyS0 Orangepi login: root Password: Last login: Thu Apr 6 12:02:12 UTC 2017 on ttyS0 Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 3.10.65+ aarch64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___| _ \(_) | | | | '__/ _` | '_ \ / _` |/ _ \ |_) | | | |_| | | | (_| | | | | (_| | __/ __/| | \___/|_| \__,_|_| |_|\__, |\___|_| |_| |___/ ***************************************************************** -e When you first running OrangePi ZeroPlus2 -e Please use OrangePi Configure tools, such as: -e sudo OrangePi_Settings ****************************************************************** blkid /dev/mmcblk0: PTUUID="560b2c98" PTTYPE="dos" /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="EMMCBOOT" UUID="E713-9DD0" TYPE="vfat" PARTUUID="560b2c98-01" /dev/mmcblk0p2: LABEL="emmclinux" UUID="cc931d85-f58d-460d-9126-b10502c48bf5" TYPE="ext4" PARTUUID="560b2c98-02" /dev/mmcblk1: PTUUID="000ebed2" PTTYPE="dos" /dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="BOOT" UUID="16AC-FBA4" TYPE="vfat" PARTUUID="000ebed2-01" /dev/mmcblk1p2: LABEL="rootfs" UUID="f254ba92-d0ab-42b1-90a2-3ced2cfdef8e" TYPE="ext4" PARTUUID="000ebed2-02"And as you can see there is a vfat /boot partition. The contents are identical on SD and eMMC:
root@Orangepi:~# mount /dev/mmcblk0p1 /tmp/boot root@Orangepi:~# diff -r /boot /tmp/boot root@Orangepi:~# find /boot /boot /boot/orangepi /boot/orangepi/uImage /boot/orangepi/OrangePiH5orangepi.dtb /boot/orangepi/OrangePiH5.dtb /boot/initrd.img /boot/uEnv.txt /boot/backup /boot/backup/orangepi /boot/backup/orangepi/uImage /boot/backup/orangepi/OrangePiH5orangepi.dtb /boot/backup/orangepi/OrangePiH5.dtb /boot/backup/uEnv.txt /boot/backup/initrd.img
Is it intentional, that Armbian's `nand-sata-install` does not create such a VFAT partition?
(PS: I've extracted and uploaded OragenPI scripts and uboot binaries to https://github.com/rmoriz/orangepi_scripts )
-
eMMC seems to be fine because i can mount and write to it.
# fdisk -l /dev/mmcblk2 Disk /dev/mmcblk2: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x9050a3d5 Device Boot Start End Sectors Size Id Type /dev/mmcblk2p1 8192 15117183 15108992 7.2G 83 Linux # blkid /dev/mmcblk0p1: UUID="962faea8-b247-4f0b-8614-9f3cbcd3593d" TYPE="ext4" PARTUUID="51af9c91-01" # SD /dev/mmcblk2p1: UUID="fdccd95d-8138-4dbd-a07f-28425d05aa1c" TYPE="ext4" PARTUUID="9050a3d5-01" # eMMC ... /dev/mmcblk0: PTUUID="51af9c91" PTTYPE="dos" # SD /dev/mmcblk2: PTUUID="9050a3d5" PTTYPE="dos" # eMMC # fsck.ext4 /dev/mmcblk2p1 e2fsck 1.44.1 (24-Mar-2018) /dev/mmcblk2p1: clean, 35980/472352 files, 306094/1888624 blocks # cat /proc/cmdline root=UUID=962faea8-b247-4f0b-8614-9f3cbcd3593d rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 panic=10 consoleblank=0 loglevel=1 ubootpart=51af9c91-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory swapaccount=1 # mkdir /tmp/emmc # mount /dev/mmcblk2p1 /tmp/emmc # diff -r /boot /tmp/emmc/boot diff -r /boot/armbianEnv.txt /tmp/emmc/boot/armbianEnv.txt 5c5 < rootdev=UUID=962faea8-b247-4f0b-8614-9f3cbcd3593d --- > rootdev=UUID=fdccd95d-8138-4dbd-a07f-28425d05aa1c Binary files /boot/boot.scr and /tmp/emmc/boot/boot.scr differ diff: /boot/dtb/dtb-4.19.13-sunxi64: Too many levels of symbolic links diff: /tmp/emmc/boot/dtb/dtb-4.19.13-sunxi64: Too many levels of symbolic links diff: /boot/dtb-4.19.13-sunxi64/dtb-4.19.13-sunxi64: Too many levels of symbolic links diff: /tmp/emmc/boot/dtb-4.19.13-sunxi64/dtb-4.19.13-sunxi64: Too many levels of symbolic links
-
Update:
In /boot/armbianEnv.txt on the SD-Card the rootdev still pointed to the sd card root. I changed it to the UUID of the eMMC (used `blkid` get it)
After rebooting, root partition is now eMMC:
root@orangepizeroplus2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 173M 0 173M 0% /dev tmpfs 49M 2.3M 46M 5% /run /dev/mmcblk2p1 7.1G 1015M 5.7G 15% /
However system does not boot without the SD-Card inserted, showing the "Resetting CPU ..." behaviour as mentioned in my opening post. Is that expected/by design?
-
current progress:
- System starts again from SD
- Used the same power supply but no UART-TTL connected (I guess this was the cause of the original case).
- tried again to install the system to eMMC (armbian-config/nand-sata-install finishes successfully)
- after power cycle system still boots from SD (/dev/mmcblk0p1 instead of /dev/mmcblk2p1)
- eMMC /dev/mmcblk2 is mountable and looks good (contains the armbian system)
- System does not boot without SD-card
relevant package versions:
ii linux-bionic-root-next-orangepizeroplus2-h5 5.69 arm64 Armbian tweaks for bionic on orangepizeroplus2-h5 (next branch) ii linux-u-boot-orangepizeroplus2-h5-next 5.69 arm64 Uboot loader 2018.05
=> apt-get dist-upgrade
ii linux-bionic-root-next-orangepizeroplus2-h5 5.70 arm64 Armbian tweaks for bionic on orangepizeroplus2-h5 (next branch) ii linux-u-boot-orangepizeroplus2-h5-next 5.70 arm64 Uboot loader 2018.05
=> again nand-sata-install + reboot
=> still booting off SD (/dev/mmcblk0p1)
Armbian for TV box rk3328
in Rockchip CPU Boxes
Posted · Edited by rmoriz
Thanks for the tip! Using the identical image with the same UUID on SD and USB the system boots. First part of the boot process reads from the SD card but later mounting rootfs from USB (both devices are required to boot successfully). Ethernet works and I can access the internal eMMC. (nand-install and boot does not work on the first try, at least requires manual partitioning and bootloader installation. Will try later this week). Sadly WiFi and SD-Card seem not to work.
Update: Booting with SD+eMMC (both required) works for me now (no USB stick) after:
- used cfdisk to dump partition layout of my USB stick (select DUMP)
- cfdisk --zero /dev/mmcblk1 (press L, load file from step above) to restore layout to eMMC (will delete all data on emmc!)
- in cfdisk re-created ext4 partition to extend size to emmc + saved
- changed `nand-sata-install` script to use /dev/mmcblk1
- executed nand-sata-install, without errors
- after finish: change UUID of ext4 emmc partition to UUID of (inaccessible) SD ext4 partition.
- sudo tune2fs /dev/mmcblk1p2 -U <UUID>
- reboot
root@rk3328:~# blkid /dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="BOOT_EMMC" UUID="6BC9-1A16" TYPE="vfat" PARTUUID="674bd3e2-01" /dev/mmcblk1p2: LABEL="ROOT_EMMC" UUID="0ac91c4b-082d-4aa4-888f-3b24a3516103" TYPE="ext4" PARTUUID="674bd3e2-02" /dev/zram0: LABEL="log2ram" UUID="9395094d-731b-46c5-a3fd-94d2399a5cac" TYPE="ext4" /dev/zram1: UUID="a6cfa5e8-df4f-445a-bc0a-14908272a3c5" TYPE="swap" /dev/zram2: UUID="17b0a1f5-1678-43c0-876c-022a7ad5557d" TYPE="swap" /dev/zram3: UUID="65beebe7-6dd2-44ab-86a6-2d0fafb7a075" TYPE="swap" /dev/zram4: UUID="c7702171-7779-4e92-bf36-bc415064f691" TYPE="swap" /dev/mmcblk1: PTUUID="674bd3e2" PTTYPE="dos" root@rk3328:~# fdisk -l /dev/mmcblk1 Disk /dev/mmcblk1: 58.2 GiB, 62537072640 bytes, 122142720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x674bd3e2 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 32768 294911 262144 128M e W95 FAT16 (LBA) /dev/mmcblk1p2 294912 122142719 121847808 58.1G 83 Linux