Hi Folks
I've ended up talking to a few people recently about LEDs.
CE and EE have four user lights which are often hooked up in different
ways on each board.
Are there any common recommendations about default LED hook ups for the
kernel (e.g. USR1 -> heartbeat, USR2 -> disk I/O, etc)?
Similarly it might be useful to have a couple of events nominated where
we recommend a firmware level bootloader[1] change LED status. Some
examples:
- Set USR1 on when bootloader starts up (a NOR/eMMC/SD is not empty
light).
- Set USR3 on when entering fastboot mode (if supported)
- Set USR3 off when leaving fastboot mode, including via "fastboot
boot" (if supported)
- Set USR1 off and USR2, 3 and 4 on if bootloader panics.
Especially for CE board (where users often don't have a UART adapter)
even the above simple hints that the bootloader has been fetched from
somewhere is useful.
I know this can't be a rule, only "good advice" (like asking CE boards
to put console on LS-UART1 if possible). However, is there any appetite
to converge for the boards we have influence over?
Daniel.
[1] Here I definitely mean EDK2 rather than grub. If we have multiple
chained firmware level bootloaders (e.g. LK -> u-boot) things are
less clear although, as it happens, if *both* implemented the above
proposal the results would still be perfectly useable from a user
perspective.
Hi,
When verified some patches on linux-next branch I found Debian rootfs
cannot be mounted successfully on Hikey, the booting log is:
http://termbin.com/akar
>From the log, we can see:
mount: mounting udev on /dev failed: Device or resource busy
...
ALERT! /dev/disk/by-partlabel/system does not exist. Dropping to a
shell!
So I bisected the linux-next branch and narrow down below patch which
introduces mounting failure; after applied this patch, the kernel will
mount devtmpfs on '/dev', then later udev cannot mount again for
devfs. Finally cannot find '/dev/disk/by-partlabel/system' for rootfs.
I don't know what's the best way to fix this issue, welcome any
suggestion for this. And report this issue in case it may impact later
Debian release?
Thanks,
Leo Yan
---8<---
>From ee35011fd0324b37fbb046561e58d4d6bae798ac Mon Sep 17 00:00:00 2001
From: Rob Landley <rob(a)landley.net>
Date: Fri, 19 May 2017 07:39:23 +1000
Subject: [PATCH] initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT
Make initramfs honor CONFIG_DEVTMPFS_MOUNT, fixing 2b2af54a5bb6 ("Driver
Core: devtmpfs - kernel-maintained tmpfs-based /dev"), which didn't
bother. Move /dev/console open after devtmpfs mount, and update help
text.
Commit 456eeabab849 in 2005 made gen_initramfs_list (when run with no
arguments) spit out an 'example' config creating /dev and /dev/console.
The kernel accidentally(?) included this for many years when you didn't
specify initramfs contents, and of course grew dependencies on this
/dev/console node in the (often hidden) initramfs. c33df4eaaf41 ("disable
init/initramfs.c") in 2007 explicitly preserved this dependency.
2bd3a997befc ("init: Open /dev/console from rootfs") in 2010 claimed it
"removes the occasionally problematic assumption that /dev/console exists
from the boot code" but actually just moved it later.
But nobody never tested statically linking an initramfs. If you point
CONFIG_INITRAMFS_SOURCE at a directory running the build as a normal user
you _don't_ get a /dev/console (because you can't create it without being
root, and can't use the existing one out of /dev unless you create your
own initramfs list file), in which case init runs with stdin/stdout/stderr
closed and you get no output.
Eric's test case for his 2010 commit referenced above was:
With this patch I was able to throw busybox on my /boot partition
(which has no /dev directory) and boot into userspace without
problems.
But it didn't work pointing CONFIG_INITRAMFS_SOURCE at a directory of the
same files. This provides the "automatically mounting devtmpfs on /dev"
workaround the earlier commit was trying to avoid.
Link: http://lkml.kernel.org/r/21935caf-501d-e97c-5611-5c4af7e0f9ae@landley.net
Signed-off-by: Rob Landley <rob(a)landley.net>
Cc: Eric W. Biederman <ebiederm(a)xmission.com>
Cc: Jean-Paul Saman <jean-paul.saman(a)nxp.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Cc: Yang Shi <yang.shi(a)linaro.org>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Emese Revfy <re.emese(a)gmail.com>
Cc: Petr Mladek <pmladek(a)suse.com>
Cc: Fabian Frederick <fabf(a)skynet.be>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/base/Kconfig | 14 ++++----------
init/main.c | 15 +++++++++------
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d718ae4..74779ee 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
depends on DEVTMPFS
help
- This will instruct the kernel to automatically mount the
- devtmpfs filesystem at /dev, directly after the kernel has
- mounted the root filesystem. The behavior can be overridden
- with the commandline parameter: devtmpfs.mount=0|1.
- This option does not affect initramfs based booting, here
- the devtmpfs filesystem always needs to be mounted manually
- after the rootfs is mounted.
- With this option enabled, it allows to bring up a system in
- rescue mode with init=/bin/sh, even when the /dev directory
- on the rootfs is completely empty.
+ Automatically mount devtmpfs at /dev on the root filesystem, which
+ lets the system to come up in rescue mode with [rd]init=/bin/sh.
+ Override with devtmpfs.mount=0 on the commandline. Initramfs can
+ create a /dev dir as needed, other rootfs needs the mount point.
config STANDALONE
bool "Select only drivers that don't need compile-time external firmware"
diff --git a/init/main.c b/init/main.c
index f866510..9ec09ff 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1038,12 +1038,6 @@ static noinline void __init kernel_init_freeable(void)
do_basic_setup();
- /* Open the /dev/console on the rootfs, this should never fail */
- if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
- pr_err("Warning: unable to open an initial console.\n");
-
- (void) sys_dup(0);
- (void) sys_dup(0);
/*
* check if there is an early userspace init. If yes, let it do all
* the work
@@ -1055,8 +1049,17 @@ static noinline void __init kernel_init_freeable(void)
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
ramdisk_execute_command = NULL;
prepare_namespace();
+ } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) {
+ sys_mkdir("/dev", 0755);
+ devtmpfs_mount("/dev");
}
+ /* Open the /dev/console on the rootfs, this should never fail */
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+ pr_err("Warning: unable to open an initial console.\n");
+ (void) sys_dup(0);
+ (void) sys_dup(0);
+
/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
--
2.7.4
