[PATCH] x86/x86_64_defconfig: Enable the serial console

[PATCH] x86/x86_64_defconfig: Enable the serial console

[Enric Balletbo i Serra]

As part of KernelCI, we added a bunch of different x86 based Chromebooks
to do test booting and runtime testing. It will be useful have serial
support for these platforms in the default defconfig, as this, is the
defconfig used by default for the different maintainer's tree.

SERIAL_8250_DW is the actual support for the console, but to have
support we need to enable X86_AMD_PLATFORM_DEVICE for specific AMD
boards and MFD_INTEL for specific Intel boards.

While here, also enable USB_RTL8152 config which enables a common
USB-Ethernet adapter used very commonly in the KernelCI labs.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---

 arch/x86/configs/x86_64_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 9936528e1939..c43f61a8059c 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -20,6 +20,7 @@ CONFIG_BLK_DEV_INITRD=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_PROFILING=y
 CONFIG_SMP=y
+CONFIG_X86_AMD_PLATFORM_DEVICE=y
 CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
 CONFIG_MICROCODE_AMD=y
 CONFIG_X86_MSR=y
@@ -149,6 +150,7 @@ CONFIG_SKY2=y
 CONFIG_FORCEDETH=y
 CONFIG_8139TOO=y
 CONFIG_R8169=y
+CONFIG_USB_RTL8152=y
 CONFIG_INPUT_POLLDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_JOYSTICK=y
@@ -164,6 +166,7 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_DETECT_IRQ=y
 CONFIG_SERIAL_8250_RSA=y
+CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_NONSTANDARD=y
 CONFIG_HW_RANDOM=y
 # CONFIG_HW_RANDOM_INTEL is not set
@@ -173,6 +176,7 @@ CONFIG_HPET=y
 # CONFIG_HPET_MMAP is not set
 CONFIG_I2C_I801=y
 CONFIG_WATCHDOG=y
+CONFIG_MFD_INTEL_LPSS_PCI=y
 CONFIG_AGP=y
 CONFIG_AGP_AMD64=y
 CONFIG_AGP_INTEL=y
-- 
2.28.0

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Thu, Oct 08, 2020 at 06:22:06PM +0200, Enric Balletbo i Serra wrote:
> As part of KernelCI, we added a bunch of different x86 based Chromebooks
> to do test booting and runtime testing. It will be useful have serial
> support for these platforms in the default defconfig, as this, is the
> defconfig used by default for the different maintainer's tree.
> 
> SERIAL_8250_DW is the actual support for the console, but to have
> support we need to enable X86_AMD_PLATFORM_DEVICE for specific AMD
> boards and MFD_INTEL for specific Intel boards.
> 
> While here, also enable USB_RTL8152 config which enables a common
> USB-Ethernet adapter used very commonly in the KernelCI labs.

To me defconfig sounds like the config which contains items which are
needed on the majority of x86 hardware out there.

Are those which you enable that common and if not, why can't your build
supply a custom .config instead?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Randy Dunlap]

On 10/8/20 9:40 AM, Borislav Petkov wrote:
> On Thu, Oct 08, 2020 at 06:22:06PM +0200, Enric Balletbo i Serra wrote:
>> As part of KernelCI, we added a bunch of different x86 based Chromebooks
>> to do test booting and runtime testing. It will be useful have serial
>> support for these platforms in the default defconfig, as this, is the
>> defconfig used by default for the different maintainer's tree.
>>
>> SERIAL_8250_DW is the actual support for the console, but to have
>> support we need to enable X86_AMD_PLATFORM_DEVICE for specific AMD
>> boards and MFD_INTEL for specific Intel boards.
>>
>> While here, also enable USB_RTL8152 config which enables a common
>> USB-Ethernet adapter used very commonly in the KernelCI labs.
> 
> To me defconfig sounds like the config which contains items which are
> needed on the majority of x86 hardware out there.

to run in normal (or common) user mode(s).

Nothing to do with automated testing like syzbot or CI IMO.

> Are those which you enable that common and if not, why can't your build
> supply a custom .config instead?

I suppose that we are lacking a definition of a defconfig, but again, IMO,
these Kconfig symbols don't meet the need for normal users.


-- 
~Randy

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Enric Balletbo i Serra]

Hi Borislav and Randy,

