• Posts

  • Joined

  • Last visited

Recent Profile Visitors

2970 profile views

umiddelb's Achievements

  2. Fist of all, you should have a source for building the firmware and the kernel. At this time there seems to be no mainline kernel support for this particular chip (
  3. I can remember that an upstream change from mainline rendered my ODROID-C2 and Khadas Vim / Vim2 unusable due to emmc timing / frequency changes in the corresponding dts files. I'm not sure if these changes (in rc? revisions) even made it into the release branch. So it's not easy to find the right one to blame.
  4. root@mgmt:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=cubox-i BOARD_NAME="Cubox i2eX/i4" BOARDFAMILY=cubox BUILD_REPOSITORY_URL= BUILD_REPOSITORY_COMMIT=b9adf0ea-dirty VERSION=5.98 LINUXFAMILY=cubox BRANCH=next ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage root@mgmt:~# uname -a Linux mgmt 5.3.1-cubox #5.98 SMP Fri Sep 27 23:11:49 CEST 2019 armv7l armv7l armv7l GNU/Linux root@mgmt:~# find /sys -name phy_id /sys/devices/soc0/soc/2100000.aips-bus/2188000.ethernet/mdio_bus/2188000.ethernet-1/2188000.ethernet-1:04/phy_id root@mgmt:~# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet netmask broadcast inet6 fe80::4eee:3b87:e07b:7419 prefixlen 64 scopeid 0x20<link> ether d0:63:b4:00:83:30 txqueuelen 1000 (Ethernet) RX packets 3342175 bytes 606622753 (606.6 MB) RX errors 0 dropped 1 overruns 0 frame 0 TX packets 2607316 bytes 244851799 (244.8 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
  5. Good idea, you may get in touch with Edward Vielmetti (@vielmettialt).
  6. This board might meet your requirements, except of the price tag ... you may regard it as an upper bound.
  7. The spi flash memory (with the u-boot environment stored inside) is accessible from the command line. Please check if the corresponding driver is loaded via dmesg. It should look like: [ 1.878826] spi-nor spi0.0: w25q32dw (4096 Kbytes) [ 1.878850] 2 cmdlinepart partitions found on MTD device spi0.0 [ 1.878854] Creating 2 MTD partitions on "spi0.0": [ 1.878870] 0x000000000000-0x0000003f0000 : "uboot" [ 1.888884] 0x0000003f0000-0x000000400000 : "uboot-environment" The partitioning information is passed as a command line parameter to the kernel (last parameter in this case): console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=c2bdee11-6a88-46c1-8630-b70864d535bb rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:4032k(uboot),64k(uboot-environment) You need to install the package u-boot-tools containing the userland tools and you need to configure the correct offsets: uli@ebin:~$ cat /etc/fw_env.config # device name device offset env. size flash sector size number of sectors /dev/mtd1 0x00000000 0x00010000 0x1000 0x10 Then fw_printenv / fw_setenv will help you to modify the u-boot environment: uli@ebin:~$ sudo fw_printenv arch=arm baudrate=115200 board=mvebu_armada-37xx board_name=mvebu_armada-37xx boot_a_script=ext4load ${boot_interface} ${devnum}:1 ${scriptaddr} ${prefix}boot.scr;source ${scriptaddr}; boot_prefixes=/ /boot/ boot_targets=usb sata mmc1 mmc0 bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done bootcmd_mmc0=setenv devnum 0; setenv boot_interface mmc; run scan_dev_for_boot; bootcmd_mmc1=setenv devnum 1; setenv boot_interface mmc; run scan_dev_for_boot; bootcmd_sata=setenv devnum 0; scsi scan; scsi dev 0; setenv boot_interface scsi; run scan_dev_for_boot; bootcmd_usb=setenv devnum 0; usb start;setenv boot_interface usb; run scan_dev_for_boot; bootdelay=2 console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 cpu=armv8 eth1addr=00:51:82:11:22:01 eth2addr=00:51:82:11:22:02 eth3addr=00:51:82:11:22:03 ethaddr=00:51:82:11:22:00 ethprime=eth0 extra_params=pci=pcie_bus_safe fdt_addr=0x6000000 fdt_addr_r=0x6f00000 fdt_high=0xffffffffffffffff fdt_name=fdt.dtb gatewayip= get_images=tftpboot $kernel_addr_r $image_name; tftpboot $fdt_addr_r $fdt_name; run get_ramfs get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramdisk_addr_r 0x8000000; tftpboot $ramdisk_addr_r $ramfs_name; else setenv ramdisk_addr_r -;fi hostname=marvell image_name=Image initrd_addr=0x1100000 initrd_image=uInitrd initrd_size=0x2000000 ipaddr= kernel_addr=0x7000000 kernel_addr_r=0x7000000 loadaddr=0x8000000 netdev=eth0 netmask= ramdisk_addr_r=0x8000000 ramfs_name=- root=root=/dev/nfs rw rootpath=/srv/nfs/ scan_dev_for_boot=for prefix in ${boot_prefixes}; do echo ${prefix};run boot_a_script; done scriptaddr=0x6d00000 serverip= set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath,tcp,v3 $extra_params $cpuidle soc=mvebu vendor=Marvell Unfortunately the offsets vary between the different u-boot versions, so you have to find out the correct one for your board. fw_printenv will tell you if the CRC check fails meaning that the chosen offsets do not fit.
  8. The problematic reset-gpios instruction is still present in the device tree description. Removing it solves the issue for my board (which is a pre-series test sample). The suggested patch doesn't apply since there are different pins involved (0x24 vs 0x21).
  9. Hi, the lastest kernel update issues the following lines in dmesg output: [ 12.214293] meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma [ 12.215002] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [ 12.223988] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_open: Hw setup failed Do I need to update the firmware as well? B.t.w. you may mention that armbianmonitor -u needs to be run as root, otherwise the fping check will fail.
  10. The download directory doesn't seem to contain the recent firmware with the correct RAM layout. The last modification date is from 2019 and I run into the some issue when I've 'refurbished' my espressobin today with Ubuntu 20.04.
  11. I don't know if you have already read an article which I've written for ODROID Magazine a couple of years ago ("Das-U-Boot") .
  12. You may test the following approach: - have a look with `fdisk -l /dev/<sd card>` and find out where the first (and only) partition starts - copy with `dd bs=512 if=/dev/<sd card> of=<imagefile> count=<start sector of first partition> - copy the contents of /boot to a different location - look which file system features have been enabled for / (`tune2fs -l /dev/<sd card>`) - write the image file to a different sd card - delete and recreate on the different sd card the first partition according to the space requirements of /boot, make sure that your starting sector count stays the same - create a filesystem for the newly created partition and make sure that the features match the information you have gathered before, some bootloaders cannot deal with journaling nor with 64bit filesystems which are switched on by default - copy the contents of /boot back to your different sd card