skandalfo

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.

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

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.