Thank you for your comments.

On 8/10/20 20:31, Randy Dunlap wrote:
> On 10/8/20 9:40 AM, Borislav Petkov wrote:
>> On Thu, Oct 08, 2020 at 06:22:06PM +0200, Enric Balletbo i Serra wrote:
>>> As part of KernelCI, we added a bunch of different x86 based Chromebooks
>>> to do test booting and runtime testing. It will be useful have serial
>>> support for these platforms in the default defconfig, as this, is the
>>> defconfig used by default for the different maintainer's tree.
>>>
>>> SERIAL_8250_DW is the actual support for the console, but to have
>>> support we need to enable X86_AMD_PLATFORM_DEVICE for specific AMD
>>> boards and MFD_INTEL for specific Intel boards.
>>>
>>> While here, also enable USB_RTL8152 config which enables a common
>>> USB-Ethernet adapter used very commonly in the KernelCI labs.
>>
>> To me defconfig sounds like the config which contains items which are
>> needed on the majority of x86 hardware out there.
> 
> to run in normal (or common) user mode(s).
> 
> Nothing to do with automated testing like syzbot or CI IMO.
> 
>> Are those which you enable that common and if not, why can't your build
>> supply a custom .config instead?
> 
> I suppose that we are lacking a definition of a defconfig, but again, IMO,
> these Kconfig symbols don't meet the need for normal users.
> 
> 

We're also probably lacking a definition of what normal users mean, because I
don't think normal users build their own kernel. I think that at least
X86_AMD_PLATFORM_DEVICE and MFD_INTEL_LPSS_PCI could be common enough to match
within the category of needed to run in normal (or common) user mode(s). I can
send a patch with only these two options.

But, yes, the main purpose after this patch is the serial console for CI. I saw
that there are already some configs with a specific purpose (tiny.config and
xen.config). So, I am wondering if would be acceptable support another specific
config for CI (i.e kernelci.config). Will it be acceptable?

Thanks,
 Enric

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Sun, Oct 11, 2020 at 01:43:44PM +0200, Enric Balletbo i Serra wrote:
> We're also probably lacking a definition of what normal users mean, because I
> don't think normal users build their own kernel.

You'd be surprised.

> I think that at least X86_AMD_PLATFORM_DEVICE and MFD_INTEL_LPSS_PCI
> could be common enough to match within the category of needed to run
> in normal (or common) user mode(s). I can send a patch with only these
> two options.

How do you quantify those things are common enough?

> But, yes, the main purpose after this patch is the serial console for CI. I saw
> that there are already some configs with a specific purpose (tiny.config and
> xen.config). So, I am wondering if would be acceptable support another specific
> config for CI (i.e kernelci.config). Will it be acceptable?

Why does this config have to be upstream? Can't your build process
supply it? Also, can your config be of any use outside of kernel CI?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Enric Balletbo i Serra]

Hi Borislav,

On 11/10/20 14:20, Borislav Petkov wrote:
> On Sun, Oct 11, 2020 at 01:43:44PM +0200, Enric Balletbo i Serra wrote:
>> We're also probably lacking a definition of what normal users mean, because I
>> don't think normal users build their own kernel.
> 
> You'd be surprised.
> 
>> I think that at least X86_AMD_PLATFORM_DEVICE and MFD_INTEL_LPSS_PCI
>> could be common enough to match within the category of needed to run
>> in normal (or common) user mode(s). I can send a patch with only these
>> two options.
> 
> How do you quantify those things are common enough?
> 

How do you quantify those things are NOT common enough? Do you have a number?

I don't have a number, the only I can tell is that both symbols enable support
for I2C, SPI an HS-UART. The AMD one, is found on AMD Carrizo and later
chipsets, the Intel one, is found on Intel Skylake and later. I.e Lots of
laptops need these to have support for the touchpad.

>> But, yes, the main purpose after this patch is the serial console for CI. I saw
>> that there are already some configs with a specific purpose (tiny.config and
>> xen.config). So, I am wondering if would be acceptable support another specific
>> config for CI (i.e kernelci.config). Will it be acceptable?
> 
> Why does this config have to be upstream?

KernelCI is focused on upstream kernel development. KernelCI builds lots of
different versions of the kernel, including stable kernels, and maintainers
trees. It does tests on real hardware, so having a config supporting as much as
possible the x86 hardware that we have in the KernelCI labs will help us to
increase the test coverage and catch more issues.

configs are tied to the kernel version, as one config symbol can be changed,
removed or renamed between kernel versions. Having in a separate project will
imply a maintenance effort for x86 hardware. Note that, for ARM and ARM64
hardware, we don't have this problem because the "normal" defconfigs seems to go
the other way regarding what could be or not in the config. So I think it would
be useful (having it would save hours of maintenance time in a separate project
to test only the x86 hardware).

> Can't your build process
> supply it? 

Yes, it can. As I said, is a matter of maintenance, if we do this we will have a
different workflow for x86 hardware.

Thanks,
 Enric

> Also, can your config be of any use outside of kernel CI?
> 
> Thx.
> 

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Sun, Oct 11, 2020 at 05:40:27PM +0200, Enric Balletbo i Serra wrote:
> How do you quantify those things are NOT common enough? Do you have a number?

I don't want to change the defconfig - you do. So quantifying is in your
court - not mine.

> I don't have a number, the only I can tell is that both symbols enable support
> for I2C, SPI an HS-UART. The AMD one, is found on AMD Carrizo and later
> chipsets, the Intel one, is found on Intel Skylake and later. I.e Lots of
> laptops need these to have support for the touchpad.

That sounds like a step in the right direction.

> KernelCI is focused on upstream kernel development. KernelCI builds lots of
> different versions of the kernel, including stable kernels, and maintainers
> trees. It does tests on real hardware, so having a config supporting as much as
> possible the x86 hardware that we have in the KernelCI labs will help us to
> increase the test coverage and catch more issues.

So those issues - where do you guys report them? Because I've never seen
one reported by kernelCI, AFAIR. I see 0day bot and syzbot doing such
reports on a regular basis but none from kernelCI AFAIK. Do you send
your bug reports to lkml and Cc the relevant parties?

> Yes, it can. As I said, is a matter of maintenance, if we do this we
> will have a different workflow for x86 hardware.

Lemme get this straight - your workflow would do:

$ make defconfig

and now here you'd have to add a single command:

$ .scripts/kconfig/merge_config.sh -m .config .kernelci.config.snippet

in order to get the symbols you want, enabled.

I've shown this one because this is how those other configs like
kvm_guest.config and xen.config work - they're config snippets and they
get merged with a preexisting config, see scripts/kconfig/Makefile.

Now, is that additional single command worth "hours of maintenance time"
or is it something you can do easily? As in:

	if (x86)
		<command>

?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Enric Balletbo i Serra]

Hi Borislav,

On 11/10/20 17:57, Borislav Petkov wrote:
> On Sun, Oct 11, 2020 at 05:40:27PM +0200, Enric Balletbo i Serra wrote:
>> How do you quantify those things are NOT common enough? Do you have a number?
> 
> I don't want to change the defconfig - you do. So quantifying is in your
> court - not mine.
> 
>> I don't have a number, the only I can tell is that both symbols enable support
>> for I2C, SPI an HS-UART. The AMD one, is found on AMD Carrizo and later
>> chipsets, the Intel one, is found on Intel Skylake and later. I.e Lots of
>> laptops need these to have support for the touchpad.
> 
> That sounds like a step in the right direction.
> 
>> KernelCI is focused on upstream kernel development. KernelCI builds lots of
>> different versions of the kernel, including stable kernels, and maintainers
>> trees. It does tests on real hardware, so having a config supporting as much as
>> possible the x86 hardware that we have in the KernelCI labs will help us to
>> increase the test coverage and catch more issues.
> 
> So those issues - where do you guys report them? Because I've never seen
> one reported by kernelCI, AFAIR. I see 0day bot and syzbot doing such
> reports on a regular basis but none from kernelCI AFAIK. Do you send
> your bug reports to lkml and Cc the relevant parties?
> 

Yes, although probably there is only a chance that you saw for ARM platforms, we
just started to attach x86 hardware to the KernelCI labs (apart from some qemu
instances).

They all can be found here:
https://groups.io/g/kernelci-results/messages?start=10:2020:-120


>> Yes, it can. As I said, is a matter of maintenance, if we do this we
>> will have a different workflow for x86 hardware.
> 
> Lemme get this straight - your workflow would do:
> 
> $ make defconfig
> 
> and now here you'd have to add a single command:
> 
> $ .scripts/kconfig/merge_config.sh -m .config .kernelci.config.snippet
> 
> in order to get the symbols you want, enabled.
> 
> I've shown this one because this is how those other configs like
> kvm_guest.config and xen.config work - they're config snippets and they
> get merged with a preexisting config, see scripts/kconfig/Makefile.
> 
> Now, is that additional single command worth "hours of maintenance time"
> or is it something you can do easily? As in:
> 
> 	if (x86)
> 		<command>
> 
> ?
>

Sorry if I didn't explain well, but I am not talking about this workflow, which
of course, is very trivial and actually even implemented in kernelCI. It
actually allows to merge fragments. Let me try explain again.

I'm going to use the arm64 / x86 naming just because for clarity, but basically
is a fragment in the kernel repository vs a fragment on another repository.

So imagine your hardware is attached to a KernelCI lab and want to run
v4l2-compliance tests on that hardware.

For arm64 (i.e : arm64_defconfig)
   1. You send a patch to the list enabling the CONFIG_YOUR_V4L2_DEVICE=m
   2. The patch is accepted and merged in linux-next.
   3. KernelCI builds linux-next, boots the kernel on the hardware, detects a
new v4l2 device, and runs the v4l2-compliance tests.


For x86:
   1. You send a patch to list enabling the CONFIG_YOUR_V4L2_DEVICE=m
   2. The patch is rejected because doesn't fit the requirements (is not common
enough)
   3. If you're lucky someone will tell you to send the patch, to the specific
KernelCI x86 fragment project.
   4. You send a patch to the separate KernelCI x86 project.
   5. The patch is accepted and merged.
   6. KernelCI builds linux-next, boots the kernel on the hardware, detects a
new v4l2 device, and runs the v4l2-compliance tests.


Of course you can skip 1-3 if you know already that. Another example:


For arm64 (i.e : arm64_defconfig):
    1. Someone renames CONFIG_A to CONFIG_AB, sends a patch, and as he did a
grep, the patch modifies all the defconfigs.
    2. The patch is accepted and merged in linux-next.
    3. KernelCI builds linux-next, boots the kernel on the hardware and all the
tests continue passing.


For x86:
    1. Someone renames CONFIG_A to CONFIG_AB, sends a patch and as he did a grep
the patches modifies all the defconfigs.
    2. The patch is accepted and merged in linux-next.
    3. KernelCI builds linux-next, boots the kernel on the hardware, and some
tests start to fail or are skipped.
    4. The maintainer is noticed about the behavior change, so he will need to
look at the problem, and find it.
    5. The maintainer sends a patch.
    6. The patch is accepted, but he needs to tag the release as per kernel <
x.y.z version it should use CONFIG_A and for kernel > x.y.z it should pick
CONFIG_AB.
    7. KernelCI builds linux-next, boots the kernel on the hardware and all the
tests pass again.

Thanks,
 Enric


> Thx.
> 

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> For x86:
>    1. You send a patch to list enabling the CONFIG_YOUR_V4L2_DEVICE=m
>    2. The patch is rejected because doesn't fit the requirements (is not common
> enough)

Well, what if that config option enables hardware which is ARM-only.
Then it doesn't make any sense to enable it in the x86 defconfig.

>    3. If you're lucky someone will tell you to send the patch, to the specific
> KernelCI x86 fragment project.

You lost me here: there's a specific fragment project?!?

>    4. You send a patch to the separate KernelCI x86 project.
>    5. The patch is accepted and merged.
>    6. KernelCI builds linux-next, boots the kernel on the hardware, detects a
> new v4l2 device, and runs the v4l2-compliance tests.
> 
> 
> Of course you can skip 1-3 if you know already that. Another example:

So this second example confused me even more. Looking at your original
patch, you want this enabled in the defconfig:

config SERIAL_8250_DW
        tristate "Support for Synopsys DesignWare 8250 quirks"
        depends on SERIAL_8250
        select SERIAL_8250_DWLIB
        help
          Selecting this option will enable handling of the extra features
          present in the Synopsys DesignWare APB UART.

and for that you need those other two: X86_AMD_PLATFORM_DEVICE and
MFD_INTEL.

