umiddelb

Members
  • Posts

    154
  • Joined

  • Last visited

Recent Profile Visitors

3450 profile views

umiddelb's Achievements

  1. You may also ask the people from the odroid forum as well, since this topic doesn't seem to be bound to a specific Linux distribution.
  2. IMHO, µSD should have highest boot priority. You may try this first and check if there are any messages indicating some trouble with emmc storage (u-boot, kernel).
  3. Hi, in addition to this topic I would like to mention that the current Odroid N2 Firmware (Armbian 22.05.0-trunk.0004 Jammy with Linux 5.10.103-meson64 / U-Boot 2022.01-armbian (Mar 03 2022 - 19:25:51 +0000) odroid-n2/n2-plus) as well has difficulties with both the orange and the red coloured eMMC modules at this time. The orange coloured eMMC module is recognised but couldn't be activated ("unable to select a mode : -5"): The red coloured eMMC module cannot be used due to a partition type mismatch (ext4 vs. dos): I don't know if there is already a corresponding Jira issue and/or development activities going on. Cheers Uli PS: odroidn2:~:% sudo armbianmonitor -u System diagnosis information will now be uploaded to curl: (52) Empty reply from server Please post the URL in the forum where you've been asked for.
  4. The u-boot feature set is defined during build-time. IIRC there has been a reason for disabling this feature in the past for certain platforms.
  5. The Utilite Pro has 2GB of RAM only, the Cubox-i has a variant (4x4) with 4 GB. Both share the same imx6 SoC, which is way slower than the Exynos 5422 from the XU4. The Utilite Pro uses an internal msata ssd (which can be replaced), the Cubox-i has an esata connector (both with 3.0 Gbps).
  6. Cool, congrats! Yes, the filesystem uses features u-boot doesn't know about (u-boot is simply too old). You can circumvent this issue by modifying nand-sata-install: upro:build:% diff ./packages/bsp/common/usr/sbin/nand-sata-install /usr/sbin/nand-sata-install 56c56 < if [[ $LINUXFAMILY == mvebu ]]; then --- > if [[ $LINUXFAMILY == mvebu || $LINUXFAMILY == imx6 ]]; then There is already a hook in this script which disables this feature during file-system creation. # for ARMv7 remove 64bit feature from default mke2fs format features if [[ $LINUXFAMILY == mvebu ]]; then mkopts[ext2]='-O ^64bit -qF' mkopts[ext3]='-O ^64bit -qF' mkopts[ext4]='-O ^64bit -qF' else mkopts[ext2]='-qF' mkopts[ext3]='-qF' mkopts[ext4]='-qF' fi Looks like you were trying to implement the distroboot feature within you script. I believe the SATA part should also use the /boot/ prefix ...
  7. You won't overwrite the entire u-boot environment when you import the textfile, the contents will be merged instead. As long as you don't issue the saveenv command the changes won't be permanent and the old u-boot environment will be used during next boot. If you wand to try the new settings first, you may enter the following command: usb start load usb 0:1 ${loadaddr} /distroboot.txt env import -t ${loadaddr} ${filesize} run bootcmd And this environment is supposed to work with the mmc cons=ttymxc3,115200 devplist=1 2 3 fdt_addr_r=0x15000000 fdt_high=0xffffffff ramdisk_addr_r=0x18000000 initrd_high=0xffffffff kernel_addr_r=0x10800000 boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_prefixes=/ /boot/ boot_scripts=boot.scr.uimg boot.scr boot_targets=mmc0 usb0 sata0 bootcmd=run findfdt; run distro_bootcmd bootcmd_mmc0=setenv devnum 2; run mmc_boot bootcmd_sata0=setenv devnum 0; run sata_boot bootcmd_usb0=setenv devnum 0; run usb_boot distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done fdtfile=undefined findfdt=setenv fdtfile imx6q-utilite-pro.dtb mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi sata_boot=if sata dev ${devnum}; then setenv devtype sata; run scan_dev_for_boot_part; fi usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; 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_scripts; done; scan_dev_for_boot_part=for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
  8. Hi Zibc, You might be right, honestly I haven't tried it with mmc, due to the difficulties when you want to remove the mmc from the Utilite again. As long as you have the original 32GB msata-ssd, I'd recommend to do so. After that you can issue the following command: sudo nand-sata-install and select the first item: "Boot from SD - system on SATA, USB or NVME" and select your recently formatted SATA partition as target. This will copy the root filesystem to your SSD (the directory /boot is skipped for some reason, you will need to copy it by hand (including the folders inside) to your SSD). The "installer" (I don't know what you actually mean: nand-sata-install or the script which runs at the first boot?) doesn't care about the spi flash memory because the cubox-i doesn't have one.
  9. Hi Zibc, in the meantime I've backported the essential part of the Cubox-i distroboot macro set to the Utilite. You may import the following u-boot environment: cons=ttymxc3,115200 devplist=1 2 3 fdt_addr_r=0x15000000 fdt_high=0xffffffff ramdisk_addr_r=0x18000000 initrd_high=0xffffffff kernel_addr_r=0x10800000 boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_prefixes=/ /boot/ boot_scripts=boot.scr.uimg boot.scr boot_targets=mmc0 usb0 sata0 bootcmd=run findfdt; run distro_bootcmd bootcmd_mmc0=setenv devnum 0; run mmc_boot bootcmd_sata0=setenv devnum 0; run sata_boot bootcmd_usb0=setenv devnum 0; run usb_boot distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done fdtfile=undefined findfdt=setenv fdtfile imx6q-utilite-pro.dtb mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi sata_boot=if sata dev ${devnum}; then setenv devtype sata; run scan_dev_for_boot_part; fi usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; 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_scripts; done; scan_dev_for_boot_part=for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done e.g. by issuing the following command within the u-boot console: load usb 0:1 ${loadaddr} /distroboot.txt env import -t ${loadaddr} ${filesize} saveenv I've reworked the boot.cmd in a way that it boots both the Cubox-i and the Utilite and does not rely on a specific storage device (e.g. hardcoded mmc 0:1 ext4): # DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # # default values setenv rootdev "/dev/mmcblk0p1" setenv verbosity "1" setenv console "display" setenv bootlogo "false" setenv disp_mode "1920x1080m60" setenv earlycon "off" if test -z "${bootfstype}"; then setenv rootfstype "ext4"; else setenv rootfstype "${bootfstype}"; fi if test "${board}" = mx6cuboxi; then setenv ramdisk_addr_r "0x14800000" if test -z "${fdtfile}"; then setenv fdtfile "imx6q-cubox-i.dtb"; fi if test -z "${cons}"; then setenv cons "ttymxc0,115200"; fi fi if load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} ${prefix}armbianEnv.txt ; then env import -t ${loadaddr} ${filesize} fi if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=${cons}"; fi if test "${earlycon}" = "on"; then setenv consoleargs "earlycon ${consoleargs}"; fi if test "${bootlogo}" = "true"; then setenv consoleargs "bootsplash.bootfile=bootsplash.armbian ${consoleargs}"; fi setenv bootargs "root=${rootdev} rootfstype=${rootfstype} rootwait ${consoleargs} consoleblank=0 video=mxcfb0:dev=hdmi,${disp_mode},if=RGB24,bpp=32 coherent_pool=2M cma=256M@2G rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi vt.global_cursor_default=0 loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile} load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}zImage bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr May be I'll find the time to file a PR on Github.
  10. If you scroll down to the specs you'll see that this board doesn't support any storage interface (beside of emmc5.1) like pcie or sata, not even USB3 (what the xu4 does). If you experience RAM constraints (e.g. during compilation), you may try zram which is enabled by default in Armbian.
  11. Hi Zibc, this environment seems to be the original one, somehow. You may interrupt the automatic boot process by pressing <enter> when the counter runs down from 5 to 0 and issue the following commands usb start load usb 0:1 $loadaddr /boot/boot.scr; source $loadaddr; I don't think that you need to build the image for the CuBox-i. Just try one of the existing images first.
  12. I'd consider this one ... https://www.hardkernel.com/shop/odroid-xu4-special-price/