Search the Community
Showing results for tags 'espressobin'.
-
I've got Jammy Minimal running on my EspressoBin v7 from Armbian_23.5.1_Espressobin_jammy_current_5.15.113_minimal. All seems to be working except the NICs do not auto-start with the system. Only lo starts. I have to "ip link set lan0 up" and "dhclient" each time it reboots. My /etc/network/interfaces: source /etc/network/interfaces.d/* # Network is managed by Network manager auto lo iface lo inet loopback auto lan0 allow-hotplug lan0 iface lan0 inet dhcp The NetworkManager.service is running. How do I make lan0 auto start? Thanks
-
I try to boot for first time an espresso bin v5, I followed the advice in (Espressobin / Ultra – Armbian](https://www.armbian.com/espressobin/) and updated my uboot, and reset the environment. env default -a ## Resetting to default environment I added the image and fdt address with: setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv image_name boot/Image setenv scriptaddr 0x6d00000 The last line is after seeing in the forum that this setting has been erased when resetting the default environment my environment is now: When I try to boot, it seems to load the initrd but never complete the boot I get: Marvell>> boot *** ERROR: `serverip' not set *** ERROR: `serverip' not set ... booting from SD 1631 bytes read in 9 ms (176.8 KiB/s) ## Executing script at 00800000 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Info: input data size = 2100 = 0x834 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument. If you do not pass a third a bd_info struct will be passed instead Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep - OS specific prep before relocation or go go - start OS 21764608 bytes read in 2021 ms (10.3 MiB/s) ext4load - load binary file from a Ext4 filesystem Usage: ext4load <interface> [<dev[:part]> [addr [filename [bytes [pos]]]]] - load binary file 'filename' from 'dev' on 'interface' to address 'addr' from ext4 filesystem 11618 bytes read in 12 ms (945.3 KiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f05d61 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.15.48-mvebu64 (root@8b3d501f9218) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.3 SMP PREEMPT Wed Jun 22 07:22:16 UTC 2022 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') ..... Omitted a long boot log .... [ 2.376178] Key type fscrypt-provisioning registered [ 2.383950] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no [ 2.394740] d0012000.serial: ttyMV0 at MMIO 0xd0012000 (irq = 0, base_baud = 1562500) is a mvebu-uart [ 2.404251] printk: console [ttyMV0] enabled [ 2.404251] printk: console [ttyMV0] enabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.425972] xenon-sdhci d00d0000.sdhci: Got CD GPIO [ 2.464648] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA [ 2.473851] Waiting for root device ... [ 2.512635] mmc0: new high speed SDHC card at address d6d7 [ 2.520455] mmcblk0: mmc0:d6d7 SU08G 7.40 GiB [ 2.531514] mmcblk0: p1 It seems that my boot env is incomplete. I tried with the last bullseyes and bookworm image, with the same result. I also tried the instructions in Armbian Documentation - Esspresso bin even if it seems obsolete by now, as it uses old uboot variable names, and contain a booiti command after sourcing the boot.scr script which itself contain the booti command; but I got the same result, even if the inird addr was distinct. Please what is wrong, and what I'm missing in this uboot environment.
-
Hello- Just got my EspressoBin v7, trying to boot to SD using Armbian 23.02 Bullseye. Followed instructions at https://www.armbian.com/espressobin/. Board is 2GB, so I used flash-image-DDR4-2g_2cs_6-1200_750.bin. U-Boot showed CPU runs at 1200, and I confirmed "C120" on the chip. Interrupt boot process bubt flash-image-DDR4-2g_2cs_6-1200_750.bin spi usb env default -a saveenv Flashed Armbian_23.02.2_Espressobin_bullseye_current_5.15.93_minimal.img to a new SanDisk SD card with belenaEtcher and dd. Board doesn't boot, I get "Wrong image format for "source" command" then it tries to boot other devices. I've tried a second new SD card and both minimal and not minimal filesystems with the same result. Any suggestions or advice is greatly appreciated. My U-Boot output: TIM-1.0 mv_ddr-devel-g251bc63 DDR4 16b 2GB 2CS WTMI-devel-18.12.1-1d97715 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.225V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (May 16 2022 17:51:06) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):a921da5e NOTICE: BL1: Built : 17:55:48, May 16 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):a921da5e NOTICE: BL2: Built : 17:55:48, May 16 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):a921da5e NOTICE: BL31: Built : 17:55:48, May 16 2022 U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000) DRAM: 2 GiB Core: 38 devices, 20 uclasses, devicetree: fit WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Executing script at 06000000 Wrong image format for "source" command SCRIPT FAILED: continuing... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk sdhci@d0000.blk... Found 2 disks No EFI system partition ERROR: invalid device tree starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device scanning bus for devices... Device 0: unknown device (NULL udevice *): mvneta_setup_txqs: can't create txq=0 BOOTP broadcast 1 timeout: packet not sent BOOTP broadcast 2 timeout: packet not sent BOOTP broadcast 3 timeout: packet not sent My printenv: => printenv boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kei boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf} boot_net_usb_start=usb start boot_pci_enum=pci enum boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_syslinux_conf=extlinux/extlinux.conf boot_targets=mmc1 mmc0 usb0 scsi0 pxe dhcp bootcmd=run distro_bootcmd bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;se; bootcmd_mmc0=devnum=0; run mmc_boot bootcmd_mmc1=devnum=1; run mmc_boot bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi bootcmd_scsi0=devnum=0; run scsi_boot bootcmd_usb0=devnum=0; run usb_boot bootfstype=ext4 criptaddr=0x6d00000 distro_bootcmd=scsi_need_init=; setenv nvme_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done efi_dtb_prefixes=/ /dtb/ /dtb/current/ eth1addr=00:51:82:11:22:01 eth2addr=00:51:82:11:22:02 eth3addr=00:51:82:11:22:03 ethact=ethernet@30000 ethaddr=00:51:82:11:22:00 fdt_addr=0x6f00000 fdt_addr_r=0x6f00000 fdtcontroladdr=7fadcf40 fdtfile=marvell/armada-3720-espressobin-v7.dtb kernel_addr=0x7000000 kernel_addr_r=0x7000000 load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi nvme_boot=run boot_pci_enum; run nvme_init; if nvme dev ${devnum}; then devtype=nvme; run scan_dev_for_boot_part; fi nvme_init=if ${nvme_need_init}; then setenv nvme_need_init false; nvme scan; fi pxefile_addr_r=0x6e00000 ramdisk_addr_r=0xa000000 sata_boot=if sata dev ${devnum}; then devtype=sata; run scan_dev_for_boot_part; fi scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run sca; scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devpt scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefixe scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinuxi scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Be scsi_boot=run boot_pci_enum; run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi stderr=serial@12000 stdin=serial@12000 stdout=serial@12000 usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi ver=U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000) Environment size: 4408/65532 bytes
-
Hi all, I came upon a few threads in this forum while working on the bootloader for my ESPRESSObin Ultra. I noticed all of the warnings here about CPU frequency (https://www.armbian.com/espressobin/#), and I think this community might be interested in the work I'm doing. I've have an ESPRESSObin Ultra which ships from Globalscale with old, buggy, and unmaintained firmware. I think the old firmware could explain a lot of the issues users have reported here with the V7. I forked the old factory firmware build script from Globalscale and moved it all to up-to-date, upstream projects: https://github.com/bschnei/ebu-bootloader I believe with some small modifications, it is possible to also build an up-to-date bootloader for other Globalscale devices that also use the Armada 37XX SoC, for example the ESPRESSObin V7. I currently use Arch Linux ARM on my device and have notified their community as well: https://archlinuxarm.org/forum/viewtopic.php?f=67&t=16746 One of the issues I can confirm has been fixed is EFI booting from U-Boot. Fixing this means we can use U-Boot Standard Boot (bootflow scan) to load user-friendly EFI apps like systemd-boot, GRUB, etc. This significantly streamlines the boot process eliminating the need for u-boot to load separate kernel, initramfs, and device tree files. This also makes packaging it a lot easier too. It also means your bootloader becomes configurable from the OS which is really nice because it means your distro of choice can configure the bootloader instead of requiring users to configure U-Boot manually. I'm not familiar with Armbian, but I think it ships with systemd-boot (?) which has an EFI application that gives you a user friendly way to control device booting. GRUB has a similar capability. Please send me a note if you are interested in testing firmware for the ESPRESSObin V7 or Ultra.
-
This is just to report, that Image file Armbian_23.11.1_Espressobin_bookworm_current_5.15.139.img.xz is not mounting. Downloaded from https://armbian.site-meganet.com/dl/espressobin/archive/Armbian_23.11.1_Espressobin_bookworm_current_5.15.139.img.xz Mounting from loop or from USB gives the same error: # mount /dev/loop0p1 /mnt/img/ mount: /mnt/img: wrong fs type, bad option, bad superblock on /dev/loop0p1, missing codepage or helper program, or other error Is there other working image?
-
I was able to boot from a SATA disk that was manually setup with a GPT-formatted table and a debootstrap'ed debian arm64 kernel. The GPT partitions included: 1. BIOS from sector 34-2047, no filesystem 2. ESP from 2048-409599 (which u-boot calls bootable even if the flag isn't set), vfat filesystem 3. XBOOTLDR from 409600-819199 with bootable flag set (0x4), ext4 FS without journal 4. linux swap 5. ARM64 root (gdisk type 8305) with bit 60 set (read-only), ext4 without journal 6. linux /var (gdisk type 8310), ext4, with /srv/ and /home/ bind-mounted from /var/local/ The bootscripts/extlinux configuration live in /boot, onto which is mounted partition 3 (XBOOTLDR) next to the actual kernel/initramdisk. It is necessary to mark this partition bootable in gdisk to have the u-boot distro-boot search it for extlinux/boot.scr. While the espressobin doesn't require u-boot flashed on the boot media, this disk partition scheme would allow rockchip64 systems to boot if the BIOS partition is extended to somewhere around sector 32767 (as rockchip needs code at sector 64 and maybe 16384 and 24576).
-
I got the EspressoBin v7 running with Armbian_23.5.1_Espressobin_jammy_current_5.15.113_minimal. Trying to control the LEDs, but they are not where I would expect them: # ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Dec 31 1969 . drwxr-xr-x 57 root root 0 Dec 31 1969 .. lrwxrwxrwx 1 root root 0 Dec 31 1969 mmc0:: -> ../../devices/platform/soc/soc:internal-regs@d0000000/ d00d0000.sdhci/leds/mmc0:: Only one LED is listed. Where are the others? How can I enable them?
-
Where to find u-boot files? Download link from source page for EspressoBin doesn't work: https://www.armbian.com/espressobin/ gets you here:
-
I was running espressobin v7 with Welcome to Armbian 21.08.1 Bullseye with Linux 5.10.60-mvebu64 and made an upgrade in a regular way : # apt upgrade The following packages will be upgraded: apache2 apache2-bin apache2-data apache2-dev apache2-utils armbian-bsp-cli-espressobin armbian-config armbian-firmware armbian-zsh asterisk asterisk-config asterisk-modules asterisk-voicemail avahi-autoipd base-files bash curl deb.torproject.org-keyring dirmngr distro-info-data dpkg dpkg-dev ffmpeg gnupg gnupg-l10n gnupg-utils gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv gzip hostapd ifenslave inetutils-inetd inetutils-telnet libapache2-mod-php7.4 libavahi-client3 libavahi-common-data libavahi-common3 libavcodec58 libavdevice58 libavfilter7 libavformat58 libavresample4 libavutil56 libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libcups2 libcurl3-gnutls libcurl4 libdpkg-perl libfreetype6 libfribidi0 libgnutls30 libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 libldap-2.4-2 libldap2-dev libldb2 liblzma5 libnm0 libnss-myhostname libntfs-3g883 libpam-systemd libpcre2-16-0 libpcre2-32-0 libpcre2-8-0 libpcre2-dev libpcre2-posix2 libpostproc55 libpq5 libsdl2-2.0-0 libsmbclient libsnmp-base libsnmp40 libssl-dev libssl1.1 libswresample3 libswscale5 libsystemd0 libtiff5 libtirpc-common libtirpc-dev libtirpc3 libudev1 libwbclient0 libxml2 libxslt1.1 linux-dtb-current-mvebu64 linux-image-current-mvebu64 linux-libc-dev linux-u-boot-espressobin-current locales logrotate nano network-manager ntfs-3g openssh-client openssh-server openssh-sftp-server openssl php7.4 php7.4-cli php7.4-common php7.4-curl php7.4-json php7.4-opcache php7.4-readline python3-ldb python3-samba rsyslog samba samba-common samba-common-bin samba-libs smbclient systemd systemd-sysv tcpdump tor tor-geoipdb tzdata udev unzip wireless-regdb xz-utils zlib1g ... update-initramfs: Converting to u-boot format update-initramfs: Converting to u-boot FIT image FIT description: EspressoBIN 3720 FIT Image Created: Sun Oct 23 13:08:21 2022 Image 0 (kernel) Description: Vanilla Linux kernel Created: Sun Oct 23 13:08:21 2022 Type: Kernel Image Compression: lzma compressed Data Size: 6882687 Bytes = 6721.37 KiB = 6.56 MiB Architecture: AArch64 OS: Linux Load Address: 0x07000000 Entry Point: 0x07000000 Hash algo: sha1 Hash value: c8d92b9c244fdcc9fb56f640d05e6fc4d3f7ffb6 Image 1 (ramdisk) Description: Boot ramdisk Created: Sun Oct 23 13:08:21 2022 Type: RAMDisk Image Compression: Unknown Compression Data Size: 8909801 Bytes = 8700.98 KiB = 8.50 MiB Architecture: AArch64 OS: Linux Load Address: unavailable Entry Point: unavailable Hash algo: sha1 Hash value: 3be954cf886386101311f7673115fa0be0c95366 Image 2 (fdtv5) Description: Flattened Device Tree ebinv5 Created: Sun Oct 23 13:08:21 2022 Type: Flat Device Tree Compression: uncompressed Data Size: 11618 Bytes = 11.35 KiB = 0.01 MiB Architecture: AArch64 Load Address: 0x06f00000 Hash algo: sha1 Hash value: dcfa1e753a26493b713b8d6eee19e0895db09cc3 Image 3 (fdtv7) Description: Flattened Device Tree ebinv7 Created: Sun Oct 23 13:08:21 2022 Type: Flat Device Tree Compression: uncompressed Data Size: 11646 Bytes = 11.37 KiB = 0.01 MiB Architecture: AArch64 Load Address: 0x06f00000 Hash algo: sha1 Hash value: 0230f9e11a6f364dc66c0aca9a72620b19a0f1e0 Default Configuration: 'v5' Configuration 0 (v5) Description: Standard Boot ebinv5 Kernel: kernel Init Ramdisk: ramdisk FDT: fdtv5 Hash algo: sha1 Hash value: unavailable Configuration 1 (v7) Description: Standard Boot ebinv7 Kernel: kernel Init Ramdisk: ramdisk FDT: fdtv7 Hash algo: sha1 Hash value: unavailable After upgrade and reboot the kernel was upgraded to : Welcome to Armbian 22.08.6 Bullseye with Linux 5.15.74-mvebu64 The side effect is that cpu-freq regulation seems to be broken: root@tiger:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. The # htop is unable to determine it either : Cpu Freq: 0 MHz The previous setup before upgrade "Armbian 21.08.1 Bullseye with Linux 5.10.60-mvebu64" ran frequency switch flawlessly: # cpufreq-info current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:93.04%, 300 MHz:0.48%, 600 MHz:0.18%, 1.20 GHz:6.30% (215) Due to inability of CPU frequency regulation, I found that the board temperature has been increased by about 5 deg. C. What could be done to fix this issue?
-
Due to systemd, Journal is going to replace all journals sooner or later, it's already one of the busiest journaling on the sytem. The logs are binary and can't be rotated like text logs, they are already compressed and can't be read by text editor, instead only by journalctl. Thus, in /usr/lib/armbian/armbian-ramlog , the directory /var/log/journal is excluded from standard log rotation and copying to HDD. Instead, it is copied once to /var/log.hdd/journal and a soft-link is created: /var/log/journal pointing to -> /var/log.hdd/journal . The RAM logging was introduced to spare the SD card, preventing many write actions that wear the SD card quickly. But this really busy log, including all system messages, is now written directly to the SD card. If this is the only way of preserving older systemd logs, shouldn't we then at least reconfigure journald in a way to e.g. log into RAM /run/log/journal and only snyc to SD card every n hours? Or maybe we could reduce the log level of journald (which is by default "debug") to e.g. "err" and reduce the write activity in that way? For me, it appears right now, that all the benefits of logging to RAM disk are canceled out by having journald log to SD card? Please correct me if I am mistaken in any of my assumptions above.
-
Recently acquired an Espressobin Ultra. When I attach an ssd (a Kingston 500GB NVMe 2280 M.2) to it the device won't start. It displays no sign of powering on. I have tried two different SSDs. no difference. Without one attached as soon as power sis applied all the ethernet interface LEDs flash briefly. With the SSD card that doesn't happen. There is no activity at the console. Do I need to change jumpers or do some other setting at the Marvell prompt before attaching it? Help would be much appreciated. Many thanks LA.
-
Dear community, I'm trying to add some storage to espressobin board and idea to utilize existing mini pcie socket for that was very appealing. I have bought Mini PCI-E to NVME Adapter on aliexpress (PCI-E to NVME Adapter) and Samsung PM991a 256Gb drive. To my surprise it is almost worked immediately - drive is detected and appeared in system as nvme device. The next step would be to check if it works and I was hit by a failure immediately, Reading from drive using dd command seems to work for first 19 Mb's seems to work, but attempt to ready anything beyond 20 Mb mark produces drive freeze and then disconnect. Drive becomes unusable until power cycle. Command I have used: dd if=/dev/nvme0n1 of=/dev/null bs=1M status=progress count=20 Dmesg shows following output: [ 134.109735] nvme nvme0: I/O 288 QID 2 timeout, aborting [ 134.109797] nvme nvme0: I/O 289 QID 2 timeout, aborting [ 164.828756] nvme nvme0: I/O 288 QID 2 timeout, reset controller [ 195.547760] nvme nvme0: I/O 16 QID 0 timeout, reset controller [ 256.769932] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 [ 256.786083] blk_update_request: I/O error, dev nvme0n1, sector 40704 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 256.786183] blk_update_request: I/O error, dev nvme0n1, sector 41472 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 256.786367] nvme nvme0: Abort status: 0x371 [ 256.786381] nvme nvme0: Abort status: 0x371 [ 287.322517] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 [ 287.322547] nvme nvme0: Removing after probe failure status: -19 [ 317.841253] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 [ 317.841505] Buffer I/O error on dev nvme0n1, logical block 5088, async page read [ 317.841524] nvme0n1: detected capacity change from 500118192 to 0 This output is quite similar to broken APST support and workaround to add "nvme_core.default_ps_max_latency_us=0" to kernel parameters is usually advised. Unfortunately it didn't help in my situation. Right now I'm actually out of ideas how to troubleshoot the problem further and seeking for advice from community... System itself is up to date: root@espressobin:~# uname -a Linux espressobin 5.15.93-mvebu64 #23.02.2 SMP PREEMPT Fri Feb 17 23:51:39 UTC 2023 aarch64 GNU/Linux root@espressobin:~# cat /etc/deb debconf.conf debian_version root@espressobin:~# cat /etc/debian_version 11.6 root@espressobin:~# cat /etc/issue Armbian 22.11.1 Bullseye \l
-
TIM-1.0 mv_ddr-devel-g251bc63 DDR4 16b 2GB 2CS WTMI-devel-18.12.1-1d97715 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (May 16 2022 17:51:06) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):a921da5e NOTICE: BL1: Built : 17:55:48, May 16 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):a921da5e NOTICE: BL2: Built : 17:55:48, May 16 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):a921da5e NOTICE: BL31: Built : 17:55:48, May 16 2022 U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000) DRAM: 2 GiB Core: 38 devices, 20 uclasses, devicetree: fit WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 => mmc list sdhci@d0000: 0 sdhci@d8000: 1 => mmc dev 0 MMC: no card present => mmc dev 1 switch to partitions #0, OK mmc1(part 0) is current device => mmcinfo Device: sdhci@d8000 Manufacturer ID: 15 OEM: 0 Name: 4FTE4R Bus Speed: 52000000 Mode: MMC High Speed (52MHz) Rd Block Len: 512 MMC version 5.1 High Capacity: Yes Capacity: 3.6 GiB Bus Width: 8-bit Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 3.6 GiB WRREL Boot Capacity: 4 MiB ENH RPMB Capacity: 512 KiB ENH Boot area 0 is not write protected Boot area 1 is not write protected When I enter armbian, mmc cannot be detected........Several versions have the same problem, 22.11, 22.08, 22.05 root@espressobin:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 28.7G 0 disk └─sda1 8:1 1 28.4G 0 part / mtdblock0 31:0 0 3.9M 0 disk mtdblock1 31:1 0 64K 0 disk zram0 254:0 0 993.7M 0 disk [SWAP] zram1 254:1 0 50M 0 disk /var/log zram2 254:2 0 993.7M 0 disk /tmp root@espressobin:~# dmesg|grep -i mmc [ 1.393013] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA
-
Folks, it has been a long time since I messed around with my ebin v5, but just wanted give it a second chance as I need to do something about my EOL Cubietruck (and my "broken" NT4 domain). So I started a second attempt with "Armbian_22.08.1_Espressobin_bullseye_current_5.15.63" just a few days ago, but didn't got much further than updating uboot and to apt update / upgrade the system, before I got distracted again. In the meantime I noticed the new "Armbian_22.11.1_Espressobin_bullseye_current_5.15.80" and I thought it would be a better idea starting from scratch with that version. However, when I boot this up from SD the only interface shown ("ifconfig") is lo. (I 'see' the other port with "ifconfig -a", but I don't get an IP set (via DHCP) whatever physical port I use on the topaz switch, though the leds are happily blinking indicating a proper link.
-
Hi eveyone, I am coming from a a hint off Github here: https://github.com/armbian/documentation/issues/165. Igor was so kind and redirected me to this community. I am struggling since beginning christmas to get my EspressoBin to latest versions out of dusty 2018 images. Device EspressoBin v7 DDR4 1G 1000_800Mhz Baseline - What did I do? - Update U-Boot according https://www.armbian.com/espressobin to devel-18.12.3 - Flashed SD-Card with armbian Focal via Balena according https://docs.armbian.com/User-Guide_Getting-Started/ - Updated Boot Environment according https://www.armbian.com/espressobin/#kernels-archive-all Problem Description - U-Boot Loads and starts over to boot from SD-Card - Booting from SD fails with Marvell>> boot *** ERROR: serverip' not set *** ERROR: serverip' not set Bad Linux ARM64 Image magic! I would be very grateful for any hints how to get armbian booted on the EspressoBin in 2022! Happy Holidays to all. cheers Full Logs U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 800 [MHz] DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d0000: 0 Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] https://github.com/armbian/documentation/issues/165
-
I flashed my espressobin v7 with bubt flash-image-DDR4-1g_1cs_5-1000_800.bin spi usb and set u-boot prompt: printenv ethaddr env default -a saveenv After the boot printenv: TIM-1.0 mv_ddr-devel-g251bc63 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-1d97715 WTMI: system early-init CPU VDD voltage default value: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (May 16 2022 17:51:06) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):a921da5e NOTICE: BL1: Built : 17:54:27, May 16 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):a921da5e NOTICE: BL2: Built : 17:54:27, May 16 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):a921da5e NOTICE: BL31: Built : 17:54:27, May 16 2022 U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000) DRAM: 1 GiB Core: 38 devices, 20 uclasses, devicetree: fit WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk sdhci@d0000.blk... Scanning disk sdhci@d8000.blk... Found 4 disks No EFI system partition ERROR: invalid device tree switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Executing script at 06000000 Wrong image format for "source" command SCRIPT FAILED: continuing... libfdt fdt_check_header(): FDT_ERR_BADMAGIC ERROR: invalid device tree starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device scanning bus for devices... Device 0: unknown device (NULL udevice *): mvneta_setup_txqs: can't create txq=0 BOOTP broadcast 1 timeout: packet not sent BOOTP broadcast 2 timeout: packet not sent BOOTP broadcast 3 timeout: packet not sent BOOTP broadcast 4 timeout: packet not sent .................. ..............
-
Starting resolvconf-pull-resolved.service... [ OK ] Finished resolvconf-pull-resolved.service. Starting resolvconf-pull-resolved.service... [ OK ] Finished resolvconf-pull-resolved.service. Starting resolvconf-pull-resolved.service... [ OK ] Finished resolvconf-pull-resolved.service. Starting resolvconf-pull-resolved.service... [ OK ] Finished resolvconf-pull-resolved.service. [ ***] A start job is running for Wait for… to be Configured (57s / no limit) I stay here for a long time every time I start... Does anyone know why? Then an error message appears: [ OK ] Finished resolvconf-pull-resolved.service. Starting resolvconf-pull-resolved.service... [ OK ] Finished resolvconf-pull-resolved.service. [FAILED] Failed to start Wait for Network to be Configured. See 'systemctl status systemd-networkd-wait-online.service' for details. [ OK ] Reached target Network is Online. Starting LSB: Advanced IEEE 802.11 management daemon... Starting /etc/rc.local Compatibility... [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started /etc/rc.local Compatibility. Then when I follow the error prompt, the following message appears: root@espressobin:~# systemctl status systemd-networkd-wait-online.service ● systemd-networkd-wait-online.service - Wait for Network to be Configured Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; > Active: failed (Result: exit-code) since Thu 2022-11-10 12:34:58 UTC; 5min> Docs: man:systemd-networkd-wait-online.service(8) Process: 667 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exit> Main PID: 667 (code=exited, status=1/FAILURE) CPU: 153ms Nov 10 12:34:58 espressobin systemd-networkd-wait-online[667]: Event loop faile> Nov 10 12:34:58 espressobin systemd[1]: systemd-networkd-wait-online.service: M> Nov 10 12:34:58 espressobin systemd[1]: systemd-networkd-wait-online.service: F> Nov 10 12:34:58 espressobin systemd[1]: Failed to start Wait for Network to be > Warning: journal has been rotated since unit was started, output may be incompl
-
Hello Everyone! In the company where I am, we are migrating the current Zynq architecture with DDR3 to Armada 3700 family with DDR4. Before deciding to migrate, we bought some espressobin and were delighted with this product. We have therefore attempted to develop two cards that use the armada A3700 processor without success. We concluded that the problem is HW but we don't know exactly where. I have done numerous tests. I try to summarize the key points as briefly as possible. Our board uses DDR4 MT40A512M16LY-062E IT:E with Armada 88F3720-A0-BVB2I080-P123. We have created a TIM, WTMI, Uboot package using A3700-utils-marvell, mv-ddr-marvell and atf-marvell from github as indicated in http://espressobin.net/espressobin-ultra-build-instruction/. The package works correctly on espressobin V7. To test it we set the serial boot with the jumpers on the board then we used the tool A3700-utils-marvell/wtptp/linux/WtpDownload_linux . We tried to throw the same thing on our board but uboot didn't start. We then investigated further: to eliminate all the SW section above WTMI we modified the source code at A3700-utils-marvell/wtmi/sys_init/main.c by inserting a return 0 immediately inside the main (therefore after “u32 status”). On espressobin we see that the DDR switches correctly at 800MHz and the console goes back to the bootROM ones (therefore with the ">" symbol). On our board, however, the symbol is always that of the bootROM (we have never seen anything different) but the DDR does not switch at 800MHz: it remains at 400MHz instead. Deepening the topic, several registers have been read from the bootROM console. In particular: the section starting from address 1FFF_0000 onwards (at least 100 registers), the section starting from 2000_6000 (at least 100 registers) and the section starting at 6410_0000 have been read. Sections 1FFF_0000 and 2000_6000 have consistent content between our board and espressobin (this is also consistent with TIM and WTMI file). The section 6410_0000 instead is consistent on espressobin with the uboot binary but it is not so on our board. Random and non-repeatable data are read following a power down of our board. We have therefore concluded (I kindly ask for your confirmation) that the problem is the DDR. To rule out any possibility, our DDR was mounted on a V7 espressobin. The system starts correctly and has therefore validated the HW component. In order to generate the package that contains the TIM (which from what we understand describes among other things some registers to allow switching to 800MHz) we use the following command: export CROSS_COMPILE = / opt / toolchains / gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu / bin / aarch64-linux-gnu- export BL33 = $ BINARIES_DIR / u-boot.bin make DEBUG = $ MY_DBG USE_COHERENT_MEM = 0 LOG_LEVEL = 60 SECURE = 0 CLOCKSPRESET = CPU_600_DDR_600 DDR_TOPOLOGY = 5 BOOTDEV = SPINOR PARTNUM = 0 PLAT = a3700 all fip CLOCKSPRESET = CPU_800_DDR_800 was also tried. The variations of this parameter are seen on espressobin (with oscilloscope on DDR clock) but not on our board (which remains at 400MHz). Further analyzing the A3700-utils-marvell/tim/ddr/DDR_TOPOLOGY_5.txt file and the "ddr_tool" sources present in mv-ddr-marvell/. The ddr_tool are compiled by us with the following: export PLATFORM = a3700 export DDR_TYPE = DDR4 make clean make We tried to change the value of CL and CWL. Putting wrong values also the espressobin stops (like our board) but we were not able to start our board instead. From what we understand (I kindly ask for your confirmation), the problem is that the TIM structure does not correctly describe our DDR4 (or our PCB with the correct timings on the tracks) this causes the check on the checksum of the uboot section made by bootROM to fail. Then reset the chip. We therefore ask for confirmation on our deduction and if there is any tool capable of giving us the correct values to be entered in ddr_tool to correctly set the communication with DDR4 on our board. At the HW level we checked the DDR4 signals (with eye diagrams too). We do not see important reflections on signals that could compromise correct communication. However, the DDR4 clock always remains stationary at 400MHz and the data contained in it always seems to be random (read with command r 6410_0000 and following from the bootROM console). Hope it can help you with problem analysis, Best regards
-
Hi, Trying to get the latest U-Boot working on my ESPRESSObin board - a v5, DDR3, 1 GB, 1cs version. I have no issues flashing it, and tftpbooting ... with the "old" supplied U-Boot. But wanting to run a recent version of OpenWrt on the board, so trying to update U-Boot. I flashed the latest version of U-Boot for it ... U-Boot comes up fine (I have serial access), but - ethernet seems to have an issue (for tftpboot, or even ping), I get, => ping 192.168.2.1 (NULL udevice *): mvneta_setup_txqs: can't create txq=0 Using ethernet@30000 device timeout: packet not sent timeout: packet not sent timeout: packet not sent timeout: packet not sent I can go back to the old U-Boot (circa 2017), and it works again (flashing from USB). But ... has anyone seen the issue above? And of course, any fixes? Thanks!
-
not an expert in device-tree, anybody knows how enable uart2/uart4? dts is attached. expressobin v7 mainline many thanks. armada-3720-espressobin-v7.dts
-
I flashed my espressobin v5 with flash-image-DDR4-1g_1cs_5-1000_800.bin After the boot it tries to boot from a network source instead of sdcard. printenv I dont know how it got to this point all I want now is to be able to boot from sdcard. Any thoughts or ideas?
-
I've been having a recent issue over the last couple months where my ArmbianEvn.txt file is being overwritten thus causing Helios to hang in the boot process. Using some samples i've found on these forums, I was able to re-create my file and get the Helios back up and running and have since stored a copy so that when it happens, I can just copy and paste and back up running in no time. To date, i've had this happen to me 4 times. I'm not worried about having go through this at this point in time, but I was curious if anyone else has seen this issue or not? I've saved a couple samples of what was written into the ArmbianEnv.txt file: /var/log/armbian-hardware-monitor.log { rotate 12 weekly compress missi /var/log/alternatives.log { monthly rotate 12 compress delaycompress missingok notifempty create 644 root root } I'm running Buster 5.10.21. I have 5-14TB EXOS drives in Raid 6 and have OMV as the only thing installed.
- 20 replies
-
2
-
- PINE A64
- ESPRESSObin
-
(and 1 more)
Tagged with:
-
I am not shure if this is board specific so I post it here and hope that you might be willing to try this on your board: - I installed audit: apt install auditd - I set up a rule for a file audit should watch: auditctl -w /boot/armbianEnv.txt -p wa - I change or touch the file being watched: touch /boot/armbianEnv.txt - I have a look at the log of audit: cat /var/log/audit/audit.log And then ––– I see nothing... Any hints what's going wrong? My guess is that the kernel might be lacking the audit module?!
-
Getting stuck out of the gate (of course never goes as documented🤣) https://puhoy.github.io/posts/armbian_on_espressobin/ While attempting to flash the required uboot update I keep getting a "permission" type error I've tried with usb stick and sd card, formated ext4, formatted fat and various permutations including simple filename....all give the same error even though usb and mmc commands say the media is there This is a v5. I have an identical one I set up a few years ago with ubuntu 18 but I did not have to flash this new uboot. Any thoughts? Do one of the jumpers have to be set in order to flash? Marvell>> usb info 1: Hub, USB Revision 3.0 - U-Boot XHCI Host Controller - Class: Hub - PacketSize: 9 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Mass Storage, USB Revision 2.0 - SanDisk Corporation Staples Relay SNDK7E38850327C07602 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5202 Version 0.32 Configuration: 1 - Interfaces: 1 Bus Powered 200mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 1 Out Bulk MaxPacket 512 Marvell>> bubt flash-image-DDR3-2g_2cs_7-1000_800.bin spi usb Burning U-BOOT image "flash-image-DDR3-2g_2cs_7-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 ** File not found flash-image-DDR3-2g_2cs_7-1000_800.bin ** Error: Failed to read file flash-image-DDR3-2g_2cs_7-1000_800.bin from usb exit not allowed from main input shell. Marvell>> mmc info Device: sdhci@d0000 Manufacturer ID: 3 OEM: 5344 Name: SU08G Tran Speed: 50000000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes Marvell>> bubt flash-image-DDR3-2g_2cs_7-1000_800.bin spi mmc Burning U-BOOT image "flash-image-DDR3-2g_2cs_7-1000_800.bin" from "mmc" to "spi" Card did not respond to voltage select! mmc_init: -95, time 42 MMC Device 1 not found No SD/MMC/eMMC card found Error: Failed to read file flash-image-DDR3-2g_2cs_7-1000_800.bin from mmc exit not allowed from main input shell.