Jens Bauer

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

FYI:
 
asked about ext4 support for boot to get rid off the FAT partition:
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=243890&p=1487617#p1487617
seems not of importance for them..
 
some charger issues:
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=244146
and a nice link provided there:
https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/
as with more or less every boardmaker, things are not mature in the beginnings.. But at least some of the flaws will likely be fixed over time..
 
 
 

OT: when the PSUs of my SheevaPlugs started to fail I "swore" myself not buy any other device from Globalscale in the future, but even though I did it again ...

I know it's not you to blame, but it's again disappointing with a GlobalScale product, which I bought as *up* to 1.2 GHz, just to find, that it's not even good enough to scale down to 1000/800, but even down to 800/800 to get a stable service.

Solved, got in UART mode and flashed the correct image.

Done.

For anyone coming across this: Removing the symlink didn't work for me on Espressobin, but the following did:
systemctl stop serial-getty@ttyS0.service  

For anyone who wants to test power consumption, I'll recommend not supplying the board with 12V, but instead 5.2V, which is the minimum voltage required by the voltage regulator.
The higher the input voltage, the higher power-loss you'll get.
I recommend a good 5.2V PSU, which provides a heavy current like more than 3A.
You can use a 6V PSU if you can't find anything lower, but just make sure that it can give the board a lot of current.
For keeping power consumption down, I also recommend that you do not use the USB-ports nor the SATA port.
That means booting Linux from the microSD card port - or if you want to cheat, you can supply an external harddisk with power from a different PSU and only connect the SATA data cable to the Espressobin. This will result in that the harddisk's power usage does not influence the measurements of the board itself.
 
-And of course, as Thomas says - it's a very good idea shutting down peripherals you do not use.
 
Unfortunately, there are things you can't change. The board has been sprayed with voltage regulators - even nested!
I'm convinced that the board could have been designed a little better regarding this.
I have not checked if you can shut down some of the power regulators completely, but even if you issue the "poweroff" command, the CPU is still running!!
 
