I've attempted to install Ubuntu_xenial_default_4.4.112.

In order to get this to work, I tried to follow the instructions on the download page as close as I could...

Downloaded flash-image-2g-1000_800_boot_sd_and_usb.bin (because I have a 2GB model, which reports CPU-speed 1000 MHz and DDR 800 MHz.

Formatted an USB-stick as FAT, copied flash-image-2g-1000_800_boot_sd_and_usb.bin to that stick, unmounted it.

Inserted the USB-stick in the EspressoBIN, rebooted the EspressoBIN.

Via the terminal I typed

Quote

bubt flash-image-MEM-CPU_DDR_boot_sd_and_usb.bin spi usb

... When it was done updating and returned to the "Marvell>>" prompt, I pressed the RESET button on the board.

The board attempts to reboot, I get the board info, and right after the SF line, I get a warning and later a few errors...

Quote

 

SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB

*** Warning - bad CRC, using default environment

 

Net:   eth0: neta@30000 [PRIME]

Hit any key to stop autoboot:  0 

*** ERROR: `serverip' not set

*** ERROR: `serverip' not set

Bad Linux ARM64 Image magic!

Marvell>>

 

 

CRC-error - does that mean that the boot image was not written properly to the SPI flash ?

Note: The bootcmd *has* changed; now it reads:

Quote

 

Marvell>> printenv bootcmd

bootcmd=run get_images; run set_bootargs; booti $kernel_addr $ramfs_addr $fdt_addr

Marvell>> printenv image_name

image_name=Image

Marvell>> printenv fdt_name

fdt_name=fdt.dtb

Marvell>> printenv ipaddr

0.0.0.0

Marvell>> printenv serverip

0.0.0.0

Marvell>> printenv ramfs_name

ramfs_name=-

 

... As I understand it, it seems it's attempting to netboot via tftp (which is why I looked at the IP adresses).

Note: I can still do a ...

Quote

scsi scan; ext4ls scsi 0:1 /

... which displays the directory on /dev/sda1 (boot partition)

 

I assume that the boot image should be "Image", but I have no clue which of the 28 .dtb files I should use.

(and whether to load them from /dtb/marvell or /dtb-4.4.112-mvebu64/marvell.

 

Sure looks similar to the issue I had with my Clearfog Pro. u-boot starts doing all sorts of stuff and is a real bear to try to figure out.

 

I ended up creating a tftp server on my Odroid, found the files it was looking for and put them on my tftp server. It took some sleuthing but I eventually figured out the whole magic is the boot script finally being written to wherever u-boot looks for it, in my case the root directory.

 

Seems like u-boot is set up to try several configurations and run with whatever it finds. My solution was several steps but I got a clean working system using buildroot to copy what I needed.

 

Your bad CRC indicates it couldn't read something. Could be looking somewhere else, or your local disk / mmc or whatever isn't built quite right.

Image name 'Image' seems like a variable. u-boot likes to pack variables into variables so that can be a chore to chase down. Big clues for you should be serverip and ipaddr not set. Bad magic means the load failed. Everything I dealt with.

 

I Did a fairly good description of how I conquered similar, take a look here.

 

If it's totally irrelevant, sorry ;]

 

29 minutes ago, Jens Bauer said:

Marvell>> printenv bootcmd

bootcmd=run get_images; run set_bootargs; booti $kernel_addr $ramfs_addr $fdt_addr

Marvell>> printenv image_name

image_name=Image

Marvell>> printenv fdt_name

fdt_name=fdt.dtb

Marvell>> printenv ipaddr

0.0.0.0

Marvell>> printenv serverip

0.0.0.0

Marvell>> printenv ramfs_name

ramfs_name=-

This is not our u-boot. This is probably stock (unchanged).

https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-mvebu64/loading-uboot-script.patch
As you can see our boot command is changed to load boot script from SD or USB.

Download flash again and repeat the procedure. I hope you don't have a faulty flash.

 

13 minutes ago, Igor said:

This is not our u-boot. This is probably stock (unchanged).

 

It never said CRC-error before, so something has changed. Perhaps this is a fail-safe / backup uboot ?

 

13 minutes ago, Igor said:

https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-mvebu64/loading-uboot-script.patch
As you can see our boot command is changed to load boot script from SD or USB.

Download flash again and repeat the procedure. I hope you don't have a faulty flash.

 

Alright, I'll try re-downloading and re-flashing. Is there any way I can verify that the .bin file is not corrupt ?

(I'd prefer downloaded a tar.bz2 file, so the archiver checks the archive integrity for me).

2 minutes ago, Jens Bauer said:

It never said CRC-error before, so something has changed. Perhaps this is a fail-safe / backup uboot ?

U-boot should print its version and compilation date somewhere at the beginning - that should be a good indication of a correct flashing.

The CRC error is irrelevant on most boards since Armbian doesn't rely on stored u-boot environment.

31 minutes ago, Igor said:

This is not our u-boot. This is probably stock (unchanged).

https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-mvebu64/loading-uboot-script.patch
As you can see our boot command is changed to load boot script from SD or USB.

Download flash again and repeat the procedure. I hope you don't have a faulty flash.

 

Before doing anything else, on my Mac, I made a backup-copy of the image that I flashed.

Then I downloaded the image again, and did a 'diff oldimg newimg' and diff didn't say that the images were different, so the images match.

I removed the old image from the USB-stick and copied the new image there anyway.

I tried re-flashing the bootloader; CRC check pass and it even said that it didn't write anything this time.

When I boot, I no longer get the CRC-warning I got earlier (?!??), but otherwise things stay the same.

 

I also tried checking if the load_script environment variable was set...

Quote

 

Marvell>> printenv load_script

## Error: "load_script" not defined"

 

 

19 minutes ago, zador.blood.stained said:

U-boot should print its version and compilation date somewhere at the beginning - that should be a good indication of a correct flashing.

The CRC error is irrelevant on most boards since Armbian doesn't rely on stored u-boot environment.

Before I flashed the image onto the SPI-flash, this was my U-boot version:

Quote

U-Boot 2017.03-armada-17.06.3-ga33ecb8 (Jul 05 2017 - 14:30:47 + 0800)

 

After re-flashing, this is what I get:

Quote

U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200)

-So it's definitely changed.

Just tried a 'strings flash-image-2g-1000_800_boot_sd_and_usb.bin'

 

and I could not find 'load_script' anywhere.

So I searched for image_name and it says:

Quote

image_name=Image

-Which indicates that this image is not what's on github.

 

If I search for get_images, I find this:

Quote

bootcmd=run get_images; run set_bootargs; booti $kernel_addr $ramfs_addr $fdt_addr

 

... Does this mean that the file I downloaded is an older file, which is actually not relevant ?

22 minutes ago, Jens Bauer said:

U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200)

That is ok. Then you probably only need to recreate and save u-boot environment. I am not completely sure ... this was some temporal solution and we don't have resources to move on with this board.

 

One idea to try:
 

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/SATA\";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"
setenv initrd_addr 0x1100000
setenv image_name "boot/Image"
setenv bootcmd "run get_images; run set_bootargs; run load_script;"

Try if it works with:

run bootcmd

If it does, repeat and save this to flash with 

saveenv