Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
Daniel Walker wrote:
On Thu, 2008-08-07 at 19:20 -0700, David VomLehn wrote:
Allow diversion of characters generated through printk so that they can
be logged separately. The printk_time variables is made externally visible
so that functions processing the diverted characters can parse off the
time added if CONFIG_PRINTK_TIME is enabled.
+
static void emit_log_char(char c)
{
+ emit_crash_char(c);
+
LOG_BUF(log_end) = c;
Isn't this duplicating the making of a custom console driver? I'm not a
console expect, but I think you could have a console driver which
catches this output and logs it..
Yes, you could, but this seems *so much* more straight-forward. Another option I
considered was changing things so that the first level interface would simply
output a character, possibly also passing some sort of context pointer. Then
whatever was called by that interface could call a console driver, if
appropriate. Even though I think this is really a cleaner way to do this, it also
involves many more changes than I think are warranted just to get this little
piece of functionality.
Another note, usually when submitting new interfaces like this you
should also submit the code that uses the interface .. In your case you
might not be able to do that, but it could never be accepted without at
least one user.
A highly valid criticism. I actually quoted your message to my management in
order to underscore how important it is that Cisco becomes a good open source
citizen. Personally, I view it as an absolute must.
Daniel
--
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
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 > 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
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: [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: initrd and uImage
On Mon, 2008-08-11 at 09:12 -0700, Tim Bird wrote: > 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. zImage (for ppc at least), is a "wrapper" around the kernel that does the load and decompress. It's akin to how uImage works, just for non-U-Boot platforms. > 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. mkuboot.sh is a script that calls the 'mkimage' tool that is provided with the U-Boot source code. I'd also recommend reading the U-Boot source code to better understand this if your board uses U-Boot as the bootloader. > > 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 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. And for U-Boot, you want to make sure the command line is set via the 'bootargs' U-Boot environment variable. josh -- 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
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 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
