gprovost Posted December 7, 2018 Author Posted December 7, 2018 @Zykr The fact that you reach "Uncompressing Linux... done, booting kernel" means that u-boot found the boot.src on your boot device (assuming microSD Card) and loaded correctly the kernel, initramfs and the device tree file. So something might be wrong with the kernel rather than u-boot. Could you copy your the boot output here. Do you remember what was your kernel version before upgrade ? Have you try a full port cycle ?
Tido Posted December 7, 2018 Posted December 7, 2018 I might be wrong, but just lately on my tinker board, after an update it pointed to the 'wrong' kernel - so it was unable to boot ! By just changing the pointer it worked again.
Zykr Posted December 7, 2018 Posted December 7, 2018 I had the default kernel in the image on the wiki, should have been 4.14.74-mvebu and the upgrade was from linux-4.4.153-mvebu/linux-image-mvebu_5.60_armhf.deb I'm not sure how to see what the current pointer is nor how to set it from uboot. Boot output: Spoiler BootROM - 1.73 Booting from MMC General initialization - Version: 1.0.0 AVS selection from EFUSE disabled (Skip reading EFUSE values) Overriding default AVS value to: 0x23 Detected Device ID 6828 High speed PHY - Version: 2.0 Init Customer board board SerDes lanes topology details: | Lane # | Speed| Type | ------------------------------| | 0 | 3 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 3 | SATA1 | | 3 | 3 | SATA3 | | 4 | 3 | SATA2 | | 5 | 5 | USB3 HOST1 | ------------------------------- High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.46.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR Training Sequence - End scrubbing DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER ** U-Boot 2013.01 (Oct 09 2018 - 13:47:44) Marvell version: 2015_T1.0p16 Board: Helios4 SoC: MV88F6828 Rev A0 running 2 CPUs CPU: ARM Cortex A9 MPCore (Rev 1) LE CPU 0 CPU @ 1600 [MHz] L2 @ 800 [MHz] TClock @ 250 [MHz] DDR3 @ 800 [MHz] DDR3 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Enabled DRAM: 2 GiB MMC: mv_sdh: 0 *** Warning - bad CRC, using default environment USB2.0 0: Host Mode USB3.0 0: Host Mode USB3.0 1: Host Mode Map: Code: 0x7fee6000:0x7ff978f0 BSS: 0x7ffef2fc Stack: 0x7f9e3f20 Heap: 0x7f9e4000:0x7fee6000 U-Boot Environment: 0x000fe000:0x00100000 (MMC) Board configuration detected: Net: | port | Interface | PHY address | |--------|-----------|--------------| | egiga0 | RGMII | 0x00 | egiga0 [PRIME] Hit any key to stop autoboot: 0 Trying to boot from MMC 1979 bytes read in 17 ms (113.3 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 173 bytes read in 13 ms (12.7 KiB/s) 19512 bytes read in 51 ms (373 KiB/s) 6238277 bytes read in 342 ms (17.4 MiB/s) 4822864 bytes read in 276 ms (16.7 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2018-12-05 14:33:27 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 6238213 Bytes = 5.9 MiB Load Address: 00000000 Entry Point: 00000000 ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x02040000 Using Device Tree in place at 02040000, end 02047c37 Skipping Device Tree update ('fdt_skip_update' = yes) Limit DDR size at 3GB due to power of 2 requirement of Address decoding Starting kernel ... Uncompressing Linux... done, booting the kernel. Printenv: Spoiler Marvell>> printenv CASset=max MALLOC_len=5 MPmode=SMP autoload=no baudrate=115200 boot_a_script=for prefix in /boot/ /; do load ${boot_interface} 0:1 ${script_addr_r} ${prefix}boot.scr && source ${script_addr_r}; done boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr bootargs_dflt=$console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none bootargs_root=root=/dev/nfs rw bootcmd=echo Trying to boot from MMC; run mmcboot;echo Trying to boot from USB; run usbboot;echo Default boot sequence failed - falling back to TFTP;tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr; bootcmd_auto=stage_boot $boot_order bootcmd_lgcy=tftpboot 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootm $loadaddr; bootdelay=3 cacheShare=no console=console=ttyS0,115200 device_partition=0:1 disaMvPnp=no eeeEnable=no enaClockGating=no enaCpuStream=no enaFPU=yes enaMonExt=no enaWrAllo=no eth1addr=00:50:43:f6:3f:07 eth1mtu=1500 eth2addr=00:50:43:f6:00:07 eth2mtu=1500 eth3addr=00:50:43:3f:00:f6 eth3mtu=1500 ethact=egiga0 ethaddr=00:50:43:00:3f:07 ethmtu=1500 ethprime=egiga0 fdt_addr=2040000 fdt_skip_update=yes fdtfile=armada-388-helios4.dtb ide_path=/ image_name=uImage initrd_name=uInitrd ipaddr=10.4.50.170 kernel_addr_r=2080000 lcd0_enable=0 lcd0_params=640x480-16@60 lcd_panel=0 limit_dram_size=yes loadaddr=0x02000000 loads_echo=0 mmcboot=setenv boot_interface mmc; run boot_a_script; mtdids=spi0=spi_flash mtdparts=mtdparts=spi0.0:4m(boot),-(spi-rootfs) mtdparts_lgcy=mtdparts=spi_flash:4m(boot),-(spi-rootfs) mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500 mv_pon_addr=00:50:43:07:00:f6 netbsd_en=no netmask=255.255.255.0 netretry=no pcieTune=no pexMode=RC pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm pxefile_addr_r=3100000 ramdisk_addr_r=2880000 rootpath=/srv/nfs/ run_script=no sata_delay_reset=0 sata_dma_mode=yes sataboot=scsi init; setenv boot_interface scsi; run boot_a_script; script_addr_r=3000000 script_name=boot.scr sd_detection_dat3=no serverip=10.4.50.38 standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000; stderr=serial stdin=serial stdout=serial usb0Mode=host usbActive=1 usbType=3 usbboot=setenv usbActive 1; setenv usbType 3; usb start; setenv boot_interface usb; run boot_a_script; vxworks_en=no yuk_ethaddr=00:00:00:EE:51:81 Environment size: 3228/8188 bytes ls of /boot on mmc: Spoiler Marvell>> ext4ls mmc 0:1 /boot/ <DIR> 4096 . <DIR> 4096 .. <SYM> 21 uInitrd <SYM> 21 zImage <SYM> 17 dtb 123827 config-4.14.83-mvebu 38518 boot.bmp 0 .next 1536 armbian_first_run.txt.template 6238213 initrd.img-4.14.83-mvebu 173 armbianEnv.txt 6238277 uInitrd-4.14.83-mvebu 4882 boot-desktop.png 1907 boot.cmd 1979 boot.scr <SYM> 17 dtb.old 5450232 vmlinuz-4.14.83-mvebu 127521 config-4.4.153-mvebu 4822864 vmlinuz-4.4.153-mvebu 2179815 System.map-4.14.83-mvebu <DIR> 4096 dtb-4.14.83-mvebu 9229812 uInitrd-4.4.153-mvebu 2197074 System.map-4.4.153-mvebu 9229748 initrd.img-4.4.153-mvebu
gprovost Posted December 8, 2018 Author Posted December 8, 2018 @Zykr It is very strange and not normal that the upgrade installed a 4.4.y instead of a 4.14.y kernel. Did you do apt-get upgrade or did you manually choose the linux-image package ? So it could be something similar that what pointed out Tido above. The ext4ls mmc 0:1 /boot/ command doesn't show the symlink target unfortunately. But based on the load sizes in your uboot log, u-boot is loading the initramfs (uIinitrd) ver 4.14.83 and loading kernel (zImage) ver 4.4.153 which is completely wrong and explain why the boot fails. The easiest would be to mount the microSD Card on your personal computer and check / fix that the following symlinks in /boot are as follow: dtb -> dtb-4.14.83-mvebu uInitrd -> uInitrd-4.14.83-mvebu zImage -> vmlinuz-4.14.83-mvebu @Igor Is it an issue you experienced before ?
gprovost Posted December 8, 2018 Author Posted December 8, 2018 @Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-) setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}
Zykr Posted December 8, 2018 Posted December 8, 2018 it was a normal apt-upgrade that provided the link, though I did download it with wget instead of apt since apt wasn't working for some reason(kept stalling out, less than x data in last 120 seconds). However, I just put it in the apt cache folder and it found it. I supposed it could have gotten corrupted at some point but I'm not sure how. trying the options in your second post sadly gives me only: "Ramdisk image is corrupt or invalid" I also tried the same thing with the "4.4.153-mvebu" kernel, but got the same result. Something must have gotten really screwed up somewhere, but I have no idea what or how. I'm not at my linux laptop at the moment, so I'll have to try checking the symlinks with ls later. Thank you very much for your help so far. Maybe I just need to reinstall and then blacklist that upgrade or pin the kernel version.
gprovost Posted December 9, 2018 Author Posted December 9, 2018 @Zykr you could also replace the content /boot with the one you extract from an image. Under linux you can mount .img file with a loop device and browse its content.
aprayoga Posted December 9, 2018 Posted December 9, 2018 Hi @Zykr, I just wanted to add on top of @gprovost instruction On 12/8/2018 at 3:36 PM, gprovost said: @Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-) setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr} Replace the loglevel in the bootargs with "ignore_loglevel earlyprintk earlycon" so the kernel can output debug message as earliest as possible. And since you encountered problem with the ramdisk, maybe just skip it for now Below is the modified command setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay ignore_loglevel earlyprintk earlycon" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} - ${fdt_addr}
lanefu Posted December 28, 2018 Posted December 28, 2018 just an anecdote. I received my Helios4 (from second production run) on Christmas eve.. what a present! Anyway I've got it up and running with just the stable armbian stretch image with OMV running raid 5 on 3x3TB enterprise drives and the thing is just a work of art. I wish we'd get more SBCs on the market like this thing... not everyone needs a TV box. 1
gprovost Posted December 28, 2018 Author Posted December 28, 2018 @lanefu Thanks for the anecdote, always nice to hear some feedback from user. Would be great if you can post a picture of your setup on our FB page or/and our Twitter. Cheers.
hatschi1000 Posted December 28, 2018 Posted December 28, 2018 Talking about anecdotes: Some of you might remember the issue of booting my helios4 with 2 HGST Deskstar HDDs I had approx. half a year ago (https://forum.armbian.com/topic/6033-helios4-support/?do=findComment&comment=57981). After we weren't able to find a solution on why the specific problem appeared here on the forum, I got in contact with @gprovost directly and after some back and forth messaging he kindly asked for the defective board to be sent back to Singapore. Soon after I received a fixed board back with which the problem did not appear anymore. Right now I'm still tinkering around my setup (2x2TB HDD in btrfs-RAID1 underneath OMV4 with (at some point at least) an automated offsite backup using btrfs-snapshots), without having had any significant problems - a big thumbs up to @gprovost and the entire helios team for the straightforward communication and flawless exchange of the faulty carrier board. 2
gprovost Posted December 28, 2018 Author Posted December 28, 2018 @hatschi1000 Happy to hear all going smoothly.
GeckoX Posted December 29, 2018 Posted December 29, 2018 Hi, I don't know if someone else had the issue but I cannot connect to my Helios 4 through the graphic interface of MacOS even though I can connect using the terminal command. When I click on Finder, on the left I can see 'Network' then 'Helios 4' then I click on 'Connect as'. I enter my username and password and then, it returns: "Connection failed". I contacted Apple Support but were unable to help me. They said it is probably a compatibility problem but I find it weird that I can see it. I tried to check the firewall but it was already disabled. I have no issue to reach it using Linux Mint (using terminal or graphic interface). Is there any work around? Thank you.
GeckoX Posted December 31, 2018 Posted December 31, 2018 (edited) Finally, after tinkering for quite a while, I found the solution. Initially, I configured RAID using mdadm and then tried to configure the disks and file sharing with Open Media Vault. Funnily, OMV could see my RAID config but didn't allow me to perform any action on it. I decided to brute force it, went to mdadm to reset everything then connected to OMV and performed the configuration. From there, I had to Setup the file sharing (enable Apple filing) and then Tadaaa!!! my Mac allowed me to connect. I should have had started with OMV but I am a beginner on NAS. Hope it will be helpful for someone. Happy New Year everybody! Edited December 31, 2018 by GeckoX
Koen Posted December 31, 2018 Posted December 31, 2018 Finally my purchase arrived. I was so excited to check it out, but no microSD in the box. I thought i had read something about a sandisk UHS-I 16Gb card being in the bundle, @gprovost ?
thermalz Posted January 1, 2019 Posted January 1, 2019 Hi all, received my kit last week and put it together today. I seem to be having issues with one of the fans. Only one will spin up, the other connected to J17 does not rotate. It's specific to J17 as swapping the fans around reverses the fan which doesn't spin. I unplugged J17 connector and plugged it back in, the fan spun up for around 3 seconds then stopped, so I currently have a system with only 1 fan functioning. Does anyone have any hints?
aprayoga Posted January 2, 2019 Posted January 2, 2019 7 hours ago, thermalz said: Hi all, received my kit last week and put it together today. I seem to be having issues with one of the fans. Only one will spin up, the other connected to J17 does not rotate. It's specific to J17 as swapping the fans around reverses the fan which doesn't spin. I unplugged J17 connector and plugged it back in, the fan spun up for around 3 seconds then stopped, so I currently have a system with only 1 fan functioning. Does anyone have any hints? Hi @thermalz, could you try sudo systemctl stop fancontrol echo 255 | sudo tee -a /sys/devices/platform/j17-pwm/hwmon/hwmon*/pwm1 and see whether the fan running full speed
gprovost Posted January 2, 2019 Author Posted January 2, 2019 @GeckoX Good to hear you figure it out. Yes OMV is the easiest approach to setup your NAS without the need to be too much Linux savvy. @Koen No there is no microSD card included in the kit. Some users of the 1st batch got a free microSD card but it was a free goodie from the PCBA factory to apology from their repeated delay.
thermalz Posted January 2, 2019 Posted January 2, 2019 5 hours ago, aprayoga said: Hi @thermalz, could you try sudo systemctl stop fancontrol echo 255 | sudo tee -a /sys/devices/platform/j17-pwm/hwmon/hwmon*/pwm1 No change, fan stays off. But goes full speed if I do this for j10-pwm.
thermalz Posted January 2, 2019 Posted January 2, 2019 I've now come home to a board which has the Power led on, 1 spinning fan at max rpm and the system won't boot/post. Nothing on the serial console. I looked through the thread and tried the unplugging of the SOC. Still nothing.
malcolm Posted January 3, 2019 Posted January 3, 2019 I have some discrepancy in the reported CPU temperatures. motd reports 32C htop reports 69C armbianmonitor reports 52C I believe the armbianmonitor but wonder why the difference. Thanks.
aprayoga Posted January 3, 2019 Posted January 3, 2019 @malcolm armbianmonitor get the value from wrong sensor. It's inherited from sensor list under Linux kernel 4.4. We have reported it to Armbian on this issue 1135. We are working to fix this. Since this could affect other board as well, we need to test carefully. The correct reading is the one reported by htop. You could also read the CPU temp using cat /sys/devices/virtual/thermal/thermal_zone0/temp
gprovost Posted January 3, 2019 Author Posted January 3, 2019 @thermalz please PM me and we see from there if we should proceed to a replacement of the board. Just reminder to all, as mentioned on our wiki in several place :
malcolm Posted January 3, 2019 Posted January 3, 2019 11 hours ago, aprayoga said: armbianmonitor get the value from wrong sensor. It's inherited from sensor list under Linux kernel 4.4. We have reported it to Armbian on this issue 1135. We are working to fix this. Since this could affect other board as well, we need to test carefully. The correct reading is the one reported by htop. You could also read the CPU temp using cat /sys/devices/virtual/thermal/thermal_zone0/temp @aprayoga Thanks!
taziden Posted January 3, 2019 Posted January 3, 2019 (edited) Hi, I'd like to use Wireguard on my Helios4 (btw thx for the great job, I'm really happy with it so far!), and for that, I need to have the kernel headers installed. What would be the best way to have kernel headers installed ? Recompile using https://github.com/helios-4/build ? Edited January 3, 2019 by taziden formatting
aprayoga Posted January 4, 2019 Posted January 4, 2019 @taziden which kernel version/release currently installed on your system? you can check using uname -r if it's 4.14.88-mvebu you can download the header and install it using wget https://apt.kobol.io/pool/main/l/linux-4.14.88-mvebu/linux-headers-next-mvebu_5.68_armhf.deb sudo dpkg -i linux-headers-next-mvebu_5.68_armhf.deb Other than that version you can install it using the usual apt sudo apt-get install linux-headers-next-mvebu 1
Koen Posted January 4, 2019 Posted January 4, 2019 On 1/2/2019 at 5:04 AM, gprovost said: @GeckoX Good to hear you figure it out. Yes OMV is the easiest approach to setup your NAS without the need to be too much Linux savvy. @Koen No there is no microSD card included in the kit. Some users of the 1st batch got a free microSD card but it was a free goodie from the PCBA factory to apology from their repeated delay. I guess we know what DPD should do then for its delays and tracking issues. Imho, since my understanding is you need a microSD card to get started (even if you eventually would choose to install to USB / SATA), is it would be good if it were included (even at extra cost) so one can get started once the kit arrives; or at least made more clear it's something to procure separately. Anyway, i hope to soon take it for a spin.
Tom3kK Posted January 4, 2019 Posted January 4, 2019 Hi there, got my Helios4 on 28th Dez'18, delivery tracking told me on 15th Jan'19, so I hope this one is really mine Everything went fine, setup (kit, OS, Omv) was easy. Today my wife asked me, if this "THING" must run all the time? Do you know, when AutoShutdown/WOL will be available?
chwe Posted January 4, 2019 Posted January 4, 2019 3 minutes ago, Tom3kK said: Today my wife asked me, if this "THING" must run all the time? just answer with yes.. sorry, I had to comment on this when I unlocked the post.. I don't know the helios well but one of my boards has all LEDs disabled so that nobody gets upset by blinking lights.. I wouldn't recommend it cause those LEDs actually make sense but well it's a working solution.. (and NO there isn't a spycam on it )
matzman666 Posted January 6, 2019 Posted January 6, 2019 On 1/2/2019 at 5:04 AM, gprovost said: @GeckoX Good to hear you figure it out. Yes OMV is the easiest approach to setup your NAS without the need to be too much Linux savvy. @Koen No there is no microSD card included in the kit. Some users of the 1st batch got a free microSD card but it was a free goodie from the PCBA factory to apology from their repeated delay. OMV may be the easiest approach, but keep in mind that your performance will significantly suffer when using OMV. OMV only supports raid creation using the whole disk, which leads to a significant performance loss according to my experience. When using the OMV encryption plugin to create your dmcrypt device, an encryption algorithm will be used that is not supported by the hardware encryption engine, which again leads to suboptimal performance. There is no way to change the encryption algorithm in OMV.
Recommended Posts