Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linux configs: cleanup #1528

Merged
merged 3 commits into from Apr 18, 2017

Conversation

@MilhouseVH
Copy link
Contributor

commented Apr 13, 2017

I've run make oldconfig on all projects and accepted the defaults.

These are the differences:

  1. All projects: Enable NFS and CIFS kernel file caching, with SMB2 and (when available) SMB3 support
  2. x86: Enable additional options (PERF_EVENTS_AMD_POWER, SND_DRIVERS, DRM_DP_AUX_CHARDEV, I2C_DESIGNWARE_BAYTRAIL)
  3. x86: Drop MEMSTICK support, enable MMC_SDHCI_PLTFM
  4. x86 & WeTek_Play: Enable CONFIG_RESET_CONTROLLER (sync with other projects)
  5. WeTek_Core: Fix CONFIG_CPU_FREQ_DEFAULT_GOV_HOTPLUG typo
  6. Several projects are missing CONFIG_FB_MODE_HELPERS=y which is selected by CONFIG_FB_UDL in #1087
  7. Drop any other other obsolete options (eg. CONFIG_INITRAMFS_ROOT_UID etc.)

Would be good if all project maintainers could take a look and comment if they have any concerns.

I'll include these changes in RPi/RPi2/Generic test builds - if no issues/concerns, merge in a week or so?

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2017

wy would amlogic hardware need CONFIG_FB_MODE_HELPERS ?

@MilhouseVH

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2017

As mentioned, because of #1087 - CONFIG_FB_MODE_HELPERS=y is now a default.

(Perhaps the question is why has CONFIG_FB_UDL been enabled for amlogic?)

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2017

yep. I doubt CONFIG_FB_UDL works or has any use case on amlogic.

EDIT: I dont think it works on rpi either, but well.. however

@MilhouseVH

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2017

OK I'll remove it from WeTek_* and update. Thanks.

@MilhouseVH

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2017

Updated.

@MilhouseVH

This comment has been minimized.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

I believe CONFIG_FB_UDL does work for console framebuffer on pi, but not for firmware driven openGL ES. So I don't believe anyone would car if removed for LE.

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

i dont know why for RPI they this enabled

but that was here #1087
display link working from USB 3.0 in my knowledge ...

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

@nahun are you actually using USB display link display with LE on Pi?

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

i just got USB-C adapter to HDMI but i got error

[ 4341.650172] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[ 4341.650177] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
[ 4341.650179] pcieport 0000:00:1c.0: device [8086:9d10] error status/mask=00000001/00002000
[ 4341.650180] pcieport 0000:00:1c.0: [ 0] Receiver Error (First)

i will check if some other config kernel changes are needed

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

the stupid thing only makes sense on x86 with drm/x11 and good usb3 usb controller. just remove it.

@nahun

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

No I couldn't get it to work, definitely can be removed.

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

i tested again on cold boot with connected USB-C adapter and boots fine with picture on screen :)
so for x86 please leave that.

"[ 54.417539] [drm:intel_dp_read_desc] DP branch: OUI 00-1c-f8 dev-ID 171GB0 HW-rev 0.1 SW-rev 15.29"

@MilhouseVH

This comment has been minimized.

Copy link
Contributor Author

commented Apr 14, 2017

Updated with additional commit dropping FB_UDL from RPi/RPi2/Odroid_C2/imx6.

CONFIG_FB_MODE_HELPERS=y remains in imx6/4.4-xbian config as it is selected by CONFIG_FB_MXC=y.

This leaves FB_UDL enabled only for Generic.

@piotrasd you commented on #1087:

for generic please enable also DRM_UDL=m ;)

that change wthout DRM for UDL dont will works on Generic, im tested once DisplayLink - USB3.0 to HDMI cable/adapter and worked with DRM_UDL=m/y, otherwise is no point to merge that for rest project if not will work

Is DRM_UDL=m still required for FB_UDL to work on Generic? Currently DRM_UDL is not set, do you have it enabled in your build?

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

i will confirm by check official Generic build

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2017

after test on latest official LE 8.0.1 where "DRM_UDL is not set" - USB-C to HDMI adapter working ;)

@MilhouseVH MilhouseVH force-pushed the MilhouseVH:config_cleanup branch from 0c27c33 to c05dc46 Apr 15, 2017
@MilhouseVH

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2017

Rebased after #1533.

@lrusak
lrusak approved these changes Apr 18, 2017
@lrusak lrusak merged commit c7b1990 into LibreELEC:master Apr 18, 2017
@vpeter4

This comment has been minimized.

Copy link
Contributor

commented on projects/imx6/linux/4.4-xbian/linux.arm.conf in b9c9792 May 4, 2017

Just for the info: This two options are still needed to build kernel without user intervention.
Will fix myself.

This comment has been minimized.

Copy link
Contributor Author

replied May 4, 2017

You mean the two above, CONFIG_ZONE_DMA and CONFIG_INITRAMFS_ROOT_UID? That's odd, as they were removed by make oldconfig when using the 4.4-xbian config at the time of this PR - are you including any additional patches that require these options? I've just checked make oldconfig again, using the current 4.4-xbian/linux.arm.conf on master, and there are no prompts/changes to the config.

This comment has been minimized.

Copy link
Contributor

replied May 4, 2017

I don't have any extra patches which would require this.
And I meant CONFIG_INITRAMFS_ROOT_UID/GID.
When running ./scripts/build linux this happen to set value because they are missing from config:

Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y
  Initramfs source file(s) (INITRAMFS_SOURCE) [path to image/initramfs.cpio] path to image/initramfs.cpio
    User ID to map to 0 (user root) (INITRAMFS_ROOT_UID) [0] (NEW) 

Don't know why oldconfig removes it. At first I though because of missing ARCH=arm but it s not that. And I also see that oldconfig is already called from linux package.mk in pre_make_target() function.

This comment has been minimized.

Copy link
Contributor Author

replied May 4, 2017

Ah, because CONFIG_INITRAMFS_SOURCE="" (in master) however this value is changed during the build, which then selects

CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0

due to:

config INITRAMFS_ROOT_UID
        int "User ID to map to 0 (user root)"
        depends on INITRAMFS_SOURCE!=""
        default "0"
        help
          This setting is only meaningful if the INITRAMFS_SOURCE is
          contains a directory.  Setting this user ID (UID) to something
          other than "0" will cause all files owned by that UID to be
          owned by user root in the initial ramdisk image.

          If you are not sure, leave it set to "0".

config INITRAMFS_ROOT_GID
        int "Group ID to map to 0 (group root)"
        depends on INITRAMFS_SOURCE!=""
        default "0"
        help
          This setting is only meaningful if the INITRAMFS_SOURCE is
          contains a directory.  Setting this group ID (GID) to something
          other than "0" will cause all files owned by that GID to be
          owned by group root in the initial ramdisk image.

          If you are not sure, leave it set to "0".

in usr/Kconfig.

I'll push a PR to fix this unless you already have something? Apologies for not catching this.

This comment has been minimized.

Copy link
Contributor

replied May 4, 2017

Nice catch!
You can send PR for this if you want. I'm still investigating some other thing which would required kernel config change and I meant to send everything at once.

This comment has been minimized.

Copy link
Contributor

replied May 4, 2017

Well...

Can you also check Odroid C2 project? I see same change there?

This comment has been minimized.

Copy link
Contributor Author

replied May 4, 2017

Yep, will do. Similar issue.

This comment has been minimized.

Copy link
Contributor Author

replied May 4, 2017

I also know why this only affects imx6/Odroid_C2 - it's because in these two projects we have

CONFIG_INITRAMFS_SOURCE=""

whereas in all the other projects, it is:

CONFIG_INITRAMFS_SOURCE=" "

Note the space which then causes GID/UID to be selected (as INITRAMFS_SOURCE!="").

I'll also add the space to imx6/Odroid_C2 - let me know if this causes any problems.

This comment has been minimized.

Copy link
Contributor

replied May 4, 2017

Having space is fine.

This comment has been minimized.

Copy link
Contributor Author

replied May 4, 2017

Fixed in #1594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.