What I don't get is why can't you have a .config.snippet which enables
what you need on the chromebooks and you can have all the serial you
want. And the net card driver for that matter.

And in all that, I still don't get why this is relevant for the upstream
kernel.

By this logic, other projects would start wanting to add more to
defconfig and which would slowly turn into an allmodconfig. So you can
simply build an allmodconfig kernel and do *all* your testing with it,
just like the distros ship an allmodconfig-like kernel. Problem solved.

/me is more confused.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Willy Tarreau]

Hi Enric,

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> For arm64 (i.e : arm64_defconfig):
>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch, and as he did a
> grep, the patch modifies all the defconfigs.
>     2. The patch is accepted and merged in linux-next.
>     3. KernelCI builds linux-next, boots the kernel on the hardware and all the
> tests continue passing.
> 
> 
> For x86:
>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch and as he did a grep
> the patches modifies all the defconfigs.
>     2. The patch is accepted and merged in linux-next.
>     3. KernelCI builds linux-next, boots the kernel on the hardware, and some
> tests start to fail or are skipped.
>     4. The maintainer is noticed about the behavior change, so he will need to
> look at the problem, and find it.
>     5. The maintainer sends a patch.
>     6. The patch is accepted, but he needs to tag the release as per kernel <
> x.y.z version it should use CONFIG_A and for kernel > x.y.z it should pick
> CONFIG_AB.
>     7. KernelCI builds linux-next, boots the kernel on the hardware and all the
> tests pass again.

Previously I thought I understood your needs, but now I don't anymore. You
seem to be saying that you're not testing *anything* outside of defconfig,
and that as such you'd like defconfig to be complete enough to provide good
coverage. This sounds a bit odd to me. And what if in the arm64 case, the
CONFIG_YOUR_V4L2_DEVICE is *not* added to defconfig ? You're in the same
situation.

We all know it's not fun to have to deal with local config snippets, but
as soon as you plan to boot on a specific hardware, this is unavoidable.
Also, config symbols are rarely renamed. Most often they are moved under
new entries (e.g. CONFIG_VENDOR_FOO) which are enabled by default, so
that updating your old configuration using "make olddefconfig" is enough
to update it.

What I'm understanding from your proposed change is not to support
KernelCI, but to support Chromebooks by default. This could make more
sense if that's a relevant platform whose support is currently limited
by default, I'm not able to judge that, but at least it seems to me
this would make more sense than having specific configs for KernelCI.

Just my 2 cents,
Willy

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Guillaume Tucker]

On 12/10/2020 04:58, Willy Tarreau wrote:
> Hi Enric,
> 
> On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
>> For arm64 (i.e : arm64_defconfig):
>>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch, and as he did a
>> grep, the patch modifies all the defconfigs.
>>     2. The patch is accepted and merged in linux-next.
>>     3. KernelCI builds linux-next, boots the kernel on the hardware and all the
>> tests continue passing.
>>
>>
>> For x86:
>>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch and as he did a grep
>> the patches modifies all the defconfigs.
>>     2. The patch is accepted and merged in linux-next.
>>     3. KernelCI builds linux-next, boots the kernel on the hardware, and some
>> tests start to fail or are skipped.
>>     4. The maintainer is noticed about the behavior change, so he will need to
>> look at the problem, and find it.
>>     5. The maintainer sends a patch.
>>     6. The patch is accepted, but he needs to tag the release as per kernel <
>> x.y.z version it should use CONFIG_A and for kernel > x.y.z it should pick
>> CONFIG_AB.
>>     7. KernelCI builds linux-next, boots the kernel on the hardware and all the
>> tests pass again.
> 
> Previously I thought I understood your needs, but now I don't anymore. You
> seem to be saying that you're not testing *anything* outside of defconfig,
> and that as such you'd like defconfig to be complete enough to provide good
> coverage. This sounds a bit odd to me. And what if in the arm64 case, the
> CONFIG_YOUR_V4L2_DEVICE is *not* added to defconfig ? You're in the same
> situation.
> 
> We all know it's not fun to have to deal with local config snippets, but
> as soon as you plan to boot on a specific hardware, this is unavoidable.
> Also, config symbols are rarely renamed. Most often they are moved under
> new entries (e.g. CONFIG_VENDOR_FOO) which are enabled by default, so
> that updating your old configuration using "make olddefconfig" is enough
> to update it.
> 
> What I'm understanding from your proposed change is not to support
> KernelCI, but to support Chromebooks by default. This could make more
> sense if that's a relevant platform whose support is currently limited
> by default, I'm not able to judge that, but at least it seems to me
> this would make more sense than having specific configs for KernelCI.

