Jump to content

Search the Community

Showing results for tags 'helios64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Last night I shutdown my Helios 64 (sudo shutdown now) but when i went to boot it this morning, after startup it looks to be hung, all blue lights solidly on. It's set to run from the micro SD card, so wondering if i hit a R/W limit on that. Serial log below, it doesn't progress beyond "starting kernel" I can mount the MicroSD on my ubuntu box and read the file structure DDR Version 1.24 20191016 In channel 0 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 254 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=60906MB FwPartOffset=2000 , 0 StorageInit ok = 76288 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xe5b60 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.10-armbian (Mar 08 2021 - 14:54:58 +0000) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 4!? 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 5 ms (622.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 166 bytes read in 5 ms (32.2 KiB/s) 15755777 bytes read in 674 ms (22.3 MiB/s) 28582400 bytes read in 1212 ms (22.5 MiB/s) 81913 bytes read in 13 ms (6 MiB/s) Failed to load '/boot/dtb/rockchip/overlay/-fixup.scr' Moving Image from 0x2080000 to 0x2200000, end=3de0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15755713 Bytes = 15 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f4fe9000, end f5eef9c1 ... OK Loading Device Tree to 00000000f4f6c000, end 00000000f4fe8fff ... OK Starting kernel ...
  2. Hello everyone, I’m starting this message by apologizing for my poor English (I am French) and also by informing you that I am a newbie with Linux. I have a big problem with my NAS Helios64. At first, I thought this problem was caused by OMV. So I went to the OMV forum to explain my situation. I created the following topic: https://forum.openmediavault.org/index.php?thread/40252-many-problems-after-an-update/&pageNo=1 . There, a kind moderator (macom) asked me to enter some instructions to try to pinpoint the root of the problem. After giving him some outputs, he told me: "For me it looks like your SD card is dead." My installation is not on an SD card but on the eMMC chip of the Helios64. (I followed the Kobol wiki instructions exactly from here : https://wiki.kobol.io/helios64/install/emmc/ ) After that, my NAS has become unreachable. I can no longer log into the OMV Dashboard. I cannot reach the NAS by SSH either. I can just tell you that all the LED lights on the NAS are solid blue. No red diode on. Is the eMMC chip of my NAS dead? Is there a solution that would prevent me from losing all the data stored on the hard drives? (They are in RAID1 and they are encrypted with the OMV LUKS encryption plugin) (I have not made a data backup elsewhere ... I know, big mistake!) I thank in advance all those who will take the time to help me.
  3. Hello I need to change a drive in the Helios64, and so I bought a new WD 2TB drive. Using a WD My Book 111D USB enclosure, I have partitioned, formatted and copied the data from the old drive. But when I change the drives to put the new one in the Helios64, the drive appears unformatted. See below. I can't understand what's happening, when I plug it back through USB everything is back to normal. Does the partitioning through USB differ somehow??? It appears as if the partition table "stays in the USB enclosure", which doesn't make sense for me. Is there something to try? Do I have to start again the process in the NAS enclosure? I don't want to spend 6+ hours copying everything back... I'm using armbian 5.10.35-rockchip64, and OMV 5. The disk appears in /dev/sda. When connected through SATA: eclapton@helios64:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1,8T 0 disk sdb 8:16 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sdc 8:32 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sdd 8:48 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sde 8:64 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup mmcblk2 179:0 0 14,6G 0 disk └─mmcblk2p1 179:1 0 14,4G 0 part / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk When connected through USB: eclapton@helios64:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1,8T 0 disk ├─sda1 8:1 0 1,2T 0 part └─sda2 8:2 0 613G 0 part sdb 8:16 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sdc 8:32 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sdd 8:48 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sde 8:64 0 931,5G 0 disk └─md0 9:0 0 2,7T 0 raid5 /srv/dev-disk-by-label-Backup sr0 11:0 1 30M 0 rom mmcblk2 179:0 0 14,6G 0 disk └─mmcblk2p1 179:1 0 14,4G 0 part / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk
  4. Sold on Reddit. Hello, looking at selling my Helios64. Mostly looking at getting a price check (what's the device still worth) and gauging interest. Device is in pristine condition, standard fans were swapped for Noctua NF-A8. (standard fans will be included) I'd prefer to keep this EU only as shipping is going to be a pain.
  5. Hello. So, really sorry to hear that Team Kobol are disbanding. Many thanks to all who worked so hard to put the Helios64 together. I am really pleased with my Helios64, and am grateful for being able to get hold of one of these. Thank you! 🙏 What with one thing an another, I never got hold of a UPS battery; the battery couldn't be shipped with the original shipment, due to restrictions on shipping Li-Ion batteries; and then the additional postage costs for sending the battery seperately were prohibitive for Team Kobol, which I completely understand, so I chose not to pay the extra for the battery. However, it would be really useful for me to build one of these, from locally sourced components (I live in New Zealand). The wiki page here (https://wiki.kobol.io/helios64/ups/) mentions that it is possible for users to build their own battery if they keep the specifications correct. I want to give this a go, so that I can get the UPS working on my box. So. I can source Panasonic NCR18650BD cells here in New Zealand. So that's step one done. The protection IC, HY2120, is a little vague. The Hycon website here (https://www.hycontek.com/en/products-en/3180) lists several variants of the IC. And while sellers on AliExpress list these as being available, I don't know the exact spec to select. Does anyone know? Tthen, there is mention of a thermistor to monitor the cells temperature. Here, I don't know where to begin. What temperature is regarded as the threshold? What particular thermistor should I be looking for...? Many questions. And then, finally, there is getting the correct connector, to plug the home-made UPS battery onto the board. I assume it's a Molex type connector, but again, I don't kow enough in order to get the correct one. I am more than happy to give this a go myself, if anyone is able to give me a few specifics about what I should be purchasing. Many thanks to you, Jon
  6. Hello, I have tried the procedure described on this topic (https://forum.armbian.com/topic/15431-helios64-support/page/9/) but it doesn't work for me. armbian is installed on an SSD, I have no micro SD card in my Helios64. Today, i can no longer start armbian :/ This is what the serial console shows me: Can you help me please ? i have a pretty complex setup and i wouldn't want to reinstall everything. Thank you, Flolm
  7. Hey, I have uninstalled cron from my system completely, but I just thought I might help contribute, even just a little, by making some services and timer files to replace the ones in these folders: /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly Now keep in mind that I have not fully tested any of these yet! I would appreciate feedback in testing these, since most of these I won't even use on my system. I barely even use the armbian-config utility at all, so... yeah... The files in question are these. Let me know if I should add more: armbian-truncate-logs armbian-updates armbian-ram-logging These are the Armbian specific ones. I know there's ones for like man-db, mdadm, logrotate, fake-hwclock and a bunch more that get installed by default. And I think systemd already has timer files for some of these. In fact, here's the timers in use on my Kobol system right now: # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2021-09-11 18:43:28 PDT 13min left Fri 2021-09-10 18:43:28 PDT 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago logrotate.timer logrotate.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago man-db.timer man-db.service Sun 2021-09-12 05:57:58 PDT 11h left Sat 2021-09-11 17:25:28 PDT 1h 4min ago apt-daily.timer apt-daily.service Sun 2021-09-12 06:20:19 PDT 11h left Sat 2021-09-11 06:59:08 PDT 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service n/a n/a Sat 2021-09-11 05:57:28 PDT 12h ago update-ddns.timer update-ddns.service 6 timers listed. Pass --all to see loaded but inactive timers, too. The "update-ddns" timer and service is my own custom one. The rest are defaults. So we'll start in order of shortest to longest activation times: armbian-truncate-logs (runs every 15 minutes) /etc/systemd/system/armbian-truncate-logs.timer [Unit] Wants=armbian-truncate-logs.service [Timer] OnActiveSec=15m [Install] WantedBy=timers.target /etc/systemd/system/armbian-truncate-logs.service [Unit] Description=Truncate the Armbian log files [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-truncate-logs [Install] WantedBy=multi-user.target armbian-updates (runs daily and on boot up) Note: We are going to change this to run after the network is brought Online, but still make it run daily. /etc/systemd/system/armbian-updates.timer [Unit] Wants=armbian-updates.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-updates.service [Unit] Description=Check for updates on the Armbian system After=network-online.target [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-apt-updates [Install] WantedBy=multi-user.target armbian-ram-logging (runs daily) Note: It is mentioned that this cron job should only run when logrotate is a cron job. This was confusing wording at first, because it doesn't tell you if it prefers to either have logrotate as a systemd timer, or if logrotate should not run at all. After looking inside the script "/usr/lib/armbian/armbian-ramlog", which passes "write" as the first argument, I tried to see if there was any problematic code that conflicts with logrotate... Using the "syncToDisk ()" function, it doesn't seem like it'd conflict with logrotate at first glance. Just to be safe, I've included the line "Conflicts=logrotate.service" just in case. If this can be safely removed, let me know. /etc/systemd/system/armbian-ram-logging.timer [Unit] Wants=armbian-ram-logging.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-ram-logging.service [Unit] Description=Perform Armbian RAM logging Conflicts=logrotate.service [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog write [Install] WantedBy=multi-user.target --- That's about it. Again, not sure if any of these should be set to "oneshot" or "simple" services, or if they need to be active "RemainOnExit" or whatnot. Just hope I can give a good template for converting cron jobs to systemd timers. It's a lot simpler than I thought to convert them. Have a wonderful day, Armbian team. And thank you for all you contribute to this project.
  8. This happened out of the blue, without indication of anything else being wrong. I just noticed that NFS stalled, and realized that the server is not on the network. The system on the box was running fine, but there were no lights on the network connector (it is connected with the upper, 1Gb, adapter). I replugged the cable into the 2.5G socket and it went online. Then I powered the box off and on again, with the cable in the 1G socket, and it came online normally. This is what I found in dmesg/syslog: Aug 31 09:31:39 localhost kernel: [379809.423687] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out Aug 31 09:31:39 localhost kernel: [379809.424506] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:468 dev_watchdog+0x398/0x3a0 [...] Aug 31 09:31:39 localhost kernel: [379809.447941] rk_gmac-dwmac fe300000.ethernet eth0: Reset adapter. [...] Aug 31 09:31:39 localhost kernel: [379809.688895] rk_gmac-dwmac fe300000.ethernet: Failed to reset the dma Aug 31 09:31:39 localhost kernel: [379809.689493] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed Aug 31 09:31:39 localhost kernel: [379809.690302] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_open: Hw setup failed Full log attached. watchdog.txt
  9. Hi everyone ! I'm really happy with my Helios64, running fine with no major issues. BUT This product can obviously be improved with future revisions, while keeping the same base. The Kobol guys told me to open a thread here to discuss what would be great improvement or new features. I'm starting with things off my mind, but please ask me to add things to this list. An explanation would be great in the comments.
  10. Hi, I have bricked my system by installing the rk3399 legacy multmedia framework. It was installed on emmc. I was able to recover my system by using the P11 jumper to skip the boot on emmc, as explained in the doc, and now my system runs on a SDCard. The problem is, it seems that I cannot access the EMMC anymore -- it does not show up /dev. My intuition is that the P11 jumper disables the EMMC altogether. Am I write and if so, how can I access the EMMC again? I would like to be able to read it again (I had important data, notably unison synchronization files) and reinstall a fresh OS on it. Any help would be welcome!
  11. Hi, Ever since updating to kernel version 5.10.60 (#21.08.1), I have been getting these weird kernel error messages. Such error messages pop up constantly when doing certain operations, like: mmc2: running CQE recovery And also some of these: EXT4-fs warning (device mmcblk2p1): ext4_end_bio:349: I/O error 10 writing to inode 256 starting block 968704) As well as these: kernel: print_req_error: 47 callbacks suppressed kernel: blk_update_request: I/O error, dev mmcblk2, sector 7716864 op 0x1:(WRITE) flags 0x4000 phys_seg 8 prio class 0 kernel: Buffer I/O error on device mmcblk2p1, logical block 954373 And when updating with "apt update", I get this: Traceback (most recent call last): File "/usr/lib/cnf-update-db", line 26, in <module> col.create(db) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 94, in create self._fill_commands(con) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 132, in _fill_commands self._parse_single_contents_file(con, f, fp.stdout) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 228, in _parse_single_contents_file l = l.decode("utf-8") UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 2625: invalid start byte Reading package lists... Error! E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi' E: Sub-process returned an error code E: LZ4F: /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-arm64_Packages.lz4 Read error (18446744073709551600: ERROR_decompressionFailed) E: LZ4F: /var/lib/apt/lists/us.mirrors.fossho.st_armbian_apt_dists_buster_main_binary-arm64_Packages.lz4 Read error (18446744073709551600: ERROR_decompressionFailed) W: You may want to run apt-get update to correct these problems E: The package cache file is corrupted Honestly, it's pretty bad. But I did run this: badblocks -v /dev/mmcblk2 And no errors were found. It makes me think that it was just the upgrade that broke everything. This one is NOT an attempt to try to upgrade to Bullseye, but just a regular Buster/Armbian upgrade. If anyone else has had a successful upgrade, then let me know... I am not sure how to diagnose or fix any of this. I am indeed running from eMMC, and not the SD card slot. The big problem is that since APT is completely broken, I can't even downgrade the kernel with it. What do I do to help fix this? I did do a full backup of my system, so I think I might be able to restore from it, but I'm not sure. In any case, it would be nice to know how to solve this without going to my backup, since it boots up and uses the networking stuff just fine, it's just that I can't update or upgrade anymore...
  12. There are a number of modifications that have been suggested that people implement to address certain issues. The ones I can find are: - In /boot/armbianEnv.txt: extraargs=libata.force=3.0 - If doing debugging, also add: verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel - In /boot/boot.cmd regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 and then run: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr - In /etc/default/cpufrequtils: ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand (or 1200000 instead of 1800000) - And if using ZFS: for disk in /sys/block/sd[a-e]/queue/scheduler; do echo none > $disk; done I've gathered these from a variety of threads. Am I missing any here?
  13. Hi! In the Kobol wiki, there are 2 supported kernels : 4.4 and 5.10 In the armbian-build GIT repo, I see also patches for 5.13. What is the status of the 5.13 patches for the Helios64? Kind regards, Xavier Miller
  14. I seem to have hit another problem with my Helios64. It seems that overnight, HDs 4 and 5 disappeared and no longer seem to be powered. I've disconnected all the other drives and tried it with just 4, and it seems to be a power problem as the drive activity light seems to light up for a short while, but not at full prightness. Also I note that SATA 4 and 5 are on a separate power line to the other 3. Anyone seen this before? Is it fixable?
  15. Hi, Just got my Helios64 crashed: red error led is blinking. I had a raspberry pi left logging on the USB-C and caught the crash: [567513.689265] rk_gmac-dwmac fe300000.ethernet eth0: Link is Down [567519.833508] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [567828.048254] rk_gmac-dwmac fe300000.ethernet eth0: Link is Down [567834.198593] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [568870.455100] rk_gmac-dwmac fe300000.ethernet eth0: Link is Down [568876.599602] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [647513.282616] Unable to handle kernel paging request at virtual address 00078000118b99f0 [647513.283329] Mem abort info: [647513.283584] ESR = 0x96000004 [647513.283863] EC = 0x25: DABT (current EL), IL = 32 bits [647513.284336] SET = 0, FnV = 0 [647513.284615] EA = 0, S1PTW = 0 [647513.284899] Data abort info: [647513.285161] ISV = 0, ISS = 0x00000004 [647513.285506] CM = 0, WnR = 0 [647513.285776] [00078000118b99f0] address between user and kernel address ranges [647513.286411] Internal error: Oops: 96000004 [#1] PREEMPT SMP [647513.286909] Modules linked in: iptable_nat iptable_filter bpfilter wireguard libchacha20poly1305 poly1305_neon ip6_udp_tunnel udp_tunnel libblake2s libcurve25519_generic libblake2s_generic veth nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter bridge aufs ipt_REJECT nf_reject_ipv4 rfkill governor_performance n ft_chain_nat xt_nat xt_MASQUERADE nf_nat xt_addrtype nft_counter zram xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink r8152 snd_soc_hdmi_codec snd_soc_rockchip_i2s hantro_vpu(C) rockchipdrm rockchip_vdec(C) snd_soc_core dw_mipi_dsi v4l2_h264 dw_hdmi snd_pcm_dmaengine ro ckchip_rga videobuf2_dma_contig analogix_dp snd_pcm pwm_fan videobuf2_dma_sg v4l2_mem2mem snd_timer gpio_charger videobuf2_vmalloc leds_pwm snd panfrost videobuf2_memops fusb302 drm_kms_helper videobuf2_v4l2 tcpm soundcore gpu_sched videobuf2_common cec typec rc_core videodev sg drm mc drm_panel_orientation_quirks gpi o_beeper cpufreq_dt ledtrig_netdev lm75 ip_tables [647513.287063] x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod realtek dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys [647513.296230] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G C 5.10.35-rockchip64 #21.05.1 [647513.297012] Hardware name: Helios64 (DT) [647513.297367] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [647513.297911] pc : scheduler_tick+0xc4/0x140 [647513.298279] lr : scheduler_tick+0xc4/0x140 [647513.298647] sp : ffff800011c13d90 [647513.298947] x29: ffff800011c13d90 x28: 00024ced30605580 [647513.299424] x27: ffff0000f77bb6c0 x26: 0000000000000000 [647513.299900] x25: 0000000000000080 x24: ffff80001156a000 [647513.300375] x23: ffff000000711d00 x22: ffff80001157fd00 [647513.300851] x21: 0000000000000005 x20: ffff8000118b99c8 [647513.301327] x19: ffff0000f77c7d00 x18: 0000000000000610 [647513.301803] x17: 0000000000000010 x16: 0000000000000000 [647513.302280] x15: 0000000000000006 x14: 0000000000000000 [647513.302756] x13: 0000000000000095 x12: 0000000000000000 [647513.303231] x11: 0000000000000000 x10: 0000000000000004 [647513.303707] x9 : 0000000000000095 x8 : 0000000000000000 [647513.304184] x7 : ffff0000f77c7d00 x6 : ffff0000f77c8800 [647513.304659] x5 : 0000000000001095 x4 : ffff8000e6248000 [647513.305135] x3 : 0000000000010001 x2 : ffff80001156a000 [647513.305612] x1 : ffff8000112a1c88 x0 : 0000000000000005 [647513.306088] Call trace: [647513.306314] scheduler_tick+0xc4/0x140 [647513.306658] update_process_times+0x8c/0xa0 [647513.307035] tick_sched_handle.isra.19+0x40/0x58 [647513.307449] tick_sched_timer+0x58/0xb0 [647513.307795] __hrtimer_run_queues+0x104/0x388 [647513.308187] hrtimer_interrupt+0xf4/0x250 [647513.308551] arch_timer_handler_phys+0x30/0x40 [647513.308950] handle_percpu_devid_irq+0xa0/0x298 [647513.309357] generic_handle_irq+0x30/0x48 [647513.309718] __handle_domain_irq+0x94/0x108 [647513.310097] gic_handle_irq+0xc0/0x140 [647513.310436] el1_irq+0xc0/0x180 [647513.310724] arch_cpu_idle+0x18/0x28 [647513.311047] default_idle_call+0x44/0x1bc [647513.311409] do_idle+0x204/0x278 [647513.311701] cpu_startup_entry+0x28/0x60 [647513.312056] secondary_start_kernel+0x170/0x180 [647513.312466] Code: 94000cfb aa1303e0 94369a27 940518e0 (f8757a82) [647513.313015] ---[ end trace 2613ef5b92c55060 ]--- [647513.313430] Kernel panic - not syncing: Oops: Fatal exception in interrupt [647513.314040] SMP: stopping secondary CPUs [647513.314403] Kernel Offset: disabled [647513.314718] CPU features: 0x0240022,6100200c [647513.315101] Memory Limit: none [647513.315387] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Don't mind the ethernet port up/down messages (the connected router likes to reboot himself). The system is running from SD card. $ uname -a Linux helios64 5.10.35-rockchip64 #21.05.1 SMP PREEMPT Fri May 7 13:53:11 UTC 2021 aarch64 GNU/Linux If you need any other information, feel free to ask. Thanks.
  16. To continue discussion from Helios64 Support Noted, we will enable ZFS support after Armbian 20.11 released. I will need your help to test since i don't have system with ZFS.
  17. Hi All, My helios64 died the other day - well failing to boot. It had been solid for quite some time, then I might have made the mistake of updating it.... This is from putty on booting: DDR Version 1.24 20191016 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 254 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 67777 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xdd6b0 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.07-armbian (Nov 27 2020 - 21:56:51 +0100) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 19 ms (163.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 166 bytes read in 13 ms (11.7 KiB/s) 15756730 bytes read in 1512 ms (9.9 MiB/s) 81913 bytes read in 41 ms (1.9 MiB/s) 2698 bytes read in 34 ms (77.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing... starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 4!? 4 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 Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.1.232 (1026 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-64-62-66-d0-04-8c Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A801E8 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A801E Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A801 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A80 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A8 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/C Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399-helios64 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399 Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm Speed: 1000, full duplex *** ERROR: `serverip' not set missing environment variable: bootfile Retrieving file: pxelinux.cfg/default Speed: 1000, full duplex *** ERROR: `serverip' not set Config file not found Speed: 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.1.232 (23 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET Speed: 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.1.232 (18 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET Any chance of recovery or start again? Any help would be much appreciated. Cheers Scott
  18. I finally assembled my Helios 64 today. Went well, just took a while. I'm reading the Kobol Wiki page for installing the OS on the internal EMMC and am a bit confused. Hoping someone can point me in the right direction. I usually boot a SBC the first time from an SD card to do some testing. Then I'll use Armbian config to install the OS onto the EMMC when I am ready. The Kobol Wiki talks about first installing uboot from an SD card. Is that actually needed? Also, do I really need to set up a serial terminal session? I usually just SSH into the box (I know find the IP address via my DHCP server) and configure everything from there.
  19. Is there an accepted procedure for moving from using ramlog to logging to disk? I've looked but everything I can find is about setting up ramlog. I assume it's more complicated than just creating a partition (or ZFS dataset) and mounting it /var/log, disabling ramlog, and rebooting.
  20. Hi, sorry, prop. a stupid question - but I was so far not figuring out the answer. I have a helios64 running - pretty standard installation, including openmediavault and docker, as described on the kobol help page. I realized that there are some firewall/iptables rules are set, as example: tester@helios64:/etc# sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:8384 ACCEPT tcp -- anywhere anywhere tcp dpt:3128 ACCEPT tcp -- anywhere anywhere tcp dpt:1443 ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:microsoft-ds ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn ACCEPT udp -- anywhere anywhere udp dpt:netbios-dgm ACCEPT udp -- anywhere anywhere udp dpt:netbios-ns ACCEPT tcp -- anywhere anywhere tcp dpt:ftp ACCEPT tcp -- anywhere anywhere tcp dpt:49152 ACCEPT tcp -- anywhere anywhere tcp dpt:22000 ACCEPT udp -- anywhere anywhere udp dpt:1900 Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER-USER all -- anywhere anywhere DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ... What I was not able to figure out is, where these rules come from!? In openmediafault no firewall rules are set. I also was not able to find any iptables settings in /etc/network, etc. Anyone an idea where these rules are configured? And with which service they are setup? Thanks!
  21. I checked for any available updates yesterday, and this (linux-u-boot-helios64-current 21.08.1) was applied. Can't find what was new or if it was only a version bump. By the way, nothing broke after the update.
  22. Hi all, been trying to sort out a stability problem with what was a rock solid helios64, i moved from running armbian on the eMMC to a 256GB sandisk extreme SD card due to plex continually filling it up. currently running Armbian 21.05.6 Buster with Linux 5.10.43-rockchip64, running OMV, Plex and ZFS not much more it appears this is where things go pear shaped: I've aready given i a bump in voltage as recommended in the config file but i cant tell where to check if it took the settting, frequency is set in armbian-config to ondemand. does anyone have any ideas? Thanks in advance Krita
  23. I not see in Helios64 assembling guide, how should be set coolers. Where should be directed airflow? Inside or outside the case?
  24. cancelled - power unit cable was not correctly plugged in and NAS was running on battery, hence the automated shutdowns, i think (but it's not clearly printed / displayed anywhere, i would say that it could have helped).
  25. NAS was on during the night and this morning : no more RAID5 (with 5 WD HDD). After reboot, i see that two disks are missing : ``` [Sun Jul 18 11:49:11 2021] ata1: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:49:14 2021] ata2: softreset failed (device not ready) [Sun Jul 18 11:49:23 2021] ata1: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:49:24 2021] ata2: softreset failed (device not ready) [Sun Jul 18 11:49:38 2021] ata1: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:49:38 2021] ata1.00: failed to set xfermode (err_mask=0x40) [Sun Jul 18 11:49:56 2021] ata2: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:49:56 2021] ata2: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:49:57 2021] ata1: illegal qc_active transition (00000000->00000001) [Sun Jul 18 11:50:06 2021] ata1: illegal qc_active transition (00000000->00000001) ``` ``` 11:49 root@helios64 /mnt/internal# ll /dev/sd* brw-rw---- 1 root disk 8, 32 2021-07-18 11:48 /dev/sdc brw-rw---- 1 root disk 8, 33 2021-07-18 11:48 /dev/sdc1 brw-rw---- 1 root disk 8, 48 2021-07-18 11:48 /dev/sdd brw-rw---- 1 root disk 8, 49 2021-07-18 11:48 /dev/sdd1 brw-rw---- 1 root disk 8, 64 2021-07-18 11:48 /dev/sde brw-rw---- 1 root disk 8, 65 2021-07-18 11:48 /dev/sde1 ``` What's happening ? Is it also a PSU that failed (like for HELIOS4 NAS ...) ? PSU unit light seems OK (blue led on the alimentation itself, not flashing)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines