I'm having problems with initramfs on the DM8148 with linux-04.01.00.06
on the Mistral TMDXEVM8148 eval board. For all cases except the one
mentioned I get "Kernel panic - not syncing: No init found".
First of all, I have been careful to prepare my initramfs subtree with a
/init script, the typical initrd/initramfs directories and files, all the
device nodes, programs and links needed, all the libraries needed by
/bin/busybox. I have checked file permissions. I have even simplified
things down to running a simple "/bin/hang" executable, which is a
statically-linked program consisting of "while (1);", which is intended
to stop execution only to prove I reached it. I have read enough stuff
on initrd and initramfs to fill a desk drawer, and still don't see what I
could be missing.
If I prepare an initrd or initramfs filesystem and load it to 0x81600000
using u-boot, and add "initrd=0x81600000,2M" to the command line, the /init
script doesn't seem to execute. I thought the initrd memory might be getting
corrupted, but I have used u-boot to prove that is not so.
If I prepare a normal initramfs and build it into the kernel, that fails.
If I prepare an initramfs with a single file, /init, which is a renamed
copy of my "hang" executable, and build that into the kernel, that works.
It "works", in the sense that it hangs rather than causing a kernel panic.
This case requires absolutely no resources other than the /init program
itself. It is also small enough to sneak past a suspected cpio problem
described below.
If I take my normal initramfs with all its files, add /bin/hang, and
change /init to be a script which does nothing else but invoke /bin/hang,
(requiring no resources except /bin/busybox, its library files, and
/bin/hang), that does not work.
Most initramfs tutorials show /init as being a script, but one vaguely
implied that /init had to be an executable program. Is this so?
Whenever I change the content of the initramfs kernel build input subtree
and rebuild the kernel, I get "section mismatch" warnings. Is this a
serious problem for initramfs testing? I would like to rebuild in 2 minutes
rather than doing a "make clean" and then waiting 20 minutes for a full
build.
I noticed that the initramfs cpio archive embedded in the kernel seems to
have a CPIO header, one or two files, followed by another CPIO header and
the rest of the files. Is it possible that the build process did something
wrong and that the kernel is only reading the first part? If I extract
the initramfs from the kernel image, a CPIO command seems to read the
entire thing seamlessly without even a warning.
I looked at the release notes for 04.00.01.07, and found nothing relating
to initramfs, so I would rather avoid that side trip right now.
Oh yeah, I should mention that linux boots just fine without an initramfs,
but I need one to change the root FS at boot time.
-
Ask a related question
What is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
