Jens Bauer Posted February 20, 2018 Share Posted February 20, 2018 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. Link to comment Share on other sites More sharing options...
Technicavolous Posted February 20, 2018 Share Posted February 20, 2018 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 ;] Link to comment Share on other sites More sharing options...
Igor Posted February 20, 2018 Share Posted February 20, 2018 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. Link to comment Share on other sites More sharing options...
Jens Bauer Posted February 20, 2018 Author Share Posted February 20, 2018 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). Link to comment Share on other sites More sharing options...
zador.blood.stained Posted February 20, 2018 Share Posted February 20, 2018 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. Link to comment Share on other sites More sharing options...
Jens Bauer Posted February 20, 2018 Author Share Posted February 20, 2018 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" Link to comment Share on other sites More sharing options...
Jens Bauer Posted February 20, 2018 Author Share Posted February 20, 2018 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. Link to comment Share on other sites More sharing options...
Jens Bauer Posted February 20, 2018 Author Share Posted February 20, 2018 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 ? Link to comment Share on other sites More sharing options...
Igor Posted February 20, 2018 Share Posted February 20, 2018 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 Link to comment Share on other sites More sharing options...
Recommended Posts