Building a initramfs image

bootz $kernel_loadaddr ( try loading it here 0x9f0c0000 )

otherwise zip ( mkimage ) them my hand until you know your environment is ok with those formats.....

a make recipe on it's is a very indirect way to troubleshoot. compare oem image format.... to hand made binaries / headers....

all the recipe does is duplicate what you already know.

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.

  1. This image shows my Makefile addition for the project and the build artifacts generated.
  2. Build artifcats generated with the above Makefile file.
  3. 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).
  4. This is a random image that I got from the internet. This image does boots up properly.
  5. The changes I did to generate a uncompressed initramfs image to overcome the issues with the compression.
  6. Binwalk output of the uncompressed image.
  7. Output of what happens when I try to boot this image. The boot process gets stuck at "Starting kernel...."

Makefile_and_build_artifacts
binwalk_images
binwalk_working_image_from_internet
Makefile_Changes_2_Generate_Uncompressed_Img
binwalk_uncompressed_image bootm_uncompressed_image !

Please let me know if you get some pointers from these details.

Thanks

1 Like

Well that wasn't what I expected in the binwalk of the image that boots :slight_smile:

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.

something like
this

Hint: To see the pictures in real size -> right click in picture -> Show picture (or similar, depending on your browser)

But I agree with you: Posting logs etc. as text is prefered. No search engine is going to find anything in screenshots.

I am not sure where these "Ubiquiti headers" information's are coming from. Is there a way to get rid of them?

Thanks

See your screenshots above.

Use the .bin that is referenced in the "mkimage" command.

(generic-minetec-..... )

Yeah, not being able to copy and paste sux!.

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

HTH

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

Not exactly similar... i think "not working" is missing a kernel.... :wink:

-gunzip it.....
-cat init.bin >> kernel ( after you possibly stripped the header off it. )

then.... they start to look a bit similar....

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.

1 Like

What's the meaning of this "board" parameter? Where can I find its definition?
Thanks