HooToo TM-05, Add LZMA Loader

Don't pull your hair out! :wink:

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! :slight_smile:

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. :crazy_face:

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) :frowning_face:. Let me try to explain!

  • with small_flash, the log is https://paste.ubuntu.com/p/pSXvmmm5Mz/. All working and loading, but a bit of a red flag ... the sysupgrade.bin header tells u-boot to CRC the entire (full) kernel. This is OK for small_flash, not breaking due to the 1.5 MB load limit.
  • removing small_flash, this is where my real remaining issue is. The log is here, https://paste.ubuntu.com/p/YVKZNz4vTk/. As you can see, the same as small_flash, CRC is for the full kernel ... but now, it's > 1.5 MB, so the CRC check fails, as only 1.5 MB is loaded (raspi_read), so then no go on the CRC. I need the header and CRC check to really only be on the lzma loader, so ~ 3 kB ... agreed? Then control will be handed off to the loader, and it will happily retrieve the > 1.5 MB kernel directly from flash (right?).

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! :slight_smile:

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,

  1. Booting case (small_flash of course) - and you can see the KERNEL using loader-okli, right?
  • Recipe,
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
  1. Failing case, but a bit different than above ... as I added another uImage (header) at the start of sysupgrade.bin. I think this helps, now the data being checked looks OK (and 3 kB!), agreed? So from here, I think just fix the boot address ... right?
  • Recipe,
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! :+1:

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,

  • don't add loader-okli to the kernel. I (think) it's not needed there, rather needs to be added to the image, so then the header and CRC are as needed
  • added loader-okli to the start of the sysupgrade.bin file ... so the header and CRC all work. @xabolcs, I can clean this up later, as you noted, but it matches to the uImage you were talking about!
  • keep the uImage lzma -M 0x4f4b4c49 for the kernel so loader-okli finds it (right?)

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! :laughing:

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 :smiley:

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 ... ;-),

  • this is where it starts it's search, looking for the magic header ... right? I have the step set to 1 (for now), so it will find it, just not as efficiently as it could, no?
  • no issue changing the value, but why would that stop the loader from starting? I don't even get the "intro" message, saying that's going to go look for the kernel
  • there is a pad in the recipe (append-loader-okli $(1) | pad-to $$$$(BLOCKSIZE)), but it's not really padding?

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 :laughing:. 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 :smile:).

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 :smile:).