Hi! Sorry if this is off topic but i'm making a LFS project, mainly educational to see how WRT software and OpenWRT generally works.. I built many LFS systems in the past but i've been dumbstruck on this build.. The machine is a Ubiquiti nanostation M5 XW and i'm trying to compile the mainline Linux kernel (5.4-rc7).. With the default config from openwrt or ath79_defconfig i get a DSP exception, with a bit of tweaking i get a kernel panic that seems to be related to SPI_DEV.. Any help is appreciated, where to go from here?
This is with a completely stock kernel but with openwrt's config, i tried ath79_defconfig with the same result.. I already submitted a bug to kernel.org's bugzilla but i just want to check here before i waste a kernel developer's time...
Well. You might want to compare the log from a known working kernel. The message looks like it cannot find the init process. I don't see the rootfs command line argument so that might be the cause.
I don't know the target and I'm just guessing from the log... But I think that your kernel is not getting it's command line correctly from the bootloader.
Embedded devices, like routers, tend to need a lot of special attention, ranging from kernel patches (yes, ath79 needs quite a few for basic functionality), configurations to get kernel and userland as small as possible and special care about how to present these to the device (in a way compatible to the OEM bootloader, etc.). OpenWrt's buildroot contains all the information for these necessary steps, while not always easy and obvious to read, you can't just ignore them and expect a current mainline kernel to boot on your device, you will have to forward port patches/ DTS files special build incantations and lots of other device specific quirks ingrained into the buildsystem.
While ath79 is on its way towards being merged into mainline piece by piece, it's not quite there yet - so at the current point in time it is indeed wasting the kernel developer's time, unless you can actually provide a fix[0] and don't just come with a(n expectable) problem.
--
[0] or come with a reproducable regression, as in vanilla mainline/ kernel.org kernel v5.3 with configuration "x1" and built by gcc "x2", binutils "x3", … was working without any modifications, upgrading to vanilla mainline/ kernel.org kernel v5.4-rc7 with configuration "y1" and built by (the same) gcc "x2", binutils "x3", … now breaks the device with error log "z0". Bisecting between v5.3..v5.4-rc7 suggests the issue to be introduced in commit "abc".
console=ttyS0,115200 earlyprintk init=/init rootfstype=squashfs root=31:03
Still reproducible so i doubt it's has anything to do with the kernel parameters, sadly 
I understand, but kernel 4.19.xx boot until another error about GPIO pins overlapping... Which is more later than the spi_dev error i'm getting.. But i get where you're coming from, thank you for the insight!
Edit: Or could be former, i honestly don't know anymore.. been pulling my hair at this for weeks now