[LEDE-DEV] TRENDnet TEW-827DRU (QCA IPQ8064), stuck at "Starting kernel ..."

[J Mo]

Hello everyone

I am trying to build LEDE for the TRENDnet TEW-827DRU and I'm stuck on a 
problem where the kernel won't boot.

This device is based off the IPQ8064 and QCA9980+QCA9980 chips. Very 
similar to the TP-Link Archer C2600, Linksys EA8500, and Netgear D7500.

I have the factory format issues worked out and I can build the required 
FIT+UBI images. This platform is like the EA8500 in that it's NAND with 
kernel in UBI (kernel, squashfs, ubifs).

I've been documenting my progress with technical details here:
https://forum.openwrt.org/viewtopic.php?pid=333532#p333532



Unfortunately, I'm stuck now. The kernel just won't start booting and/or 
I'm not getting any console output from the kernel, but I suspect it's 
not actually booting at all.

I've gone to google and found a number of good hints that I should check 
my serial port configuration, entry/load addresses, machine IDs, and 
similar, but as of yet, I've not figured out what my problem is.

I am a novice. This is probably something stupid that I've overlooked, 
typoed, or just don't know about.

I've reviewed my DTS file several times and I think it's okay. I don't 
have any reason to suspect the serial port on this one is any different 
than the other similar models. The OEM boot log looks very similar to 
the other models in that respect. This isn't a new platform, just a 
different device from another OEM.



I tried making a new kernel with LL_DEBUG/printk, but I'm still not 
getting anything, but that may be because I'm compiling it wrong?

Kernel low-level debugging functions (read help!) (DEBUG_LL) [Y/n/?] y
   Kernel low-level debugging port
   > 1. Kernel low-level debugging messages via QCOM UARTDM 
(DEBUG_QCOM_UARTDM) (NEW)
     2. Kernel low-level debugging via EmbeddedICE DCC channel 
(DEBUG_ICEDCC)
     3. Kernel low-level debug output via semihosting I/O 
(DEBUG_SEMIHOSTING)
     4. Kernel low-level debugging via 8250 UART (DEBUG_LL_UART_8250)
     5. Kernel low-level debugging via ARM Ltd PL01x Primecell UART 
(DEBUG_LL_UART_PL01X)
   choice[1-5]: 1
Physical base address of debug UART (DEBUG_UART_PHYS) [0xf991e000] (NEW) 
0x16340000
Virtual base address of debug UART (DEBUG_UART_VIRT) [0xfa71e000] (NEW) 
0xf6340000
Early printk (EARLY_PRINTK) [Y/n/?] y

Are those addresses right? Heck if I know, especially the virt address, 
where does that get mapped? I tried putting "debug" and "earlyprintk" in 
my uboot bootargs.



Here is what I get on the console:

Hit any key to stop autoboot:  0
MMC Device 0 not found
MMC Device 0 not found
Creating 1 MTD partitions on "nand0":
0x0000058a0000-0x0000098a0000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=0"
UBI: MTD device size:            64 MiB
UBI: number of good PEBs:        512
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     3
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 512
UBI: number of PEBs reserved for bad PEB handling: 5
UBI: max/mean erase counter: 1/0
Read 0 bytes from volume kernel to 44000000
No size specified -> Using max size (2031616)
    Image Name:   ARM LEDE Linux-4.4.15
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2008105 Bytes = 1.9 MiB
    Load Address: 42208000
    Entry Point:  42208000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
OK

device nand0 <nand0>, # parts = 1
  #: name                size            offset          mask_flags
  0: fs                  0x04000000      0x058a0000      0

active partition: nand0,0 - (fs) 0x04000000 @ 0x058a0000

defaults:
mtdids  : none
mtdparts: none
Using machid 0x1260 from environment

Starting kernel ...



And then nothing.

Those entry/load addresses are correct as far as I can tell. It's the 
same as similar devices.

I know almost nothing about ARM machine IDs, ARMTAGS, and that sort of 
thing.

There is an OEM boot log and additional information in the forum post I 
linked to earlier.

I would share my current branch code, but my damned personal server's 
power supply just died yesterday and the replacement doesn't get here 
until Thursday.

I've tried various iterations of padding the kernel and trying to align 
it exactly like the OEM kernel.

I don't suspect any issues in u-boot, but that's possible. Source code 
is available from the OEM (link in forum post).

My build of the OEM image just finished now and I'm about to start 
inspecting that, looking for clues.



Any advice would be helpful.

Thanks for reading.