Do you have binwalk outputs of a stock image and then of the image are you are working with? May provide some hints. I had LZMA ERRORs on one that I am working with it turned out to be the lmza dictionary size. Binwalk will show the compression of the stock FW image including the dictionary size. I ended up with -d16 in the lzma after I found the stock FW dictionary size.
Don't know if this is what you are running into, but might be worth a look if you have not already
Sorry for making you zoom to see the images properly. Please let me know if there is any other better way upload the images.
Details of the images in the order they have been uploaded.
This image shows my Makefile addition for the project and the build artifacts generated.
Build artifcats generated with the above Makefile file.
This image shows the output of the binwalk for the images generated with the above settings. None of these images boots up. I tried both lzma and gzip compression and both fails with the errors that I had reported in my previous replies (ERROR: LzmaDecode.c, 543).
This is a random image that I got from the internet. This image does boots up properly.
The changes I did to generate a uncompressed initramfs image to overcome the issues with the compression.
Binwalk output of the uncompressed image.
Output of what happens when I try to boot this image. The boot process gets stuck at "Starting kernel...."
!
Please let me know if you get some pointers from these details.
Well that wasn't what I expected in the binwalk of the image that boots
I expected to see a uImage header first. I am a novice for sure so may not provide any valuable tips at this point, but here are a few thoughts.
My thought would be to make your image look as similar to the one that boots as possible.
Looks like there is no uImage header in the bin that boots. The last one you tried to boot did, I wonder if it confuses the old u-boot version.
Also are the Ubiquiti headers needed? Not present in the one that boots.
Maybe there is some unusual header in the bin that boots. If you haven't already it might be helpful to hexdump the first part of that image and/or run strings against it.
There might be tips in the bootlog of the image that works
Again, I am in over my head here, hopefully more experienced people will have seen something like this and know more.
As tips for posting... Some of your images my old eyes can't read. A couple other options are you can use https://pastebin.com/, paste the output there then copy the link to your post. Is really good for long output. Short ones like a single binwalk you can just paste in the post. If you put it in the post you can use the </> button to format it like code.
There should be, but unfortunately I don't exactly what you will need to do. The things I think of to do in search of hints are
scan the make output. I use -j1 V=s options on make and then scan to see what it is doing to build your images.
Search for "Ubiquiti" or "biquiti" (to avoid casing) in the source code and see if you can find parts building those headers.
Anything unusual in your make recipe for the image? The ones I have seen will have callouts to build custom headers, like edimax
When messing with the image/bin build itself sometimes it is easier and faster to manually run some of the tools like mkimage. You'll see these in the make output
I was able to get rid of those "Ubiquiti headers" information's. It was coming from the "arch/mips/ath79/prom.c". But even after that the uncompressed initramfs image doesn't seem to work. The binwalk between the working image and the non-working one is almost identical with few exceptions.
So since I am not able to do a TFTP boot from RAM (LZMA decompression fails and uncompressed Initramfs image doesn't work), I have done a workaround in u-boot to download the squashfs image from the TFTP server, verify the CRC, write to the flash, again verify the CRC of the image in flash and boot the new image if everything is fine.
But this method itself wont work if the flash has gone bad in the first place. But still something is better than having nothing.
You'll also receive the same error, "Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543" if your image is simply too big. (Not too big for ram, or too big for flash, but too big for what the bootm command is capable of working with. Carambola2 devices, with a uboot 1.1.4 base on them behave like this. Perfectly normal with a small image, complete failure with bigger images.