Jump to content

FEL mass storage or writing images directly to eMMC


Recommended Posts

@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 by zador.blood.stained
Moved from this thread: http://forum.armbian.com/index.php/topic/2125-armbian-for-orange-pi-does-not-boot/
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines