On 08/25/2015 01:59 AM, Itaru Kitayama wrote:
Hi Al,
Below is the dmesg. In the modified kernel I call disable_acpi() right after acpi_boot_table_init(). (Otherwise, no meaningful output is obtained even with earlycon)
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.2.0-rc5+ (root@r2-a21) (gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) ) #23 SMP Mon Aug 24 20:29:06 EDT 2015 [snip...]
My apologies for not being clearer.
This info from dmesg shows ACPI tables being loaded, and then DT being used for the initialization of devices. The problem is that ACPI is not working. So, what I need so that I can understand is the dmesg output from when ACPI is _not_ working. Please use earlycon, of course, but take out the call to disable_acpi(). If you get nothing at that point, please make sure there is no console= on the kernel cmdline; it doesn't look like there is, but it wouldn't hurt to be sure. There are some versions of the firmware/OS combination where using console= and having an SPCR table cause no console at all.