* Re: embedded rootfs utility
From: Grant Likely @ 2008-08-14 16:35 UTC (permalink / raw)
To: Behan Webster; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <48A442C2.2060309@websterwood.com>
On Thu, Aug 14, 2008 at 8:35 AM, Behan Webster <behanw@websterwood.com> wrote:
> Grant Likely wrote:
>> Also, when booting on something like a 5200 with an uncommon serial
>> ports name (ttyPSC0), I had to manually add the /dev/ttyPSC0 device
>> file before it would boot.
>>
> You're using an older version then. The latest (v1.2) allows you to
> specify the serial port/baud rate when running the tool.
Hmm, I can only find v1.1.2 on your website.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: embedded rootfs utility
From: Behan Webster @ 2008-08-14 14:35 UTC (permalink / raw)
To: Grant Likely; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <fa686aa40808132329k49dee24br1d5c83c0d90ea113@mail.gmail.com>
Grant Likely wrote:
> Hey Behan, a few more comments...
>
> On Fri, Aug 8, 2008 at 11:03 AM, Behan Webster <behanw@websterwood.com> wrote:
>
>> Geert Uytterhoeven wrote:
>>
>>> Thanks for this useful tool!
>>> I'm used to plain debootstrap, but decided to give your elbs-rootfs a try for
>>> creating up a mipsel and a powerpc NFS root file system. It worked fine,
>>> except for one minor nit. As an NFS root file system is mounted read-only by
>>> default, I had to manually do
>>>
>>> | mount -n proc /proc -t proc
>>> | mount -n -o remount -w /
>>>
>>> before running finish.sh. Perhaps this can be added to the top of finish.sh?
>>>
>>>
>> Odd. I never had this issue. It has always just worked for me.
>>
>
> I had to do this also, and I had to explicitly "export PATH" to get
> the finish script to work. Otherwise I dpkg complains
>
I've also never had this issue, but I will add it to the script.
> What I probably did differently is that I booted the system with
> "init=/bin/bash" on the command line instead of letting it just run
> init. I needed to do this because if I let it run init, I got
> complaints about PAM failures when trying to log in as root. How are
> you booting the system on first run?
>
There's your problem. You may have had pam failures before you used
elbs-rootfs, but you shouldn't when using it. My script twiddles with
inittab to give you a getty with a bash shell without a password, and
then fixes it in the finish.sh script. If you just boot with it
normally it should just work. I'm too lazy to type init=/bin/bash, so
the script does it for you. :)
> Also, when booting on something like a 5200 with an uncommon serial
> ports name (ttyPSC0), I had to manually add the /dev/ttyPSC0 device
> file before it would boot.
>
You're using an older version then. The latest (v1.2) allows you to
specify the serial port/baud rate when running the tool.
Behan
--
Behan Webster
behanw@websterwood.com
^ permalink raw reply
* Re: Flatten device tree & PPC linu
From: Grant Likely @ 2008-08-14 6:43 UTC (permalink / raw)
To: fundu_1999; +Cc: linux-embedded
In-Reply-To: <260388.87819.qm@web63408.mail.re1.yahoo.com>
On Wed, Aug 13, 2008 at 11:44 PM, Fundu <fundu_1999@yahoo.com> wrote:
> i was reading this ...
> http://free-electrons.com/kerneldoc/latest/powerpc/booting-without-of.txt
> and was wondering if the kernel 2.4(yes 2.4) expects a flatten device tree ?
No, 2.4 does not support flattened device trees. It is a 2.6 thing
for arch/powerpc.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: embedded rootfs utility
From: Grant Likely @ 2008-08-14 6:29 UTC (permalink / raw)
To: Behan Webster; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <489C7C69.5060209@websterwood.com>
Hey Behan, a few more comments...
On Fri, Aug 8, 2008 at 11:03 AM, Behan Webster <behanw@websterwood.com> wrote:
> Geert Uytterhoeven wrote:
>> Thanks for this useful tool!
>> I'm used to plain debootstrap, but decided to give your elbs-rootfs a try for
>> creating up a mipsel and a powerpc NFS root file system. It worked fine,
>> except for one minor nit. As an NFS root file system is mounted read-only by
>> default, I had to manually do
>>
>> | mount -n proc /proc -t proc
>> | mount -n -o remount -w /
>>
>> before running finish.sh. Perhaps this can be added to the top of finish.sh?
>>
> Odd. I never had this issue. It has always just worked for me.
I had to do this also, and I had to explicitly "export PATH" to get
the finish script to work. Otherwise I dpkg complains.
What I probably did differently is that I booted the system with
"init=/bin/bash" on the command line instead of letting it just run
init. I needed to do this because if I let it run init, I got
complaints about PAM failures when trying to log in as root. How are
you booting the system on first run?
Also, when booting on something like a 5200 with an uncommon serial
ports name (ttyPSC0), I had to manually add the /dev/ttyPSC0 device
file before it would boot.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Flatten device tree & PPC linux
From: Fundu @ 2008-08-14 5:44 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1218656903.10489.50.camel@localhost.localdomain>
i was reading this ...
http://free-electrons.com/kerneldoc/latest/powerpc/booting-without-of.txt
and was wondering if the kernel 2.4(yes 2.4) expects a flatten device tree ?
Anybody any ideas ?
TIA !
--- On Wed, 8/13/08, Josh Boyer <jwboyer@gmail.com> wrote:
> From: Josh Boyer <jwboyer@gmail.com>
> Subject: kernel dump solutions
> To: linux-embedded@vger.kernel.org
> Date: Wednesday, August 13, 2008, 12:48 PM
> Hi All,
>
> I'm curious what people are using for a kernel dump
> solution on embedded
> platforms. It seems that kexec/kdump is the default
> solution for
> desktop and server machines, but this seems to be a bit
> heavy for
> embedded platforms. Requiring a second kernel to do the
> dump seems like
> a cost that most platform designers wouldn't be willing
> to incur.
>
> The only other alternative that I'm aware of is LKCD.
> It doesn't seem
> particularly active at all these days. Mcore has been
> sufficiently dead
> for years. So what's left? What else are people
> using?
>
> josh
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: David VomLehn @ 2008-08-13 20:27 UTC (permalink / raw)
To: Tim Bird; +Cc: Grant Likely, Daniel Walker, linux-embedded
In-Reply-To: <48A32FC4.7060006@am.sony.com>
Tim Bird wrote:
> David VomLehn wrote:
>> Our use case is:
>> 1. We register a panic handler
>> 2. The kernel panics and calls our panic handler
>> 3. We register a function to log printk output
>> 4. We print registers, stack, memory, and various other pieces of
>> information using standard kernel functions, which all use printk
>> 5. As printk output is generated, we store it in memory
>> 6. We unregister the printk logging function
>> 7. The panic handler exits
>> 8. The kernel does the rest of its usual panic handling
...
>
> I'm not sure exactly what triggers the transition from step 5 to 6 in
> your steps above. That is, how do you know when to unregister the
> printk logging function?
The printk logging function is unregistered when we are done printing everything
we're interested in.
> But, taking a step back, instead of storing the information somewhere
> else, why not just use the log buffer as the storage medium, and transfer
> that all-at-once when you've collected the information you want?
An interesting suggestion, but we've seen cases where the logging itself causes
subsequent faults. In such cases, you would get nothing at all if you waited to
store information until you've collected everything. A partial report,
particularly if you've tried to print the most useful things first, is better
than none at all. In addition, there is the risk that, for a particularly long
report, you might wrap the log buffer and lose the first part of your output.
--
David VomLehn
^ permalink raw reply
* kernel dump solutions
From: Josh Boyer @ 2008-08-13 19:48 UTC (permalink / raw)
To: linux-embedded
Hi All,
I'm curious what people are using for a kernel dump solution on embedded
platforms. It seems that kexec/kdump is the default solution for
desktop and server machines, but this seems to be a bit heavy for
embedded platforms. Requiring a second kernel to do the dump seems like
a cost that most platform designers wouldn't be willing to incur.
The only other alternative that I'm aware of is LKCD. It doesn't seem
particularly active at all these days. Mcore has been sufficiently dead
for years. So what's left? What else are people using?
josh
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Tim Bird @ 2008-08-13 19:02 UTC (permalink / raw)
To: David VomLehn; +Cc: Grant Likely, Daniel Walker, linux-embedded
In-Reply-To: <48A32068.3010000@cisco.com>
David VomLehn wrote:
> Our use case is:
> 1. We register a panic handler
> 2. The kernel panics and calls our panic handler
> 3. We register a function to log printk output
> 4. We print registers, stack, memory, and various other pieces of
> information using standard kernel functions, which all use printk
> 5. As printk output is generated, we store it in memory
> 6. We unregister the printk logging function
> 7. The panic handler exits
> 8. The kernel does the rest of its usual panic handling
>
> I'm not proposing storing the data in a specific place; that will be up
> to the platform. We will be storing in a piece of memory set aside for
> this purpose, but storing it in NOR flash makes a lot of sense, too, or
> using NAND flash or possibly even disk. All I'm proposing is a small
> framework that will allow plugging in a logging function when needed and
> removing it when done. I'll do the common piece that looks like a fake
> console and we, and other people, can use the simpler interface it
> provides.
I'm not sure exactly what triggers the transition from step 5 to 6 in
your steps above. That is, how do you know when to unregister the
printk logging function?
But, taking a step back, instead of storing the information somewhere
else, why not just use the log buffer as the storage medium, and transfer
that all-at-once when you've collected the information you want? That is,
change your steps to:
1. Register a panic handler
2. The kernel panics and calls our panic handler
3. Record the current position of the log buffer insertion point
4. Print registers, stack, memory, and various other pieces of
information using standard kernel functions, which all use printk
5. As printk output is generated - it is stored by the kernel
in the log buffer (no change to printk code is needed).
** (not sure what the trigger is to stop, here) **
6. Record the current position of the log buffer, and transfer
data logged between steps 3 and 6 to wherever you like. That
is, copy it directly from the log buffer.
7. The panic handler exits
8. The kernel does the rest of its usual panic handling
This reduces your intrusion to just your trigger points, and
grabbing the log buffer position. (Side Note - the way the log
buffer position is stored is a bit funky. It is an absolute
value that monotonically increases, and is masked when used
to refer to the buffer. This is why the log buffer size
is constrained to a power of two).
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: David VomLehn @ 2008-08-13 17:56 UTC (permalink / raw)
To: Grant Likely; +Cc: Daniel Walker, linux-embedded
In-Reply-To: <20080813021212.GA17587@secretlab.ca>
Grant Likely wrote:
> On Tue, Aug 12, 2008 at 06:30:54PM -0700, David VomLehn wrote:
>>
>> Regardless of implementation, it seems to me that it could be of use for
>> some other embedded platforms. Any suggestions as to where it should go
>> in the tree? drivers/char? drivers/misc?
>
> Depends on what you're storing to. Can you send more details about the
> specific use case that you will use this interface for?
The system I'm working on is a settop box. It is in an environment where it is
connected to a central server. The settop box doesn't have enough space to hold
core dumps and the upstream connection to the server has too little bandwidth to
upload them if we did store them. We have found that we can usually diagnose and
fix problems with much less information than a core dump however, so we want to
be able to capture that information and send it upstream.
Our use case is:
1. We register a panic handler
2. The kernel panics and calls our panic handler
3. We register a function to log printk output
4. We print registers, stack, memory, and various other pieces of
information using standard kernel functions, which all use printk
5. As printk output is generated, we store it in memory
6. We unregister the printk logging function
7. The panic handler exits
8. The kernel does the rest of its usual panic handling
I'm not proposing storing the data in a specific place; that will be up to the
platform. We will be storing in a piece of memory set aside for this purpose, but
storing it in NOR flash makes a lot of sense, too, or using NAND flash or
possibly even disk. All I'm proposing is a small framework that will allow
plugging in a logging function when needed and removing it when done. I'll do the
common piece that looks like a fake console and we, and other people, can use the
simpler interface it provides.
> g.
--
David VomLehn
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Grant Likely @ 2008-08-13 2:12 UTC (permalink / raw)
To: David VomLehn; +Cc: Daniel Walker, linux-embedded
In-Reply-To: <48A2394E.8030500@cisco.com>
On Tue, Aug 12, 2008 at 06:30:54PM -0700, David VomLehn wrote:
> Grant Likely wrote:
>
>> I'm not thrilled with this patch. It seems so much more straight
>> forward in your special case, but it comes at the expense of making
>> the code path more complex in every other case.
>>
>> I would much rather see this be done using the existing console driver
>> interface. The only possible reason I could see wanting to do things
>> this way is if you don't trust the console code to call your console
>> driver, which I think is a pretty unlikely case.
>
> I'll buy that reasoning.
>
> Regardless of implementation, it seems to me that it could be of use for
> some other embedded platforms. Any suggestions as to where it should go
> in the tree? drivers/char? drivers/misc?
Depends on what you're storing to. Can you send more details about the
specific use case that you will use this interface for?
g.
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: David VomLehn @ 2008-08-13 1:30 UTC (permalink / raw)
To: Grant Likely; +Cc: Daniel Walker, linux-embedded
In-Reply-To: <fa686aa40808121539pc02a645n908500844c698bca@mail.gmail.com>
Grant Likely wrote:
> I'm not thrilled with this patch. It seems so much more straight
> forward in your special case, but it comes at the expense of making
> the code path more complex in every other case.
>
> I would much rather see this be done using the existing console driver
> interface. The only possible reason I could see wanting to do things
> this way is if you don't trust the console code to call your console
> driver, which I think is a pretty unlikely case.
I'll buy that reasoning.
Regardless of implementation, it seems to me that it could be of use for some
other embedded platforms. Any suggestions as to where it should go in the tree?
drivers/char? drivers/misc?
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
--
David VomLehn
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Grant Likely @ 2008-08-12 22:39 UTC (permalink / raw)
To: David VomLehn; +Cc: Daniel Walker, linux-embedded
In-Reply-To: <48A0CC8D.3050302@cisco.com>
On Mon, Aug 11, 2008 at 5:34 PM, David VomLehn <dvomlehn@cisco.com> wrote:
>
> 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.
I'm not thrilled with this patch. It seems so much more straight
forward in your special case, but it comes at the expense of making
the code path more complex in every other case.
I would much rather see this be done using the existing console driver
interface. The only possible reason I could see wanting to do things
this way is if you don't trust the console code to call your console
driver, which I think is a pretty unlikely case.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
From: Tim Bird @ 2008-08-12 19:52 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <48A091B7.6050601@zytor.com>
Allow x86 to support a built-in kernel command line. The built-in
command line can override the one provided by the boot loader, for
those cases where the boot loader is broken or it is difficult
to change the command line in the the boot loader.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
---
arch/x86/Kconfig | 45 +++++++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/setup.c | 16 ++++++++++++++++
2 files changed, 61 insertions(+), 0 deletions(-)
H. Peter Anvin wrote:
> Ingo Molnar wrote:
>> 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:
[...Nested ifdefs...]
OK. This version changes absolutely nothing if CONFIG_CMDLINE_BOOL is not
set (the default). Also, no space is appended even when CONFIG_CMDLINE_BOOL
is set, but the builtin string is empty. This is less sloppy all the way
around, IMHO.
Note that I use the same option names as on other arches for
this feature.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3d0f2b6..f7bbbd7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1393,6 +1393,51 @@ config COMPAT_VDSO
If unsure, say Y.
+config CMDLINE_BOOL
+ bool "Built-in kernel command line"
+ default n
+ help
+ Allow for specifying boot arguments to the kernel at
+ build time. On some systems (e.g. embedded ones), it is
+ necessary or convenient to provide some or all of the
+ kernel boot arguments with the kernel itself (that is,
+ to not rely on the boot loader to provide them.)
+
+ To compile command line arguments into the kernel,
+ set this option to 'Y', then fill in the
+ the boot arguments in CONFIG_CMDLINE.
+
+ Systems with fully functional boot loaders (i.e. non-embedded)
+ should leave this option set to 'N'.
+
+config CMDLINE
+ string "Built-in kernel command string"
+ depends on CMDLINE_BOOL
+ default ""
+ help
+ Enter arguments here that should be compiled into the kernel
+ image and used at boot time. If the boot loader provides a
+ command line at boot time, it is appended to this string to
+ form the full kernel command line, when the system boots.
+
+ However, you can use the CONFIG_CMDLINE_OVERRIDE option to
+ change this behavior.
+
+ In most cases, the command line (whether built-in or provided
+ by the boot loader) should specify the device for the root
+ file system.
+
+config CMDLINE_OVERRIDE
+ bool "Built-in command line overrides boot loader arguments"
+ default n
+ depends on CMDLINE_BOOL
+ help
+ Set this option to 'Y' to have the kernel ignore the boot loader
+ command line, and use ONLY the built-in command line.
+
+ This is used to work around broken boot loaders. This should
+ be set to 'N' under normal conditions.
+
endmenu
config ARCH_ENABLE_MEMORY_HOTPLUG
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2d88858..492610c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -223,6 +223,9 @@ unsigned long saved_video_mode;
#define RAMDISK_LOAD_FLAG 0x4000
static char __initdata command_line[COMMAND_LINE_SIZE];
+#ifdef CONFIG_CMDLINE_BOOL
+static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
+#endif
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
struct edd edd;
@@ -665,6 +668,19 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = virt_to_phys(&__bss_start);
bss_resource.end = virt_to_phys(&__bss_stop)-1;
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+ if (builtin_cmdline[0]) {
+ /* append boot loader cmdline to builtin */
+ strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ }
+#endif
+#endif
+
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
1.5.6
^ permalink raw reply related
* ppc linux cpu features fixups
From: Mihaela Grigore @ 2008-08-12 17:49 UTC (permalink / raw)
To: linux-embedded
Hello,
There is a piece of code in the early initialization of the 2.6 kernel
that identifies the cpu type and then tries to eliminate code that
does not apply to the current cpu. This is done by writing nop's over
sections of code that are not needed (do_cpu_ftr_fixups in
arch/ppc/kernel/misc.S)
When I try to run the kernel in a ppc emulator, I get a segmentation
fault in do_cpu_ftr_fixups. From examining the section headers of the
vmlinux, the text section is marked as readonly. The piece of code
above mentioned is trying to write a nop to memory location inside the
text section.
Since the kernel does run on boards with ppc cpu's, can somebody
explain how come this is actually working ? Or if/where I am mistaking
with my assumptions ?
Thank you and please ass me in cc in a reply to this message
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: David VomLehn @ 2008-08-11 23:34 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-embedded
In-Reply-To: <1218210904.19162.144.camel@localhost.localdomain>
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
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-11 22:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <48A091B7.6050601@zytor.com>
H. Peter Anvin wrote:
> Ingo Molnar wrote:
>> * Tim Bird <tim.bird@am.sony.com> 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
=============================
^ permalink raw reply
* Re: initrd and uImage
From: Jean-Christophe PLAGNIOL-VILLARD @ 2008-08-11 20:56 UTC (permalink / raw)
To: Fundu; +Cc: linux-embedded
In-Reply-To: <54582.81328.qm@web63407.mail.re1.yahoo.com>
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 200000 uImage
U-Boot> tftp a00000 uRamdisk
U-Boot> bootm 200000 a00000
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.
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: H. Peter Anvin @ 2008-08-11 19:23 UTC (permalink / raw)
To: Ingo Molnar
Cc: Tim Bird, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <20080811191012.GA16553@elte.hu>
Ingo Molnar wrote:
> * Tim Bird <tim.bird@am.sony.com> 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
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Ingo Molnar @ 2008-08-11 19:10 UTC (permalink / raw)
To: Tim Bird
Cc: linux kernel, linux-embedded, Matt Mackall, H. Peter Anvin,
Thomas Gleixner
In-Reply-To: <489A1844.3090502@am.sony.com>
* Tim Bird <tim.bird@am.sony.com> 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
^ permalink raw reply
* Re: initrd and uImage
From: Josh Boyer @ 2008-08-11 17:17 UTC (permalink / raw)
To: Tim Bird; +Cc: fundu_1999, linux-embedded
In-Reply-To: <48A064E7.1070104@am.sony.com>
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 <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.
And for U-Boot, you want to make sure the command line is set via the
'bootargs' U-Boot environment variable.
josh
^ permalink raw reply
* Re: initrd and uImage
From: Tim Bird @ 2008-08-11 16:12 UTC (permalink / raw)
To: fundu_1999; +Cc: linux-embedded
In-Reply-To: <54582.81328.qm@web63407.mail.re1.yahoo.com>
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
=============================
^ permalink raw reply
* Re: embedded rootfs utility
From: Michelle Konzack @ 2008-08-10 15:14 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <488FCF7D.5010005@websterwood.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
Hello Behan,
Since I am running Debian GNU/Linux on my ARMs...
I like to know, whether I can use it for the Atmel AT91SAM7SE, Atmel
AT91SAM9G20, Freescale i.MX31 and NXP LH7A404 too?
I have a WHOLE Debian mirror available and currently building my
EmDebian mirror too.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
From: Bodo Eggert @ 2008-08-09 14:08 UTC (permalink / raw)
To: Thomas Petazzoni, linux-kernel, linux-embedded, Thomas Petazzoni,
tglx
In-Reply-To: <aXrl4-2FX-1@gated-at.bofh.it>
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> This patch adds some configuration options that allow to compile out
> CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
> new configuration options are only visible when CONFIG_EMBEDDED is
> selected, as they are mostly interesting for space savings reasons.
> +menuconfig PROCESSOR_SELECT
> + default y
> + bool "Supported processor vendors" if EMBEDDED
> + help
> + This lets you choose what x86 vendor support code your kernel
> + will include.
> +
> +config CPU_SUP_INTEL_32
> + default y
> + bool "Support Intel processors" if PROCESSOR_SELECT
> + depends on !64BIT
> + help
> + This enables extended support for Intel processors
> +
I don't think having a generic kernel for only Intel CPUs makes much sense,
and OTOH, if you optimize for e.g. Athlon CPUs, you're likely to not need
Intel code on that machine - even on desktop systems.
What about an option to "Include code for CPUs from all supported vendors",
invisible and y for generic kernels?
^ permalink raw reply
* RE: [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput for crash logging
From: Daniel Walker @ 2008-08-08 22:01 UTC (permalink / raw)
To: Haller, John H (John); +Cc: Mike Frysinger, dvomlehn, linux-embedded
In-Reply-To: <B78930B8E34A824993912C39C24569E601548BB5@ILEXC3U01.ndc.lucent.com>
On Fri, 2008-08-08 at 16:24 -0500, Haller, John H (John) wrote:
> > On Fri, 2008-08-08 at 16:13 -0400, Mike Frysinger wrote:
> >
> > > same sort of things as the point of David's code. early/crash
> > > scenarios for people to safely extract portions of the kernel log
> > > buffer for transmission/storage elsewhere. as was explained in the
> > > original thread behind the commit.
> >
> > How is that code suppose to help anyone if you aren't calling it from
> > anyplace in the kernel? Clearly your using it, right? Where
> > is the code
> > your calling these functions from?
> >
> > Daniel
> Not that it was in the patch, but netconsole would be an
> obvious potential user. It would be most useful in board
> specific startup code such as arch/ppc/platforms, where
> a particular board might have a place to put information
> like this for later retrieval. One would hope that such
> board specific file would be forthcoming, rather than be
> maintained out-of-tree.
In the thread where this code was created it was assumed that the
blackfin architecture would use the functions .. However, blackfin
doesn't appear to use it .. Not sure where that code went, but it hasn't
materialized in almost a year.
It basically all comes back to my original point which is don't submit
code that isn't used .. If you have a specific user for the code you can
tailor ifdefs. Then for instance it doesn't bloat non-blackfin
architectures, or non-netconsole users .. Or if it's used only during
init you can flag it with __init and it will be freed after the system
boots. When it's enable and exists it's possible for it to get called
and serve some useful purpose ..
Daniel
^ permalink raw reply
* RE: [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput for crash logging
From: Haller, John H (John) @ 2008-08-08 21:24 UTC (permalink / raw)
To: Daniel Walker, Mike Frysinger; +Cc: dvomlehn, linux-embedded
In-Reply-To: <1218228464.19162.194.camel@localhost.localdomain>
> On Fri, 2008-08-08 at 16:13 -0400, Mike Frysinger wrote:
>
> > same sort of things as the point of David's code. early/crash
> > scenarios for people to safely extract portions of the kernel log
> > buffer for transmission/storage elsewhere. as was explained in the
> > original thread behind the commit.
>
> How is that code suppose to help anyone if you aren't calling it from
> anyplace in the kernel? Clearly your using it, right? Where
> is the code
> your calling these functions from?
>
> Daniel
Not that it was in the patch, but netconsole would be an
obvious potential user. It would be most useful in board
specific startup code such as arch/ppc/platforms, where
a particular board might have a place to put information
like this for later retrieval. One would hope that such
board specific file would be forthcoming, rather than be
maintained out-of-tree.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox