* 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: Flatten device tree & PPC linu
From: David VomLehn @ 2008-08-14 17:27 UTC (permalink / raw)
To: Grant Likely; +Cc: fundu_1999, linux-embedded
In-Reply-To: <fa686aa40808132343r1b0bed8bx79252d3450c34483@mail.gmail.com>
Grant Likely wrote:
> 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.
It came originally from the PowerPC world, but there is now Sparc implementation
in the kernel tree. We're working on using device tree for MIPS and, according to
a participant at the OLS Device Tree BOFS, someone in the ARM world is also
working on an implementation. I don't know how much work it would be to backport
to 2.4, but my guess is that it's pretty independent of the kernel version.
There is now a device tree mailing list independent of PowerPC. You can find more
info at https://ozlabs.org/mailman/listinfo/devicetree-discuss
^ permalink raw reply
* Re: embedded rootfs utility
From: Behan Webster @ 2008-08-14 19:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <fa686aa40808140935h666c2c7bt18e1ec6e53089f37@mail.gmail.com>
Grant Likely wrote:
> 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.
>
Version 1.1.2 of elbs contains v1.2 of the rootfs tool. I suppose I
should Sync the version numbers on a release.
--
Behan Webster
behanw@websterwood.com
^ permalink raw reply
* Re: embedded rootfs utility
From: Grant Likely @ 2008-08-14 19:25 UTC (permalink / raw)
To: Behan Webster; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <48A48576.5060601@websterwood.com>
On Thu, Aug 14, 2008 at 1:20 PM, Behan Webster <behanw@websterwood.com> wrote:
> Grant Likely wrote:
>> 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.
>>
> Version 1.1.2 of elbs contains v1.2 of the rootfs tool. I suppose I
> should Sync the version numbers on a release.
Okay, then I've still got a problem. I did specify the serial port
when running it, and the files in /etc were all set correctly. It was
just the /dev/ttyPSC0 device file which was missing.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: embedded rootfs utility
From: Behan Webster @ 2008-08-14 19:32 UTC (permalink / raw)
To: Grant Likely; +Cc: Geert Uytterhoeven, linux-embedded
In-Reply-To: <fa686aa40808141225r561eb0b0wcead5618542de85@mail.gmail.com>
Grant Likely wrote:
> On Thu, Aug 14, 2008 at 1:20 PM, Behan Webster <behanw@websterwood.com> wrote:
>
>> Grant Likely wrote:
>>
>>> 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.
>>>
>>>
>> Version 1.1.2 of elbs contains v1.2 of the rootfs tool. I suppose I
>> should Sync the version numbers on a release.
>>
>
> Okay, then I've still got a problem. I did specify the serial port
> when running it, and the files in /etc were all set correctly. It was
> just the /dev/ttyPSC0 device file which was missing
I see. I thought MAKEDEV would have done that for you. It appears that
MAKEDEV doesn't support ttyPSC0.
Yes, I suppose then you would have to make that dev file manually...
Best laid plans...
--
Behan Webster
behanw@websterwood.com
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
From: Ingo Molnar @ 2008-08-15 14:03 UTC (permalink / raw)
To: Tim Bird
Cc: H. Peter Anvin, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <48A1EA04.7090102@am.sony.com>
* Tim Bird <tim.bird@am.sony.com> wrote:
> 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>
applied to tip/x86/commandline for v2.6.28 merging - thanks Tim!
Ingo
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
From: Ingo Molnar @ 2008-08-15 14:12 UTC (permalink / raw)
To: Tim Bird
Cc: H. Peter Anvin, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <48A1EA04.7090102@am.sony.com>
* Tim Bird <tim.bird@am.sony.com> wrote:
> + To compile command line arguments into the kernel,
> + set this option to 'Y', then fill in the
FYI, this tab-to-space whitespace error caused this build failure in
-tip testing:
arch/x86/Kconfig:1500: unknown option "set"
arch/x86/Kconfig:1501: unknown option "the"
arch/x86/Kconfig:1503: unknown option "Systems"
arch/x86/Kconfig:1504: unknown option "should"
arch/x86/Kconfig:1519: unknown option "In"
arch/x86/Kconfig:1520: unknown option "by"
arch/x86/Kconfig:1521: unknown option "file"
i fixed it up. This line was broken too:
> + In most cases, the command line (whether built-in or provided
Ingo
^ permalink raw reply
* Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
From: Ingo Molnar @ 2008-08-15 14:18 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-kernel, linux-embedded, tglx, mingo, hpa, michael
In-Reply-To: <1217929519-10527-1-git-send-email-thomas.petazzoni@free-electrons.com>
* 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.
>
> An example of size saving, on x86 with only Intel CPU support:
>
> text data bss dec hex filename
> 1125479 118760 212992 1457231 163c4f vmlinux.old
> 1121355 116536 212992 1450883 162383 vmlinux
> -4124 -2224 0 -6348 -18CC +/-
>
> However, I'm not exactly sure that the Kconfig wording is correct with
> regard to !64BIT / 64BIT.
applied to tip/x86/cpu, thanks Thomas. (I've done a trivial cleanup:
converted the macro to an inline.)
Peter, do you like this version of the patch or would you like further
improvements?
Ingo
^ permalink raw reply
* Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
From: Ingo Molnar @ 2008-08-15 14:38 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-kernel, linux-embedded, tglx, mingo, hpa, michael
In-Reply-To: <20080815141855.GB12954@elte.hu>
-tip testing found a couple of build failures:
LD .tmp_vmlinux1
arch/x86/lib/lib.a(usercopy_32.o): In function `__copy_to_user_ll':
(.text+0x11e): undefined reference to `movsl_mask'
arch/x86/lib/lib.a(usercopy_32.o): In function `__copy_from_user_ll':
(.text+0x1fa): undefined reference to `movsl_mask'
arch/x86/lib/lib.a(usercopy_32.o): In function
`__copy_from_user_ll_nozero':
(.text+0x2d6): undefined reference to `movsl_mask'
arch/x86/lib/lib.a(usercopy_32.o): In function `copy_from_user':
(.text+0x5ac): undefined reference to `movsl_mask'
arch/x86/lib/lib.a(usercopy_32.o): In function `copy_to_user':
(.text+0x6bf): undefined reference to `movsl_mask'
make: *** [.tmp_vmlinux1] Error 1
with:
http://redhat.com/~mingo/misc/config-Fri_Aug_15_16_35_03_CEST_2008.bad
and:
arch/x86/kvm/built-in.o: In function `paging64_cmpxchg_gpte':
mmu.c:(.text+0xa80d): undefined reference to `cmpxchg_486_u64'
with:
http://redhat.com/~mingo/misc/config-Fri_Aug_15_16_27_47_CEST_2008.bad
reverting your change solved both of them.
i still have the commit in tip/x86/cpu so please send a delta fix ontop
of your previous patch once you figure out the problem. Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
From: H. Peter Anvin @ 2008-08-15 20:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, tglx, mingo,
michael
In-Reply-To: <20080815141855.GB12954@elte.hu>
Ingo Molnar wrote:
> * 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.
>>
>> An example of size saving, on x86 with only Intel CPU support:
>>
>> text data bss dec hex filename
>> 1125479 118760 212992 1457231 163c4f vmlinux.old
>> 1121355 116536 212992 1450883 162383 vmlinux
>> -4124 -2224 0 -6348 -18CC +/-
>>
>> However, I'm not exactly sure that the Kconfig wording is correct with
>> regard to !64BIT / 64BIT.
>
> applied to tip/x86/cpu, thanks Thomas. (I've done a trivial cleanup:
> converted the macro to an inline.)
>
> Peter, do you like this version of the patch or would you like further
> improvements?
>
I'm fine with it.
I think there might still be cross-dependencies, but it doesn't break
anything old, so we can deal with that via bug reports.
The other thing that probably should be done is breaking out the
Intel-specific versus generic parts of intel_cacheinfo.c.
-hpa
^ permalink raw reply
* [PATCH] [x86] Make movsl_mask definition non-CPU specific
From: Thomas Petazzoni @ 2008-08-18 10:33 UTC (permalink / raw)
To: mingo
Cc: linux-kernel, linux-embedded, tglx, mingo, hpa, michael,
thomas.petazzoni
In-Reply-To: <20080815143843.GA519@elte.hu>
movsl_mask is currently defined in arch/x86/kernel/cpu/intel.c, which
contains code specific to Intel CPUs. However, movsl_mask is used in
the non-CPU specific code in arch/x86/lib/usercopy_32.c, which breaks
the compilation when support for Intel CPUs is compiled out.
This patch solves this problem by moving movsl_mask's definition close
to its users in arch/x86/lib/usercopy_32.c.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/x86/kernel/cpu/intel.c | 7 -------
arch/x86/lib/usercopy_32.c | 7 +++++++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b75f256..5c8959b 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -23,13 +23,6 @@
#include <mach_apic.h>
#endif
-#ifdef CONFIG_X86_INTEL_USERCOPY
-/*
- * Alignment at which movsl is preferred for bulk memory copies.
- */
-struct movsl_mask movsl_mask __read_mostly;
-#endif
-
static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)
{
/* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */
diff --git a/arch/x86/lib/usercopy_32.c b/arch/x86/lib/usercopy_32.c
index 24e6094..9e68075 100644
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -14,6 +14,13 @@
#include <asm/uaccess.h>
#include <asm/mmx.h>
+#ifdef CONFIG_X86_INTEL_USERCOPY
+/*
+ * Alignment at which movsl is preferred for bulk memory copies.
+ */
+struct movsl_mask movsl_mask __read_mostly;
+#endif
+
static inline int __movsl_is_ok(unsigned long a1, unsigned long a2, unsigned long n)
{
#ifdef CONFIG_X86_INTEL_USERCOPY
--
1.5.4.3
^ permalink raw reply related
* [PATCH] [x86] Move cmpxchg fallbacks to a generic place
From: Thomas Petazzoni @ 2008-08-18 10:33 UTC (permalink / raw)
To: mingo
Cc: linux-kernel, linux-embedded, tglx, mingo, hpa, michael,
thomas.petazzoni
In-Reply-To: <20080815143843.GA519@elte.hu>
arch/x86/kernel/cpu/intel.c defines a few fallback functions
(cmpxchg_*()) that are used when the CPU doesn't support cmpxchg
and/or cmpxchg64 natively. However, while defined in an Intel-specific
file, these functions are also used for CPUs from other vendors when
they don't support cmpxchg and/or cmpxchg64. This breaks the
compilation when support for Intel CPUs is disabled.
This patch moves these functions to a new
arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when
X86_32 is enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/x86/kernel/cpu/Makefile | 2 +-
arch/x86/kernel/cpu/cmpxchg.c | 72 +++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/intel.c | 64 ------------------------------------
3 files changed, 73 insertions(+), 65 deletions(-)
create mode 100644 arch/x86/kernel/cpu/cmpxchg.c
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a35ee92..a0fc6c1 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -5,7 +5,7 @@
obj-y := intel_cacheinfo.o addon_cpuid_features.o
obj-y += proc.o feature_names.o
-obj-$(CONFIG_X86_32) += common.o bugs.o
+obj-$(CONFIG_X86_32) += common.o bugs.o cmpxchg.o
obj-$(CONFIG_X86_64) += common_64.o bugs_64.o
obj-$(CONFIG_CPU_SUP_AMD_32) += amd.o
diff --git a/arch/x86/kernel/cpu/cmpxchg.c b/arch/x86/kernel/cpu/cmpxchg.c
new file mode 100644
index 0000000..2056ccf
--- /dev/null
+++ b/arch/x86/kernel/cpu/cmpxchg.c
@@ -0,0 +1,72 @@
+/*
+ * cmpxchg*() fallbacks for CPU not supporting these instructions
+ */
+
+#include <linux/kernel.h>
+#include <linux/smp.h>
+#include <linux/module.h>
+
+#ifndef CONFIG_X86_CMPXCHG
+unsigned long cmpxchg_386_u8(volatile void *ptr, u8 old, u8 new)
+{
+ u8 prev;
+ unsigned long flags;
+
+ /* Poor man's cmpxchg for 386. Unsuitable for SMP */
+ local_irq_save(flags);
+ prev = *(u8 *)ptr;
+ if (prev == old)
+ *(u8 *)ptr = new;
+ local_irq_restore(flags);
+ return prev;
+}
+EXPORT_SYMBOL(cmpxchg_386_u8);
+
+unsigned long cmpxchg_386_u16(volatile void *ptr, u16 old, u16 new)
+{
+ u16 prev;
+ unsigned long flags;
+
+ /* Poor man's cmpxchg for 386. Unsuitable for SMP */
+ local_irq_save(flags);
+ prev = *(u16 *)ptr;
+ if (prev == old)
+ *(u16 *)ptr = new;
+ local_irq_restore(flags);
+ return prev;
+}
+EXPORT_SYMBOL(cmpxchg_386_u16);
+
+unsigned long cmpxchg_386_u32(volatile void *ptr, u32 old, u32 new)
+{
+ u32 prev;
+ unsigned long flags;
+
+ /* Poor man's cmpxchg for 386. Unsuitable for SMP */
+ local_irq_save(flags);
+ prev = *(u32 *)ptr;
+ if (prev == old)
+ *(u32 *)ptr = new;
+ local_irq_restore(flags);
+ return prev;
+}
+EXPORT_SYMBOL(cmpxchg_386_u32);
+#endif
+
+#ifndef CONFIG_X86_CMPXCHG64
+unsigned long long cmpxchg_486_u64(volatile void *ptr, u64 old, u64 new)
+{
+ u64 prev;
+ unsigned long flags;
+
+ /* Poor man's cmpxchg8b for 386 and 486. Unsuitable for SMP */
+ local_irq_save(flags);
+ prev = *(u64 *)ptr;
+ if (prev == old)
+ *(u64 *)ptr = new;
+ local_irq_restore(flags);
+ return prev;
+}
+EXPORT_SYMBOL(cmpxchg_486_u64);
+#endif
+
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 5c8959b..77618c7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -307,69 +307,5 @@ static struct cpu_dev intel_cpu_dev __cpuinitdata = {
cpu_vendor_dev_register(X86_VENDOR_INTEL, &intel_cpu_dev);
-#ifndef CONFIG_X86_CMPXCHG
-unsigned long cmpxchg_386_u8(volatile void *ptr, u8 old, u8 new)
-{
- u8 prev;
- unsigned long flags;
-
- /* Poor man's cmpxchg for 386. Unsuitable for SMP */
- local_irq_save(flags);
- prev = *(u8 *)ptr;
- if (prev == old)
- *(u8 *)ptr = new;
- local_irq_restore(flags);
- return prev;
-}
-EXPORT_SYMBOL(cmpxchg_386_u8);
-
-unsigned long cmpxchg_386_u16(volatile void *ptr, u16 old, u16 new)
-{
- u16 prev;
- unsigned long flags;
-
- /* Poor man's cmpxchg for 386. Unsuitable for SMP */
- local_irq_save(flags);
- prev = *(u16 *)ptr;
- if (prev == old)
- *(u16 *)ptr = new;
- local_irq_restore(flags);
- return prev;
-}
-EXPORT_SYMBOL(cmpxchg_386_u16);
-
-unsigned long cmpxchg_386_u32(volatile void *ptr, u32 old, u32 new)
-{
- u32 prev;
- unsigned long flags;
-
- /* Poor man's cmpxchg for 386. Unsuitable for SMP */
- local_irq_save(flags);
- prev = *(u32 *)ptr;
- if (prev == old)
- *(u32 *)ptr = new;
- local_irq_restore(flags);
- return prev;
-}
-EXPORT_SYMBOL(cmpxchg_386_u32);
-#endif
-
-#ifndef CONFIG_X86_CMPXCHG64
-unsigned long long cmpxchg_486_u64(volatile void *ptr, u64 old, u64 new)
-{
- u64 prev;
- unsigned long flags;
-
- /* Poor man's cmpxchg8b for 386 and 486. Unsuitable for SMP */
- local_irq_save(flags);
- prev = *(u64 *)ptr;
- if (prev == old)
- *(u64 *)ptr = new;
- local_irq_restore(flags);
- return prev;
-}
-EXPORT_SYMBOL(cmpxchg_486_u64);
-#endif
-
/* arch_initcall(intel_cpu_init); */
--
1.5.4.3
^ permalink raw reply related
* Re: embedded rootfs utility
From: Geert Uytterhoeven @ 2008-08-18 11:30 UTC (permalink / raw)
To: Behan Webster; +Cc: Grant Likely, linux-embedded
In-Reply-To: <48A442C2.2060309@websterwood.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2640 bytes --]
On Thu, 14 Aug 2008, Behan Webster wrote:
> Grant Likely wrote:
> > 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.
Me neither.
> > 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. :)
I had authentication problems afterwards. As my board didn't have an RTC,
the system insisted on changing my root password after each reboot and
login.
> > 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.
Yep, it's a pity we cannot standardize on /dev/ttyS0 for the first serial
port...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [PATCH] [x86] Move cmpxchg fallbacks to a generic place
From: Ingo Molnar @ 2008-08-18 14:07 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-kernel, linux-embedded, tglx, mingo, hpa, michael
In-Reply-To: <1219055602-8046-2-git-send-email-thomas.petazzoni@free-electrons.com>
* Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> arch/x86/kernel/cpu/intel.c defines a few fallback functions
> (cmpxchg_*()) that are used when the CPU doesn't support cmpxchg
> and/or cmpxchg64 natively. However, while defined in an Intel-specific
> file, these functions are also used for CPUs from other vendors when
> they don't support cmpxchg and/or cmpxchg64. This breaks the
> compilation when support for Intel CPUs is disabled.
>
> This patch moves these functions to a new
> arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when
> X86_32 is enabled.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
applied both fixes to tip/x86/cpu, thanks Thomas.
I also flipped it around with the cpu-id reduction patch, so that it
remains bisectable. The new commit IDs in -tip are:
8bfcb39: x86: make movsl_mask definition non-CPU specific
774400a: x86: move cmpxchg fallbacks to a generic place
8d02c21: x86: configuration options to compile out x86 CPU support code
Ingo
^ permalink raw reply
* Re: embedded rootfs utility
From: Grant Likely @ 2008-08-18 16:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Behan Webster, linux-embedded
In-Reply-To: <Pine.LNX.4.64.0808181328260.30933@vixen.sonytel.be>
On Mon, Aug 18, 2008 at 5:30 AM, Geert Uytterhoeven
<Geert.Uytterhoeven@sonycom.com> wrote:
> On Thu, 14 Aug 2008, Behan Webster wrote:
>> Grant Likely wrote:
>> > On Fri, Aug 8, 2008 at 11:03 AM, Behan Webster <behanw@websterwood.com> 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.
>
> Yep, it's a pity we cannot standardize on /dev/ttyS0 for the first serial
> port...
Indeed; but it could be potentially solved with a few udev rules. I
should look into that...
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Module init for compiled in vs loaded modules
From: Fundu @ 2008-08-19 1:44 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <fa686aa40808180900q730b921an64483d985793b33b@mail.gmail.com>
Hi,
For kernel modules can be loaded by explicitly do insmod etc for ones that are not compiled into the kernel.
1) But where do i look to find how the kernel loads(ie. calls the fn exported by module_init(XXXX)) for modules compiled into the kernel.
2) Does the kernel call some kind of probe to load them ? say i have 2 module compiled into the kernel for 2 diff type of ether cards. Would the kernel call init on both.
thanks !
^ permalink raw reply
* Re: Module init for compiled in vs loaded modules
From: Amol Lad @ 2008-08-19 4:29 UTC (permalink / raw)
To: fundu_1999; +Cc: linux-embedded
In-Reply-To: <970019.41811.qm@web63401.mail.re1.yahoo.com>
Code base of 2.6.18
>
> 1) But where do i look to find how the kernel loads(ie. calls the fn exported by module_init(XXXX)) for modules compiled into the kernel.
linux/init.h:
#ifndef MODULE
...
#define module_init(x) __initcall(x);
#define __initcall(fn) device_initcall(fn)
#define device_initcall(fn) __define_initcall("6",fn)
#define __define_initcall(level,fn) \
static initcall_t __initcall_##fn __attribute_used__ \
__attribute__((__section__(".initcall" level ".init"))) = fn
...
#endif
So as you can see call to module_init is actually an initcall.
initcalls are processed in do_initcalls function in init/main.c
static void __init do_basic_setup(void)
{
....
do_initcalls();
}
>
> thanks !
Amol
>
>
>
>
>
> --
> 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
* [RFC] Remove more code when IP_MULTICAST=n
From: Thomas Petazzoni @ 2008-08-19 13:00 UTC (permalink / raw)
To: linux-embedded; +Cc: David Woodhouse
[RFC] Remove more code when IP_MULTICAST=n
The idea of this patch originates from a patch by Matt Mackall in the
Linux Tiny project, adding a new CONFIG_IGMP option to compile out
net/ipv4/igmp.o on embedded devices running applications that don't
care about multicast.
After discussion with David Woodhouse, we wondered why introducing a
new option is necessary: couldn't all the IGMP code be compiled out
when IP_MULTICAST=n (IP_MULTICAST is an already existing option) ?
This patch implements this idea: net/ipv4/igmp.o and multicast-related
socket operations get compiled out when IP_MULTICAST=N. However, my
understanding of the network stack internals is too limited to be sure
that it actually makes sense, which is why I'm sending this patch
simply for comments on what could be done. In particular :
* I'm not sure why net/ipv4/igmp.o was needed when IP_MULTICAST=n ;
* I'm not sure that returning -ENOPROTOOPT for socket operations
related to multicast management is correct when IP_MULTICAST=n.
For reference, the size savings are as follows, before and after the
patch, for a x86 kernel with IP_MULTICAST=n.
text data bss dec hex filename
2034992 157896 270336 2463224 2595f8 vmlinux
2024260 157856 270336 2452452 256be4 vmlinux.new
-10732 -40 0 -10772 -2A14 +/-
Remaining to fix:
* Virtual server support, using ip_mc_join_group() in
ipv4/ipvs/ip_vs_sync.c
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
include/linux/igmp.h | 11 +++++++++
net/ipv4/Makefile | 3 +-
net/ipv4/af_inet.c | 2 -
net/ipv4/igmp.c | 50 +--------------------------------------------
net/ipv4/ip_sockglue.c | 4 +++
net/ipv4/sysctl_net_ipv4.c | 3 --
6 files changed, 20 insertions(+), 53 deletions(-)
Index: linuxdev/include/linux/igmp.h
===================================================================
--- linuxdev.orig/include/linux/igmp.h
+++ linuxdev/include/linux/igmp.h
@@ -215,6 +215,7 @@
#define IGMPV3_QQIC(value) IGMPV3_EXP(0x80, 4, 3, value)
#define IGMPV3_MRC(value) IGMPV3_EXP(0x80, 4, 3, value)
+#ifdef CONFIG_IP_MULTICAST
extern int ip_check_mc(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u16 proto);
extern int igmp_rcv(struct sk_buff *);
extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
@@ -235,6 +236,16 @@
extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_rejoin_group(struct ip_mc_list *im);
+#else
+#define ip_check_mc(a, b, c, d) ({ 0; })
+#define ip_mc_sf_allow(a, b, c, d) ({ 1; })
+#define ip_mc_init_dev(a) ({ })
+#define ip_mc_up(a) ({ })
+#define ip_mc_down(a) ({ })
+#define ip_mc_destroy_dev(a) ({ })
+#define ip_mc_init_dev(a) ({ })
+#define ip_mc_drop_socket(a) ({ })
+#endif
#endif
#endif
Index: linuxdev/net/ipv4/Makefile
===================================================================
--- linuxdev.orig/net/ipv4/Makefile
+++ linuxdev/net/ipv4/Makefile
@@ -9,7 +9,7 @@
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
tcp_minisocks.o tcp_cong.o \
datagram.o raw.o udp.o udplite.o \
- arp.o icmp.o devinet.o af_inet.o igmp.o \
+ arp.o icmp.o devinet.o af_inet.o \
fib_frontend.o fib_semantics.o \
inet_fragment.o
@@ -19,6 +19,7 @@
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
obj-$(CONFIG_IP_MROUTE) += ipmr.o
+obj-$(CONFIG_IP_MULTICAST) += igmp.o
obj-$(CONFIG_NET_IPIP) += ipip.o
obj-$(CONFIG_NET_IPGRE) += ip_gre.o
obj-$(CONFIG_SYN_COOKIES) += syncookies.o
Index: linuxdev/net/ipv4/af_inet.c
===================================================================
--- linuxdev.orig/net/ipv4/af_inet.c
+++ linuxdev/net/ipv4/af_inet.c
@@ -115,8 +115,6 @@
#include <linux/mroute.h>
#endif
-extern void ip_mc_drop_socket(struct sock *sk);
-
/* The inetsw table contains everything that inet_create needs to
* build a new socket.
*/
Index: linuxdev/net/ipv4/igmp.c
===================================================================
--- linuxdev.orig/net/ipv4/igmp.c
+++ linuxdev/net/ipv4/igmp.c
@@ -108,7 +108,6 @@
#define IP_MAX_MEMBERSHIPS 20
#define IP_MAX_MSF 10
-#ifdef CONFIG_IP_MULTICAST
/* Parameter names and values are taken from igmp-v2-06 draft */
#define IGMP_V1_Router_Present_Timeout (400*HZ)
@@ -143,7 +142,6 @@
static void igmpv3_clear_delrec(struct in_device *in_dev);
static int sf_setstate(struct ip_mc_list *pmc);
static void sf_markstate(struct ip_mc_list *pmc);
-#endif
static void ip_mc_clear_src(struct ip_mc_list *pmc);
static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
int sfcount, __be32 *psfsrc, int delta);
@@ -156,8 +154,6 @@
}
}
-#ifdef CONFIG_IP_MULTICAST
-
/*
* Timer management
*/
@@ -975,8 +971,6 @@
return 0;
}
-#endif
-
/*
* Add a filter to a device
@@ -1011,7 +1005,6 @@
dev_mc_delete(dev,buf,dev->addr_len,0);
}
-#ifdef CONFIG_IP_MULTICAST
/*
* deleted ip_mc_list manipulation
*/
@@ -1112,21 +1105,17 @@
}
read_unlock(&in_dev->mc_list_lock);
}
-#endif
static void igmp_group_dropped(struct ip_mc_list *im)
{
struct in_device *in_dev = im->interface;
-#ifdef CONFIG_IP_MULTICAST
int reporter;
-#endif
if (im->loaded) {
im->loaded = 0;
ip_mc_filter_del(in_dev, im->multiaddr);
}
-#ifdef CONFIG_IP_MULTICAST
if (im->multiaddr == IGMP_ALL_HOSTS)
return;
@@ -1147,7 +1136,6 @@
igmp_ifc_event(in_dev);
}
done:
-#endif
ip_mc_clear_src(im);
}
@@ -1160,7 +1148,6 @@
ip_mc_filter_add(in_dev, im->multiaddr);
}
-#ifdef CONFIG_IP_MULTICAST
if (im->multiaddr == IGMP_ALL_HOSTS)
return;
@@ -1177,7 +1164,6 @@
im->crcount = in_dev->mr_qrv ? in_dev->mr_qrv :
IGMP_Unsolicited_Report_Count;
igmp_ifc_event(in_dev);
-#endif
}
@@ -1224,21 +1210,17 @@
im->crcount = 0;
atomic_set(&im->refcnt, 1);
spin_lock_init(&im->lock);
-#ifdef CONFIG_IP_MULTICAST
im->tm_running=0;
setup_timer(&im->timer, &igmp_timer_expire, (unsigned long)im);
im->unsolicit_count = IGMP_Unsolicited_Report_Count;
im->reporter = 0;
im->gsquery = 0;
-#endif
im->loaded = 0;
write_lock_bh(&in_dev->mc_list_lock);
im->next=in_dev->mc_list;
in_dev->mc_list=im;
write_unlock_bh(&in_dev->mc_list_lock);
-#ifdef CONFIG_IP_MULTICAST
igmpv3_del_delrec(in_dev, im->multiaddr);
-#endif
igmp_group_added(im);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
@@ -1251,7 +1233,6 @@
*/
void ip_mc_rejoin_group(struct ip_mc_list *im)
{
-#ifdef CONFIG_IP_MULTICAST
struct in_device *in_dev = im->interface;
if (im->multiaddr == IGMP_ALL_HOSTS)
@@ -1265,7 +1246,6 @@
im->crcount = in_dev->mr_qrv ? in_dev->mr_qrv :
IGMP_Unsolicited_Report_Count;
igmp_ifc_event(in_dev);
-#endif
}
/*
@@ -1314,7 +1294,6 @@
for (i=in_dev->mc_list; i; i=i->next)
igmp_group_dropped(i);
-#ifdef CONFIG_IP_MULTICAST
in_dev->mr_ifc_count = 0;
if (del_timer(&in_dev->mr_ifc_timer))
__in_dev_put(in_dev);
@@ -1322,7 +1301,6 @@
if (del_timer(&in_dev->mr_gq_timer))
__in_dev_put(in_dev);
igmpv3_clear_delrec(in_dev);
-#endif
ip_mc_dec_group(in_dev, IGMP_ALL_HOSTS);
}
@@ -1335,7 +1313,6 @@
return;
in_dev->mc_tomb = NULL;
-#ifdef CONFIG_IP_MULTICAST
in_dev->mr_gq_running = 0;
setup_timer(&in_dev->mr_gq_timer, igmp_gq_timer_expire,
(unsigned long)in_dev);
@@ -1343,7 +1320,6 @@
setup_timer(&in_dev->mr_ifc_timer, igmp_ifc_timer_expire,
(unsigned long)in_dev);
in_dev->mr_qrv = IGMP_Unsolicited_Report_Count;
-#endif
rwlock_init(&in_dev->mc_list_lock);
spin_lock_init(&in_dev->mc_tomb_lock);
@@ -1455,16 +1431,14 @@
ip_rt_multicast_event(pmc->interface);
}
if (!psf->sf_count[MCAST_INCLUDE] && !psf->sf_count[MCAST_EXCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
struct in_device *in_dev = pmc->interface;
-#endif
/* no more filters for this source */
if (psf_prev)
psf_prev->sf_next = psf->sf_next;
else
pmc->sources = psf->sf_next;
-#ifdef CONFIG_IP_MULTICAST
+
if (psf->sf_oldin &&
!IGMP_V1_SEEN(in_dev) && !IGMP_V2_SEEN(in_dev)) {
psf->sf_crcount = in_dev->mr_qrv ? in_dev->mr_qrv :
@@ -1473,15 +1447,13 @@
pmc->tomb = psf;
rv = 1;
} else
-#endif
+
kfree(psf);
}
return rv;
}
-#ifndef CONFIG_IP_MULTICAST
#define igmp_ifc_event(x) do { } while (0)
-#endif
static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
int sfcount, __be32 *psfsrc, int delta)
@@ -1504,9 +1476,7 @@
}
spin_lock_bh(&pmc->lock);
read_unlock(&in_dev->mc_list_lock);
-#ifdef CONFIG_IP_MULTICAST
sf_markstate(pmc);
-#endif
if (!delta) {
err = -EINVAL;
if (!pmc->sfcount[sfmode])
@@ -1524,13 +1494,10 @@
if (pmc->sfmode == MCAST_EXCLUDE &&
pmc->sfcount[MCAST_EXCLUDE] == 0 &&
pmc->sfcount[MCAST_INCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
struct ip_sf_list *psf;
-#endif
/* filter mode change */
pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
pmc->crcount = in_dev->mr_qrv ? in_dev->mr_qrv :
IGMP_Unsolicited_Report_Count;
in_dev->mr_ifc_count = pmc->crcount;
@@ -1539,7 +1506,6 @@
igmp_ifc_event(pmc->interface);
} else if (sf_setstate(pmc) || changerec) {
igmp_ifc_event(pmc->interface);
-#endif
}
out_unlock:
spin_unlock_bh(&pmc->lock);
@@ -1577,7 +1543,6 @@
return 0;
}
-#ifdef CONFIG_IP_MULTICAST
static void sf_markstate(struct ip_mc_list *pmc)
{
struct ip_sf_list *psf;
@@ -1651,7 +1616,6 @@
}
return rv;
}
-#endif
/*
* Add multicast source filter list to the interface list
@@ -1678,9 +1642,7 @@
spin_lock_bh(&pmc->lock);
read_unlock(&in_dev->mc_list_lock);
-#ifdef CONFIG_IP_MULTICAST
sf_markstate(pmc);
-#endif
isexclude = pmc->sfmode == MCAST_EXCLUDE;
if (!delta)
pmc->sfcount[sfmode]++;
@@ -1697,17 +1659,14 @@
for (j=0; j<i; j++)
(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[i]);
} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
-#ifdef CONFIG_IP_MULTICAST
struct ip_sf_list *psf;
in_dev = pmc->interface;
-#endif
/* filter mode change */
if (pmc->sfcount[MCAST_EXCLUDE])
pmc->sfmode = MCAST_EXCLUDE;
else if (pmc->sfcount[MCAST_INCLUDE])
pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
/* else no filters; keep old mode for reports */
pmc->crcount = in_dev->mr_qrv ? in_dev->mr_qrv :
@@ -1718,7 +1677,6 @@
igmp_ifc_event(in_dev);
} else if (sf_setstate(pmc)) {
igmp_ifc_event(in_dev);
-#endif
}
spin_unlock_bh(&pmc->lock);
return err;
@@ -2404,13 +2362,9 @@
struct ip_mc_list *im = (struct ip_mc_list *)v;
struct igmp_mc_iter_state *state = igmp_mc_seq_private(seq);
char *querier;
-#ifdef CONFIG_IP_MULTICAST
querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
IGMP_V2_SEEN(state->in_dev) ? "V2" :
"V3";
-#else
- querier = "NONE";
-#endif
if (state->in_dev->mc_list == im) {
seq_printf(seq, "%d\t%-10s: %5d %7s\n",
Index: linuxdev/net/ipv4/ip_sockglue.c
===================================================================
--- linuxdev.orig/net/ipv4/ip_sockglue.c
+++ linuxdev/net/ipv4/ip_sockglue.c
@@ -544,6 +544,7 @@
if (!val)
skb_queue_purge(&sk->sk_error_queue);
break;
+#ifdef CONFIG_IP_MULTICAST
case IP_MULTICAST_TTL:
if (sk->sk_type == SOCK_STREAM)
goto e_inval;
@@ -860,6 +861,7 @@
kfree(gsf);
break;
}
+#endif
case IP_ROUTER_ALERT:
err = ip_ra_control(sk, val ? 1 : 0, NULL);
break;
@@ -1044,6 +1046,7 @@
case IP_RECVERR:
val = inet->recverr;
break;
+#ifdef CONFIG_IP_MULTICAST
case IP_MULTICAST_TTL:
val = inet->mc_ttl;
break;
@@ -1099,6 +1102,7 @@
release_sock(sk);
return err;
}
+#endif
case IP_PKTOPTIONS:
{
struct msghdr msg;
Index: linuxdev/net/ipv4/sysctl_net_ipv4.c
===================================================================
--- linuxdev.orig/net/ipv4/sysctl_net_ipv4.c
+++ linuxdev/net/ipv4/sysctl_net_ipv4.c
@@ -411,8 +411,6 @@
.mode = 0644,
.proc_handler = &proc_dointvec
},
-
-#endif
{
.ctl_name = NET_IPV4_IGMP_MAX_MSF,
.procname = "igmp_max_msf",
@@ -421,6 +419,7 @@
.mode = 0644,
.proc_handler = &proc_dointvec
},
+#endif
{
.ctl_name = NET_IPV4_INET_PEER_THRESHOLD,
.procname = "inet_peer_threshold",
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [RFC] Remove more code when IP_MULTICAST=n
From: Geert Uytterhoeven @ 2008-08-19 14:18 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-embedded, David Woodhouse
In-Reply-To: <20080819150047.38f09acf@surf>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 563 bytes --]
On Tue, 19 Aug 2008, Thomas Petazzoni wrote:
> [RFC] Remove more code when IP_MULTICAST=n
Probably you wanted to cc netdev@vger.kernel.org?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Module init for compiled in vs loaded modules
From: T Ziomek @ 2008-08-19 16:11 UTC (permalink / raw)
To: Fundu; +Cc: linux-embedded
In-Reply-To: <970019.41811.qm@web63401.mail.re1.yahoo.com>
Please, do not start a new thread by replying to a message in an existing
thread. Compose a new message from scratch to the mailing list.
Otherwise your thread shows up in the middle of another, *unrelated*
thread when anybody looks at a threaded view of the archives. Just
look at
<http://thread.gmane.org/gmane.linux.kernel.embedded/626/focus=815> to
see what I mean.
Thanks, Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Module init for compiled in vs loaded modules
From: Fundu @ 2008-08-19 17:26 UTC (permalink / raw)
To: linux embedded; +Cc: Amol Lad
> linux/init.h:
>
> #ifndef MODULE
> ...
> #define module_init(x) __initcall(x);
> #define __initcall(fn) device_initcall(fn)
> #define device_initcall(fn)
> __define_initcall("6",fn)
> #define __define_initcall(level,fn) \
> static initcall_t __initcall_##fn __attribute_used__
> \
> __attribute__((__section__(".initcall" level
> ".init"))) = fn
> ...
> #endif
>
> initcalls are processed in do_initcalls function in
> init/main.c
>
> static void __init do_basic_setup(void)
> {
> ....
> do_initcalls();
> }
>
> >
> > thanks !
>
> Amol
thanks Rajat and Amol.
One other question,
1) how does the kernel know which module to load first in order to satisfy dependencies issues ?
2) is there a way i could print the module init fn name from do_initcalls. to see in what order compiled in modules are called.
tia.
^ permalink raw reply
* Adding a new platform
From: David VomLehn @ 2008-08-19 18:01 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Linux Embedded Maillist
I'm working to educate our management on the need to get our platform in the
kernel mainline. I expect I will be asked to tell them how much work this is.
What do we need to do to add a new MIPS platform?
--
David VomLehn
^ permalink raw reply
* Re: Adding a new platform
From: Ralf Baechle @ 2008-08-19 18:22 UTC (permalink / raw)
To: David VomLehn; +Cc: Linux Embedded Maillist
In-Reply-To: <48AB0A7A.8040209@cisco.com>
On Tue, Aug 19, 2008 at 11:01:30AM -0700, David VomLehn wrote:
> I'm working to educate our management on the need to get our platform in
> the kernel mainline. I expect I will be asked to tell them how much work
> this is. What do we need to do to add a new MIPS platform?
Basically a patchset that adds support for the base platform and all
necessary drivers. Send that to the respective mailing lists and
maintainers (see MAINTAINERS file) and wait for the feedback. Expect to
polish your patchset a few times until everybody is happy. That's the
basic receipe. See also Documentation/SubmittingPatches,
Documentation/SubmittingDrivers and Documentation/SubmitChecklist.
Ralf
^ permalink raw reply
* New elinux.org mailing lists
From: Bill Traynor @ 2008-08-19 19:56 UTC (permalink / raw)
To: linux-embedded
I've added a few mailing lists to elinux.org at
http://elinux.org/ELinuxWiki:Mailing_List
"Announce" is the ubiquitous announce list and will be extremely low traffic.
"wiki-dev" is for anyone interested in the content/functionality of the wiki.
"discuss" is for everything else.
The "discuss" list is probably most applicable to the linux-embedded
audience and will be dedicated to topics that would otherwise not be
applicable to this list, such as detailed discussion about particular
devices, and or non-kernel specific topics.
Thanks
Bill
^ permalink raw reply
* Re: New elinux.org mailing lists
From: David Anders @ 2008-08-20 2:31 UTC (permalink / raw)
To: linux-embedded, Bill Traynor
In-Reply-To: <0c62747a6e9b254692b71bbe55f82510.squirrel@www.geekisp.com>
bill aka wmat,
could you add something for hacking news? maybe something like device-hacking@elinux.org ?
i think this would be good to use for things like the zipit and news of cheap devices for hacking.
dave aka prpplague
--- On Tue, 8/19/08, Bill Traynor <wmat@naoi.ca> wrote:
> From: Bill Traynor <wmat@naoi.ca>
> Subject: New elinux.org mailing lists
> To: linux-embedded@vger.kernel.org
> Date: Tuesday, August 19, 2008, 2:56 PM
> I've added a few mailing lists to elinux.org at
> http://elinux.org/ELinuxWiki:Mailing_List
>
> "Announce" is the ubiquitous announce list and
> will be extremely low traffic.
> "wiki-dev" is for anyone interested in the
> content/functionality of the wiki.
> "discuss" is for everything else.
>
> The "discuss" list is probably most applicable to
> the linux-embedded
> audience and will be dedicated to topics that would
> otherwise not be
> applicable to this list, such as detailed discussion about
> particular
> devices, and or non-kernel specific topics.
>
> Thanks
> Bill
> --
> 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
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