Bug#870185: FATAL: kernel 4.11.0-0.bpo.1-marvell does not boot on QNAP TS-219P II
Package: linux-image-4.11.0-0.bpo.1-marvell
Version: 4.11.6-1~bpo9+1: armel
I had Debian Stretch installed on my QNAP TS-219P II and already upgraded to the backports kernel linux-image-4.9.0-0.bpo.3-marvell (4.9.30-2+deb9u2~bpo8+1: armel). Upgrading that to the package specified above yielded a no-boot situation. The full output of the serial console:
__ __ _ _
| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__| ** LOADER **
** MARVELL BOARD: DB-88F6282A-BP LE TS-219P2+ ,PHY=1.8v
U-Boot 1.1.4 (Jan 3 2012 - 14:49:37) Marvell version: 3.5.3
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CD5C0
Soc: MV88F6282 Rev 1CPU running @ 2000Mhz L2 running @ 500Mhz
SysClock = 500Mhz , TClock = 200Mhz
DRAM (DDR3) CAS Latency = 7 tRP = 7 tRAS = 20 tRCD=7
DRAM CS[0] base 0x00000000 size 256MB
DRAM CS[1] base 0x10000000 size 256MB
DRAM Total size 512MB 16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
[16384kB@f8000000] Flash: 16 MB
CPU : Marvell Feroceon (Rev 1)
USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
PEX 1: PCI Express Root Complex Interface
PEX interface detected Link X1
Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found
Net: egiga0 [PRIME]
Hit any key to stop autoboot: 0
QNAP: Recovery Button pressed: 0
Marvell>> boot
Send Cmd : 0x68 to UART1
## Booting image at 00800000 ...
Image Name: kernel 4.11.0-0.bpo.1-marvell
Created: 2017-07-30 18:55:56 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2076472 Bytes = 2 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
That's it, no further output, no boot. The kernel seems to die early on.
I've observed such early failures on another platform when a "bad" device tree binary was flashed. Is it possible that kernel 4.11 requires a changed dtb, and that was not correctly upgraded?
Reply to: