Don't pull your hair out! 
Just stick to small_flash and practice with working LOADER_FLASH_OFFS!
And please include a full serial log with a working OKLI magic.
Is your git tree on GitHub up to date? I would like to check your recipes! 
Yeah, @mpratt14's device required more advanced magic, as the bootloader crc checks both kernel and rootfs not just the 1.5M kernel size limit. 
Thanks! And yes, not enough hair left to start pulling it out ... LOL. To clarify - with small_flash, all is good ... the LOADER offset works, kernel loads, etc. The OpenWrt image is "found at 0xa0502840" => exactly as I expect (flash base is 0x00500000). So that's all good.
The problem is what happens when I try to remove small_flash (which I think is pretty much all I have left, then cleanup of course) 
. Let me try to explain!
Make sense?
And do your question - no, as I have been hacking things about, trying different options, I haven't pushed my code up. But that said, here is my latest device recipe (which I think is where the issues must be ... agreed?),
SOC := mt7620n
IMAGE_SIZE := 7872k
DEVICE_VENDOR := Ravpower
DEVICE_MODEL := WD03
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
LOADER_TYPE := bin
LOADER_FLASH_OFFS := 0x0
BLOCKSIZE := 64k
COMPILE := loader-$(1).bin
# COMPILE := loader-$(1).bin loader-$(1).uImage
COMPILE/loader-$(1).bin := loader-okli-compile
# COMPILE/loader-$(1).uImage := append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE) | lzma | uImage lzma
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 5120 | uImage none
# KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size
FYI, the commented out lines are just things I was trying, to be similar to @mpratt14. Oh, and don't let the Ravpower WD03 worry you, I'm using it because it's basically the same HW, but my HooToo code is a bit messed up, as I was trying to go down the "tiny" path (but this is a better way, so using this device for testing).
Thanks!
Once you succesed with the above!
Show me that (device recipe and) full serial log please! 
The serial logs you linked above use lzma-loader instead loader-okli and friends.
Sure! I think I'm using loader-okli and friends, based on the recipe, but I won't guarantee it ... LOL! Actually, a slight update below as well ... think it's very close. Two cases,
define Device/ravpower_wd03
SOC := mt7620n
IMAGE_SIZE := 7872k
DEVICE_VENDOR := Ravpower
DEVICE_MODEL := WD03
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
LOADER_TYPE := bin
LOADER_FLASH_OFFS := 0x0
BLOCKSIZE := 64k
COMPILE := loader-$(1).bin
# COMPILE := loader-$(1).bin loader-$(1).uImage
COMPILE/loader-$(1).bin := loader-okli-compile
# COMPILE/loader-$(1).uImage := append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE) | lzma | uImage lzma
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 5120 | uImage none
# KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size
endef
TARGET_DEVICES += ravpower_wd03
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xE872D718, created: 2020-06-25 00:36:19, image size: 1348385 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0xD929FF37, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: none, image name: "MIPS OpenWrt Linux-4.14.180"
5820 0x16BC Copyright string: "Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>"
10368 0x2880 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4156823 bytes
1303401 0x13E369 MySQL ISAM compressed data file Version 11
1348449 0x149361 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2477174 bytes, 1353 inodes, blocksize: 1048576 bytes, created: 2020-06-25 00:36:19
define Device/ravpower_wd03
SOC := mt7620n
IMAGE_SIZE := 7872k
DEVICE_VENDOR := Ravpower
DEVICE_MODEL := WD03
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
LOADER_TYPE := bin
LOADER_FLASH_OFFS := 0x0
BLOCKSIZE := 64k
COMPILE := loader-$(1).bin
# COMPILE := loader-$(1).bin loader-$(1).uImage
COMPILE/loader-$(1).bin := loader-okli-compile
# COMPILE/loader-$(1).uImage := append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE) | lzma | uImage lzma
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 5120 | uImage none
# KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
IMAGE/sysupgrade.bin := append-loader-okli $(1) | lzma | uImage lzma | append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size
endef
TARGET_DEVICES += ravpower_wd03
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x592153C1, created: 2020-06-25 00:36:19, image size: 3400 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0xFF2359A5, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-4.14.180"
64 0x40 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6372 bytes
3464 0xD88 uImage header, header size: 64 bytes, header CRC: 0xE872D718, created: 2020-06-25 00:36:19, image size: 1348385 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0xD929FF37, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: none, image name: "MIPS OpenWrt Linux-4.14.180"
9284 0x2444 Copyright string: "Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>"
13832 0x3608 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4156823 bytes
1306865 0x13F0F1 MySQL ISAM compressed data file Version 11
1351913 0x14A0E9 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2477174 bytes, 1353 inodes, blocksize: 1048576 bytes, created: 2020-06-25 00:36:19
Thanks!!!
@arrmo Slow down there chief
If you made any modifcation to loader.c, undo that. There is no reason to touch the loader's source code. Anything that starts with 0x80.... or similar refers to where it will be offloaded into RAM. This is why when you boot you see Load Address start with 0x8.
From your bootlog, kernel got placed in ram at 0x80500000, boot process moved it to top of RAM aka 0x80000000
## Booting image at 80500000 ...
Image Name: MIPS OpenWrt Linux-4.14.180
Image Type: MIPS Linux Kernel Image (uncompressed)
Data Size: 1343693 Bytes = 1.3 MB
Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
OK
I think you are missing the point of the loader. It looks to me like you are just adding the loader to the kernel, instead of replacing it with the kernel.
Understand the purpose of the image commands:
loader-okli: is for making a simple loader for a compressed kernel for bootloaders that can only load uncompressed or non-lzma compressed kernels.
Example:
define Build/loader-okli
dd if=$(KDIR)/loader-$(word 1,$(1)).$(LOADER_TYPE) bs=$(word 2,$(1)) conv=sync of="$@.new"
[...]
KERNEL := kernel-bin | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 7680
Despite loader-okli being the last command, it actually places the loader in the front of the kernel (the in-file in dd is the loader, the out-file leaves space for the rest)
loader-okli-compile: is for loading a kernel in a different part of the flash, hence the variable LOADER_FLASH_OFFS (flash offset)
define Build/loader-okli-compile
$(call Build/loader-common,FLASH_OFFS=$(LOADER_FLASH_OFFS) FLASH_MAX=0)
endef
Notice how in loader-okli-compile there is not interaction with a recipe target $@. It literally just spits out the 4 kb loader binary. This is why the loader.uImage line is necessary, since the binary by itself is not bootable.
From my commit:
COMPILE/loader-ens202ext.bin := loader-okli-compile
COMPILE/loader-ens202ext.uImage := append-loader-okli ens202ext | \
pad-to $$$$(BLOCKSIZE) | lzma | uImage lzma
This creates a uImage wrapping around the loader. This is because the bootloader is going to launch the loader ONLY, which will then find the actual kernel and launch that.
It's hard to see whats really happening unless you look at the custom factory.bin recipe engenius_ens202ext-factory...
See that for factory.bin, we start with kernel + rootfs
IMAGE/factory.bin := append-squashfs-fakeroot-be | pad-to $$$$(BLOCKSIZE) | \
append-kernel | pad-to $$$$(BLOCKSIZE) | append-rootfs | pad-rootfs | \
check-size | engenius_ens202ext-factory
Everything you see here, fakeroot + the ACTUAL kernel + rootfs gets passed to engenius_ens202ext-factory as the recipe target $@
Then:
$(CP) $(KDIR)/loader-ens202ext.uImage $@.tmp/openwrt-senao-ens202ext-uImage-lzma.bin && \
$(CP) $@ $@.tmp/openwrt-senao-ens202ext-root.squashfs && \
First line is: okli loader gets copied to the uImage-lzma.bin, this is to be booted
Second line is: the entire target $@ is copied to root.squashfs, which is "seen" by the bootloader as rootfs.
Remember the target passed to the image command is kernel + rootfs.
Therefore the partition meant for the kernel does not have the kernel at all. Rather, the space for the kernel has the loader ONLY, and the space for rootfs has kernel + rootfs. Everything is shifted over.
This is a huge waste of space until one implements the virtual_flash node.
The value I set for LOADER_FLASH_OFFS is 0x230000
This is because...
here is /proc/mtd from original software (which is actually old openwrt)
root@ENS202EXT:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00050000 00010000 "custom"
mtd3: 00180000 00010000 "kernel"
mtd4: 00bd0000 00010000 "rootfs"
mtd5: 00200000 00010000 "failsafe"
mtd6: 00010000 00010000 "ART"
Here is the partition table after all the changes (from the bootlog posted earlier)
[ 0.478112] Creating 9 MTD partitions on "spi0.0":
[ 0.486305] 0x000000000000-0x000000040000 : "u-boot"
[ 0.496478] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.507339] 0x000000050000-0x0000000a0000 : "custom"
[ 0.517415] 0x0000000a0000-0x0000000b0000 : "loader"
[ 0.527672] 0x0000000b0000-0x000000220000 : "firmware2"
[ 0.538259] 0x000000220000-0x000000230000 : "fakeroot"
[ 0.548666] 0x000000230000-0x000000df0000 : "firmware1"
[ 0.559316] 0x000000df0000-0x000000ff0000 : "failsafe"
[ 0.569699] 0x000000ff0000-0x000001000000 : "art"
The bootloader always attempts to boot at 0x0a0000. This is where the kernel used to be. The old kernel partition took up 1536k (0x18) of space, which makes the next partition start at 0x220000 (0xa + 0x8 = 0x12). That partition used to be the rootfs partition. I needed 1 more block because I had to do the same thing for rootfs (a fake/substitute for rootfs). Therefore, the actual kernel starts at 0x230000 for me. Remember that offset is relative to start of flash, not relative to where the loader is.
Nice progress! 
Yeah, there is a missing uImage recipe: the u-boot needs an uImaged kernel.
But I prefer the COMPILE/loader-$(1).uImage for that.
Yep, figuring that out ... LOL. I can see that u-boot needs a uImage (loader) kernel - need the size right to not break the CRC check.
@mpratt14 - really appreciate the comments! Please just give me a bit to digest (work through them). But really do appreciate you taking the time to capture these. FYI, I started through, realized I need to think more (=digest) ... but so you know, the only changes I made to loader.c were print statements, to try to understand it a bit, that's all!
@mpratt14 Again, thanks so much for the comments! Some thoughts, below - by all means correct me where I'm off base - I'm sure I am somewhat. LOL.
Agree with you! I'm realizing that now ... so thinking I pre-pend with this loader, but then remove it from "later" in the chain (image). Agreed?
Right - or for the case I have here, where u-boot won't load the full kernel. Right? Meaning => have loader-okli pull directly from flash. Correct?
That makes sense! I admit, this was part of my confusion - trying to understand what commands result in pre- vs. post-pend. Thanks!
Yes, that's what I have gradually been realizing, working through this (sorry, much of this is new to me). It makes sense now, and is actually very similar to what I need as well. It also addresses my CRC issue ... as u-boot doesn't load the full (large / OpenWrt) kernel.
OK, that part I'm still digesting ... LOL. Let me think / debug some more here, may come back with a few other questions.
Thanks again so much for the details!
Hmmm ... OK, I updated the Device "recipe" (below), I think matching to what you were saying @mpratt14 - but by all means disagree!
define Device/ravpower_wd03
SOC := mt7620n
IMAGE_SIZE := 7872k
DEVICE_VENDOR := Ravpower
DEVICE_MODEL := WD03
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
LOADER_TYPE := bin
LOADER_FLASH_OFFS := 0x0
BLOCKSIZE := 64k
COMPILE := loader-$(1).bin
COMPILE/loader-$(1).bin := loader-okli-compile
KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49
IMAGE/sysupgrade.bin := append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE) | lzma | uImage lzma | append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size
endef
TARGET_DEVICES += ravpower_wd03
Key changes are,
binwalk seems to say this is what I get,
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x592153C1, created: 2020-06-25 00:36:19, image size: 3400 bytes, Data Address: 0x80000000, Entry
Point: 0x80000000, data CRC: 0xFF2359A5, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt
Linux-4.14.180"
64 0x40 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6372 bytes
3528 0xDC8 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4156823 bytes
1296561 0x13C8B1 MySQL ISAM compressed data file Version 11
1341609 0x1478A9 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2477174 bytes, 1353 inodes, blocksize: 1048576 bytes, created: 2020-06-25 00:36:19
And here is the log, https://paste.ubuntu.com/p/fwKYVTJ6rV/. To me, this looks right ... data size, checksum ... all OK (I think ... LOL). And this was loaded from flash, to RAM (correct?), but what's odd is that starting loader-okli (which is at 0x8000000 now?) ... just hangs here? Hmmm.
Thanks!
Yeah you're on the right track now
Recipe looks OK in my opinion, but we are to avoid long lines, therefore something like
NOTE: I swapped check-size and append-metadata. Metadata never gets written to flash anyway as far as I understand
IMAGE/sysupgrade.bin := append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE) | \
lzma | uImage lzma | append-kernel | append-rootfs | pad-rootfs | \
check-size | append-metadata
Actually I thought your last log still had something like
Data Size: 1348385 Bytes = 1.3 MB
but in your last log, whatever you did is ok too, as long as the bootloader sees only the loader. Remember the goal is to eliminate the kernel size limit, by using loader as a substitute, however you want to do it is fine.
Why did you call this a failing case again? Log looks ok...but did kernel actually load? You had a uImage header on top of a uImage header or something?
I think you had two loaders at the same time, but its ok now. You can use either loader-okli or loader-okli-compile, but not both.
Thanks for the comments! And I do think we're on the same page. Agree with you on the long lines, will clean this all up properly once it's working. To your question, this is a failing case because I get to,
Starting kernel ...
And that's it ... LOL. Very odd, but it's not running the (3.3 kB) loader-okli. Not sure why. I believe the addresses are correct, it sees the right type and checksum (info below) ... it's just not proceeding from there. That's what I'm stumped at now, very odd.
## Booting image at 80500000 ...
Image Name: MIPS OpenWrt Linux-4.14.180
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 3400 Bytes = 3.3 kB
Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80000000) ...
## Giving linux memsize in MB, 64
Starting kernel ...
And that's where it hangs. Any pointers to my stupidity appreciated! 
Thanks!
This is your last remaining issue. Its not possible for the offset to be 0x0, that is the location of the bootloader on the flash. From your binwalk output, the correct offset would be (offset of loader + 0xDC8). Anytime you see "offset" this is relative to the start of flash, not relative to the position of the loader. The loader doesn't know where it is, but the start of flash is always 0x0. I had the same issue until I realized this 
Also its worth noting. We have to be careful including the loader in the sysupgrade.bin. If there is any change to the loader in the future, the size of the loader might change, which would then change the offset location of the actual kernel. This is why in my commit for the ENS202EXT there is a dedicated partition for the loader. I would recommend padding to the nearest 4k and then setting offset to 0x1000 (which is 4k in hex).
Here I was explaining how it worked on my commit, for the ENS202EXT, the numbers don't apply here, but the idea is the same.
That makes sense! But, then a few questions ... ;-),
Agreed! But again, if it starts a bit too low (in terms of offset), and steps by 1 ... it will find it, right? Again, perhaps not 100% efficient, but it should work (I think)?
I may be missing your point, by all means disagree. To me the problem is why the loader isn't even starting.
Thanks!
Not sure, but if you modified loader.c make sure you reverse those changes
You either know where these things on the flash are or you don't. The value of LOADER_FLASH_OFFS is simply the answer to the question "Where is the kernel on the flash chip?"
Maybe post your partition table again, with some detailed notes?
EDIT:
If your flash partition is something like this
$ cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 007b0000 00010000 "firmware"
mtd4: 00120f6e 00010000 "kernel"
mtd5: 0068f092 00010000 "rootfs"
mtd6: 00440000 00010000 "rootfs_data"
mtd7: 00000000 00000000 "art"
Then the loader starts at 0x50000 on the flash
Then the kernel starts at 0x50DC8 on the flash
It might be different for you at this point, look at your DTS
I shortened the recipe line, like you suggested - that seemed to make a difference. It boots now! Pasting a couple things here, to make it easier to read (vs. all inline).
https://paste.ubuntu.com/p/2QrrZQG83M/
And it's almost all working! Boots now, finds the header by searching, boots ... and just a hiccup with the partitions now?
Thanks!
Nice, just a couple notes
"Where the loader is" would include the header, because thats what u-boot needs to find in order to boot it. That doesn't matter though, we care about the kernel location. I know the variable is called "loader" flash offset, but it is actually for telling the loader where the kernel is.
From your log:
OpenWrt kernel loader for MIPS based SoC
Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>
Looking for OpenWrt image...
> Flash, base address: 0xa0500000
> Flash, start offset: 0x00000000
> Flash, end offset: 0x0f000000
> Flash, step size: 0x00000001
> Flash, search size: 0x0f000000 (251658240 bytes)
found at 0xa0500dd8
> Kernel, offset: 0x00000040
> Kernel, size: 0x00146ae1
> Kernel, load address: 0x80000000
> LZMA data, offset: 0xa0500e18
> LZMA data, size: 0x00146ae1
LZMA stream properties valid!
Decompressing kernel... done!
Starting kernel at 80000000...
See how it found the kernel at 0xa0500dd8
This is what you would have to figure out ahead of time
and set the variable like this:
LOADER_FLASH_OFFS := 0x500dd8
However it seems to be doing the job for you...
@xabolcs I actually didn't know the loader will find the kernel for you. Is that what it does when set to 0x0?
FYI, I got that from this link - just to share what I can!
Hmmm ... now why is the flash partioning failing. Wondering if it's related to that KERNEL line?!?!
Not sure how that made a difference LOL
Do you make clean between builds?
From your log:
[ 0.834524] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 0.849507] Please append a correct "root=" boot option; here are the available partitions:
This is related to your DTS. I had the same issue. Need to fix your "compatible" property, as it is not splitting the "firmware" mtd into kernel and rootfs.
Try this:
compatible = "openwrt,okli";
This goes in the firmware parition node
Right now in your DTS you have
partition@50000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x50000 0x7b0000>;
};
so try this:
partition@50000 {
compatible = "openwrt,okli";
label = "firmware";
reg = <0x50000 0x7b0000>;
};
Related commit if you are curious to read
I admit - I do not . Just tried that, not fixing my issues ... so let me run a full make dirclean, and update / reset .config. Will see if that works. I admit, I struggle to reliably rebuild the kernel (often find it's "old"), so I don't clean very often. Will report back, as a full dirclean and rebuild takes a bit.
Awesome - thanks! Trying this now (with the full rebuild 
).
I am, appreciate it!
Dang it! OK, here is what I have in the dts file now (and a full dirclean and make),
partition@50000 {
compatible = "openwrt,okli";
label = "firmware";
reg = <0x50000 0x7b0000>;
};
Still the same, doesn't seem to be splitting that "firmware" partition. I did check, the link you sent does seem to be in the code I have locally (sanity check 
).