zador.blood.stained Posted September 26, 2016 Posted September 26, 2016 (edited) @Igor/@Zador: what about a H3 mini image that just contains u-boot/kernel and hands out the whole eMMC device as USB Mass Storage gadet (like it's done here). This way users could flash eMMC directly from Etcher (using the virtual USB thumb drive) and it would be also the fastest way to create an eMMC clone on the Fast Ethernet equipped devices. It's a good idea, but it still leaves a question of loading u-boot and kernel/script.bin/initrd initially. If SPL doesn't want to boot from available SD card this won't help much... ... unless FEL is used to "bootstrap" the process. Just for experiment I compiled sunxi-fel for Windows and installed libUSB driver in single click with Zadig tool. So we could provide an application/set of scripts for Linux and Windows to do this. Edited October 15, 2016 by zador.blood.stained Moved from this thread: http://forum.armbian.com/index.php/topic/2125-armbian-for-orange-pi-does-not-boot/ 1
zador.blood.stained Posted September 27, 2016 Author Posted September 27, 2016 ... unless FEL is used to "bootstrap" the process. Just for experiment I compiled sunxi-fel for Windows and installed libUSB driver in single click with Zadig tool. So we could provide an application/set of scripts for Linux and Windows to do this. Initial attempt: https://github.com/zador-blood-stained/fel-mass-storage 2
tkaiser Posted September 27, 2016 Posted September 27, 2016 Initial attempt: https://github.com/zador-blood-stained/fel-mass-storage You can add 'OS X' to the documentation where Linux is already mentioned: Step 1) Cloned repo, started the script bash-3.2# ./start.sh Connect device in FEL mode and press <Enter> 100% [================================================] 5025 kB, 580.8 kB/s 100% [================================================] 36 kB, 555.5 kB/s 100% [================================================] 3160 kB, 580.5 kB/s 100% [================================================] 0 kB, 86.6 kB/s Step 2) Watching Orange Pi Plus 2E booting within ~5 seconds: U-Boot SPL 2016.09-dirty (Sep 27 2016 - 14:33:57) DRAM: 2048 MiB Trying to boot from FEL U-Boot 2016.09-dirty (Sep 27 2016 - 14:33:57 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi One DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 MMC: no card present *** Warning - MMC init failed, using default environment In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 (FEL boot) ## Executing script at 43100000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3160359 Bytes = 3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Using machid 0x1029 from environment Starting kernel ... [sun8i_fixup]: From boot, get meminfo: Start: 0x40000000 Size: 2048MB ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1 ion_reserve_select: ion chipid [0x2004620! ion_reserve_common: ion reserve: [0xb0000000, 0xc0000000]! <7Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... Starting g_mass_storage script Done # Step 3) Checking available devices from OS X: macbookpro-tk:~ tk$ diskutil list ... /dev/disk3 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *15.6 GB disk3 1: Linux 15.5 GB disk3s1 macbookpro-tk:~ tk$ system_profiler SPUSBDataType ... Mass Storage Gadget: Product ID: 0xa4a5 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 0.00 Speed: Up to 480 Mb/sec Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc Location ID: 0x14200000 / 9 Current Available (mA): 500 Current Required (mA): 2 Capacity: 15,63 GB (15.634.268.160 bytes) Removable Media: Yes Detachable Drive: Yes BSD Name: disk3 Partition Map Type: MBR (Master Boot Record) S.M.A.R.T. status: Not Supported Volumes: disk3s1: Capacity: 15,48 GB (15.476.867.072 bytes) BSD Name: disk3s1 Content: Linux Step 4) Starting Etcher which immediately suggests using /dev/disk3 with 15.6GB (won't flash, I need the installation a few more days) Step 5) Say thank you to Zador! Step 6) Wait for Zador's OK, then compile sunxi-fel on a OS X 10.6 host and create a small self-contained application wrapper using Platypus, include Armbian logo and send it to Igor to put it online.
zador.blood.stained Posted September 27, 2016 Author Posted September 27, 2016 Step 6) Wait for Zador's OK, then compile sunxi-fel on a OS X 10.6 host and create a small self-contained application wrapper using Platypus, include Armbian logo and send it to Igor to put it online. I don't know much about OS X, but I tried making statically linked sunxi-fel for Linux, but it depends on libusb-1.0, libusb-1.0 depends on libudev, and libudev cannot be statically linked as far as I see. So just make sure that there will be no dependency problems with sunxi-fel on older or newer OS X releases if you want to include precompiled sunxi-fel binary.
Igor Posted September 27, 2016 Posted September 27, 2016 I made a success boot test under Windows with Bananapi M2+ ... works but need to be powered separate. Mass storage gadget becomes available.
tkaiser Posted September 27, 2016 Posted September 27, 2016 I don't know much about OS X, but I tried making statically linked sunxi-fel for Linux, but it depends on libusb-1.0, libusb-1.0 depends on libudev, and libudev cannot be statically linked as far as I see. That's a bit different on OS X, there you don't link statically but throw the needed libraries around and relink them (normally you put them in a 'Frameworks' folder in your application bundle but since the whole app will be just a stub all the relevant stuff will be put into 'Resources'). So you just throw the needed lib next to the executable and adjust paths: bash-3.2# pwd /Users/tk/sunxi-tools bash-3.2# otool -L sunxi-fel sunxi-fel: /usr/local/opt/libusb/lib/libusb-1.0.0.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) bash-3.2# cp -p /usr/local/opt/libusb/lib/libusb-1.0.0.dylib . bash-3.2# /Library/Developer/CommandLineTools/usr/bin/install_name_tool -id @executable_path/libusb-1.0.0.dylib libusb-1.0.0.dylib bash-3.2# /Library/Developer/CommandLineTools/usr/bin/install_name_tool -change /usr/local/opt/libusb/lib/libusb-1.0.0.dylib @executable_path/libusb-1.0.0.dylib sunxi-fel bash-3.2# otool -L sunxi-fel sunxi-fel: @executable_path/libusb-1.0.0.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) bash-3.2# mv /usr/local/opt/libusb/lib/libusb-1.0.0.dylib /tmp/ bash-3.2# ./sunxi-fel ver AWUSBFEX soc=00001680(H3) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000 I made a success boot test under Windows with Bananapi M2+ ... works but need to be powered separate. That's strange, is it possible that your USB port does not provide enough current? I booted M2+ many times directly from the USB3 ports of several Macs (all providing 900-1000mA on these ports) and currently it's powered from an USB2 port of a Lime2 (with a short cable though). @Zador: the kernel you used: is there everything unnecessary disabled (eg. network, switching from Fast to GBit Ethernet on any of the RTL8211E equipped devices makes a difference of +350mW)? @Igor: Do you have high resolution Armbian logo lying around (vectorized even better)? I would then provide an app for OS X 'Armbian H3 booter' or something like that. BTW: We all know how the journey will continue: 'sunxi-fel ver' shows which SoC is available so we could provide one single tool to rule them all (at least sunxi)
zador.blood.stained Posted September 27, 2016 Author Posted September 27, 2016 @Zador: the kernel you used: is there everything unnecessary disabled (eg. network, switching from Fast to GBit Ethernet on any of the RTL8211E equipped devices makes a difference of +350mW)? I believe network is disabled in FEX file but u-boot initializes EMAC/GMAC too. I guess kernel can be recompiled without tons of multimedia and network stuff to reduce size and some u-boot options can be disabled too. @Igor: Do you have high resolution Armbian logo lying around (vectorized even better)? I would then provide an app for OS X 'Armbian H3 booter' or something like that. BTW: We all know how the journey will continue: 'sunxi-fel ver' shows which SoC is available so we could provide one single tool to rule them all (at least sunxi) Right now this tool is useful mostly to make eMMC backups or to turn a device without eMMC into a card reader. Since root device is hardcoded as /dev/mmcblk0p1 both in boot script and fstab, flashing standard Armbian images (to eMMC) won't work out of the box.
Igor Posted September 27, 2016 Posted September 27, 2016 @tkaiser Logo with fonts http://forum.armbian.com/index.php/topic/1325-claim-a-task-set-due-date-and-start-doing-it/page-4#entry11938 1
tkaiser Posted September 27, 2016 Posted September 27, 2016 Right now this tool is useful mostly to make eMMC backups or to turn a device without eMMC into a card reader. Since root device is hardcoded as /dev/mmcblk0p1 both in boot script and fstab, flashing standard Armbian images (to eMMC) won't work out of the box. Understood. Thought about situation with OS X (mounting ext4 with FUSE) and dropped the idea since way too unreliable. On the H3 itself it looks like this (I booted the OPi Plus 2E with an 8GB SD card inserted): # blkid /dev/mmcblk0p1: UUID="95adb0a1-57d1-41b5-ae03-f9b14605bbdd" TYPE="ext4" PARTUUID="1db0e6fb-01" /dev/mmcblk1p1: UUID="83289bfb-5e48-4ae3-8c20-8557131a06ec" TYPE="ext4" PARTUUID="f88eb67b-01" /dev/mmcblk0: PTUUID="1db0e6fb" PTTYPE="dos" /dev/mmcblk1: PTUUID="f88eb67b" PTTYPE="dos" # cat /proc/partitions major minor #blocks name 179 0 7761920 mmcblk0 179 1 7605648 mmcblk0p1 179 16 15267840 mmcblk1 179 17 15114128 mmcblk1p1 179 48 4096 mmcblk1boot1 179 32 4096 mmcblk1boot0 Hmm... UUIDs are there but not an easy way to check when flashing is finished to do necessary adjustments before user powers device off. By reading through http://linux-sunxi.org/Bootable_eMMC I thought that it might be the best way to use these special eMMC boot partitions once we know how they work. Then we could do some first boot magic from there I would assume... (same with SPI in case we really get the next batch of Xunlong boards with populated bootable SPI flash)
Igor Posted September 28, 2016 Posted September 28, 2016 I plugged into USB2 port located at my (Das) keyboard which is most convenient for such experiments. Keyboard has a long cable but micro USB power cable was a short one ... USB3 port on hub gives enough power. U-boot hanged at RAM init.
tkaiser Posted September 28, 2016 Posted September 28, 2016 Since root device is hardcoded as /dev/mmcblk0p1 both in boot script and fstab, flashing standard Armbian images (to eMMC) won't work out of the box. Thinking about NanoPi NEO AIR we could provide the images with both boot script and fstab entry pointing /dev/mmcblk1p1 instead? But then people want to try out Armbian first on SD card without erasing FA's Ubuntu Core image on the eMMC and we end up pretty fast providing two sets of OS images and confused users. Ok, we need a more intelligent approach if we ever want to provide OS images being able to be flashed in this way we're talking here about (Regarding NanoPi AIR it gets interesting anyway since there's no Ethernet and not even a header soldered to connect serial console to. Sounds like a job for g_serial anyway and we might end up with exactly the same way as Next Thing Co. deals it with their C.H.I.P.)
zador.blood.stained Posted October 15, 2016 Author Posted October 15, 2016 Since new H3 images will support booting from eMMC directly, I think we should make a separate page on armbian.com (not on docs.armbian.com) with instructions for flashing the images directly to eMMC, and link this page from download pages for boards with eMMC.
tkaiser Posted October 15, 2016 Posted October 15, 2016 Since new H3 images will support booting from eMMC directly, I think we should make a separate page on armbian.com (not on docs.armbian.com) with instructions for flashing the images directly to eMMC, and link this page from download pages for boards with eMMC. Good idea. Do you plan to add support for A20 and A64 to https://github.com/zador-blood-stained/fel-mass-storage anytime soon (thinking about the Olimex boards)?
zador.blood.stained Posted October 15, 2016 Author Posted October 15, 2016 Yes, I'll try to implement A20 next (eMMC only, no NAND) based on Lime2-eMMC config. For A64 we need to get eMMC equipped device and eMMC enabled device tree file first. Before that we still need to update nand-sata-install, armbianmonitor and documentation to use new environment file.
tkaiser Posted October 16, 2016 Posted October 16, 2016 Hmm... just stumbled accross this: https://github.com/lolet/FELix
tkaiser Posted October 16, 2016 Posted October 16, 2016 And now uploaded the OS X application wrapper to https://github.com/ThomasKaiser/sunxi-armbian-flasher-osx -- it's outlined there how to update the contained fel-mass-storage stuff and is only meant as an example since for a proper application code signing and other stuff would be required which is beyond my interest/time. The 'main logic' is contained in the StartFlashing function.
zador.blood.stained Posted October 16, 2016 Author Posted October 16, 2016 Hmm... just stumbled accross this: https://github.com/lolet/FELix I believe this doesn't work for eMMC out of the box and it doesn't have newest sunxi-tools features like detecting SoC type by SID.
tkaiser Posted October 16, 2016 Posted October 16, 2016 I believe this doesn't work for eMMC out of the box and it doesn't have newest sunxi-tools features like detecting SoC type by SID. Yeah, was meant more of a collection (since maybe stuff for NAND could be added later). BTW: I'm currently thinking about the impact of this and that. We have a new cmdline parameter 'storage_type' but will not differentiate between SD card and eMMC the FriendlyARM way but by UUID from now on. Isn't this in conflict?
zador.blood.stained Posted October 16, 2016 Author Posted October 16, 2016 Yeah, was meant more of a collection (since maybe stuff for NAND could be added later). Once NAND is properly supported in mainline kernel and u-boot, NAND support will be easy to implement. BTW: I'm currently thinking about the impact of this and that. We have a new cmdline parameter 'storage_type' but will not differentiate between SD card and eMMC the FriendlyARM way but by UUID from now on. Isn't this in conflict? If this parameter is required, it should be added to armbianEnv.txt from family_tweaks to keep main boot script simple. Now it is not present in new simplified boot-sunxi.cmd script anyway. 1
martinayotte Posted October 16, 2016 Posted October 16, 2016 I've played a bit with MTD/UBIFS on my Olimex-Micro-A20, it works well. But I didn't get chance to try building U-Boot with MTD/UBIFS yet ...
eperie Posted October 19, 2016 Posted October 19, 2016 @Zabor Documentation at fel-mass-storage indicates that Zadig 2.2 and sunxi-fel.exe were successfully tested on Windows 8.1 32 bits:Just to let you know they are working great on Windows 10 64 bits (build 14393.321) as well - thanks a for this Windows port of sunxi-fel.
multivac61 Posted October 20, 2016 Posted October 20, 2016 Would you be able to flash image to eMMC via a simple shell script like the Friendly Arm guys offer?
Igor Posted October 21, 2016 Posted October 21, 2016 Would you be able to flash image to eMMC via a simple shell script like the Friendly Arm guys offer? We offer this kind of install since early days of the project and it's working fine. We are talking about direct eMMC flash from your PC.
wildcat_paris Posted October 21, 2016 Posted October 21, 2016 Hello Igor, We are talking about direct eMMC flash from your PC. I am not sure it is even possible in general. At least, the XU4 eMMC, the PC-SD2eMMC converter only displays the /dev/mmcblk0 (& not the other partitions boot0 boot1 rpmb) And what I have tested so far, you need a kernel with eMMC magement to access all the partitions.
Igor Posted October 21, 2016 Posted October 21, 2016 Yes, not in general. This flasher covers only Allwinner boards with eMMC chip. 1
wildcat_paris Posted October 21, 2016 Posted October 21, 2016 Hello TK, Understood. Thought about situation with OS X (mounting ext4 with FUSE) and dropped the idea since way too unreliable. On the H3 itself it looks like this (I booted the OPi Plus 2E with an 8GB SD card inserted): # blkid /dev/mmcblk0p1: UUID="95adb0a1-57d1-41b5-ae03-f9b14605bbdd" TYPE="ext4" PARTUUID="1db0e6fb-01" /dev/mmcblk1p1: UUID="83289bfb-5e48-4ae3-8c20-8557131a06ec" TYPE="ext4" PARTUUID="f88eb67b-01" /dev/mmcblk0: PTUUID="1db0e6fb" PTTYPE="dos" /dev/mmcblk1: PTUUID="f88eb67b" PTTYPE="dos" Hmm... UUIDs are there but not an easy way to check when flashing is finished to do necessary adjustments before user powers device off. By reading through http://linux-sunxi.org/Bootable_eMMC I thought that it might be the best way to use these special eMMC boot partitions once we know how they work. Then we could do some first boot magic from there I would assume... (same with SPI in case we really get the next batch of Xunlong boards with populated bootable SPI flash) were the SD & eMMC using GPT or MBR? I am a little lost about PARTUUID which is/was originally dedicated to GPT OR is there now an option (clean "trick") to identify datas (partition) in the MBR as a PARTUUID? Zador wasn't clear about this point. Only mentioning about shorter version of PARTUUID (edit) is it http://www.gossamer-threads.com/lists/linux/kernel/1583540 ? When reading eMMC spec - boot0/1 are SLC NAND memory (Odroid size = 4MB) - rpmb is a security feature mimicking a partition (4MB) - the remaining of the eMMC is MLC NAND for Samsung (if not TLC or TLC3D for other brands) the eMMC provided by Odroid was sold with uboot 12.07 on the boot0 partition. boot1 is empty. uboot 12.07 was switching to mmcblk0 to fetch the initrd / kernel edit: uboot 12.07 can be replaced by uboot 16.05 (on boot0) and the XU4 is working fine with a single partition. eMMC is a standard so I guess the cards will load uboot from boot0 and fetch the kernel on the mmcblk0/1 partition so: SD card install: can only use MBR (to keep space for uboot) eMMC: can use either MBR or GPT as uboot/blobs are on boot0 partion edit 2: Since kernel 3.8 and newer it is possible to use MBR 32-bit UUID, so it's possible to use a MBR partition table as well. In this case PARTUUID refer to an MBR partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-filled hex representation of the 32-bit "NT disk signature", and PP is a zero-filled hex representation of the 1-based partition number. https://wiki.gentoo.org/wiki/GRUB http://lxr.linux.no/#linux+v3.8/init/do_mounts.c#L190
tkaiser Posted October 22, 2016 Posted October 22, 2016 OR is there now an option (clean "trick") to identify datas (partition) in the MBR as a PARTUUID? It's about FEL (Allwinner boards only) and now we use UUID with MBR to uniquely identify partitions. Latest commits now allow also nand_sata_install to work with the new scheme so we can now immediately flash to eMMC on sunxi devices (since it's not hardcoded to /dev/mmcblk0 any more but uses the UUID) or do it the usual way burning an image to SD card and then transfering the contents to eMMC the usual way.
zador.blood.stained Posted October 22, 2016 Author Posted October 22, 2016 There are still some issues/considerations like u-boot update procedure or UUID collision if same image is flashed both to SD and eMMC, but hopefully this will be sorted out in the future.
sgufa Posted January 11, 2017 Posted January 11, 2017 @zador how did you build uinitrd and zimage? I would try to build them for A20...
zador.blood.stained Posted January 11, 2017 Author Posted January 11, 2017 Simply copied from a working image after adding mass_storage script to the initrd and recompiling it. Ideally this needs to be redone based on the mainline kernel (and it will be universal for A10, A20 and H3 devices).
Recommended Posts