Things to consider:
Powering a SATA drive from the board uses a lot of power. A 3.5" drive use much more than a 2.5" drive (check your drive's specs).
USB devices use lots of power.
MicroSD / MMC uses some power, but it's not extreme.
A Mini-PCIe WiFi card uses a lot of power; I'm fairly convinced that the built-in Gbit Ethernet uses less.
(unfortunately the Topaz switch has not been utilized very well on the board; it's fairly much a waste, it's just using power without giving extra performance).
The DDR RAM uses a fair amount of power, but for good reasons it's not smart to turn it off.
... All those things add on top of the CPU's own power usage, which is said to be 1W.
 
At the moment, I do not have the proper equipment ready for measuring the power usage on the board; but if I find a way, I'll be using a multimeter and a 5.2V power source - and I'll likely be running Armbian from the SD-card or perhaps cheating by running it from a SATA disk with a secondary power supply, so you can easily add your own numbers for the harddisks of your choice.

Hi,
 
I see where this bootcmd comes from - from the espressobin download page here.  I was just tryin' to follow directions.
 
 
I'll try to follow your directions instead. Tom
 

I tried posting yesterday, but when I clicked 'submit reply', the forum web-site was gone and so was everything I typed. :/
 
I can't reconstruct my post, but I gave an example on how little is actually needed; fortunately, I had that in my copy-and-paste buffer, so here it is:
# Set boot arguments: setenv bootargs 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk1p1 rootfstype=ext4 rootwait loglevel=1' # load kernel file 'boot/image' to RAM at address 0x5000000: ext4load mmc 0:1 0x5000000 boot/image # load fdt file to RAM at address 0x4f00000: ext4load mmc 0:1 0x4f00000 boot/dtb/marvell/armada-3720-community.dtb # execute kernel in RAM: booti 0x5000000 - 0x4f00000 -Actually 'loglevel=1' is not strictly necessary, but there's no reason to be impolite.
The above will only boot from partition 1 of the micro-SD card, but it's so short that it gives a fairly easy overview (in commands) of what's basically going on.
 
The 'bootargs' environment variable is special; it's actually read by the Linux kernel.
 
 
Anyway, I gave another example on how the environment variables could be added back in, in order to make it more readable with the stuff you might want to change at the top:
setenv iface mmc; setenv dev 0:1; setenv root '/dev/mmcblk1p1' setenv image_name 'boot/image' setenv fdt_name 'boot/dtb/marvell/armada-3720-community.dtb' setenv kernel_addr 0x5000000; setenv fdt_addr 0x4f00000 setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' setenv bootargs "$console root=$root rootfstype=ext4 rootwait loglevel=1" ext4load $iface $dev $kernel_addr $image_name ext4load $iface $dev $fdt_addr $fdt_name booti $kernel_addr - $fdt_addr -As you see, it's a lot easier to see what's going on if adding environment variables with descriptive names.
The above is basically how Armbian boots. Armbian's boot, however, also loads a script-file from the boot-device called 'boot/boot.scr', which first imports environment variables from a file called 'boot/armbianEnv.txt'. This can be both helpful and confusing.
Helpful because it makes things work quickly and easily.
Confusing if you're trying to change something from your boot-prompt, because you'll keep ending up booting from the same device.
 
Armbian's boot sequence tries to find a bootable device by first probing the SD-card and checking if there's a kernel available there. If not, then it continues to USB.
It also supports netboot. This is ideal for someone who does not want to wear out the SD-card slot (they're very fragile, because board vendors very much like to save 3 cents on picking the worst type they can find!)
 
We can also take the load_script environment variable from a few posts earlier ...
setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD"; setenv boot_interface mmc; else echo "... booting from USB"; usb start; setenv boot_interface usb; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' .... and expand it and remove the semicolons, so it's a little easier to read ...
if test -e mmc 0:1 boot/boot.scr; then   echo "... booting from SD"   setenv boot_interface mmc else   echo "... booting from USB"   usb start   setenv boot_interface usb fi if test -e $boot_interface 0:1 boot/boot.scr; then   ext4load $boot_interface 0:1 0x00800000 boot/boot.scr   source fi ... then we can add a few modifications to support SATA-boot ...
setenv script "boot/boot.scr" if test -e mmc 0:1 $script; then setenv devname SD setenv boot_interface mmc else usb start if test -e usb 0:1 $script; then setenv devname USB setenv boot_interface usb else scsi scan scsi dev 0:1 setenv devname SATA setenv boot_interface scsi fi fi if test -e $boot_interface 0:1 $script; then echo "... booting from $devname" ext4load $boot_interface 0:1 0x00800000 $script source fi ... and finally wrap it back up in one line ...
setenv load_script 'setenv script "boot/boot.scr"; if test -e mmc 0:1 $script; then setenv devname SD; setenv boot_interface mmc; else usb start; if test -e usb 0:1 $script; then; setenv devname USB; setenv boot_interface usb; else scsi scan; scsi dev 0:1; setenv devname SATA; setenv boot_interface scsi; fi; fi; if test -e $boot_interface 0:1 $script; then echo "... booting from $devname"; ext4load $boot_interface 0:1 0x00800000 $script; source; fi' ... which is basically what I use for booting from SATA (except from I do not attempt to boot from USB, since I often have my SD-card attached without wanting to boot from it.

Did you add "emmc_fix=on" to /boot/armbianEnv.txt on the eMMC (you needed to mount it after flashing) or did you try to insert a SD card in the microSD slot on the board? Without this eMMC won't be detected by the kernel.

You can copy it to the same USB stick (as a file) and dd it to the eMMC. Please note that you need to add/set "emmc_fix=on" in /boot/armbianEnv.txt both on your USB stick and on eMMC after you flash the image on it, or you can just insert any SD card into the SD slot.
 
There is no USB OTG port here so UMS (mass storage gadget) or fastboot is not an option here. The only "better" solution could be tftp based to download the image to RAM or USB storage and flash it to eMMC, but it requires setting up a tftp server, or writing the image from USB to eMMC from u-boot.

OFF,OFF,ON,ON,ON as per Solid-Run wiki for SD/eMMC. 

Please try setting switches to OFF,ON,OFF,OFF,ON instead.
 
I just tried to use kwboot from mainline u-boot and it worked fine for me
git clone --depth 1 git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- clearfog_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- tools tools/kwboot -b ~/u-boot-uart.mmc /dev/ttyUSB0 screen /dev/ttyUSB0 115200  

It may be easier to unpack the .deb package from here than mounting the existing image and extracting files from its filesystem.
 
Not with PuTTY and I'm not sure if there is a good way to do it from Windows in general.
I would recommend reading this tutorial and official Solid-Run instructions here.
You can get the u-boot binary from Armbian packages and this binary can easily boot an image from USB flash with "run usbboot" but you still need to find a way to load the u-boot via UART (either using kwboot or scripts linked in the first tutorial).
 
It is.

Hello everyone,
I am trying to achieve first boot with a Clearfog Base with eMMC.
 
It was not clear (at least to me) that the eMMC version does not allow booting from SD card *at all*
But hey, let's get this baby up&running, can anybody please help me?
 
I am trying to follow this procedure [https://www.armbian.com/clearfog-base/]:
1) Write the image to a USB flash drive
-> easy enough, I did it with Win32DiskImager and a well-tested 64GB USB stick
 
2) Load the modified u-boot (from the Armbian image) using the UART method
-> I have issues here. I suppose that UART method consists in plugging in the microUSB cable into my PC and open the COM3 port with Putty, than hitting some key to interrupt normal boot.
Unfortunately the terminal just spits out garbled text. The setup for the COM3 port in windows is 9600bps, 8data, no parity, 1 stop, no flow control and matches the config in Putty.
 
Where do I find the modified u-boot in armbian image?
 
I'm stuck here, and I don't know how to proceed.
 
Thank you
Genesio

I am now trying following steps from here: https://github.com/nightseas/arm_applications/blob/master/doc/getting_started_with_clearfog_base.md#boot-from-usb-disk----download-armbian-to-emmc
from inside armbian running from the USB stick:
 
dd'ing the img to the eMMC device was successful:
root@clearfogbase:~# dd if=/root/Armbian_5.35_Clearfogbase_Ubuntu_xenial_default_4.4.102.img of=/dev/mmcblk0 bs=4M 352+0 records in 352+0 records out 1476395008 bytes (1.5 GB, 1.4 GiB) copied, 79.9802 s, 18.5 MB/s root@clearfogbase:~# sudo mount /dev/mmcblk0p1 /mnt mount: special device /dev/mmcblk0p1 does not exist I was not able to mount the partition in order to modify the armbianEnv.txt.
But, as I have a uSD card into the slot, I am trying to boot from eMMC anyway.
 
So I just went on with dd'ing the bootloader to the eMMC:
root@clearfogbase:~# echo 0 > /sys/block/mmcblk0boot0/force_ro root@clearfogbase:~# echo 0 > /sys/block/mmcblk0boot1/force_ro root@clearfogbase:~# sudo dd if=u-boot.mmc of=/dev/mmcblk0boot0 1836+1 records in 1836+1 records out 940108 bytes (940 kB, 918 KiB) copied, 0.167683 s, 5.6 MB/s root@clearfogbase:~# sudo dd if=u-boot.mmc of=/dev/mmcblk0boot1 1836+1 records in 1836+1 records out 940108 bytes (940 kB, 918 KiB) copied, 0.17947 s, 5.2 MB/s root@clearfogbase:~# echo 1 > /sys/block/mmcblk0boot0/force_ro root@clearfogbase:~# echo 1 > /sys/block/mmcblk0boot1/force_ro root@clearfogbase:~# sync  
Now I think I could just set the dip switches into eMMC boot position and reboot.
Is that correct?

Ok, it works.
after setting the DIP switches to eMMC boot, I rebooted with the uSD card into the slot and armbian was running fine from eMMC.
 
Then I logged in and modified the armbianEnv.txt
 
The clearfog now boots from eMMC without uSD card into the slot.
 
Thank you for your help and patience
 

I summarized the content of a few sites and wrote a complete installation guide for Armbian on a Clearfog pro and Clearfog base.

You will need
a FAT formatted USB Stick where you can store the Armbian image and some bootloader files an USB A to microUSB B cable Clearfog Base or Pro with a power adapter Prepare installation files
mkdir -p /opt/clearfog_installation cd /opt/clearfog_installation curl https://wiki.solid-run.com/lib/exe/fetch.php?media=products:a38x:software:debian:clearfog-emmc-v3.tar.gz --output clearfog-emmc-v3.tar.gz tar xfz clearfog-emmc-v3.tar.gz  
Copy following files to an USB stick
 
mnt <your usb> /mnt/ mv u-boot-clearfog-base-mmc.kwb zImage armada-388-clearfog.dtb /mnt/ Put Armbian to the stick
You have to create the _extlinux_ directory and put the _extlinux.conf_ into it. You'll need this do boot a linux image. With it you will be able to write the Armbian image to the eMMC memory
mkdir -p /mnt/extlinux mv extlinux.conf /mnt/extlinux/ cd /mnt/extlinux/  
Clearfog Pro
   
wget https://dl.armbian.com/clearfogpro/Debian_stretch_next.7z Clearfog Base
   
wget https://dl.armbian.com/clearfogbase/Debian_stretch_next.7z
Extract and check integrity
7za e Debian_stretch_next.7z shasum -a 256 -c sha256sum.sha Armbian_*.img STRG+c cd /opt/clearfog_installation umount /mnt  
 
Next Steps
Plug in USB stick to the Clearfog Plug in USB cable (USB A site) to the PC Plug in USB cable (microUSB B site) to the Clearfog Set Jumper to UART **0 1 0 0 1**  
PC
The maintainer delivers *kwboot* for the installation. With it you can send the u-boot bootloader to the device
   
./kwboot -t -b u-boot-clearfog-base-uart.kwb /dev/ttyUSB0  
Clearfog
- Power up the Clearfog
- Wait a few minutes of the U-Boot image to download
- !! Hit a key to stop autoboot !!
- Configure the eMMC to boot from hardware boot partition
 
PC (kwboot terminal)
mmc partconf 0 1 1 0 date reset run bootcmd_usb0 login with _root_
 
mount /dev/sda1 /mnt dd if=/mnt/extlinux/Armbian_5.59_Clearfogpro_Debian_stretch_next_4.14.66.img of=/dev/mmcblk0 bs=1M conv=fsync hdparm -z /dev/mmcblk0 umount /mnt/ mount /dev/mmcblk0p1 /mnt/ echo 0 > /sys/block/mmcblk0boot0/force_ro dd if=/mnt/usr/lib/linux-u-boot-next-clearfogpro_5.59_armhf/u-boot.mmc of=/dev/mmcblk0boot0 sed -i 's/emmc_fix=off/emmc_fix=on/g' /mnt/boot/armbianEnv.txt umount /mnt/ poweroff  
PC (a second terminal)
killall kwboot screen /dev/ttyUSB0 115200  
Clearfog
Unplug power adapter Set jumpers to **0 0 1 1 1** Plugin power jack Now you should see Armbian booting up in the terminal were you executed the _screen_ command

Sources
First insights (armbian.com)
Maintainers installation guide (wiki.solid-run.com)
First hint for armbian bootloader installation (armbian.com)
Final Armbian bootloader installation hint

Latest RK3399 arrival in the lab. For now just some q&d photographs:
 



 
@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
 
A quick preliminary specifications list:
RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

-And I haven't even begun yet.
 
I think it's important to understand the details on how the boot-process works. Once you have this knowledge, you'll know much better how to get things working if something gets messed up.
 
The CPU has a small on-chip boot-ROM. In this boot-ROM, there's code that cannot be altered.
This code is the code that checks the 3 jumper connections; usually these are set to load the boot-loader from SPI NOR-Flash.
If there's something messed up, you'll not get the "Marvell >>" prompt, but instead you'll get a single "> " - still, don't worry if that happens, because there is a way out.
When the boot-loader is 'trusted-firmware'-verified, then it is loaded (usually from SPI NOR-Flash as mentioned earlier, but could also be from SATA, UART or eMMC), and finally this boot-loader is executed. The boot-ROM code has now done its job.
 
The bootloader that was just loaded and executed is usually Uboot (it could be anything; even your own code).
This bootloader is the one that presents you with the "Marvell >>" prompt and allows you to interrupt the boot-process by pressing for instance space or return.
If the bootloader is not interrupted by a keypress within the timeout (usually 2 seconds), then it issues one single command automatically:
run bootcmd
-This 'bootcmd' is nothing but an environment variable. It contains a string that is executed by Uboot's command-interpreter.
You can issue this command to see what's in the variable:
 
printenv bootcmd
 
My 'bootcmd' looks like this:
run boot_armbian
 
-Yours might be different.
So another environment variable is being executed by the command-interpreter.
That environment variable holds instructions on ...
1: Get netboot images - just in case we're netbooting via PXE
2: Setup boot parameters
3: Probe the block devices, in order to find the most likely block-device to boot from (such as MicroSD-card/USB/SATA)
   Probing is usually done by the 'test' command. A boot-interface and boot-device is chosen (those are usually kept in environment variables)
   The boot-interface could for instance be "scsi" if you're booting from SATA or "mmc" if you're booting from a MicroSD card
4: Load the kernel image and emergency image (usually done by the ext4load command)
5: Execute kernel image (done by the 'iboot' command).
 
When step 5 is executed, Uboot finished its task and the kernel takes over.
If something goes wrong, the emergency disk image is brought up.
 
 
... If you at some point are at the "Marvell >>" prompt and want to play around, here's a few things you can try out:
 
If you have a SATA disk connected:
scsi scan; scsi dev 0:1
ext4ls scsi 0:1 /
 
If you have a MicroSD card inserted:
ext4ls mmc 0:1 /
 
If you have a USB block-device attached:
ext4ls usb 0:1 /
ext4ls usb 1:1 /
 
The number before the colon is the device number, the number after the colon is the partition.
-So if you have your rootfs on partition 12 on your SATA drive, then you could for instance ...
ext4ls scsi 0:14 /bin
... to see some of the executable files on that partition.
 
Note: 'scsi scan' probes the SATA interface; you will not be able to do anything useful with the device without issuing that command.
 
You can also set some environment variables if you wish to:
setenv myVariable "echo hello there"
printenv myVariable
echo $myVariable
run myVariable
 
You should be able to execute the boot instructions one-by-one until you reach 'iboot'.
 
Let's assume that you've found out how to make your board boot; you've written down all the commands necessary and tested that they indeed boot if you write them exactly as you have them ready (hopefully you have a terminal with copy-and-paste).
When you've got your commands tested, you can set the environment variables and save those variables to your SPI-Flash using this command:
saveenv
Wait for the prompt to return. Make sure you can type on the command-line (thus you will know that the writing is done).
After that, you can just boot as usual (either by typing 'boot' or 'reset' or by pressing the reset button).
-Do *not* press the reset button while the flash-memory is being written to; that will surely mess up things.
 
At this point, you may have tried some of the above; I expect that you're likely stuck somewhere, if so, please let me know where, so we can get you unstuck.

-And I haven't even begun yet.
 
I think it's important to understand the details on how the boot-process works. Once you have this knowledge, you'll know much better how to get things working if something gets messed up.
 
The CPU has a small on-chip boot-ROM. In this boot-ROM, there's code that cannot be altered.
This code is the code that checks the 3 jumper connections; usually these are set to load the boot-loader from SPI NOR-Flash.
If there's something messed up, you'll not get the "Marvell >>" prompt, but instead you'll get a single "> " - still, don't worry if that happens, because there is a way out.
When the boot-loader is 'trusted-firmware'-verified, then it is loaded (usually from SPI NOR-Flash as mentioned earlier, but could also be from SATA, UART or eMMC), and finally this boot-loader is executed. The boot-ROM code has now done its job.
 
The bootloader that was just loaded and executed is usually Uboot (it could be anything; even your own code).
This bootloader is the one that presents you with the "Marvell >>" prompt and allows you to interrupt the boot-process by pressing for instance space or return.
If the bootloader is not interrupted by a keypress within the timeout (usually 2 seconds), then it issues one single command automatically:
run bootcmd
-This 'bootcmd' is nothing but an environment variable. It contains a string that is executed by Uboot's command-interpreter.
You can issue this command to see what's in the variable:
 
printenv bootcmd
 
My 'bootcmd' looks like this:
run boot_armbian
 
-Yours might be different.
So another environment variable is being executed by the command-interpreter.
That environment variable holds instructions on ...
1: Get netboot images - just in case we're netbooting via PXE
2: Setup boot parameters
3: Probe the block devices, in order to find the most likely block-device to boot from (such as MicroSD-card/USB/SATA)
   Probing is usually done by the 'test' command. A boot-interface and boot-device is chosen (those are usually kept in environment variables)
   The boot-interface could for instance be "scsi" if you're booting from SATA or "mmc" if you're booting from a MicroSD card
4: Load the kernel image and emergency image (usually done by the ext4load command)
5: Execute kernel image (done by the 'iboot' command).
 
When step 5 is executed, Uboot finished its task and the kernel takes over.
If something goes wrong, the emergency disk image is brought up.
 
 
... If you at some point are at the "Marvell >>" prompt and want to play around, here's a few things you can try out:
 
If you have a SATA disk connected:
scsi scan; scsi dev 0:1
ext4ls scsi 0:1 /
 
If you have a MicroSD card inserted:
ext4ls mmc 0:1 /
 
If you have a USB block-device attached:
ext4ls usb 0:1 /
ext4ls usb 1:1 /
 
The number before the colon is the device number, the number after the colon is the partition.
-So if you have your rootfs on partition 12 on your SATA drive, then you could for instance ...
ext4ls scsi 0:14 /bin
... to see some of the executable files on that partition.
 
Note: 'scsi scan' probes the SATA interface; you will not be able to do anything useful with the device without issuing that command.
 
You can also set some environment variables if you wish to:
setenv myVariable "echo hello there"
printenv myVariable
echo $myVariable
run myVariable
 
You should be able to execute the boot instructions one-by-one until you reach 'iboot'.
 
Let's assume that you've found out how to make your board boot; you've written down all the commands necessary and tested that they indeed boot if you write them exactly as you have them ready (hopefully you have a terminal with copy-and-paste).
When you've got your commands tested, you can set the environment variables and save those variables to your SPI-Flash using this command:
saveenv
Wait for the prompt to return. Make sure you can type on the command-line (thus you will know that the writing is done).
After that, you can just boot as usual (either by typing 'boot' or 'reset' or by pressing the reset button).
-Do *not* press the reset button while the flash-memory is being written to; that will surely mess up things.
 
At this point, you may have tried some of the above; I expect that you're likely stuck somewhere, if so, please let me know where, so we can get you unstuck.

Not enough. The recovery image is loaded to RAM only, so when you reset it goes away and you boot again from a borked image once jumpers are back to normal.
 
What you need to do is use the image in RAM you just booted from to flash a good one to SPI.
 
After WtpDownload finishes, going back to the serial terminal and pressing enter a couple of times should give you a working uboot prompt (with your UART image that now can write to your flash). From there you should be able to use the bubt command like explained here, or some other of the commands in that page to make your changes permanent.

So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! 
 
Steps:
Had to use miniterm: miniterm --eol CR /dev/ttyUSB0 115200 rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted. Set the jumpers for UART recovery and powered the board. In miniterm I hit enter until I got the E prompt, then entered "wtp". Then I ran the upload:  <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E  
As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence.
I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it.
I flashed it to SPI:
Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-2g-2cs-1000_800.bin" from "usb" to "spi" USB0:   Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1:   USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found reading flash-image-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB     Updating, 8% 126859 B/s    Updating, 16% 127704 B/s    Updating, 31% 167458 B/s    Updating, 39% 155994 B/s 262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s Done! I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.
 

Probably the easiest and fastest way to set up an Ubuntu Xenial build environment (needed by the armbian build scripts) is using a chroot jail. This thread should be a quick copy paste "tutorial" to create your own chroot jail and on an Debian based linux installation.
 
1.) Install debootstrap
$ sudo apt install debootstrap  
2.) Chreate chroot jail using debootstrap
$ sudo debootstrap --variant=buildd --arch=amd64 xenial ./system/ http://archive.ubuntu.com/ubuntu/  
3.) Mount your local system into the chroot
$ for f in dev dev/pts proc sys ; do sudo mount -o bind /$f ./system/$f ; done 4.) Mount resolv.conf from host system into chroot
$ sudo mount --bind /etc/resolv.conf ./system/etc/resolv.conf  
5.) Enter the chroot and install some important packages
$ sudo chroot ./system $ apt install -y sudo nano git 6.) Add universe to your chroots repo list (needed by the build scripts)
$ sudo nano /etc/apt/sources.list change from: deb http://archive.ubuntu.com/ubuntu xenial main to: deb http://archive.ubuntu.com/ubuntu xenial main universe then: $ sudo apt update 7.) Download and start build script in root users home directory
$ cd $ git clone https://github.com/armbian/build $ cd build $ service apt-cacher-ng start ( $ export EXPERT=yes ) $ ./compile.sh Now you can start building your images from source
I know this is not rocket science, but I think this might help some people getting into Armbian!