Re: initrd and uImage
Fundu wrote: Hi, First off i have a ppc based board. and i'm trying to load a kernel image with ramdisk rootfs. i have build the kernel. it spit uImage,zImage and vmlinux.gz my question are. 1) what are all the different image types ? i know the uImage is just the kernel, what are the rest (zImage vmlinux.gz)? vmlinux is the uncompressed result of compiling and linking the kernel. I presume that vmlinux.gz is a gzipped version of vmlinux. zImage is some other compressed kernel image format. uImage is another kernel image format, with information specifically for loading with U-Boot. You can see what commands are being used to create these different images by using V=1 with your kernel make. (e.g. make V=1 uImage) On my machine, I see the following: /bin/sh /a/home/tbird/work/tiny/branch_ss/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x10008000 -e 0x10008000 -n 'Linux-2.6.23.17-alp_nl-gfcc28266' -d arch/arm/boot/zImage arch/arm/boot/uImage If I recall correctly, mkuboot.sh prepends the size and start location for the kernel onto the zImage, in order to create the uImage. However, don't take my word for it -- see the U-Boot documentation, or even better read the mkuboot.sh source, or the source for U-Boot itself. That's the beauty of open source. You can see all the software and examine/modify any part you want. If the source is impenetrable, there's always the U-Boot mailing list. 2) i'm using u-boot as the bootldr. so i download the uImage (cause zImage and vmlinux.gz aren't bootlable) from tftp server and then do bootm address the kernel only load partially. How does the kernel know where/how to load the rootfs ? Usually, you tell it with a command line option (root=...). The command line can come from the boot loader, or it may be compiled into the kernel binary. See Documentation/kernel-parameters.txt for information about kernel command line options. This mentions root=, but I didn't see any examples in my quick glance just now. Here are some examples I use: Use the first partition on the first IDE hard drive: root=/dev/hda1 or (later kernels): root=/dev/sda1 Use NFS root filesystem (kernel config must support this) root=/dev/nfs (Usually you need to add some other arguments to make sure the kernel IP address gets configured, or to specify the host NFS path.) Use flash device partition 2: root/dev/mtd/2 I hope this helps. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bootup: Add built-in kernel command line for x86
* Tim Bird [EMAIL PROTECTED] wrote:
Add support for a built-in command line for x86 architectures. The
Kconfig help gives the major rationale for this addition.
i have actually used a local hack quite similar to this to inject boot
options into bzImages via randconfig - so i would find this feature
rather useful.
a small observation:
+ /* append boot loader cmdline to builtin, unless builtin overrides it */
+ if (builtin_cmdline[0] != '!') {
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ } else {
+ strlcpy(boot_command_line, builtin_cmdline[1],
+ COMMAND_LINE_SIZE);
+ }
the default branch changes existing command lines slightly: it appends a
space to them. This could break scripts that rely on the precise
contents of /proc/cmdline output. (i have some - they are arguably
dodgy)
Best would be to make it really apparent in the code that nothing
changes if this config option is not set. Preferably there should be no
extra code at all in that case.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bootup: Add built-in kernel command line for x86
Ingo Molnar wrote:
* Tim Bird [EMAIL PROTECTED] wrote:
Add support for a built-in command line for x86 architectures. The
Kconfig help gives the major rationale for this addition.
i have actually used a local hack quite similar to this to inject boot
options into bzImages via randconfig - so i would find this feature
rather useful.
a small observation:
+ /* append boot loader cmdline to builtin, unless builtin overrides it */
+ if (builtin_cmdline[0] != '!') {
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ } else {
+ strlcpy(boot_command_line, builtin_cmdline[1],
+ COMMAND_LINE_SIZE);
+ }
the default branch changes existing command lines slightly: it appends a
space to them. This could break scripts that rely on the precise
contents of /proc/cmdline output. (i have some - they are arguably
dodgy)
Best would be to make it really apparent in the code that nothing
changes if this config option is not set. Preferably there should be no
extra code at all in that case.
I would like to see this:
#ifdef CONFIG_BUILTIN_CMDLINE
# ifdef CONFIG_BUILTIN_CMDLINE_OVERRIDE
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
# else
if (boot_command_line) {
strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
}
# endif
#endif
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initrd and uImage
On 09:42 Fri 08 Aug , Fundu wrote: Hi, First off i have a ppc based board. and i'm trying to load a kernel image with ramdisk rootfs. Which version of U-Boot do you use? Which features do you enable? i have build the kernel. it spit uImage,zImage and vmlinux.gz my question are. 1) what are all the different image types ? i know the uImage is just the kernel, what are the rest (zImage vmlinux.gz)? 2) i'm using u-boot as the bootldr. so i download the uImage (cause zImage and vmlinux.gz aren't bootlable) from tftp server and then do bootm address the kernel only load partially. How does the kernel know where/how to load the rootfs ? It's depend on which uImage you use. In U-Boot, you can generate a Multi-File Image with the ramdisk inside, FDT, multiple configuration etc... In the case you describe you are supposed to download the ramdisk via tftp also and set the kernel parameter via the bootargs variable and do bootm. example U-Boot tftp 20 uImage U-Boot tftp a0 uRamdisk U-Boot bootm 20 a0 good examples on these pages http://www.denx.de/wiki/view/DULG/Manual http://www.denx.de/wiki/view/DULG/RootFileSystemOnARamdisk http://www.denx.de/wiki/view/DULG/CombiningKernelAndRamdisk Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bootup: Add built-in kernel command line for x86
H. Peter Anvin wrote:
Ingo Molnar wrote:
* Tim Bird [EMAIL PROTECTED] wrote:
Add support for a built-in command line for x86 architectures. The
Kconfig help gives the major rationale for this addition.
i have actually used a local hack quite similar to this to inject boot
options into bzImages via randconfig - so i would find this feature
rather useful.
a small observation:
+/* append boot loader cmdline to builtin, unless builtin
overrides it */
+if (builtin_cmdline[0] != '!') {
+strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+} else {
+strlcpy(boot_command_line, builtin_cmdline[1],
+COMMAND_LINE_SIZE);
+}
the default branch changes existing command lines slightly: it appends
a space to them. This could break scripts that rely on the precise
contents of /proc/cmdline output. (i have some - they are arguably dodgy)
Yeah, I wasn't too comfortable with that.
Best would be to make it really apparent in the code that nothing
changes if this config option is not set. Preferably there should be
no extra code at all in that case.
Agreed.
I would like to see this:
#ifdef CONFIG_BUILTIN_CMDLINE
# ifdef CONFIG_BUILTIN_CMDLINE_OVERRIDE
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
# else
if (boot_command_line) {
strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
}
# endif
#endif
You missed copying builtin_cmdline back to boot_command_line, but
in general this looks OK to me. If nobody objects to the ifdef
multiplicity, I'll work up a version tomorrow for review. (Sorry,
I'm a bit swamped today.)
-- Tim
=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
