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

Tue Aug 9 23:56:34 PDT 2016

I'm not sure what this was but I rebased my branch and it's fixed now.

On 08/09/2016 05:33 AM, J Mo wrote:
> 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.
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev