Porting OpenWrt to WinkHub v1

Hi folks,

I am trying to port OpenWrt to the Wink Hub v1, which is an i.MX28-based board with a whole bunch of IoT radios attached via serial ports. The standard flash has updater_kernel and updater-root partitions intended for recovery and update purposes, which appears to be ideal for messing around with OpenWrt, but still keep the ability to boot back to a working OS.
I have downloaded the duckbill i.MX28 kernel from the 19.07.2 release, and have written it to /dev/mtd1 using nandwrite. (This is a whole other story, having started with dd and caused a whole bunch of ECC bitflip errors on the NAND, I had to work around that by erasing the partition inside u-boot to get rid of the errors!)
Unfortunately, while loading the kernel from mtd updater-kernel works, and iminfo reports the correct header information, the kernel fails to boot.

U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  NAND, 3V3
DRAM:  64 MiB
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
Hit any key to stop autoboot:  0 
=> setenv bootargs 'noinitrd console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi'; mtdparts default && ubi part database && ubifsmount ubi0:database && ubifsload ${loadaddr} openwrt-19.07.1-mxs-uImage 1799536 && bootm ${loadaddr}
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=3"
UBI: MTD device size:            8 MiB
UBI: number of good PEBs:        64
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:     1
UBI: available PEBs:             6
UBI: total number of reserved PEBs: 58
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 63/45
UBIFS: mounted UBI device 0, volume 0, name "database"
UBIFS: mounted read-only
UBIFS: file system size:   5459968 bytes (5332 KiB, 5 MiB, 43 LEBs)
UBIFS: journal size:       1015809 bytes (992 KiB, 0 MiB, 6 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  269835 bytes (263 KiB)
Loading file 'openwrt-19.07.1-mxs-uImage' to addr 0x42000000 with size 1799536 (0x001b7570)...
Done
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   ARM OpenWrt Linux-4.14.167
   Created:      2020-01-29  16:05:35 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1799472 Bytes = 1.7 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

I have actually tried writing the OpenWrt kernel to a USBIFS partition as well, and copying the kernel from there, but it fails in exactly the same way as it does if I load it from mtd1/updater-kernel.

Does anyone have any ideas as to why the modern kernel won't boot, while the ancient 2.6.35 one provided by the vendor does? My first thought is that the method that u-boot uses to pass bootargs to the kernel has changed, and as a result, the kernel is not aware of the available serial port for boot-time logging. But I have no idea what it should be doing, or how to check.

What's the corresponding output when the legacy vendor supplied kernel boots? Can you post that?

Truncated boot log, showing the u-boot environment settings, and the initial boot messages from the vendor kernel.
Full boot log available here: https://pastebin.com/swviZcPa

U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  NAND, 3V3
DRAM:  64 MiB
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
Hit any key to stop autoboot:  0 
=> 
=> printenv
app_boot=run appboot_args && nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00300000; bootm ${loadaddr}
appboot_args=setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi';
baudrate=115200
bd_addr=0021CC06B4DA
boot_app=run app_boot || run app_boot_bad
boot_getflag=mtdparts default && ubi part database && ubifsmount ubi0:database && mw 42000000 0 8 && ubifsload 42000000 DO_UPDATE 1 && run boot_logic
boot_logic=mw 42000004 30; if cmp 42000000 42000004 1; then run boot_app; else run boot_updater; fi;
boot_updater=run updater_boot || run updater_boot_bad
bootcmd=mtdparts default; run boot_getflag || echo Falling back to updater...; run boot_updater
bootdelay=1
bootfile=uImage
ethact=FEC0
ethaddr=00:04:00:00:00:00
ethprime=FEC0
loadaddr=0x42000000
serialno=142103108WZD1
stderr=serial
stdin=serial
stdout=serial
updater_args=setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=2 root=ubi0:rootfs rw gpmi';
updater_boot=run updater_args && nand read ${loadaddr} updater-kernel 0x00300000 && bootm ${loadaddr}
updater_boot_bad=run appboot_args; setenv bootargs ${bootargs} badupdater; nand read ${loadaddr} app-kernel 0x00400000; bootm ${loadaddr}
ver=U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)

Environment size: 1456/16379 bytes
=> setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi';
=> mtdparts default
=> nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}

NAND read: device 0 offset 0x2b00000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-2.6.35.3-flex-dvt
   Created:      2014-04-30   3:15:35 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1928460 Bytes = 1.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3-flex-dvt (saurabh@localhost.localdomain) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #32 PREEMPT Tue Apr 29 23:15:31 EDT 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Freescale MX28EVK board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60784k/60784k available, 4752k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
    vmalloc : 0x84800000 - 0xf0000000   (1720 MB)
    lowmem  : 0x80000000 - 0x84000000   (  64 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .init : 0x80008000 - 0x80027000   ( 124 kB)
      .text : 0x80027000 - 0x803b6000   (3644 kB)
      .data : 0x803b6000 - 0x803deec0   ( 164 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
	RCU-based detection of stalled CPUs is disabled.
	Verbose stalled-CPUs detection is disabled.
NR_IRQS:288

As an extra data point, here is a comparison of the files written to that partition:

% file nandbackup/mtd1 openwrt-19.07.1-mxs-uImage 
nandbackup/mtd1:            u-boot legacy uImage, Linux-2.6.35.3-flex-dvt, Linux/ARM, OS Kernel Image (Not compressed), 1928460 bytes, Wed Apr 30 03:15:35 2014, Load Address: 0x40008000, Entry Point: 0x40008000, Header CRC: 0xDF2294AE, Data CRC: 0xCE6AAB35
openwrt-19.07.1-mxs-uImage: u-boot legacy uImage, ARM OpenWrt Linux-4.14.167, Linux/ARM, OS Kernel Image (Not compressed), 1799472 bytes, Wed Jan 29 16:05:35 2020, Load Address: 0x40008000, Entry Point: 0x40008000, Header CRC: 0xFD476D82, Data CRC: 0x70AA943F

Superficially, they appear to be configured the same, from what I can tell.