* Fwd: kernel 3.0.93 on s3c2410 problome.
From: Kernux Zhang @ 2013-08-30 1:13 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <CAB-=yQeb8FN++rp6qdNbb_Yhi3zx_9o1gwxvGCeM4AECO8MB+A@mail.gmail.com>
in the download source,I only run : make s3c2410_defconfig ; make
uImage. then get the uImage and I download it in my board to boot.and
I got the follows:
## Booting kernel from Legacy Image at 30800000 ...
Image Name: Linux-3.0.93
Created: 2013-08-29 5:03:32 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2298128 Bytes = 2.2 MiB
Load Address: 30108000
Entry Point: 30108000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 3.0.93 (root@localhost.localdomain) (gcc version 4.7.3
(Sourcery CodeBench Lite 2013.05-24) ) #8 Thu Aug 29 13:03:14 CST 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=00007177
CPU: VIVT data cache, VIVT instruction cache
Machine: SMDK2410
Memory policy: ECC disabled, Data cache writeback
CPU S3C2410A (id 0x32410002)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
S3C2410: core 202.800 MHz, memory 101.400 MHz, peripheral 50.700 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: noinitrd root=/dev/mtdblock2 rw console=ttySAC0,115200
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60216k/60216k available, 5320k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xc4800000 - 0xf6000000 ( 792 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.init : 0xc0108000 - 0xc012f000 ( 156 kB)
.text : 0xc012f000 - 0xc0543000 (4176 kB)
.data : 0xc0544000 - 0xc05724a0 ( 186 kB)
.bss : 0xc05724c4 - 0xc059b1f8 ( 164 kB)
NR_IRQS:99
irq: clearing subpending status 00000002
Console: colour dummy device 80x30
console [ttySAC0] enabled
Calibrating delay loop... 50.17 BogoMIPS (lpj=125440)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Internal error: Oops - undefined instruction: 0 [#1]
Modules linked in:
CPU: 0 Not tainted (3.0.93 #8)
PC is at 0xc0545f28
LR is at alloc_inode+0x28/0xac
pc : [<c0545f28>] lr : [<c01ca9f4>] psr: 40000053
sp : c0545e88 ip : c0545ea0 fp : c0545e9c
r10: 000002fb r9 : 41129200 r8 : c0092540
r7 : c009312c r6 : c0545ea8 r5 : c0545ea8 r4 : 00000000
r3 : c0545ea8 r2 : c3801520 r1 : c009312c r0 : c0545ea8
Flags: nZcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user
Control: 0000717f Table: 30104000 DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc0544260)
Stack: (0xc0545e88 to 0xc0546000)
5e80: 00000000 c3801520 c0545ec4 c0545ea0 c01cafb4 c01ca9dc
5ea0: c3801520 c0545ea8 00400000 c0545ea8 c045d1a0 30127880 c0545ee4 c0545ec8
5ec0: c0203d84 c01caf38 c0545ed4 c04541a8 c3801520 c0545ea8 c0545f08 c0545ee8
5ee0: c02067d4 c0203d78 c04ee5f8 c38139e0 c0559ab0 c0559ab0 00000000 c0545f2c
5f00: c0545f0c c01b808c c02066ec 00000000 00400000 c04ee5f8 c38139e0 00400000
5f20: c0545f50 c0545f30 c01cdd54 c01b8080 00000000 00000000 c0586628 c0545f7c
5f40: 30104000 c0545f60 c0545f54 c01cddb0 c01cdd10 c0545f80 c0545f64 c0118fb8
5f60: c01cdda4 00000000 00000000 c0546258 c054622c c0545fa4 c0545f84 c0118134
5f80: c0118f64 00000000 c0117ae4 c01b67d0 00000000 00003ab2 c0545fd0 c0545fa8
5fa0: c0117d5c c01180b4 00000000 c0545fd0 c0545fbc c0118278 c05460e0 c012975c
5fc0: c0080280 c0545ff4 c0545fd4 c0108908 c0117ccc c0108350 c012975c 00007175
5fe0: c0546068 c0129758 00000000 c0545ff8 3010803c c01086c0 00000000 00000000
Backtrace:
[<c01ca9cc>] (alloc_inode+0x0/0xac) from [<c01cafb4>] (iget_locked+0x8c/0x138)
r5:c3801520 r4:00000000
[<c01caf28>] (iget_locked+0x0/0x138) from [<c0203d84>]
(sysfs_get_inode+0x1c/0x1a8)
[<c0203d68>] (sysfs_get_inode+0x0/0x1a8) from [<c02067d4>]
(sysfs_mount+0xf8/0x178)
r5:c0545ea8 r4:c3801520
[<c02066dc>] (sysfs_mount+0x0/0x178) from [<c01b808c>] (mount_fs+0x1c/0xe0)
r8:00000000 r7:c0559ab0 r6:c0559ab0 r5:c38139e0 r4:c04ee5f8
[<c01b8070>] (mount_fs+0x0/0xe0) from [<c01cdd54>] (vfs_kern_mount+0x54/0x94)
r6:00400000 r5:c38139e0 r4:c04ee5f8
[<c01cdd00>] (vfs_kern_mount+0x0/0x94) from [<c01cddb0>]
(kern_mount_data+0x1c/0x20)
r8:30104000 r7:c0545f7c r6:c0586628 r5:00000000 r4:00000000
[<c01cdd94>] (kern_mount_data+0x0/0x20) from [<c0118fb8>] (sysfs_init+0x64/0xc0)
[<c0118f54>] (sysfs_init+0x0/0xc0) from [<c0118134>] (mnt_init+0x90/0x19c)
r6:c054622c r5:c0546258 r4:00000000
[<c01180a4>] (mnt_init+0x0/0x19c) from [<c0117d5c>] (vfs_caches_init+0xa0/0x130)
r5:00003ab2 r4:00000000
[<c0117cbc>] (vfs_caches_init+0x0/0x130) from [<c0108908>]
(start_kernel+0x258/0x2bc)
r6:c0080280 r5:c012975c r4:c05460e0
[<c01086b0>] (start_kernel+0x0/0x2bc) from [<3010803c>] (0x3010803c)
r6:c0129758 r5:c0546068 r4:00007175
Code: c38139e0 00400000 c0545f50 c0545f30 (c01cdd54)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Backtrace:
[<c013dec4>] (dump_backtrace+0x0/0x10c) from [<c0450378>] (dump_stack+0x18/0x1c)
r6:c0548440 r5:00000000 r4:c0572a1c
[<c0450360>] (dump_stack+0x0/0x1c) from [<c04504f8>] (panic+0x60/0x180)
[<c0450498>] (panic+0x0/0x180) from [<c0156968>] (do_exit+0x600/0x6a0)
r3:00000000 r2:c0544000 r1:c0545d30 r0:c04e549c
r7:c0545e40
[<c0156368>] (do_exit+0x0/0x6a0) from [<c013e37c>] (die+0x18c/0x1c4)
r7:c0545e40
[<c013e1f0>] (die+0x0/0x1c4) from [<c013e3d4>] (arm_notify_die+0x20/0x58)
r8:00000000 r7:c0545f28 r6:c0545e40 r5:c0549220 r4:ffffffff
[<c013e3b4>] (arm_notify_die+0x0/0x58) from [<c012f1a4>]
(do_undefinstr+0x118/0x168)
[<c012f08c>] (do_undefinstr+0x0/0x168) from [<c013adb8>] (__und_svc+0x38/0x60)
Exception stack(0xc0545e40 to 0xc0545e88)
5e40: c0545ea8 c009312c c3801520 c0545ea8 00000000 c0545ea8 c0545ea8 c009312c
5e60: c0092540 41129200 000002fb c0545e9c c0545ea0 c0545e88 c01ca9f4 c0545f28
5e80: 40000053 ffffffff
r8:c0092540 r7:c009312c r6:c0545ea8 r5:c0545e74 r4:ffffffff
[<c01ca9cc>] (alloc_inode+0x0/0xac) from [<c01cafb4>] (iget_locked+0x8c/0x138)
r5:c3801520 r4:00000000
[<c01caf28>] (iget_locked+0x0/0x138) from [<c0203d84>]
(sysfs_get_inode+0x1c/0x1a8)
[<c0203d68>] (sysfs_get_inode+0x0/0x1a8) from [<c02067d4>]
(sysfs_mount+0xf8/0x178)
r5:c0545ea8 r4:c3801520
[<c02066dc>] (sysfs_mount+0x0/0x178) from [<c01b808c>] (mount_fs+0x1c/0xe0)
r8:00000000 r7:c0559ab0 r6:c0559ab0 r5:c38139e0 r4:c04ee5f8
[<c01b8070>] (mount_fs+0x0/0xe0) from [<c01cdd54>] (vfs_kern_mount+0x54/0x94)
r6:00400000 r5:c38139e0 r4:c04ee5f8
[<c01cdd00>] (vfs_kern_mount+0x0/0x94) from [<c01cddb0>]
(kern_mount_data+0x1c/0x20)
r8:30104000 r7:c0545f7c r6:c0586628 r5:00000000 r4:00000000
[<c01cdd94>] (kern_mount_data+0x0/0x20) from [<c0118fb8>] (sysfs_init+0x64/0xc0)
[<c0118f54>] (sysfs_init+0x0/0xc0) from [<c0118134>] (mnt_init+0x90/0x19c)
r6:c054622c r5:c0546258 r4:00000000
[<c01180a4>] (mnt_init+0x0/0x19c) from [<c0117d5c>] (vfs_caches_init+0xa0/0x130)
r5:00003ab2 r4:00000000
[<c0117cbc>] (vfs_caches_init+0x0/0x130) from [<c0108908>]
(start_kernel+0x258/0x2bc)
r6:c0080280 r5:c012975c r4:c05460e0
[<c01086b0>] (start_kernel+0x0/0x2bc) from [<3010803c>] (0x3010803c)
r6:c0129758 r5:c0546068 r4:00007175
what should I do???
^ permalink raw reply
* [JOB] ARM Embedded Developer - 100% Telecommute
From: OSJ @ 2013-09-09 23:04 UTC (permalink / raw)
To: linux-embedded
I have a client looking for a remote ARM Embedded Developer with the
following skills:
They need someone capable of doing Linux driver development and modification
on an embedded system, preferably with experience with the LPC3250 ARM based
processor. The tasks involve modification of the preliminary boot software,
modification of the touch screen driver, and implementation of a USB WiFi
dongle into the Linux kernel.
It is imperative that we find someone who is well versed in what they need
and won't have a very big learning curve. They own a company that makes GPS
units for golf carts. They are based in Hilton Head, SC. This would be a
contract position and is remote. It would be an on-going position as needed
but getting it up and running is the most important thing right now.
The position pays $50/hour and is 100% remote. No on-site work needed at
all.
If you have the skills mentioned above, please submit your resume to
opensourcestaffing|AT|gmail.com
Thank you,
Beauregard Gould
opensourcestaffing|AT|gmail.com
http://osjobs.wordpress.com
^ permalink raw reply
* Re: [JOB] ARM Embedded Developer - 100% Telecommute
From: Rob Landley @ 2013-09-10 2:13 UTC (permalink / raw)
To: Rob Landley; +Cc: OSJ, linux-embedded
In-Reply-To: <1378779104.8385.18@driftwood>
On 09/09/2013 09:11:44 PM, Rob Landley wrote:
> On 09/09/2013 06:04:49 PM, OSJ wrote:
>> I have a client looking for a remote ARM Embedded Developer with the
>> following skills:
The balsa email client is kind of annoying. Removing an email from the
cc: list doesn't actually take effect until you click somewhere else to
change focus. I really need to switch to a less broken one.
Sorry for spamming the list,
Rob
^ permalink raw reply
* [PATCH] init: make init failures more explicit
From: Michael Opdenacker @ 2013-10-18 8:47 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, linux-embedded, Michael Opdenacker
This patch proposes to make init failures more explicit.
Before this, the "No init found" message didn't help much.
It could sometimes be misleading and actually mean
"No *working* init found".
This message could hide many different issues:
- no init program candidates found at all
- some init program candidates exist but can't be executed
(missing execute permissions, failed to load shared libraries,
executable compiled for an unknown architecture...)
This patch notifies the kernel user when a candidate
init program is found but can't be executed. It also replaces
"No init found" by "No working init found", which is more correct.
This will help embedded Linux developers (especially the new comers),
regularly making and debugging new root filesystems.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
init/main.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/init/main.c b/init/main.c
index 63d3e8f..a9a2833 100644
--- a/init/main.c
+++ b/init/main.c
@@ -811,6 +811,20 @@ static int run_init_process(const char *init_filename)
(const char __user *const __user *)envp_init);
}
+static int try_to_run_init_process(const char *init_filename)
+{
+ int ret;
+
+ ret = run_init_process(init_filename);
+
+ if (ret && ret != -ENOENT) {
+ pr_err("Starting init: %s exists but couldn't execute it\n",
+ init_filename);
+ }
+
+ return ret;
+}
+
static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
@@ -843,13 +857,13 @@ static int __ref kernel_init(void *unused)
pr_err("Failed to execute %s. Attempting defaults...\n",
execute_command);
}
- if (!run_init_process("/sbin/init") ||
- !run_init_process("/etc/init") ||
- !run_init_process("/bin/init") ||
- !run_init_process("/bin/sh"))
+ if (!try_to_run_init_process("/sbin/init") ||
+ !try_to_run_init_process("/etc/init") ||
+ !try_to_run_init_process("/bin/init") ||
+ !try_to_run_init_process("/bin/sh"))
return 0;
- panic("No init found. Try passing init= option to kernel. "
+ panic("No working init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] init: make init failures more explicit
From: Kieran Bingham @ 2013-10-18 9:01 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: akpm, linux-kernel, linux-embedded
In-Reply-To: <1382086049-14386-1-git-send-email-michael.opdenacker@free-electrons.com>
Fantastic
I've been hurt by this in the past
- and this patch would certainly would have helped save some time!
--
Kieran
On 18 October 2013 09:47, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
>
> This message could hide many different issues:
> - no init program candidates found at all
> - some init program candidates exist but can't be executed
> (missing execute permissions, failed to load shared libraries,
> executable compiled for an unknown architecture...)
>
> This patch notifies the kernel user when a candidate
> init program is found but can't be executed. It also replaces
> "No init found" by "No working init found", which is more correct.
>
> This will help embedded Linux developers (especially the new comers),
> regularly making and debugging new root filesystems.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
> init/main.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 63d3e8f..a9a2833 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -811,6 +811,20 @@ static int run_init_process(const char *init_filename)
> (const char __user *const __user *)envp_init);
> }
>
> +static int try_to_run_init_process(const char *init_filename)
> +{
> + int ret;
> +
> + ret = run_init_process(init_filename);
> +
> + if (ret && ret != -ENOENT) {
> + pr_err("Starting init: %s exists but couldn't execute it\n",
> + init_filename);
> + }
> +
> + return ret;
> +}
> +
> static noinline void __init kernel_init_freeable(void);
>
> static int __ref kernel_init(void *unused)
> @@ -843,13 +857,13 @@ static int __ref kernel_init(void *unused)
> pr_err("Failed to execute %s. Attempting defaults...\n",
> execute_command);
> }
> - if (!run_init_process("/sbin/init") ||
> - !run_init_process("/etc/init") ||
> - !run_init_process("/bin/init") ||
> - !run_init_process("/bin/sh"))
> + if (!try_to_run_init_process("/sbin/init") ||
> + !try_to_run_init_process("/etc/init") ||
> + !try_to_run_init_process("/bin/init") ||
> + !try_to_run_init_process("/bin/sh"))
> return 0;
>
> - panic("No init found. Try passing init= option to kernel. "
> + panic("No working init found. Try passing init= option to kernel. "
> "See Linux Documentation/init.txt for guidance.");
> }
>
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] init: make init failures more explicit
From: Geert Uytterhoeven @ 2013-10-18 9:23 UTC (permalink / raw)
To: Michael Opdenacker
Cc: Andrew Morton, linux-kernel@vger.kernel.org, Linux Embedded
In-Reply-To: <1382086049-14386-1-git-send-email-michael.opdenacker@free-electrons.com>
On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> + if (ret && ret != -ENOENT) {
> + pr_err("Starting init: %s exists but couldn't execute it\n",
I think it makes sense to also print the value of ret here.
Apart from your -ENOEXEC case, peeking a bit around, it can be also be
-EINVAL, -ENOMEM (debug binary too big for small embedded system?),
-EACCES, -E2BIG, ...
> + init_filename);
> + }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] init: make init failures more explicit
From: Janne Karhunen @ 2013-10-18 9:31 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: akpm, Linux Kernel Mailing List, linux-embedded
In-Reply-To: <1382086049-14386-1-git-send-email-michael.opdenacker@free-electrons.com>
On Fri, Oct 18, 2013 at 11:47 AM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
Heh, I was just looking at similar thing, except in my case dumping
out the execve error code would be the key (now I'm getting -ENOEXEC
back from init exec for no obvious reason). In case something like
this is getting merged I'd appreciate -errno dump as well.
diff --git a/init/main.c b/init/main.c
index 63d3e8f..56fb84a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -815,6 +815,8 @@ static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
{
+ int err;
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
@@ -826,9 +828,11 @@ static int __ref kernel_init(void *unused)
flush_delayed_fput();
if (ramdisk_execute_command) {
- if (!run_init_process(ramdisk_execute_command))
+ err = run_init_process(ramdisk_execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s\n", ramdisk_execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ ramdisk_execute_command, err);
}
/*
@@ -838,10 +842,12 @@ static int __ref kernel_init(void *unused)
* trying to recover a really broken machine.
*/
if (execute_command) {
- if (!run_init_process(execute_command))
+ err = run_init_process(execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s. Attempting defaults...\n",
- execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ execute_command, err);
+ pr_err("Attempting defaults...\n");
}
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
--
Janne
^ permalink raw reply related
* Re: [PATCH] init: make init failures more explicit
From: Michael Opdenacker @ 2013-10-18 9:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Morton, linux-kernel@vger.kernel.org, Linux Embedded
In-Reply-To: <CAMuHMdWXWfGqw041pkOYKzLjQ05GfCcz9jOFQaPa=d_RwhOUcg@mail.gmail.com>
Hi Geert,
On 10/18/2013 11:23 AM, Geert Uytterhoeven wrote:
> On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker
> <michael.opdenacker@free-electrons.com> wrote:
>> + if (ret && ret != -ENOENT) {
>> + pr_err("Starting init: %s exists but couldn't execute it\n",
> I think it makes sense to also print the value of ret here.
> Apart from your -ENOEXEC case, peeking a bit around, it can be also be
> -EINVAL, -ENOMEM (debug binary too big for small embedded system?),
> -EACCES, -E2BIG, ...
I agree. It would definitely make sense. I'll propose a new version.
Many thanks!
Cheers,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
^ permalink raw reply
* [PATCH v2] init: make init failures more explicit
From: Michael Opdenacker @ 2013-10-18 12:00 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, linux-embedded, janne.karhunen, geert,
Michael Opdenacker
This patch proposes to make init failures more explicit.
Before this, the "No init found" message didn't help much.
It could sometimes be misleading and actually mean
"No *working* init found".
This message could hide many different issues:
- no init program candidates found at all
- some init program candidates exist but can't be executed
(missing execute permissions, failed to load shared libraries,
executable compiled for an unknown architecture...)
This patch notifies the kernel user when a candidate init program is
found but can't be executed. The error code is displayed, to quickly
find the root cause. "No init found" is also replaced by
"No working init found", which is more correct.
This will help embedded Linux developers (especially the new comers),
regularly making and debugging new root filesystems.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
init/main.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/init/main.c b/init/main.c
index 63d3e8f..3662767 100644
--- a/init/main.c
+++ b/init/main.c
@@ -811,6 +811,20 @@ static int run_init_process(const char *init_filename)
(const char __user *const __user *)envp_init);
}
+static int try_to_run_init_process(const char *init_filename)
+{
+ int ret;
+
+ ret = run_init_process(init_filename);
+
+ if (ret && ret != -ENOENT) {
+ pr_err("Starting init: %s exists but couldn't execute it (error: %d - see errno-base.h and errno.h)\n",
+ init_filename, ret);
+ }
+
+ return ret;
+}
+
static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
@@ -843,13 +857,13 @@ static int __ref kernel_init(void *unused)
pr_err("Failed to execute %s. Attempting defaults...\n",
execute_command);
}
- if (!run_init_process("/sbin/init") ||
- !run_init_process("/etc/init") ||
- !run_init_process("/bin/init") ||
- !run_init_process("/bin/sh"))
+ if (!try_to_run_init_process("/sbin/init") ||
+ !try_to_run_init_process("/etc/init") ||
+ !try_to_run_init_process("/bin/init") ||
+ !try_to_run_init_process("/bin/sh"))
return 0;
- panic("No init found. Try passing init= option to kernel. "
+ panic("No working init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v2] init: make init failures more explicit
From: Geert Uytterhoeven @ 2013-10-18 12:20 UTC (permalink / raw)
To: Michael Opdenacker
Cc: Andrew Morton, linux-kernel@vger.kernel.org, Linux Embedded,
janne.karhunen
In-Reply-To: <1382097633-10166-1-git-send-email-michael.opdenacker@free-electrons.com>
On Fri, Oct 18, 2013 at 2:00 PM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> + pr_err("Starting init: %s exists but couldn't execute it (error: %d - see errno-base.h and errno.h)\n",
IMHO the "- see errno-base.h and errno.h" is a bit overkill.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] init: make init failures more explicit
From: Michael Opdenacker @ 2013-10-18 13:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Morton, linux-kernel@vger.kernel.org, Linux Embedded,
janne.karhunen
In-Reply-To: <CAMuHMdXas3ALeMXkj1YuDARVAL4Ln19UjXm8oRiGoLyKBc_B7A@mail.gmail.com>
On 10/18/2013 02:20 PM, Geert Uytterhoeven wrote:
> On Fri, Oct 18, 2013 at 2:00 PM, Michael Opdenacker
> <michael.opdenacker@free-electrons.com> wrote:
>> + pr_err("Starting init: %s exists but couldn't execute it (error: %d - see errno-base.h and errno.h)\n",
> IMHO the "- see errno-base.h and errno.h" is a bit overkill.
Yes, I was wondering. Good to have your opinion on this!
I'll post an update with just the error number, also adding the error
code to the other two "Failed to execute" error messages.
Thanks!
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
^ permalink raw reply
* [PATCH v3] init: make init failures more explicit
From: Michael Opdenacker @ 2013-10-18 14:11 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, linux-embedded, janne.karhunen, geert,
Michael Opdenacker
This patch proposes to make init failures more explicit.
Before this, the "No init found" message didn't help much.
It could sometimes be misleading and actually mean
"No *working* init found".
This message could hide many different issues:
- no init program candidates found at all
- some init program candidates exist but can't be executed
(missing execute permissions, failed to load shared libraries,
executable compiled for an unknown architecture...)
This patch notifies the kernel user when a candidate init program is
found but can't be executed. In each failure situation, the error code
is displayed, to quickly find the root cause. "No init found" is also
replaced by "No working init found", which is more correct.
This will help embedded Linux developers (especially the new comers),
regularly making and debugging new root filesystems.
Credits to Geert Uytterhoeven and Janne Karhunen for their improvement
suggestions.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
init/main.c | 39 +++++++++++++++++++++++++++++----------
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/init/main.c b/init/main.c
index 63d3e8f..4ba3b33 100644
--- a/init/main.c
+++ b/init/main.c
@@ -811,10 +811,26 @@ static int run_init_process(const char *init_filename)
(const char __user *const __user *)envp_init);
}
+static int try_to_run_init_process(const char *init_filename)
+{
+ int ret;
+
+ ret = run_init_process(init_filename);
+
+ if (ret && ret != -ENOENT) {
+ pr_err("Starting init: %s exists but couldn't execute it (error %d)\n",
+ init_filename, ret);
+ }
+
+ return ret;
+}
+
static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
{
+ int ret;
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
@@ -826,9 +842,11 @@ static int __ref kernel_init(void *unused)
flush_delayed_fput();
if (ramdisk_execute_command) {
- if (!run_init_process(ramdisk_execute_command))
+ ret = run_init_process(ramdisk_execute_command);
+ if (!ret)
return 0;
- pr_err("Failed to execute %s\n", ramdisk_execute_command);
+ pr_err("Failed to execute %s (error %d)\n",
+ ramdisk_execute_command, ret);
}
/*
@@ -838,18 +856,19 @@ static int __ref kernel_init(void *unused)
* trying to recover a really broken machine.
*/
if (execute_command) {
- if (!run_init_process(execute_command))
+ ret = run_init_process(execute_command);
+ if (!ret)
return 0;
- pr_err("Failed to execute %s. Attempting defaults...\n",
- execute_command);
+ pr_err("Failed to execute %s (error %d). Attempting defaults...\n",
+ execute_command, ret);
}
- if (!run_init_process("/sbin/init") ||
- !run_init_process("/etc/init") ||
- !run_init_process("/bin/init") ||
- !run_init_process("/bin/sh"))
+ if (!try_to_run_init_process("/sbin/init") ||
+ !try_to_run_init_process("/etc/init") ||
+ !try_to_run_init_process("/bin/init") ||
+ !try_to_run_init_process("/bin/sh"))
return 0;
- panic("No init found. Try passing init= option to kernel. "
+ panic("No working init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v3] init: make init failures more explicit
From: Janne Karhunen @ 2013-10-18 14:53 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: akpm, Linux Kernel Mailing List, linux-embedded, geert
In-Reply-To: <1382105505-13730-1-git-send-email-michael.opdenacker@free-electrons.com>
On Fri, Oct 18, 2013 at 5:11 PM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> Credits to Geert Uytterhoeven and Janne Karhunen for their improvement
> suggestions.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Worksforme
Tested-by: Janne Karhunen <Janne.Karhunen@gmail.com>
--
Janne
^ permalink raw reply
* [FOSDEM] [CFP] Embedded and mobile devroom
From: Geert Uytterhoeven @ 2013-10-23 14:26 UTC (permalink / raw)
Every year there is a special dedicated track for embedded and mobile
projects at Fosdem (see: www.fosdem.org ). If you are interested to
give a talk about your project read further for the details.
FOSDEM will be held the 1st and 2nd of February 2014 in Brussels,
Belgium.
For this year's program we are looking for people who would like to do
a presentation about their own or some community's project in this area.
These projects must be Free Software or Open Source.
Example of topics of interest:
* Embedded Linux in general
* Linux kernel development for embedded devices
* Build systems and embedded/mobile operating systems
* Multimedia and graphics
* Embedded systems optimization (boot time, memory consumption, power
consumption, etc.)
* Filesystem and storage
* Real-time
* Non-Linux embedded, such as Arduino
* Hardware platforms, such as BeagleBone, RaspberryPi
* Open source/free software for or related to Android
* ...
We are also interested in short tutorials, project overviews,
achievements, ports to new hardware and hardware hacking, real life
deployments, ... all are welcome and all submissions will be reviewed
by our panel.
Submissions require a small abstract and short speaker presentation
and should be submitted to fosdem.embedded@gmail.com or through
https://penta.fosdem.org/submission/ before the 10th of December 2013.
You can apply for a full length (~45 min) or a shorter (~20min) talk.
The panel consists of:
Philippe De Swert
Peter De Schrijver
Geert Uytterhoeven
Thomas Petazzoni
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Evolution of Linux kernel sizes
From: Geert Uytterhoeven @ 2013-11-27 9:35 UTC (permalink / raw)
To: Linux/m68k, Linux Embedded; +Cc: linux-kernel@vger.kernel.org
Preface:
The results below are for m68k.
Why would you care about m68k? You don't, but that doesn't
mean the results are not applicable to other architectures and
platforms where RAM is a precious resource.
Below are the static kernel sizes (as reported by "size") for m68k
multi-platform kernels (m68k/multi_defconfig), for kernel versions
2.6.28 to 3.12:
text data bss dec hex filename
3420940 204772 163888 3789600 39d320 vmlinux-v2.6.28
3464548 219592 164972 3849112 3abb98 vmlinux-v2.6.29
3388760 207964 156588 3753312 394560 vmlinux-v2.6.30
3453128 210649 157580 3821357 3a4f2d vmlinux-v2.6.31
3477222 212032 158156 3847410 3ab4f2 vmlinux-v2.6.32
3513197 210032 154880 3878109 3b2cdd vmlinux-v2.6.33
3530751 211200 154032 3895983 3b72af vmlinux-v2.6.34
3583761 211404 154448 3949613 3c442d vmlinux-v2.6.35
3570768 179888 153344 3904000 3b9200 vmlinux-v2.6.36
3568083 182516 149992 3900591 3b84af vmlinux-v2.6.37
3609796 182736 149228 3941760 3c2580 vmlinux-v2.6.38
3621429 180576 145056 3947061 3c3a35 vmlinux-v2.6.39
3756437 181424 140184 4078045 3e39dd vmlinux-v3.0
3778616 203272 135564 4117452 3ed3cc vmlinux-v3.1
3550337 182512 183004 3915853 3bc04d vmlinux-v3.2
3579169 183044 182360 3944573 3c307d vmlinux-v3.3
3520525 210752 176384 3907661 3ba04d vmlinux-v3.4
3543961 211604 181788 3937353 3c1449 vmlinux-v3.5
3567386 209328 181888 3958602 3c674a vmlinux-v3.6
3623569 210344 181572 4015485 3d457d vmlinux-v3.7
3981063 216584 184284 4381931 42dceb vmlinux-v3.8
3999784 220336 183356 4403476 433114 vmlinux-v3.9
4040393 217440 188108 4445941 43d6f5 vmlinux-v3.10
4076456 222544 190632 4489632 4481a0 vmlinux-v3.11
4010686 220476 190220 4421382 437706 vmlinux-v3.12
It's not a perfect list, as config files evolve over time, but there's
clearly a trend of increasing kernel sizes, ca. 25 KiB/version.
One issue we're facing is that currently the early kernel startup
code on m68k does not support kernel images larger than 4 MiB.
However, I'm not inclined to fix that, as it removes all incentive
to keep kernel sizes small ;-)
The current distro solution is to make as many drivers as possible
modular, and use an initrd. But this adds complexity, and not
everyone wants to use an initrd.
Then you start wondering: What options can I disable? What does
disabling an option gain?
So I wrote a script to automate this process, starting from the current
.config:
https://github.com/geertu/linux-scripts/blob/master/linux-analyze-marginal-sizes
From the accompanying README:
Starting from the current .config file, find out how much space is saved
in the kernel image by individually disabling each of the currently
enabled config options. Module support and all modules are disabled first.
You can pass make options to specify e.g. the target architecture and
cross compiler.
Caveats:
* This is only about static kernel size, not about dynamic memory
consumption.
* You cannot just add up the numbers, as some config options depend on
other config options.
* It's highly recommended to use ccache or distcc.
Example: Display the top 10 options to decrease kernel image size:
linux-analyze-marginal-sizes CROSS_COMPILE=m68k-linux-gnu- \
ARCH=m68k -j 4 | tee log
grep -w saves log | sort -nr --key=4 | head -10
For v3.13-rc1, the top 10 is:
Disabling CONFIG_NET saves 1038404 bytes
Disabling CONFIG_INET saves 572034 bytes
Disabling CONFIG_EXT4_FS saves 328370 bytes
Disabling CONFIG_NFS_FS saves 258728 bytes
Disabling CONFIG_NETWORK_FILESYSTEMS saves 258728 bytes
Disabling CONFIG_SCSI saves 241850 bytes
Disabling CONFIG_FB saves 207496 bytes
Disabling CONFIG_AMIGA saves 160700 bytes
Disabling CONFIG_MAC saves 151134 bytes
Disabling CONFIG_ATARI saves 138392 bytes
I hope you find this useful!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Evolution of Linux kernel sizes
From: Richard Cochran @ 2013-11-27 9:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/m68k, Linux Embedded, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdUr2Vr9+STwcYf1PcB=PF+u3SJxU3LYnzqQ+vdbDsp71A@mail.gmail.com>
On Wed, Nov 27, 2013 at 10:35:25AM +0100, Geert Uytterhoeven wrote:
> For v3.13-rc1, the top 10 is:
>
> Disabling CONFIG_NET saves 1038404 bytes
> Disabling CONFIG_INET saves 572034 bytes
...
> I hope you find this useful!
As another poor soul stuck with tiny resources, thank you for this
work! Now, if I could only leave networking out...
Thanks,
Richard
^ permalink raw reply
* Re: Evolution of Linux kernel sizes
From: Wolfgang Denk @ 2013-11-27 15:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/m68k, Linux Embedded, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdUr2Vr9+STwcYf1PcB=PF+u3SJxU3LYnzqQ+vdbDsp71A@mail.gmail.com>
Dear Geert,
In message <CAMuHMdUr2Vr9+STwcYf1PcB=PF+u3SJxU3LYnzqQ+vdbDsp71A@mail.gmail.com> you wrote:
>
> Below are the static kernel sizes (as reported by "size") for m68k
> multi-platform kernels (m68k/multi_defconfig), for kernel versions
> 2.6.28 to 3.12:
>
> text data bss dec hex filename
...
> 4010686 220476 190220 4421382 437706 vmlinux-v3.12
It's even more dramatic if you look further back. The U-Boot README
still has examples of 2.4.4 kernels for PowerPC _including_ network
support:
-> tools/mkimage -l examples/uImage.TQM850L
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327.86 kB = 0.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
resp. the same kernel using an uncompressed image:
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 792160 Bytes = 773.59 kB = 0.76 MB
Those were the days then, 13 years ago...
Today:
Image Name: Linux-3.12.0-11101-gfe9baba
Created: Wed Nov 27 15:05:33 2013
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1509145 Bytes = 1473.77 kB = 1.44 MB
Load Address: 00000000
Entry Point: 00000000
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 3172240 Bytes = 3097.89 kB = 3.03 MB
Compressed: 1509145 / 335725 = 4.50
Uncompressed: 3172240 / 792160 = 4.00
[1] http://git.denx.de/?p=u-boot.git;a=blob;f=README#l5142
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I think it's a new feature. Don't tell anyone it was an accident. :-)
-- Larry Wall on s/foo/bar/eieio in <10911@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* U-Boot <-> Kernel; NAND operation proposal
From: Leon Pollak @ 2013-12-04 16:39 UTC (permalink / raw)
To: linux-embedded
Hello, all.
I beg your pardon ahead for possible stupidity and inconsistency of what
I am going to say - this may be simply because of the lack of
experience. Below is my story and proposal as the result.
During the last 2 years, my product, which is based on DM368 (ARM7 based
TI CPU) and Micron's NAND flashes (256MiB, 2K page) behaves unstably.
This means that some units from time to time refuse to boot for
different reasons.
Today, after so long time and so many corrections, I can say that most
of the problems (not all!), which lead to the unit unable to start to
the end (to the application) where because of the incompatible modes of
NAND operating between u-boot and kernel.
For example, in the configuration I started from, which was supplied by
some vendor as evaluation board, u-boot was configured to use 4-bit HW
ECC, while kernel used 1-bit SW ECC.
The OOB layouts used in both systems were different.
Also BBT were configured differently.
There were several other "small things", which combination was
inconsistent and produced the incorrect NAND functioning, which finally
in some cases made the unit inoperative.
--
The major issue here is that such inconsistencies are not manifested in
some way, until the unit suddenly refuse to boot up after 2 weeks or 2
years.
All this lead me to the following thought (very draftly):
Each NAND has the "spare free" area in the first (zero) block, which is
used for storing CIS information. This information does not occupy all
the block, which usually is several hundreds of kilobytes.
So, this "spare" place may be used for storing some descriptive
information of ALL possible NAND flash and its service parameters.
I am speaking about ECC bits, Sw/HW, OOB layout, BBT layout, patter
places, bad block marks, and everything else you can imagine.
Further, this information must be used both by u-boot and kernel. Or
even by other components, for example, RBL/UBL in DM36x from TI.
Thanks to all who read this.
Best Regards
--
Leon Pollak
^ permalink raw reply
* Re: U-Boot <-> Kernel; NAND operation proposal
From: Lambrecht Jürgen @ 2013-12-18 10:03 UTC (permalink / raw)
To: Leon Pollak; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <18990519.GPctzMhBYx@leonp.plris.com>
Hi Leon,
you better post this to linux-mtd@lists.infradead.org.
You will get a better response there.
On 12/04/2013 05:39 PM, Leon Pollak wrote:
> Hello, all.
>
> I beg your pardon ahead for possible stupidity and inconsistency of what
> I am going to say - this may be simply because of the lack of
> experience. Below is my story and proposal as the result.
>
> During the last 2 years, my product, which is based on DM368 (ARM7 based
> TI CPU) and Micron's NAND flashes (256MiB, 2K page) behaves unstably.
You have linux on ARM7, uClinux then?
> This means that some units from time to time refuse to boot for
> different reasons.
I think booting from NAND is a bad idea for embedded devices. NAND has
bit-rot (also called
read-disturb(http://ecos.sourceware.org/ml/ecos-discuss/2011-05/msg00074.html))
(http://www.linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc), even
when just reading (the bootloader binary). So suddenly the boot binary
could have e.g. a bit-flip.
But maybe you already have redundant boot images?
We always use NOR flash to boot.
>
> Today, after so long time and so many corrections, I can say that most
> of the problems (not all!), which lead to the unit unable to start to
> the end (to the application) where because of the incompatible modes of
> NAND operating between u-boot and kernel.
>
> For example, in the configuration I started from, which was supplied by
> some vendor as evaluation board, u-boot was configured to use 4-bit HW
> ECC, while kernel used 1-bit SW ECC.
>
> The OOB layouts used in both systems were different.
> Also BBT were configured differently.
>
> There were several other "small things", which combination was
> inconsistent and produced the incorrect NAND functioning, which finally
> in some cases made the unit inoperative.
>
> --
>
> The major issue here is that such inconsistencies are not manifested in
> some way, until the unit suddenly refuse to boot up after 2 weeks or 2
> years.
>
> All this lead me to the following thought (very draftly):
>
> Each NAND has the "spare free" area in the first (zero) block, which is
> used for storing CIS information. This information does not occupy all
(I think the experts on linux-mtd will know this stands for Card
Information Structure, but I didn't ;-)
> the block, which usually is several hundreds of kilobytes.
> So, this "spare" place may be used for storing some descriptive
> information of ALL possible NAND flash and its service parameters.
> I am speaking about ECC bits, Sw/HW, OOB layout, BBT layout, patter
> places, bad block marks, and everything else you can imagine.
>
> Further, this information must be used both by u-boot and kernel. Or
> even by other components, for example, RBL/UBL in DM36x from TI.
I think that is a good idea. I recently also had nand flash issues with
BBT layout.
You better also post this to the uboot and barebox (uboot v2) mailing
list; I only know barebox:
barebox@lists.infradead.org
Kind regards,
Jürgen
>
> Thanks to all who read this.
> Best Regards
--
Jürgen Lambrecht
R&D Associate
Mobile: +32 499 644 531
Tel: +32 (0)51 303045 Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk
^ permalink raw reply
* GPIO triggers kernel reboot
From: Heiko Schocher @ 2014-01-25 16:02 UTC (permalink / raw)
To: linux-embedded; +Cc: Wolfgang Denk, linux-arm-kernel@lists.infradead.org
Hello all,
is it possible to reboot current mainline kernel triggered from a
GPIO in kernel space?
If not, how can be done this, so that it has a chance to go into
mainline?
Thanks for any suggestions
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* RE: GPIO triggers kernel reboot
From: Mehaffey, John @ 2014-01-25 19:11 UTC (permalink / raw)
To: hs@denx.de, linux-embedded@vger.kernel.org
Cc: Wolfgang Denk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <52E3E031.6040709@denx.de>
> -----Original Message-----
> From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-owner@vger.kernel.org] On Behalf Of Heiko Schocher
> Sent: Saturday, January 25, 2014 8:03 AM
> To: linux-embedded@vger.kernel.org
> Cc: Wolfgang Denk; linux-arm-kernel@lists.infradead.org
> Subject: GPIO triggers kernel reboot
>
> Hello all,
>
> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
>
> If not, how can be done this, so that it has a chance to go into mainline?
>
> Thanks for any suggestions
>
> bye,
> Heiko
Hi Heiko,
Call kexec() from the GPIO driver.
It will take some effort to get it right :)
Sincerely,
John Mehaffey
Principal Engineer, Automotive
Mentor Graphics
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> --
> 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: GPIO triggers kernel reboot
From: Mehaffey, John @ 2014-01-25 20:24 UTC (permalink / raw)
To: hs@denx.de, linux-embedded@vger.kernel.org
Cc: Wolfgang Denk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <371E240E6FC1D44DA5E51EE9DCDCB7845E5EA0A1@NA-MBX-01.mgc.mentorg.com>
> -----Original Message-----
> From: linux-embedded-owner@vger.kernel.org
> [mailto:linux-embedded-owner@vger.kernel.org] On Behalf Of Heiko
> Schocher
> Sent: Saturday, January 25, 2014 8:03 AM
> To: linux-embedded@vger.kernel.org
> Cc: Wolfgang Denk; linux-arm-kernel@lists.infradead.org
> Subject: GPIO triggers kernel reboot
>
> Hello all,
>
> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
>
> If not, how can be done this, so that it has a chance to go into mainline?
>
> Thanks for any suggestions
>
> bye,
> Heiko
Hi Heiko,
Call kexec() from the GPIO driver.
It will take some effort to get it right :)
Or if a simple reboot is all that you want, examine the several reboot APIs in kernel/reboot.c
Sincerely,
John Mehaffey
Principal Engineer, Automotive
Mentor Graphics
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> --
> 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
--
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: GPIO triggers kernel reboot
From: Florian Fainelli @ 2014-01-26 2:54 UTC (permalink / raw)
To: hs, linux-embedded; +Cc: Wolfgang Denk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <52E3E031.6040709@denx.de>
Le 25/01/2014 08:02, Heiko Schocher a écrit :
> Hello all,
>
> is it possible to reboot current mainline kernel triggered from a
> GPIO in kernel space?
>
> If not, how can be done this, so that it has a chance to go into
> mainline?
Your GPIO could (should) be bound to a gpio-keys driver which will
deliver key presses event; which you can ultimately bind to the action
of triggering a system reboot.
Granted, this makes you cross a lot of layers, and requires user-space
to implemnt the reboot policy, but what you are asking for is both a
mechanism and policy mix, which is usually not accepted.
You are probably working with HW which won't change, but wiring a reset
button to a system reset output is usually much simpler ;)
>
> Thanks for any suggestions
>
> bye,
> Heiko
^ permalink raw reply
* Re: GPIO triggers kernel reboot
From: Heiko Schocher @ 2014-01-27 6:17 UTC (permalink / raw)
To: Mehaffey, John
Cc: linux-embedded@vger.kernel.org, Wolfgang Denk,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <371E240E6FC1D44DA5E51EE9DCDCB7845E5EA0E1@NA-MBX-01.mgc.mentorg.com>
Hello John,
Am 25.01.2014 21:24, schrieb Mehaffey, John:
>> -----Original Message-----
>> From: linux-embedded-owner@vger.kernel.org
>> [mailto:linux-embedded-owner@vger.kernel.org] On Behalf Of Heiko
>> Schocher
>> Sent: Saturday, January 25, 2014 8:03 AM
>> To: linux-embedded@vger.kernel.org
>> Cc: Wolfgang Denk; linux-arm-kernel@lists.infradead.org
>> Subject: GPIO triggers kernel reboot
>>
>> Hello all,
>>
>> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
>>
>> If not, how can be done this, so that it has a chance to go into mainline?
>>
>> Thanks for any suggestions
>>
>> bye,
>> Heiko
>
> Hi Heiko,
> Call kexec() from the GPIO driver.
> It will take some effort to get it right :)
Thanks for your answer!
Hmm.. but has this a chance to go into mainline?
> Or if a simple reboot is all that you want, examine the several reboot APIs in kernel/reboot.c
A current implementation from a customer is for an arm, am335x based board
to add in board setup code:
ret = request_irq(OMAP_GPIO_IRQ(RESET_BUTTON_IRQ_GPIO)
, (irq_handler_t)arm_pm_restart, IRQF_TRIGGER_LOW, "reset button", NULL);
and as I want to bring this board to mainline, I think this is not
an acceptable/good way ... or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: GPIO triggers kernel reboot
From: Heiko Schocher @ 2014-01-27 6:22 UTC (permalink / raw)
To: Steve deRosier
Cc: linux-embedded, Wolfgang Denk,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CALLGbRKK_ZcOB6nAiV67njrphXMQXN7Y2s81n5k3PWoSVrsrUw@mail.gmail.com>
Hello Steve,
Thanks for your answer!
Am 25.01.2014 20:39, schrieb Steve deRosier:
> Hi Heiko,
>
> It's certainly possible, and it's also easily done from user-space.
> Something like this is more policy than function. It's also a potential
> security issue. As such I'd expect it highly unlikely that the kernel
> maintainers would allow it to go upstream. Give it a try though.
Ok, thats what I also think ...
> I'd approach this from user-space. Add in the gpio-keys driver and use the
> input-event-daemon to trigger a reboot. Super easy.
Yes, that was also my suggestion, but is there a way to do this without
user space usage in a generic way?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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