scarlet/kevin: Create an environment for video and camera testing on upstream kernels |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionCreating this bug to track any changes needed to get a bootable and usable Chromium OS image on scarlet and kevin running an upstream kernel. The two things discovered until now are: - kernel config options for the Kingdisplay MIPI DSI panel missing in the fallback rockchip64_defconfig, - portage overrides needed to install media-libs/mesa with LLVMpipe and its dependencies (e.g. sys-devel/llvm) instead of the proprietary graphics stack.
,
Nov 22
Tracking any related CLs with this gerrit hashtag: https://chromium-review.googlesource.com/q/hashtag:%22scarlet-upstream%22+(status:open%20OR%20status:merged)
,
Nov 22
With all the CLs from the topic in #2 and with attached kernel patches on top of latest linux-next, building and flashing scarlet-upstream gives me a usable system that I can sign in to.
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/mesa/+/99760adafdb41739ee2b181827e71796ba7b202f commit 99760adafdb41739ee2b181827e71796ba7b202f Author: Ray Strode <rstrode@redhat.com> Date: Fri Nov 23 03:07:55 2018 UPSTREAM: gallium/winsys/kms: don't unmap what wasn't mapped At the moment, depending on pipe transfer flags, the dumb buffer map address can end up at either kms_sw_dt->ro_mapped or kms_sw_dt->mapped. When it's time to unmap the dumb buffer, both locations get unmapped, even though one is probably initialized to 0. That leads to the code segment getting unmapped at runtime and crashes when trying to call into unrelated code. This commit addresses the problem by using MAP_FAILED instead of NULL for ro_mapped and mapped when the dumb buffer is unmapped, and only unmapping mapped addresses at unmap time. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107098 Signed-off-by: Ray Strode <rstrode@redhat.com> Fixes: d891f28df9a ("gallium/winsys/kms: Fix possible leak in map/unmap.") Cc: Lepton Wu <lepton@chromium.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 9baff597ce021f7691187b0d1d1bbc16d07b13e1) BUG=chromium:907715 TEST=llvmpipe does not crash on scarlet anymore Change-Id: I4b218d1dd0419ff3ef691179b75c6fcf91244882 Signed-off-by: Tomasz Figa <tfiga@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1343916 Reviewed-by: Lepton Wu <lepton@chromium.org> [modify] https://crrev.com/99760adafdb41739ee2b181827e71796ba7b202f/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/fd6b158722ed88bf0252b8cf04120c6549d9ec02 commit fd6b158722ed88bf0252b8cf04120c6549d9ec02 Author: Tomasz Figa <tfiga@chromium.org> Date: Fri Nov 23 03:07:40 2018 media-libs/mesa: Fix spurious munmaps when kms-swrast is used Add a patch to cherry pick an upstream commit that fixes the problem: 9baff597ce0 ("gallium/winsys/kms: don't unmap what wasn't mapped") BUG=chromium:907715 TEST=llvmpipe does not crash anymore on scarlet Change-Id: Ia14c92b4135c5a7e9285ab1d332b3c6124fb3dc6 Reviewed-on: https://chromium-review.googlesource.com/1343917 Commit-Ready: Tomasz Figa <tfiga@chromium.org> Tested-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Lepton Wu <lepton@chromium.org> [modify] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-9999.ebuild [modify] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-18.2_pre1.ebuild [rename] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-18.2_pre1-r25.ebuild [add] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/files/18.2-gallium-winsys-kms-dont-unmap-what-wasnt-mapped.patch
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/4f1c6852a110e55171af3c899d9f517b7e76d075 commit 4f1c6852a110e55171af3c899d9f517b7e76d075 Author: Tomasz Figa <tfiga@chromium.org> Date: Fri Nov 23 03:07:40 2018 eclass/cros-kernel: Enable Kingdisplay config options in rockchip64_defconfig Some variants of Scarlet are equipped with a MIPI DSI display by Kingdisplay. Add necessary config options to rockchip64_defconfig. BUG=chromium:907715 TEST=Display lights up with upstream kernel on a Kingdisplay Scarlet Change-Id: Ida76fd2c81f5795d6b616d17ffd577bc78de8ac4 Reviewed-on: https://chromium-review.googlesource.com/1343918 Commit-Ready: Tomasz Figa <tfiga@chromium.org> Tested-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> [modify] https://crrev.com/4f1c6852a110e55171af3c899d9f517b7e76d075/eclass/cros-kernel/rockchip64_defconfig
,
Nov 27
Doug suggested an idea of just setting the appropriate environment variables in the chroot and then use the regular workflow (build_packages, build_image, any manual emerges, etc.). It needs one CL to pull Mesa instead of the proprietary graphics libraries when LLVMpipe is enabled, but otherwise works really well and doesn't seem to require too many rebuilds from an already build Chrome OS for given board. Thanks Doug for the nice idea. The current instructions are: 1) Cherry pick the CLs in https://chromium-review.googlesource.com/q/hashtag:%2522scarlet-upstream%2522+status:open (for anyone with internal checkout also: https://chrome-internal-review.googlesource.com/q/hashtag:%2522scarlet-upstream%2522+status:open), 2) export VIDEO_CARDS=llvmpipe, 3) for scarlet: export USE="llvm llvm_targets_ARM gpu_sandbox_failures_not_fatal -gpu_sandbox_start_early -tpm2 mocktpm" for kevin: USE="llvm llvm_targets_ARM gpu_sandbox_failures_not_fatal -gpu_sandbox_start_early", 4) check out your upstream branch of choice to src/third_party/kernel/v4.4, 5) apply the patches from comment #3, 6) cros_workon-$BOARD start minigbm chromeos-kernel-4_4, 7) follow the regular Chrome OS build flow, flash the image and get a working Chrome OS image on an (almost clean) upstream kernel. Then you can just make any changes in the kernel and follow the normal emerge-$BOARD chromeos-kernel-4_4 && ./update_kernel.sh [...] workflow, or whatever you normally use with Chrome OS, to update the kernel on the device.
,
Nov 27
,
Nov 27
Also, that was tested on Scarlet. I'm going to try on Kevin as well. Ezequiel reported that some display-related configs are missing from rockchip64_defconfig [1] and also USB devices not being detected (?). [1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/rockchip64_defconfig
,
Nov 27
,
Nov 27
Correction. In 2), it should be: export VIDEO_CARDS="llvmpipe rockchip" I just tested on my kevin and with some additions to rockchip64_defconfig (included in the cherry picks from 1)), both display and USB seem to work - I can SSH to the device over a USB ethernet.
,
Nov 30
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/eb9f1c352678d44ba2e624f65b98a73cfc26a57d commit eb9f1c352678d44ba2e624f65b98a73cfc26a57d Author: Tomasz Figa <tfiga@chromium.org> Date: Fri Nov 30 00:09:05 2018 eclass/cros-kernel: Enable Analogix DP bridge in rockchip64_defconfig The display on Kevin is routed via an Analogix DP bridge built into the SoC. Add necessary config options to rockchip64_defconfig. BUG=chromium:907715 TEST=Display lights up with upstream kernel on a kevin Change-Id: I464ffc2b766641ef70e98a7481ae81a0113b2166 Reviewed-on: https://chromium-review.googlesource.com/1351313 Commit-Ready: Douglas Anderson <dianders@chromium.org> Tested-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org> [modify] https://crrev.com/eb9f1c352678d44ba2e624f65b98a73cfc26a57d/eclass/cros-kernel/rockchip64_defconfig
,
Nov 30
For the record: Be careful with using Kevin on 4.19+. It's easy to get your Wifi into a deadlock: https://patchwork.kernel.org/patch/10706959/ [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage" *SMH* Hopefully that will get merged quickly.
,
Dec 5
Does anyone actually have Scarlet + K&D display working on 4.20-rc+? I'm using the DTS from rockchip/for-next, but I keep getting this super-helpful probe deferral loop: [ 24.576726] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff8008a72b60) [ 24.587245] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff8008a72b60) [ 24.596622] panel-kingdisplay-kd097d04 ff960000.mipi.0: Linked as a consumer to regulator.4 [ 24.606065] rockchip-drm display-subsystem: bound ff960000.mipi (ops 0xffffff8008a75320) [ 24.615234] rockchip-drm display-subsystem: failed to bind ff968000.mipi (ops 0xffffff8008a75320): -517 [ 24.625840] panel-kingdisplay-kd097d04 ff960000.mipi.0: Dropping the link to regulator.4 [ 24.635077] rockchip-drm display-subsystem: master bind failed: -517 [ 24.645403] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff8008a72b60) [ 24.655938] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff8008a72b60) [ 24.665307] panel-kingdisplay-kd097d04 ff960000.mipi.0: Linked as a consumer to regulator.4 [ 24.674768] rockchip-drm display-subsystem: bound ff960000.mipi (ops 0xffffff8008a75320) [ 24.683942] rockchip-drm display-subsystem: failed to bind ff968000.mipi (ops 0xffffff8008a75320): -517 It appears to be an infinite loop. I'm impressed. (A red herring: audio also was stuck in a probe deferral, but disabling it doesn't help. It appears the display subsystem is looping all by itself.)
,
Dec 5
Ah, the dual MIPI stuff was only in -next. (It still sucks that DRM can put itself in an infinite deferral loop like that though.) With pulling the appropriate bits from drm-next, I have things working.
,
Dec 5
517 is EPROBEDEFER. That means keep trying, so the loop isn't surprising. There maybe a bad dependency loop - a depends on b depends on c depends on a or similar.
,
Dec 11
,
Dec 12
Updated the kernel patches to work with recent linux-next.
,
Dec 13
I had to add this to get audio: diff --git a/eclass/cros-kernel/rockchip64_defconfig b/eclass/cros-kernel/rockchip64_defconfig index 8b082c1438b0..9a5aeeaba095 100644 --- a/eclass/cros-kernel/rockchip64_defconfig +++ b/eclass/cros-kernel/rockchip64_defconfig @@ -346,7 +346,7 @@ CONFIG_DRM_BRIDGE=y CONFIG_DRM_PANEL_BRIDGE=y CONFIG_DRM_ROCKCHIP=y CONFIG_ROCKCHIP_ANALOGIX_DP=y -CONFIG_DRM_ROCKCHIP_CDN_DP=y +CONFIG_ROCKCHIP_CDN_DP=y CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_BACKLIGHT_LCD_SUPPORT=y
,
Dec 21
Just FYI, IIRC acourbot@ had some problems with recent linux-next, so here's my last known good tag: next-20181127. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by tfiga@chromium.org
, Nov 22