Subject: unable to open initial console (ENODEV) (WAS: problem w/ kernel init
 (rootfs vs initial console / init process))
From: mtx <metux@gmx.de>
To: linux-kernel@vger.kernel.org
References: <ed912df6-390f-989f-1ddc-7759a2989141@gmx.de>
Message-ID: <74bc1cea-03e5-3c72-bdfd-b893587f2163@gmx.de>
Date: Sun, 10 Sep 2017 17:02:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <ed912df6-390f-989f-1ddc-7759a2989141@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 882
Lines: 19

On 10.09.2017 11:09, mtx wrote:

> it tries to open the initial console, before even attempt to mount the > root fs, which obviously is doomed to fail. (directly passing root=> 
via cmdline - no initrd etc)
Solved it. For the record: the uart2 node was still disabled, so the
kernel did allocate a console for the port, but no tty_driver assigned.

tty_lookup_driver() (tty_io.c) is called on opening tty devices (such as
/dev/console). it asks console_device() (in printk.c), which scans the
consoles list for one with a tty_driver.

As my DT left the console's uart port disabled, the corresponding device
wasn't initialized, thus leaving the console w/o assigned tty_driver.

BTW: maybe we should think about some logic which spits out a warning,
or maybe implement an own special tty_driver for /dev/console, which
goes to the active console(s), just like printk() does.

--mtx