This is correct, KernelCI doesn't really need these configs to be
upstreamed.  It's useful as Enric pointed out, but there are
already several specific config fragments being managed by the
KernelCI build system as one would expect, and we can take care
of one more if need be.

However, it was found while adding some x86 Chromebooks[1] to
KernelCI that x86_64_defconfig lacked some basic things for
anyone to be able to boot a kernel with a serial console enabled
on those.  That is what this patch is really about.  When doing
upstream kernel development and building your own kernel, it is
obviously a very useful thing to have.

Agreed, it is easy enough for a developer to turn these configs
on when required.  But it's not entirely trivial to find out
which configs to turn on, especially when you don't have access
to the kernel log.  I went through the Chrome OS 4.14 kernel
config fragments to get there.  Everyone would probably not
agree, but it does seem to me that the convenience of having it
upstream outweighs the costs.

If it's about size or performance, anyone can compare the kernel
image sizes and other things with the KernelCI (staging) build
artifacts based on v5.9[2].

As mentioned earlier in this thread, there aren't any written
rules about what goes into x86_64_defconfig and what does not.
Based on past history, and looking at it from a developer's point
of view rather than KernelCI, does it make sense in this case?

Thanks,
Guillaume


[1] HP Intel x360 "octopus" and AMD 11A-G6-EE "grunt":
    https://staging.kernelci.org/test/plan/id/5f8101a97ba4fdae00cafbb0/
    https://staging.kernelci.org/test/plan/id/5f81003f56c3586920cafbb4/

[2] Plain x86_64_defconfig:
    https://storage.staging.kernelci.org/kernelci/staging-mainline/staging-mainline-20201011.0/x86_64/x86_64_defconfig/gcc-8/
    with "x86 Chromebook" fragment:
    https://storage.staging.kernelci.org/kernelci/staging-mainline/staging-mainline-20201011.0/x86_64/x86_64_defconfig+x86-chromebook/gcc-8/

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Mon, Oct 12, 2020 at 11:22:10AM +0100, Guillaume Tucker wrote:
> However, it was found while adding some x86 Chromebooks[1] to
> KernelCI that x86_64_defconfig lacked some basic things for
> anyone to be able to boot a kernel with a serial console enabled
> on those.

Hold on, those are laptops, right? How come they do have serial console?
Because laptops don't have serial console - that has been the eternal
problem with debugging kernels on laptops. Or do they do some sort of
serial over USB emulation and this is something which only chromebooks
have?

Or is that how it is done:

https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/serial-debugging-howto

?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Willy Tarreau]

On Mon, Oct 12, 2020 at 04:32:12PM +0200, Borislav Petkov wrote:
> On Mon, Oct 12, 2020 at 11:22:10AM +0100, Guillaume Tucker wrote:
> > However, it was found while adding some x86 Chromebooks[1] to
> > KernelCI that x86_64_defconfig lacked some basic things for
> > anyone to be able to boot a kernel with a serial console enabled
> > on those.
> 
> Hold on, those are laptops, right? How come they do have serial console?
> Because laptops don't have serial console - that has been the eternal
> problem with debugging kernels on laptops.

Well, to be precise, they don't have *anymore*. I used to exclusively
select laptops having a serial port given that I was using it daily with
routers, until I had to resign when I abandonned my good old NC8000 :-/

Willy

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Guillaume Tucker]

On 12/10/2020 15:40, Willy Tarreau wrote:
> On Mon, Oct 12, 2020 at 04:32:12PM +0200, Borislav Petkov wrote:
>> On Mon, Oct 12, 2020 at 11:22:10AM +0100, Guillaume Tucker wrote:
>>> However, it was found while adding some x86 Chromebooks[1] to
>>> KernelCI that x86_64_defconfig lacked some basic things for
>>> anyone to be able to boot a kernel with a serial console enabled
>>> on those.
>>
>> Hold on, those are laptops, right? How come they do have serial console?
>> Because laptops don't have serial console - that has been the eternal
>> problem with debugging kernels on laptops.

