zador.blood.stained Posted July 24, 2017 Posted July 24, 2017 5 minutes ago, lupus said: Please find attached the current environment: Default environment doesn't try to use the boot script, so it needs to be changed (or u-boot needs to be recompiled and reflashed). Can you please provide output of "help" too? 0 Quote
lupus Posted July 24, 2017 Posted July 24, 2017 3 minutes ago, zador.blood.stained said: Can you please provide output of "help" too? Marvell>> help ? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootelf - Boot from an ELF image in memory booti - boot arm64 Linux Image image from memory bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol bootvx - Boot vxWorks from an ELF image bubt - Burn a u-boot image to flash cmp - memory compare cp - memory copy crc32 - checksum calculation echo - echo args to console editenv - edit environment variable env - environment handling commands exit - exit script ext2load- load binary file from a Ext2 filesystem ext2ls - list files in a directory (default /) ext4load- load binary file from a Ext4 filesystem ext4ls - list files in a directory (default /) ext4size- determine a file's size ext4write- create a file in the root directory false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fatsize - determine a file's size fdt - flattened device tree utility commands fsinfo - print information about filesystems fsload - load binary file from a filesystem image go - start application at address 'addr' gpio - query and control gpio pins help - print command description/usage i2c - I2C sub-system ir - ir - Reading and changing internal register values. loop - infinite loop on address range ls - list files in a directory (default /) map - Display address decode windows md - memory display mdio - MDIO utility commands mii - MII utility commands mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mw - memory write (fill) nm - memory modify (constant address) pci - list and access PCI Configuration Space ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables remap - Remap the output address of a window reset - Perform RESET of the CPU resetenv- resetenv - reset all variables to default run - run commands in an environment variable saveenv - save environment variables to persistent storage scsi - SCSI sub-system scsiboot- boot from SCSI device setenv - set environment variables sf - SPI flash sub-system showvar - print local hushshell variables sleep - delay execution for some time sspi - SPI utility command test - minimal test like /bin/sh tftpboot- boot image via network using TFTP protocol true - do nothing, successfully usb - USB sub-system usbboot - boot from USB device version - print monitor, compiler and linker version Marvell>> 0 Quote
zador.blood.stained Posted July 24, 2017 Posted July 24, 2017 2 minutes ago, lupus said: sleep - delay execution for some time sspi - SPI utility command No "source" command, so you can't even run a script with this u-boot. 0 Quote
tkaiser Posted July 24, 2017 Posted July 24, 2017 Hmm... I tried it now with my older 4.4.52 based OMV build and it looks like this then: https://pastebin.com/cF9eHnKf So after mounting the rootfs and doing a root@rock64:/mnt/sda1/boot# cp dtb/marvell/armada-3720-community.dtb armada-3720-community.dtb it looks like this: https://pastebin.com/RWJi6YuU I have read-only serial console access (can't type anything) and this thing overheats really badly within a minute. 0 Quote
tkaiser Posted July 24, 2017 Posted July 24, 2017 And this is with latest official Armbian nightly without mPCIe card and SATA disk connected after mounting rootfs and doing root@rock64:/mnt/sda1/boot# ln -s /boot/dtb-4.4.73-mvebu64/marvell/armada-3720-community.dtb armada-3720-community.dtb https://pastebin.com/YGtgAYZz 0 Quote
umiddelb Posted July 24, 2017 Posted July 24, 2017 1 hour ago, zador.blood.stained said: Default environment doesn't try to use the boot script, so it needs to be changed (or u-boot needs to be recompiled and reflashed). Can you please provide output of "help" too? It might be sufficient to update the stored u-boot environment on the second spi partition. 0 Quote
umiddelb Posted July 24, 2017 Posted July 24, 2017 5 hours ago, tkaiser said: I wanted to try out 4.13-rc2 (@umiddelb updated already) but fail already with u-boot: This is branch new-master and will become master, after v4.13.0 has been released. 0 Quote
zador.blood.stained Posted July 24, 2017 Posted July 24, 2017 36 minutes ago, umiddelb said: It might be sufficient to update the stored u-boot environment on the second spi partition. No since "source" command is not supported - it requires patching and recompiling anyway 0 Quote
tkaiser Posted July 24, 2017 Posted July 24, 2017 9 minutes ago, zador.blood.stained said: "source" command is not supported - it requires patching and recompiling anyway IMO we should also try to get images out that work with Marvell's u-boot present in SPI flash (so at least providing a symlink pointing to /boot/armada-3720-community.dtb and kernel image at the same location in correct format). It seems all ESPRESSOBin come with a Micro USB cable suitable for serial console so at least users could fix stuff at the u-boot prompt but at least I was not able to get a full serial connection (maybe my board is broken) and IMO it's better to avoid such hassles if possible. 0 Quote
lanefu Posted July 25, 2017 Author Posted July 25, 2017 3 hours ago, tkaiser said: IMO we should also try to get images out that work with Marvell's u-boot present in SPI flash (so at least providing a symlink pointing to /boot/armada-3720-community.dtb and kernel image at the same location in correct format). It seems all ESPRESSOBin come with a Micro USB cable suitable for serial console so at least users could fix stuff at the u-boot prompt but at least I was not able to get a full serial connection (maybe my board is broken) and IMO it's better to avoid such hassles if possible. I'm not sure even assuming board defaults is entirely safe.. mine had like TFTP or NFS boot defaults for testing or something. Re usb serial -- I seem to have to use the USB + 12v power supply to get console. Then its interesting because the USB serial will then stay up, and you can just cycle the 12v. 0 Quote
lupus Posted July 25, 2017 Posted July 25, 2017 6 hours ago, tkaiser said: I was not able to get a full serial connection (maybe my board is broken) and IMO it's better to avoid such hassles if possible. My board also started to overheat at the u-boot prompt - but after the environment variables were correctly set it could boot Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z and the thermal issues were gone after that. Please send a PM in case you wish to replace your board. 0 Quote
lupus Posted July 28, 2017 Posted July 28, 2017 Regarding potential thermal issues: There would not appear to be any. I checked the temperature of the Marvell 3720 using an infrared thermometer while at the Marvell>> prompt in U-boot. The chip reached a steady state temperature of 55 degrees Celsius within 10 minutes (ambient temperature 25 degrees Celsius). Power consumption of espressobin is about 5W in this context. Then I did boot Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z and within the first 10 minutes the 3720 reached a steady state temperature of 45 degrees Celsius (idle, ondemand, CPU frequency 200MHz). The power consumption in this context is about 3.5 W (can probably be further reduced my managing eth phy). Although these values were measured at the outside (not core temperatures), they would not appear to be problematic at all. According to Globalscaletechnologies, even core temperatures around 65 - 73 degrees Celsius (idle) would be considered normal. They observe these core temperatures in U-boot and on buildroot OS (idle). I conclude, that Armbian does already better due to cpu frequency scaling. BTW - I could not find any direct thermal monitoring in /sys/... 0 Quote
tkaiser Posted July 30, 2017 Posted July 30, 2017 Some more news. Since I thought the 1st ESPRESSOBin I bought from @lupuswould be broken (no way to access TX serial console through USB, overheating, crashing) he offered to replace the board and so we met again, I returned my board and I took his known to work. In the meantime it happened that I realized being out of the office that my laptop's battery only lasted for 6 hours so I checked and realized that I had a zombie process running since days fully utilizing one CPU core: 83941 minicom 99.7 20:48:18 1/1 0 15 4096B 0B 460K 83941 1 running *0[1] 0.00000 0.00000 501 338 72 This process obviously was stuck somewhere in IO (I used a PL2303 at the time and the macOS driver is known to be not the greatest piece of software) and obviously also reponsible for not being able to enter anything over serial console while playing with my ESPRESSOBin over days. To prepare arrival of my new board I changed some stuff (updating legacy kernel to Marvell's 17.08 branch and switching from ondemand governor to powersave as a shot in the dark). I also quickly built a new legacy Ubuntu image but didn't test myself yet: Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.78.7z In the meantime @lupus confirmed 'my' board being accessible through serial console and also that my board boots with the new image that changed default cpufreq governor. Might be related to http://espressobin.net/forums/topic/crash-after-booting-for-about-a-minute/ I remember when starting to support H3 boards last year with mainline kernel cpufreq scaling only worked without crashing after applying this u-boot patch. Maybe it's something similar here. 0 Quote
tom_i Posted July 31, 2017 Posted July 31, 2017 Hi, I have some issue with booting Espresobin. Yesterday I've updated (upgraded) Armbian via aptitude update aptitude upgrade and after reboot I can't boot to Armbian due to some error: https://pastebin.com/Ji4Kgdb6 I have there Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73 and upgraded version was 5.32.170731 I think. Anyone with same problem? 0 Quote
lupus Posted August 1, 2017 Posted August 1, 2017 The update worked for me using apt-get update && apt-get upgrade. Power consumption went up to 4.5 W due to powersave instead of ondemand. Helios LanTest results are OK (test run on 28.07.) The issue reported by tom_i seems to be related to the wifi card "Modules linked in: mwifiex_pcie mwifiex cfg80211 rfkill". Did you try to boot without the wifi card ? 0 Quote
tom_i Posted August 1, 2017 Posted August 1, 2017 No I didn't, I can try it today maybe. Yesterday I've just insert there another SD card because I bought new Class10 card, but haven't had time to finish configuration. So yesterday I made it, finally 0 Quote
tom_i Posted August 5, 2017 Posted August 5, 2017 OK, so today my EspressoBin shutdown its WIFI connection. So I had to investigate it, but no luck. https://pastebin.com/eWiWGuEt I've tried to rmmod/modprobe all necesary modules for marvell wifi "mwifiiex, mwifiex_pcie, cfg80211" 00:00.0 Ethernet controller: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless But no wlan0 in ifconfig After boot too. Looks that this wifi minipci card is broken. Any idea how to check, that it's ok? Thank you very much. 0 Quote
tkaiser Posted August 6, 2017 Posted August 6, 2017 I'm giving up on ESPRESSOBin for now. Even with the 2nd board I'm now playing with I'm still not able to access serial console (read is ok but not able to interact). Besides that the board horribly overheats with our legacy kernel. I let a new OMV image build few hours ago which boots but then runs into instabilities after some time (eg. ext4 errors, by touching the SD card slot next to the ARMADA 3720 I already burned my finger and touching the SoC itself was only possible for a very short fraction of time). Serial console output here and debug output there. It seems cpufreq scaling is not available while @lupus mentioned that power consumption increased by 1.5W after I switched from ondemand to CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y some days ago which makes not that much sense anyway. According to boot log the SoC runs at 1.0GHz and should even be capable to run at up to 1.2GHz. Given the huge amounts of heat it dissipates I fear I need active cooling to play further with this thing. What do other experience with legacy kernel after let's say 5 minutes uptime? Does it hurt to press a finger on the SoC or not? 0 Quote
martinayotte Posted August 6, 2017 Posted August 6, 2017 53 minutes ago, tkaiser said: I'm still not able to access serial console (read is ok but not able to interact) I got the same issue when I tried serial-debug on Rock64, output on TX is Ok, but no RX. Probably something in DT. 0 Quote
tkaiser Posted August 6, 2017 Posted August 6, 2017 On 12.7.2017 at 9:54 PM, umiddelb said: the board tends to crash silently with the marvell-linux 4.4 kernel after a couple of hours. Have you ever checked SoC temperature (touching with a finger is enough, if it doesn't hurt then something's different compared to my experiences with Armada 3720 so far. And did you check clockspeeds with mainline kernel? I did a quick check with 7-zip's benchmark mode and get with legacy kernel (running at 1.0GHz according to u-boot output) this -- can you or others running mainline kernel please check too: root@espressobin:~# 7z b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) RAM size: 926 MB, # CPU hardware threads: 2 RAM usage: 425 MB, # Benchmark threads: 2 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 726 143 495 706 | 18868 199 858 1703 23: 722 143 514 735 | 18631 199 858 1705 24: 720 143 540 775 | 18387 199 859 1706 25: 710 142 572 811 | 18290 199 863 1720 ---------------------------------------------------------------- Avr: 143 530 757 199 859 1709 Tot: 171 695 1233 I added a heatsink and a fan powered by a random SinoVoip product and let now cpuburn-a53 run for at least an hour. So far no freezes/instabilities and SD card slot doesn't feel hot unlike before with neither heatsink nor fan: 0 Quote
Igor Posted August 6, 2017 Posted August 6, 2017 31 minutes ago, tkaiser said: And did you check clockspeeds with mainline kernel? I tried 4.13 a few days ago but it was not booting. I had success with 4.12, but without SD card support which Uli added later. Perhaps we should do for 4.12 and have at least one working alternative? 0 Quote
tkaiser Posted August 6, 2017 Posted August 6, 2017 1 hour ago, Igor said: Perhaps we should do for 4.12 and have at least one working alternative? Well, currently I'm trying to figure out why I didn't manage to get any stable experience with Espressobin so far. Since Uli reported 4.4 kernel would freeze after some time I just thought let's check whether he's also able to report overheating and maybe settings are different between legacy and mainline kernel (eg. mainline only with one CPU core active running at very low clockspeeds). Currently I've no idea whether we're making use of DVFS with any kernel on 3720 and I also don't know at which voltage the CPU cores are fed with. I only know that for me adding heatsink and fan seemed to solve my issues: root@espressobin:~# ps auxwww | grep burn root 5942 99.5 0.0 1624 320 pts/0 R 09:51 126:56 /usr/local/bin/cpuburn-a53 root 5943 99.5 0.0 1624 80 pts/0 R 09:51 126:55 /usr/local/bin/cpuburn-a53 root 9027 0.0 0.2 4200 1968 pts/1 S+ 11:59 0:00 grep burn If cpuburn-a53 is running now for over 2 hours without problems and the board is still stable and I got even ext4 fs errors before when it only idled around (while touching the SD card slot burned my finger)... then I think thermal issues might be worth an investigation here. 0 Quote
tkaiser Posted August 6, 2017 Posted August 6, 2017 Update: I stopped cpuburn-a53 after almost 3 hours, then switched to an optimized Linpack: sudo apt install libmpich-dev cd /tmp git clone https://github.com/ThomasKaiser/StabilityTester cd StabilityTester/ while true ; do ./xhpl64 ; done I get 1.48 GFLOPS on average. Stopped then the fan to see what happens. Linpack reported 'PASSED' all the time but since I touched the heatsink with my fingers from time to time and it again started to hurt I stopped the test (switched on the fan again). Currently to me it seems we are (or at least I am) running in an overheating issue with this board. Please can other Espressobin users share the result of a 'thumb test'? Put your thumb on the SoC while the board is idling. Does it hurt or not? 0 Quote
umiddelb Posted August 6, 2017 Posted August 6, 2017 3 hours ago, tkaiser said: Have you ever checked SoC temperature (touching with a finger is enough, if it doesn't hurt then something's different compared to my experiences with Armada 3720 so far. 2 seconds, then the heats becomes very uncomfortable. 3 hours ago, tkaiser said: I did a quick check with 7-zip's benchmark mode and get with legacy kernel (running at 1.0GHz according to u-boot output) this -- can you or others running mainline kernel please check too: It's more or less the same with 4.13-rc3 ubuntu@ebin:~$ 7z b 7-Zip 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) RAM size: 2000 MB, # CPU hardware threads: 2 RAM usage: 425 MB, # Benchmark threads: 2 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 736 143 501 716 | 18910 200 855 1707 23: 732 143 521 745 | 18671 200 856 1709 24: 727 143 546 782 | 18407 199 857 1708 25: 723 144 575 825 | 18257 199 861 1717 ---------------------------------------------------------------- Avr: 143 535 767 199 857 1710 Tot: 171 696 1239 3 hours ago, tkaiser said: And did you check clockspeeds with mainline kernel? Mainline kernel doesn't come with cpufreq support. 1 Quote
tkaiser Posted August 6, 2017 Posted August 6, 2017 2 minutes ago, umiddelb said: Mainline kernel doesn't come with cpufreq support. As does legacy kernel. Thanks for your 7-zip numbers that show identical performance with mainline and legacy kernel (the whole 'test' is just about both kernels using same CPU and DRAM clock speeds which is obviously true according to the numbers). I'm still thinking we have a heat related instability issue here and should investigate about DVFS settings (or at least DFS!). Can other users who don't use a heatsink and fan do the primitive 'thumb test' on the SD card slot? On my board at an uptime of ~15 minutes this already feels way too hot. 0 Quote
tkaiser Posted August 7, 2017 Posted August 7, 2017 I let that Linpack ran over night in a loop with heatsink and fan active: root@espressobin:/usr/local/src/StabilityTester# grep -c "FAILED" nohup.out 0 root@espressobin:/usr/local/src/StabilityTester# grep -c "PASSED" nohup.out 732 No problems occured. Still interested in other users reporting thermal 'feelings' (we don't have thermal readouts active in any kernel yet so it needs a finger pressed on the SoC or SD card slot nearby if touching the SoC hurts too much) 0 Quote
tkaiser Posted August 7, 2017 Posted August 7, 2017 It seems the Trusted Firmware version burned to SPI NOR flash now uses the following config to set CPU and DRAM clockspeeds on the Espressobin production version shipped recently: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/blob/A3700_utils-armada-17.06/clocks-1000-800.txt Has anyone of you already played around with other settings available there or has a clue how to apply them? 0 Quote
lupus Posted August 7, 2017 Posted August 7, 2017 I am using tkaisers image http://kaiser-edv.de/tmp/NumpU8/Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.78.7z - updated with apt-get update && apt-get upgrade (powersave enabled - no cpufreq available). With an ambient temperature of 26 degrees Celsius, the temperature of the marvell 3720 is 50 degrees (steady state, measured after 10 minutes with an infrared thermometer), idle power consumption is 3.7W now ! The hottest chip (60 degrees) is the small one next to the 3720 with the label "U5" next to it. 50 degrees is far to hot to touch but should be OK for the silicon. Please find attached the output of armbianmonitor -u: http://sprunge.us/CWFi 0 Quote
Igor Posted August 7, 2017 Posted August 7, 2017 What am I doing wrong? Spoiler baudrate=115200 boot_interface=mmc bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait bootcmd=mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait fsck.repair=yes governor=ondemand no_console_suspend mtdparts=spi32766.0:1536k(uboot),64k(uboot-environment),-(reserved) net.ifnames=0 elevator=noop; booti $kernel_addr $initrd_addr $fdt_addr bootdelay=3 console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 eth1addr=00:00:00:00:51:82 eth2addr=00:00:00:00:51:83 ethact=neta0 ethaddr=F0:AD:4E:03:64:7F ethprime=egiga0 fdt_addr=0x1000000 fdt_file_mmc=/boot/armada-3720-community-linux-4.4.8-devel-16.07.3.dtb fdt_high=0xffffffffffffffff fdt_name=boot/dtb/marvell/armada-3720-community.dtb filesize=28f9 gatewayip=10.4.50.254 get_images=mmc dev 0; ext2load mmc 0 0x2000000 /boot/Image-linux-4.4.8-devel-16.07.3-armada_v8_mvebu; ext2load mmc 0 0x1000000 armada-3720-community.dtb get_ramfs=if test - != -; then setenv ramfs_addr 0x3000000; tftp - -; else setenv ramfs_addr -;fi hostname=marvell image_name=boot/Image image_name_mmc=/boot/Image initrd_addr=0x1100000 initrd_image=boot/uInitrd initrd_size=0x2000000 ipaddr=0.0.0.0 kernel_addr=0x2000000 loadaddr=0x2000000 loads_echo=0 microsdboot=mmc info;usb reset; ext2load mmc 0:1 $kernel_addr $image_name_mmc; ext2load mmc 0:1 $fdt_addr $fdt_file_mmc; setenv bootargs $console root=/dev/mmcblk0p1 rw panic=3 earlyprintk rootdelay=2; booti $kernel_addr $ramfs_addr $fdt_addr netdev=eth0 netmask=255.255.255.0 ramfs_addr=- ramfs_name=- root=root=/dev/mmcblk0p1 rw rootdev=/dev/mmcblk0p1 rootfstype=ext4 rootpath=/srv/nfs/ serverip=0.0.0.0 set_bootargs=setenv bootargs console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw ip=0.0.0.0:0.0.0.0:10.4.50.254:255.255.255.0:marvell:eth0:none nfsroot=0.0.0.0:/srv/nfs/ stderr=serial stdin=serial stdout=serial verbosity=1 Spoiler [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc3-ebin-129859-ga19e2f6 (ubuntu@ebin) (gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04)) #3 SMP PREEMPT Mon Jul 31 08:35:08 CEST 2017 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] bootconsole [ar3700_uart0] enabled [ 0.000000] Bad mode in Error handler detected on CPU0, code 0xbf000002 -- SError [ 0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.13.0-rc3-ebin-129859-ga19e2f6 #3 [ 0.000000] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 0.000000] task: ffff000008df2c80 task.stack: ffff000008de0000 [ 0.000000] PC is at setup_arch+0x10c/0x4f8 [ 0.000000] LR is at setup_arch+0x108/0x4f8 [ 0.000000] pc : [<ffff000008d43d1c>] lr : [<ffff000008d43d18>] pstate: 000000c5 [ 0.000000] sp : ffff000008de3f20 [ 0.000000] x29: ffff000008de3f20 x28: 0000000000d40018 [ 0.000000] x27: 000000003ff963f8 x26: 0000000000000000 [ 0.000000] x25: 000000003ff2d784 x24: 0000000000000000 [ 0.000000] x23: 0000000000000000 x22: ffff000008de9000 [ 0.000000] x21: ffff7dfffe80006c x20: ffff000008e0b000 [ 0.000000] x19: ffff000008080000 x18: 0000000000000010 [ 0.000000] x17: 0000000000002080 x16: 0000000000001800 [ 0.000000] x15: 0000000000000006 x14: ffff000088e9d58f [ 0.000000] x13: 0000000000000000 x12: 0000000000000028 [ 0.000000] x11: 0000000000000007 x10: 0101010101010101 [ 0.000000] x9 : fffffffffffffffb x8 : 0000000000000008 [ 0.000000] x7 : 0000000000000003 x6 : 0000000000800000 [ 0.000000] x5 : 0000000000000000 x4 : 0000000000000065 [ 0.000000] x3 : 0000000000000063 x2 : 0000000000000065 [ 0.000000] x1 : ffff000008c21011 x0 : 0000000000000001 [ 0.000000] Process swapper (pid: 0, stack limit = 0xffff000008de0000) [ 0.000000] Stack: (0xffff000008de3f20 to 0xffff000008de4000) [ 0.000000] 3f20: ffff000008de3fa0 ffff000008d4083c ffff000008dae028 ffff000008e94000 [ 0.000000] 3f40: ffff000008e94000 ffff000008de9000 0000000000000000 0000000000000000 [ 0.000000] 3f60: 000000003ff2d784 0000000000000000 0000000000000001 0000000001000000 [ 0.000000] 3f80: ffffffffffffffff 0000000000000000 0000000080000000 fefefefefefefefe [ 0.000000] 3fa0: ffff000008de3ff0 ffff000008d401e0 0000000000000400 000000003ff9fe20 [ 0.000000] 3fc0: 0000000001000000 0000000000000003 0000000000000000 0000000000000000 [ 0.000000] 3fe0: 0000000000000000 ffff000008dae028 0000000000000000 00000000009e726c [ 0.000000] Call trace: [ 0.000000] [<ffff000008d43d1c>] setup_arch+0x10c/0x4f8 [ 0.000000] [<ffff000008d4083c>] start_kernel+0x74/0x39c [ 0.000000] [<ffff000008d401e0>] __primary_switched+0x64/0x6c [ 0.000000] Code: 911f4000 9400350d 97fff297 d50344ff (d0fffcd6) [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x4c/0x68 with crng_init=0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! 0 Quote
umiddelb Posted August 8, 2017 Posted August 8, 2017 wrong fdt file, please take armada-3720-espressobin.dtb (/boot/kernel.d/linux-4.13.0-rc3-ebin-129859-ga19e2f6/armada-3720-espressobin.dtb) instead. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.