Espressobin support development efforts

[zador.blood.stained]

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?

[lupus]

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>> 

 

[zador.blood.stained]

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.

[tkaiser]

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.

[tkaiser]

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

[umiddelb]

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.

[umiddelb]

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.

[zador.blood.stained]

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

[tkaiser]

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.

[lanefu]

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.

[lupus]

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.

[lupus]

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/... 

[tkaiser]

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.

 

[tom_i]

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?

[lupus]

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 ?

[tom_i]

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

[tom_i]

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.

[tkaiser]

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?

[martinayotte]

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.

 

[tkaiser]

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:

[Igor]

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?

[tkaiser]

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.

[tkaiser]

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? 

 

 

 

 

[umiddelb]

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.

 

[tkaiser]

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.

[tkaiser]

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)

[tkaiser]

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?

[lupus]

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

[Igor]

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!

 

 

 

[umiddelb]

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.