Yes the link you pointed at is a prerequisite to enable serial
console in the firmware (Coreboot/Depthcharge).

> Well, to be precise, they don't have *anymore*. I used to exclusively
> select laptops having a serial port given that I was using it daily with
> routers, until I had to resign when I abandonned my good old NC8000 :-/

You can get serial console on recent enough Chromebooks with a
debug interface such as SuzyQable:

  https://www.sparkfun.com/products/14746

It's not a USB Type-C adapter, it has a debug interface which
works with Chromebooks that support Case-Closed Debugging.
Anyone can do that without modifying the Chromebook, and with a
bit of patience to go through the documentation[1]...

The KernelCI sample results from my previous email were run using
just that: off-the-shelf Chromebooks + SuzyQ + rebuilt firmware
for interactive console and tftp boot + kernel with the config
options in Enric's patch.

Thanks,
Guillaume


[1] https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Mon, Oct 12, 2020 at 04:40:40PM +0200, Willy Tarreau wrote:
> Well, to be precise, they don't have *anymore*. I used to exclusively
> select laptops having a serial port given that I was using it daily with
> routers, until I had to resign when I abandonned my good old NC8000 :-/

Yah, with all those new features crap they add to modern laptops, you'd
think they put in a serial port for 2¢ but nope... ;-\

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Borislav Petkov]

On Mon, Oct 12, 2020 at 04:10:45PM +0100, Guillaume Tucker wrote:
> You can get serial console on recent enough Chromebooks with a
> debug interface such as SuzyQable:
> 
>   https://www.sparkfun.com/products/14746
> 
> It's not a USB Type-C adapter, it has a debug interface which
> works with Chromebooks that support Case-Closed Debugging.
> Anyone can do that without modifying the Chromebook, and with a
> bit of patience to go through the documentation[1]...
> 
> The KernelCI sample results from my previous email were run using
> just that: off-the-shelf Chromebooks + SuzyQ + rebuilt firmware
> for interactive console and tftp boot + kernel with the config
> options in Enric's patch.

That sounds interesting, thanks for elaborating.

At the same time, you see how this setup is very hw-specific and not
really common and those options do not really belong in a defconfig but
in a kernelCI snippet, I'd say.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Nick Desaulniers]

On Mon, Oct 12, 2020 at 8:10 AM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
>
> On 12/10/2020 15:40, Willy Tarreau wrote:
> > On Mon, Oct 12, 2020 at 04:32:12PM +0200, Borislav Petkov wrote:
> >> On Mon, Oct 12, 2020 at 11:22:10AM +0100, Guillaume Tucker wrote:
> >>> However, it was found while adding some x86 Chromebooks[1] to
> >>> KernelCI that x86_64_defconfig lacked some basic things for
> >>> anyone to be able to boot a kernel with a serial console enabled
> >>> on those.
> >>
> >> Hold on, those are laptops, right? How come they do have serial console?
> >> Because laptops don't have serial console - that has been the eternal
> >> problem with debugging kernels on laptops.
>
> Yes the link you pointed at is a prerequisite to enable serial
> console in the firmware (Coreboot/Depthcharge).
>
> > Well, to be precise, they don't have *anymore*. I used to exclusively
> > select laptops having a serial port given that I was using it daily with
> > routers, until I had to resign when I abandonned my good old NC8000 :-/
>
> You can get serial console on recent enough Chromebooks with a
> debug interface such as SuzyQable:
>
>   https://www.sparkfun.com/products/14746
>
> It's not a USB Type-C adapter, it has a debug interface which
> works with Chromebooks that support Case-Closed Debugging.
> Anyone can do that without modifying the Chromebook, and with a
> bit of patience to go through the documentation[1]...
>
> The KernelCI sample results from my previous email were run using
> just that: off-the-shelf Chromebooks + SuzyQ + rebuilt firmware
> for interactive console and tftp boot + kernel with the config
> options in Enric's patch.
>
> Thanks,
> Guillaume
>
>
> [1] https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md

Thanks for the links, I've just now ordered one.  For the open case
debugging, we have some custom daughter board with a ribbon cable.
It's...not pretty.  I didn't know we had closed case debugging on
CrOS.

-- 
Thanks,
~Nick Desaulniers