| Message ID | 1418633784-7709-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Rejected |
| Headers | show |
Hi Alexey, list, On Mon, Dec 15, 2014 at 9:56 AM, Alexey Brodkin <Alexey.Brodkin@synopsys.com > wrote: > > Consider following cases: > * Buildroot only builds rootfs that could be used on systems with > different default serial ports (ttyS0, ttyS1, ttyAMA3 etc) > * Target system has multiple serial ports and in kernel command > line users/developers may select different serial ports as > debug consoles > > In both cases hard-coded with BR2_TARGET_GENERIC_GETTY tty will > only work for 1 particular serial port. > > This change introduces an option to use whatever existing console. > For example console selected in kernel's command line will be used. > I would add another case: when BR is used to build a system without a dedicated console, but the SoC can be modified to provide one (like a NAS without a serial port, but with miniUART inside). In those cases I've seen OEMs use askfirst in inittab, as it uses less memory then a getty always waiting. > I'm not sure if the same thing works for SysVinit so marking it > dependent on Busybox init. > I think it does, but I will test it also when I'll have time. Anyway, I like this option. Also tested it with my build: x86_64 build and target platform, uClibc, GCC 4.9.2, kernel 3.18 w/ integrated initrd, VMware PXE booted, openvmtools included. Works as intended. Tested-by: Karoly Kasza <kaszak@gmail.com> Reviewed-by: Karoly Kasza <kaszak@gmail.com> Best regards, Karoly
Hi Karoly, On Mon, 2014-12-15 at 12:43 +0100, Károly Kasza wrote: > I would add another case: when BR is used to build a system without a > dedicated console, but the > SoC can be modified to provide one (like a NAS without a serial port, > but with miniUART inside). > In those cases I've seen OEMs use askfirst in inittab, as it uses less > memory then a getty always waiting. > > > I'm not sure if the same thing works for SysVinit so marking > it > dependent on Busybox init. > I think it does, but I will test it also when I'll have time. > > > Anyway, I like this option. Also tested it with my build: x86_64 build > and target platform, uClibc, GCC 4.9.2, kernel 3.18 w/ integrated > initrd, VMware PXE booted, openvmtools included. Works as intended. > > > Tested-by: Karoly Kasza <kaszak@gmail.com> > Reviewed-by: Karoly Kasza <kaszak@gmail.com> Thanks a lot for your feedback. I just wanted to add that IMHO this might be even a default option. I didn't do it as default because this is a new option and it's a good practice to no mark new options as default. But if this patch gets accepted probably in the future we may set it as default. Reason is simple - if you build something not from X_defconfig (which was created and tested by some other guy so it is expected to work) then chances are high that you will select improper serial port and its settings. Just because there's too much rope... tty{0|S|AMA|ARC|...} and all speed and other things. But let's first make sure this change is accepted. -Alexey
Dear Alexey Brodkin, On Mon, 15 Dec 2014 11:56:24 +0300, Alexey Brodkin wrote: > Consider following cases: > * Buildroot only builds rootfs that could be used on systems with > different default serial ports (ttyS0, ttyS1, ttyAMA3 etc) To achieve this, there is no need for a new option, just specify "console" as the terminal on which to run getty. The only change needed is to add "console" to /etc/securetty. Thomas
Hi Thomas, On Tue, 2014-12-16 at 08:14 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Mon, 15 Dec 2014 11:56:24 +0300, Alexey Brodkin wrote: > > Consider following cases: > > * Buildroot only builds rootfs that could be used on systems with > > different default serial ports (ttyS0, ttyS1, ttyAMA3 etc) > > To achieve this, there is no need for a new option, just specify > "console" as the terminal on which to run getty. The only change needed > is to add "console" to /etc/securetty. Well, actually putting "console" in BR2_TARGET_GENERIC_GETTY_PORT resolves only part of issues - need to specify particular tty. But still we have serial port settings like baudrate. BR2_TARGET_GENERIC_GETTY_BAUDRATE_x must match your serial port settings. So we're loosing flexibility of my approach here, but what is even more important imagine if there're 2 serial ports in the system and they have different baudrates but both properly described in kernel bootargs. With BR2_TARGET_GENERIC_GETTY only 1 console could be used then but not either of them. -Alexey
Dear Alexey Brodkin, On Wed, 17 Dec 2014 15:03:12 +0000, Alexey Brodkin wrote: > Well, actually putting "console" in BR2_TARGET_GENERIC_GETTY_PORT > resolves only part of issues - need to specify particular tty. > > But still we have serial port settings like baudrate. > BR2_TARGET_GENERIC_GETTY_BAUDRATE_x must match your serial port > settings. > > So we're loosing flexibility of my approach here, but what is even more > important imagine if there're 2 serial ports in the system and they have > different baudrates but both properly described in kernel bootargs. With > BR2_TARGET_GENERIC_GETTY only 1 console could be used then but not > either of them. Ah, yes I haven't looked at the baudrate issue. Isn't there a way to not pass any baudrate to getty, and let it use whatever baudrate is already configured on the device? Best regards, Thomas
Hi Thomas, On Wed, 2014-12-17 at 16:14 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Wed, 17 Dec 2014 15:03:12 +0000, Alexey Brodkin wrote: > > > Well, actually putting "console" in BR2_TARGET_GENERIC_GETTY_PORT > > resolves only part of issues - need to specify particular tty. > > > > But still we have serial port settings like baudrate. > > BR2_TARGET_GENERIC_GETTY_BAUDRATE_x must match your serial port > > settings. > > > > So we're loosing flexibility of my approach here, but what is even more > > important imagine if there're 2 serial ports in the system and they have > > different baudrates but both properly described in kernel bootargs. With > > BR2_TARGET_GENERIC_GETTY only 1 console could be used then but not > > either of them. > > Ah, yes I haven't looked at the baudrate issue. Isn't there a way to > not pass any baudrate to getty, and let it use whatever baudrate is > already configured on the device? Probably not. At least in case of Busybox I saw this on attempt to execute getty without baudrate at all. --->--- BAUD_RATE of 0 leaves it unchanged BusyBox v1.22.1 (2014-12-15 15:41:48 MSK) multi-call binary. Usage: getty [OPTIONS] BAUD_RATE[,BAUD_RATE]... TTY [TERMTYPE] Open TTY, prompt for login name, then invoke /bin/login -h Enable hardware RTS/CTS flow control -L Set CLOCAL (ignore Carrier Detect state) -m Get baud rate from modem's CONNECT status message -n Don't prompt for login name -w Wait for CR or LF before sending /etc/issue -i Don't display /etc/issue -f ISSUE_FILE Display ISSUE_FILE instead of /etc/issue -l LOGIN Invoke LOGIN instead of /bin/login -t SEC Terminate after SEC if no login name is read -I INITSTR Send INITSTR before anything else -H HOST --->--- -Alexey
Dear Alexey Brodkin, On Wed, 17 Dec 2014 15:24:44 +0000, Alexey Brodkin wrote: > Probably not. At least in case of Busybox I saw this on attempt to > execute getty without baudrate at all. Well, you didn't read it all... > > --->--- > BAUD_RATE of 0 leaves it unchanged ... see this :-) So if you set the baud rate to 0, it will keep the one configured by console= in the kernel command line. Best regards, Thomas
Hi Thomas, On Wed, 2014-12-17 at 16:36 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Wed, 17 Dec 2014 15:24:44 +0000, Alexey Brodkin wrote: > > > Probably not. At least in case of Busybox I saw this on attempt to > > execute getty without baudrate at all. > > Well, you didn't read it all... > > > > > --->--- > > BAUD_RATE of 0 leaves it unchanged > > ... see this :-) > > So if you set the baud rate to 0, it will keep the one configured by > console= in the kernel command line. Right it was too obvious. So looks like this is a replacement for my patch: --->--- BR2_TARGET_GENERIC_GETTY_PORT=console BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y --->--- Then the question is why this is not a default in Buildroot? IMHO most of the time kernel's bootcmd has console set so explicit setup of tty in Buildroot might be required in some corner cases only. -Alexey
> > Right it was too obvious. > > So looks like this is a replacement for my patch: > --->--- > BR2_TARGET_GENERIC_GETTY_PORT=console > BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y > --->--- > Doesn't your patch allow multiple getty ? I don't think console does that... that was a feature I was interested in. > Then the question is why this is not a default in Buildroot? > IMHO most of the time kernel's bootcmd has console set so explicit > setup > of tty in Buildroot might be required in some corner cases only. > > -Alexey > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Dear Jeremy Rosen, On Wed, 17 Dec 2014 16:53:33 +0100 (CET), Jeremy Rosen wrote: > Doesn't your patch allow multiple getty ? I don't think console > does that... > > that was a feature I was interested in. multiple getty is really something we want to leave to project-specific customization of the inittab. Use a rootfs overlay or a post-build script to do that. There are too many potential customizations that can be done in inittab to allow all of them to be done through Buildroot config options. Best regards, Thomas
Dear Alexey Brodkin, On Wed, 17 Dec 2014 15:50:16 +0000, Alexey Brodkin wrote: > Right it was too obvious. > > So looks like this is a replacement for my patch: > --->--- > BR2_TARGET_GENERIC_GETTY_PORT=console > BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y > --->--- Yes. Does it work? :-) > Then the question is why this is not a default in Buildroot? > IMHO most of the time kernel's bootcmd has console set so explicit setup > of tty in Buildroot might be required in some corner cases only. I agree, maybe we should make this the default. What happens on PC-style platforms? Is console= typically set to tty1 ? Best regards, Thomas
Hi Thomas, On Wed, 2014-12-17 at 17:08 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Wed, 17 Dec 2014 15:50:16 +0000, Alexey Brodkin wrote: > > > Right it was too obvious. > > > > So looks like this is a replacement for my patch: > > --->--- > > BR2_TARGET_GENERIC_GETTY_PORT=console > > BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y > > --->--- > > Yes. Does it work? :-) Indeed it worked but on the board I tried it there's only 1 console for now so didn't have a chance to make sure either of selected consoles may work but frankly don't expect any issues here. > > Then the question is why this is not a default in Buildroot? > > IMHO most of the time kernel's bootcmd has console set so explicit setup > > of tty in Buildroot might be required in some corner cases only. > > I agree, maybe we should make this the default. What happens on > PC-style platforms? Is console= typically set to tty1 ? Well from dmesg output of my Fedora 21 I see this: --->--- [ 0.000000] console [tty0] enabled --->--- Is this what you're looking for? -Alexey
Dear Alexey Brodkin, On Wed, 17 Dec 2014 16:18:44 +0000, Alexey Brodkin wrote: > > > Then the question is why this is not a default in Buildroot? > > > IMHO most of the time kernel's bootcmd has console set so explicit setup > > > of tty in Buildroot might be required in some corner cases only. > > > > I agree, maybe we should make this the default. What happens on > > PC-style platforms? Is console= typically set to tty1 ? > > Well from dmesg output of my Fedora 21 I see this: > --->--- > [ 0.000000] console [tty0] enabled > --->--- > Is this what you're looking for? I don't know if running a getty on tty0 actually works. tty0 is actually a "fake" device that points to the current virtual console. To be tested, maybe with the Qemu/x86 emulation. Best regards, Thomas
Dear Alexey Brodkin, On Mon, 15 Dec 2014 11:56:24 +0300, Alexey Brodkin wrote: > Consider following cases: > * Buildroot only builds rootfs that could be used on systems with > different default serial ports (ttyS0, ttyS1, ttyAMA3 etc) > * Target system has multiple serial ports and in kernel command > line users/developers may select different serial ports as > debug consoles > > In both cases hard-coded with BR2_TARGET_GENERIC_GETTY tty will > only work for 1 particular serial port. > > This change introduces an option to use whatever existing console. > For example console selected in kernel's command line will be used. > > I'm not sure if the same thing works for SysVinit so marking it > dependent on Busybox init. > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Anton Kolesov <akolesov@synopsys.com> > Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> In the light of the discussion that has taken place, we have found a solution that apparently matches your use case, by using the existing Buildroot options. Therefore, I've marked your patch as Rejected in patchwork. If you disagree, do not hesitate to re-send an updated version with an extended justification. Thanks a lot! Thomas
Hi Thomas, On Wed, 2014-12-17 at 17:28 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Wed, 17 Dec 2014 16:18:44 +0000, Alexey Brodkin wrote: > > > > > Then the question is why this is not a default in Buildroot? > > > > IMHO most of the time kernel's bootcmd has console set so explicit setup > > > > of tty in Buildroot might be required in some corner cases only. > > > > > > I agree, maybe we should make this the default. What happens on > > > PC-style platforms? Is console= typically set to tty1 ? > > > > Well from dmesg output of my Fedora 21 I see this: > > --->--- > > [ 0.000000] console [tty0] enabled > > --->--- > > Is this what you're looking for? > > I don't know if running a getty on tty0 actually works. tty0 is > actually a "fake" device that points to the current virtual console. To > be tested, maybe with the Qemu/x86 emulation. I've just tried Qemu/x86 and with following config it worked like a charm: --->--- BR2_x86_pentiumpro=y BR2_KERNEL_HEADERS_VERSION=y BR2_DEFAULT_KERNEL_VERSION="3.17.2" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_17=y BR2_TARGET_GENERIC_GETTY_PORT="console" BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.17.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.17.config" BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set --->--- So then I think it's time for a patch that by default selects: 1. BR2_TARGET_GENERIC_GETTY_PORT="console" 2. BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y Any objections? -Alexey
Dear Alexey Brodkin, On Tue, 23 Dec 2014 09:40:27 +0000, Alexey Brodkin wrote: > So then I think it's time for a patch that by default selects: > 1. BR2_TARGET_GENERIC_GETTY_PORT="console" > 2. BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP=y > > Any objections? I'm fine with that. Maybe we'll need the ACK from Peter on this, though, but I would personally support such a change. Best regards, Thomas
diff --git a/system/Config.in b/system/Config.in index 39f27c7..0fa0dc6 100644 --- a/system/Config.in +++ b/system/Config.in @@ -311,6 +311,11 @@ config BR2_TARGET_GENERIC_GETTY_OPTIONS endmenu endif +config BR2_TARGET_ASKFIRST_SHELL + bool "Start an \"askfirst\" shell on the console (whatever that may be)" + depends on BR2_INIT_BUSYBOX + depends on !BR2_TARGET_GENERIC_GETTY + config BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW bool "remount root filesystem read-write during boot" default y diff --git a/system/skeleton/etc/inittab b/system/skeleton/etc/inittab index b1892c1..3a2514a 100644 --- a/system/skeleton/etc/inittab +++ b/system/skeleton/etc/inittab @@ -23,6 +23,9 @@ null::sysinit:/bin/hostname -F /etc/hostname # now run any rc scripts ::sysinit:/etc/init.d/rcS +# Start an "askfirst" shell on the console (whatever that may be) +#::askfirst:-/bin/sh # ASKFIRST_SHELL + # Put a getty on the serial port #ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL diff --git a/system/system.mk b/system/system.mk index e4a3160..f93e27a 100644 --- a/system/system.mk +++ b/system/system.mk @@ -76,6 +76,15 @@ endif TARGET_FINALIZE_HOOKS += SYSTEM_GETTY endif +ifeq ($(BR2_TARGET_ASKFIRST_SHELL),y) +# Add askfirst shell to busybox inittab +define SYSTEM_ASKFIRST + $(SED) '/# ASKFIRST_SHELL$$/s~^.*#~::askfirst:-/bin/sh #~' \ + $(TARGET_DIR)/etc/inittab +endef +TARGET_FINALIZE_HOOKS += SYSTEM_ASKFIRST +endif + ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y) # Find commented line, if any, and remove leading '#'s define SYSTEM_REMOUNT_RW
Consider following cases: * Buildroot only builds rootfs that could be used on systems with different default serial ports (ttyS0, ttyS1, ttyAMA3 etc) * Target system has multiple serial ports and in kernel command line users/developers may select different serial ports as debug consoles In both cases hard-coded with BR2_TARGET_GENERIC_GETTY tty will only work for 1 particular serial port. This change introduces an option to use whatever existing console. For example console selected in kernel's command line will be used. I'm not sure if the same thing works for SysVinit so marking it dependent on Busybox init. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- system/Config.in | 5 +++++ system/skeleton/etc/inittab | 3 +++ system/system.mk | 9 +++++++++ 3 files changed, 17 insertions(+)