y52

Members
  • Content Count

    147
  • Joined

  • Last visited

About y52

  • Rank
    Elite member

Recent Profile Visitors

722 profile views
  1. I am upgrading the OrangePI plus bought in 2016 to Buster and moved the system to eMMC with "armbian-config". / _ \| _ \(_) _ | | | | |_) | |_| |_ | |_| | __/| |_ _| \___/|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-sunxi Does armbian-config update the u-boot firmware? Or should I run it manually as described? $ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8 How could the current firmware version be checked and backed up before updating it ? Where is an appropriate latest firmware file? Is the one below good for OrangePI? https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/ [ ] orangepi_plus.sdcard.img.gz 2019-07-12 00:11 245K [ ] u-boot-sunxi-with-spl.bin.gz 2019-07-12 00:11 245K Incidentally, is the boot from SATA supported on OrangePI plus ?
  2. I can't mount the eMMC : root@orangepiplus:~# lsblk -o model,name,type,fstype,size,label MODEL NAME TYPE FSTYPE SIZE LABEL mmcblk1boot0 disk 4M mmcblk1boot1 disk 4M mmcblk0 disk 60G └─mmcblk0p1 part ext4 60G <- @ SDCard mmcblk1 disk 7.3G └─mmcblk1p1 part ext4 7.2G <- eMM #mount /dev/mmcblk1p1 /mnt/mountpoint [34182.366277] EXT4-fs (mmcblk1p1): couldn't mount RDWR because of unsupported optional features (400) Is there a reason for that?
  3. I followed the Rasbian Jessy to Stretch migration link (above). It doesn't allow for the kernel upgrade. The migration ends up with the root@orangepiplus:/# uname -a Linux orangepiplus 3.4.113-sun8i #8 SMP PREEMPT Sat Feb 9 20:17:57 CET 2019 armv7l GNU/Linux The fresh installation from scratch allows for the Linux 4.19.20. Thus at least the kernel upgrade procedure needs to be thought of. The other question for Orange PI : how could different boot device be chosen? How could I choose booting from Nand or SD Card of USB?
  4. Hello, I have the same issue : my SD Card died all of a sudden, leaving me an option to update the Debian distribution. The previous installed one was: ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.113-sun8i It is still left in a Nand and could be booted off it. What is the procedure to update the whole system to Debian Stretch? Thank you.
  5. I added this setting to give (boot log): [ 0.000000] Kernel command line: console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=cdf86afe-e235-4b45-a02b-7954f2bbdaaa rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) rootdelay=3 [ 0.000000] Memory: 2026008K/2097152K available (10684K kernel code, 730K rwdata, 3244K rodata, 640K init, 502K bss, 54760K reserved, 16384K cma-reserved) However, the board didn't show up after "shutdown -r now". It was still necessary unplugging it and power up back for it to reboot. "rootwait" and "rootdelay=3", are those rootargs not conflicting and self excluding?
  6. Good suggestion. Which file the boot arguments are set? I looked into armbianEnv.txt, but "rootwait" is not there. Otherwise, are you suggesting changing the variable in the bootloader ? I looked into the current U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian last Marvell>> printenv the rootarg is not set either. Could you be more specific?
  7. Have you seen this https://github.com/armbian/build/commit/9c7ce48f2b6cef71080ee6f04cca6f521f98df96 ? Yes. I understood it. It goes in line with the changes made to boot.cmd You should still replace the wrong boot.scr on your download page. Have you tried # cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table ? I have this table in place : root@karmae:~# cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table From : To : 200000 250000 500000 1000000 200000: 0 1 2 0 250000: 1 0 1846 3910 500000: 2 1822 0 85 1000000: 0 3934 61 0 What should be necessary to check more ? globalscale technologies turns a deaf year to such claims. They consider their boards to fully meet the specifications. I could have sent the board at my own risk for the cost of 50 USD, which is not worth it. globalscale technologies doesn't even guaranty the replacement. Once, the RMA guy told, that they may check it, but since then he doesn't even dare responding. It is really not up to the mark handling so badly technical claims for their boards.
  8. I've recompiled boot.scr from boot.cmd and, this time, the boot with the U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) went without a hitch. Still the absence of CPU scaling persists. I shall observe how stable the board is with this U-Boot. The previous configuration resulted in hazardous reboots each couple of days.
  9. Interestingly enough, that CPU scaling seems not being reported by armbianmonitor : 14:54:44: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:54:49: 1000MHz 0.00 3% 0% 2% 0% 0% 0% 14:54:54: 1000MHz 0.00 1% 0% 0% 0% 0% 0% 14:54:59: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:55:05: 1000MHz 0.00 1% 0% 0% 0% 0% 0% 14:55:10: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:55:15: 1000MHz 0.00 1% 0% 0% 0% 0% 0% or is broken with this U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200). The previous u-boot versions gave the impression of a functional scaling : 12:32:23: 1000MHz 1.01 21% 7% 10% 0% 4% 0% 12:32:28: 1000MHz 0.93 2% 1% 0% 0% 0% 0% 12:32:33: 0MHz 0.86 1% 0% 0% 0% 0% 0% 12:32:38: 0MHz 0.79 2% 1% 0% 0% 0% 0%^C
  10. I've found the new boot script in https://dl.armbian.com/espressobin/u-boot/bootscript/ However, looking at their content, it seems, that boot.cmd and boot.scr are unrelated to each other and different. As I understand it, boot.scr should be compiled from boot.cmd : "mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr". Why are they completely different? Is there any confusion? boot.scr refers to display environments like setenv disp_mode "1920x1080m60" etc. It should be coming from another build and another board. Which one is correct and should be used for expressobin? boot.cmd looks to be more appropriate, but should be recompiled before used with the boot.
  11. The load address is not an issue. It has been set correctly : Marvell>> setenv fdt_addr 0x6000000 Marvell>> setenv kernel_addr 0x7000000 Marvell>> setenv loadaddr 0x8000000 Marvell>> setenv initrd_size 0x2000000 Marvell>> setenv initrd_addr 0x1100000 Marvell>> setenv scriptaddr 0x6d00000 What is broken in the new u-boot environment is the path to the 'image_name' image_name=Image while the image file is located in 'boot/Image' and the u-boot command "scan_dev_for_boot 'for prefix in ${boot_prefixes}; do echo ${prefix};run boot_a_script; done'" doesn't return the correct path to the Image file. There are probably other issues, as the board doesn't boot consistently between cold boot and hot reset.
  12. I am still on ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.9-mvebu64. I've used the new u-boot environments provided in the the EspressoBin download page), but there are no instructions for the changes in the /boot media. Could you be more specific about the new /boot scripts?
  13. I've upgraded the u-boot loader to the last one : U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 1000 [MHz] NB AXI 250 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] Then I have changed the u-boot environments as it was required. Much to my surprise, I was unable to boot initially. I boot from the the 'mmc' device and the logs showed the errors : Marvell>> 1176 bytes read in 13 ms (87.9 KiB/s) ## Executing script at 06d00000 221 bytes read in 3 ms (71.3 KiB/s) ** File not found Image ** 5837603 bytes read in 256 ms (21.7 MiB/s) ** File not found boot/dtb/marvell/armada-3720-community.dtb ** 8330 bytes read in 10 ms (813.5 KiB/s) Bad Linux ARM64 Image magic! After some debugging, I found, that the 'image_name' environment is badly formed. Indeed : Marvell>> printenv image_name image_name=Image while the image file is located in 'boot/Image' I tried changing the 'boot_prefixes' environment as follows: Marvell>> setenv boot_prefixes '/boot/' Marvell>> printenv boot_prefixes boot_prefixes=/boot/ But it didn't help. So I set : setenv image_name boot/Image saveenv The boot went fine until the next 'shutdown -r now'. When hot rebooting again, the boot process seems to process the sequence for a different boot target : Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 4.17.9-mvebu64 (root@nightly) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #164 SMP PREEMPT Tue Jul 24 18:15:33 UTC 2018 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] bootconsole [ar3700_uart0] enabled Loading, please wait... starting version 237 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. ....many times.... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... mdadm: error opening /dev/md?*: No such file or directory /scripts/local-block/mdadm: 58: /scripts/local-block/mdadm: rm: not found done. ....many times.... Begin: Running /scripts/local-block ... done. done. Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p1 does not exist. Dropping to a shell! (initramfs) If I unplug the board and power it back again, the board boots normally. What's wrong with the u-boot scripts and environments? Besides, is the new kernel build 4.18.xx available for upgrade?
  14. 1st of all you will need to make sure, that the basic network functionality is valid. Make sure the pings out of the interface are not lost. If you can not ping out, than fix it before proceeding further. SSH service may not be launched or ssh keys are not generated. Other issues, like closed port may not allow to connect over ssh.
  15. Your wan interface has been activated now. You will need checking your full network setup. Initially I ran into difficulty with several network management systems beeing active simultaneously. You will need deactivating unnecessary services. Set your ip address manually with "ip addr add xxxx dev xx" to confirm your network connectivity and then look for the root reasons, why you can not bring up your network automatically.