- Aarch64-laptops - lists.linaro.org

Lenovo Miix 630 possible hardware issue verification

by russianneuromancer＠ya.ru

Hello! I received Lenovo Miix 630-12Q35 today, and to my surprise, there is no audio even in preinstalled system, even after OS reset via Troubleshooting section of Windows bootloader. As "Qualcomm(R) Aqstic(TM)" and "Qualcomm Audio DSP Subsystem Device" devices is preset in "System devices" section of Device Manager, and there is no errors from these two drivers, I believe this could be a software issue with Qualcomm drivers for Windows. I tried to add "Qualcomm(R) Aqstic(TM)" (as Sound device, not System device) manually (via "Action" > "Add legacy hardware" menu item in Device Manager) but this does not help - Aqstic audio inputs/output does not appear in Device Manager, so it's still impossible to verify if audio actually working or not. Obviously, I don't want to keep the defective unit on hands and would like to find out if audio hardware actually works, or there is something broken in hardware which means audio stay non-working even when Qualcomm Aqstic get supported by aarch64-laptop project. So I wondering if there was any progress with Qualcomm Aqstic support in Linux on these laptops? Even if there are preliminary patches and UCM draft that allow testing at least part of hardware (speaker or microphone or audio jack) that would be a great help in this case, so I at least will be able to find if the hardware works.

4 years, 11 months

2
1
0 0

Freedreno for WebGL 2 on Firefox?

by Richard Henwood

Hi All, I'm looking at WebGL 2 on Firefox on my Lenovo C630. It seems that 'WebGL 1 Driver Renderer' is happy reporting 'freedreno -- FD630' and WebGL 1 Driver Version '3.1 Messa 19.2.1'. However, for WebGL 2, Firefox reports: WebGL creation failed: * tryNativeGL * Exhausted GL driver options. ... and marking driver version as '-'. I've played with forcing WebGL and disabling the Firefox sandbox so it can see various bits of the system, but it hasn't helped. Any suggestions? best regards, Richard -- Richard.Henwood(a)arm.com Server Software Eco-System Tel: +1 512 410 9612 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 11 months

2
2
0 0

FYI: 5.5RC-1 Ubuntu mainline kernel boots to GUI...

by Richard Henwood

Hi All, FYI: I installed both '*snapdragon*' and non-snapdragon kernels on my Lenovo Yoga C630 over the weekend from Ubuntu mainline: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.5-rc1/ They both booted to GUI which I was happy to observe and thought I would share here. The keyboard wasn't working, presumably because of: https://github.com/aarch64-laptops/build/issues/33 wifi, also wasn't working (although I have found it to be quite reliable on my 5.3 kernel recently.) best regards, Richard -- Richard.Henwood(a)arm.com Server Software Eco-System Tel: +1 512 410 9612 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

3
2
0 0

DtbLoader updates, and distro boot plan

by Rob Clark

Hi, I've updated my DtbLoader with what I think will be the final approach for dealing with the fact that all of these laptops can have one of several panels installed (I can resend the patchset to the aarch64- laptops list if that is useful): https://github.com/robclark/edk2/commits/dtbloader This is the third iteration of panel-picking, now using dtb overlays to patch the dtb according to which panel is installed on the laptop. I think this is the approach that will finally get upstream kernel buy-in, namely because it doesn't require any kernel patches. Because of the dtb overlay approach, for distro boot using DT, distro's will need to use DtbLoader, or handle applying the dtb overlay somewhere else. Overview ======== The patchset I have on top of Leif's original DtbLoader handle two things to make this a useful thing for distro boot, and in particular having a single image (or installer) which can support multiple laptops: 1) pick a device specific dtb based on SMBIOS tables 2) apply a panel specific dtb overlay based on UEFIDisplayInfo In particular, it tries to load dtb from (in order, paths relative to EFI system partition where DtbLoader is installed): 1) \dtb\$SysVendor\$ProductName-$BoardName.dtb 2) \dtb\$SysVendor\$ProductName.dtb and panel overlay dtb from: 1) \dtb\$SysVendor\$ProductName-$BoardName-panel-$PanelId.dtb 2) \dtb\$SysVendor\$ProductName-panel-$PanelId.dtb 3) \dtb\panels\panel-$PanelId.dtb with this in place, the correct dtb is loaded before grub starts, so from distro PoV it is all just a config table provided by the firmware. (Also, based on comments from Ard on IRC, it sounds like we'll also use DtbLoader to avoid needing the efi=novamap hack, which I assume is also useful to distros to avoid device specific hacks.) Installation ============ I've put a pre-built DtbLoader.efi here: https://people.freedesktop.org/~robclark/DtbLoader.efi 1) copy DtbLoader.efi to EFI system partition2) copy dtb files to EFI system partition with the layout described above 3) Boot Shell.efi (overwrite \EFI\BOOT\BOOTAA64.EFI with Shell.efi) 4) switch to boot device (FS2: in my case) 5) use bcfg to install Shell> fs2: FS2:\> bcfg driver add 1 \DtbLoader.efi "dtb loader" FS2:\> reset At this point you can copy normal shim back to \EFI\BOOT\BOOTAA64.EFI.. on subsequent reboots, efibootmgr will load DtbLoader.efi for you. Open Issues =========== 1) The path to DtbLoader.efi is stored with the full EFI devicepath.. so installer media would have to install/load it's own DtbLoader.efi and dtb files? Which is maybe suboptimal, especially for a laptop released after the installer media was baked. (The DtbLoader.efi shouldn't need to change, but a new laptop based on an already supported SoC would at least need new dtb tables) a) maybe the DtbLoader is installed before the user boots the install media.. but in this case, if distro is installing to internal disk and replacing the EFI partition, it would need to take care to preserve DtbLoader and the \dtb directory 2) How to handle dtb updates? Should the distro do this? Or is there some way we can use fwupd to push out dtb updates outside of distro? Or?? 3) Constructing the \dtb directory.. currently there isn't any link between dtb's that come out of kernel build, and where DtbLoader.efi expects to find things. I guess this is managable with a shell script for now. And if we push out dtb updates outside of the distro then it is really just a thing for whatever generates the "firmware update" package to care about. But if we have distro's updating the dtb files in the EFI system partition then we should come up with something better 4) ACPI vs DT boot? I guess this is easy, if DtbLoader doesn't find a dtb to load (ie. \dtb\LENOVO\81JL.dtb, etc), it doesn't change anything. So DtbLoader.efi should be safe to load on all aarch64 devices. 5) Secure-boot? Or at least not interfering with secure-boot support on devices using ACPI boot? I *guess* if DtbLoader.efi is not signed and BIOS is configured for secure-boot, then efibootmgr won't load it. So no-harm, no-foul? Anything else? BR, -R

5 years

2
2
0 0

[PATCH 0/4] drm+dt: multi panel selection and yoga c630 display

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> It is not uncommon for devices to use one of several possible panels. The Lenovo Yoga C630 laptop is one such device. This patchset introduces an optional "panel-id" property which can be used by the firmware to find the correct panel node to enable. The second patch adds support in drm/of to automatically pick the enabled endpoint, to avoid adding the same logic in multiple bridges/drivers. The last patch uses this mechanism to enable display support for the Yoga C630. An example usage: boe_panel { compatible = "boe,nv133fhm-n61"; panel-id = <0xc4>; /* fw will change status to "Ok" if this panel is installed */ status = "disabled"; ports { port { boe_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_boe>; }; }; }; }; ivo_panel { compatible = "ivo,m133nwf4-r0"; panel-id = <0xc5>; /* fw will change status to "Ok" if this panel is installed */ status = "disabled"; ports { port { ivo_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_ivo>; }; }; }; }; sn65dsi86: bridge@2c { compatible = "ti,sn65dsi86"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; sn65dsi86_in_a: endpoint { remote-endpoint = <&dsi0_out>; }; }; port@1 { reg = <1>; sn65dsi86_out_boe: endpoint@c4 { remote-endpoint = <&boe_panel_in_edp>; }; sn65dsi86_out_ivo: endpoint@c5 { remote-endpoint = <&ivo_panel_in_edp>; }; }; }; }; This replaces an earlier proposal[1] to use chosen/panel-id to select the installed panel, in favor of adding support[2] to an EFI driver module (DtbLoader.efi) to find the installed panel, locate it in dtb via the 'panel-id' property, and update it's status to "Ok". [1] https://patchwork.kernel.org/cover/11024613/ [2] https://github.com/robclark/edk2/commits/dtbloader In this case, DtbLoader, which is somewhat generic (ie. this mechanism applies to all snapdragon based devices which orignally ship with windows), determines the panel-id of the installed panel from the UEFIDisplayInfo variable. As I understand, a similar situation exists with the pine64 laptops. A similar scheme could be used to support this, by loading the panel-id from a u-boot variable. In other cases (phones), a more device specific shim would be needed to determine the panel-id by reading some GPIOs, or some other more device- specific mechanism. Bjorn Andersson (1): arm64: dts: qcom: c630: Enable display Rob Clark (3): dt-bindings: display: panel: document panel-id drm/of: add support to find any enabled endpoint drm/bridge: ti-sn65dsi86: find any enabled endpoint .../bindings/display/panel/panel-common.yaml | 26 +++ .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 165 ++++++++++++++++++ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/drm_of.c | 41 ++++- 4 files changed, 232 insertions(+), 2 deletions(-) -- 2.23.0

5 years

4
15
0 0

[PATCH 0/4] drm+dt+efi: support devices with multiple possible panels

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> Now that we can deal gracefully with bootloader (firmware) initialized display on aarch64 laptops[1], the next step is to deal with the fact that the same model of laptop can have one of multiple different panels. (For the yoga c630 that I have, I know of at least two possible panels, there might be a third.) This is actually a scenario that comes up frequently in phones and tablets as well, so it is useful to have an upstream solution for this. The basic idea is to add a 'panel-id' property in dt chosen node, and use that to pick the endpoint we look at when loading the panel driver, e.g. / { chosen { panel-id = <0xc4>; }; ivo_panel { compatible = "ivo,m133nwf4-r0"; power-supply = <&vlcm_3v3>; no-hpd; ports { port { ivo_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_ivo>; }; }; }; }; boe_panel { compatible = "boe,nv133fhm-n61"; power-supply = <&vlcm_3v3>; no-hpd; ports { port { boe_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out_boe>; }; }; }; }; sn65dsi86: bridge@2c { compatible = "ti,sn65dsi86"; ... ports { #address-cells = <1>; #size-cells = <0>; ... port@1 { #address-cells = <1>; #size-cells = <0>; reg = <1>; endpoint@c4 { reg = <0xc4>; remote-endpoint = <&boe_panel_in_edp>; }; endpoint@c5 { reg = <0xc5>; remote-endpoint = <&ivo_panel_in_edp>; }; }; }; } }; Note that the panel-id is potentially a sparse-int. The values I've seen so far on aarch64 laptops are: * 0xc2 * 0xc3 * 0xc4 * 0xc5 * 0x8011 * 0x8012 * 0x8055 * 0x8056 At least on snapdragon aarch64 laptops, they can be any u32 value. However, on these laptops, the bootloader/firmware is not populating the chosen node, but instead providing an "UEFIDisplayInfo" variable, which contains the panel id. Unfortunately EFI variables are only available before ExitBootServices, so the second patch checks for this variable before EBS and populates the /chosen/panel-id variable. [1] https://patchwork.freedesktop.org/series/63001/ Rob Clark (4): dt-bindings: chosen: document panel-id binding efi/libstub: detect panel-id drm: add helper to lookup panel-id drm/bridge: ti-sn65dsi86: use helper to lookup panel-id Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++ drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++ drivers/firmware/efi/libstub/efistub.h | 2 + drivers/firmware/efi/libstub/fdt.c | 9 +++ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +- drivers/gpu/drm/drm_of.c | 21 ++++++ include/drm/drm_of.h | 7 ++ 7 files changed, 160 insertions(+), 2 deletions(-) -- 2.20.1

5 years

6
28
0 0

[PATCH 0/5] DtbLoader: panel-id and dtb picking support

by Rob Clark

This patchset builds on top of Leif's DtbLoader, adding support to pick a laptop specific dtb based on SMBIOS tables, and patching for /chosen/panel-id based on UEFIDisplayInfo. I'll send a new version of the kernel side patchset that uses /chosen/panel-id to pick the appropriate panel driver in the near future (ie. I'll probably get to it tomorrow) Rob Clark (5): DtbLoader: refactor out helper to try loading dtb DtbLoader: Try to pick dtb based on SMBIOS tables DtbLoader: move CRC calculation DtbLoader: resize fdt DtbLoader: add panel-id detection/fixup for qcom devices .../Application/ConfigTableLoader/Common.h | 2 + .../Application/ConfigTableLoader/DtbLoader.c | 437 +++++++++++++++--- .../ConfigTableLoader/DtbLoader.inf | 2 + .../Application/ConfigTableLoader/Qcom.c | 94 ++++ .../Application/ConfigTableLoader/Qcom.h | 30 ++ 5 files changed, 506 insertions(+), 59 deletions(-) create mode 100644 EmbeddedPkg/Application/ConfigTableLoader/Qcom.c create mode 100644 EmbeddedPkg/Application/ConfigTableLoader/Qcom.h -- 2.23.0

5 years

1
5
0 0

Adding devicetree command to grub

by Jeffrey Hugo

I'm curious, how have folks been adding the devicetree command to the grub menu entry? So far I've been manually editing the grub.cfg since that worked well with my development flow, but now things have changed a bit for me, and I'm looking for a way that it would be appended automatically when the config is autogenerated when installing a new kernel. -Jeff

5 years, 2 months

4
3
0 0

is anyone running Debian?

by Richard Henwood

hi All, Is anyone running Debian user-space on a Yoga C630 or similar machine? I am interested in understanding how you got it to work and if you have written about your experience anywhere. best regards, Richard -- Richard.Henwood(a)arm.com Server Software Eco-System IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 3 months

6
7
0 0

Yoga c630 won't boot from "enabled installer"

by David

I was able to get the Lenovo C630 to boot from the flash drive and have the trackpad work. Awesome! I'm now thinking the build looks good enough to install on the UFS drive. I tried the "enabled installer". I've updated WIndows. There are no pending updates. I've shrunk the partiion. I"m not running S mode I've disabled secure boot. I used Dimitri's Bionic installer. md5sum bde45aa67f19333955d00349aa6b2077 I flashed the installer onto a USB stick using gnome-disks WIth the flash drive in the left USB-C port, it boots straight to Windows. This is the same machine that was booting successfully from the flash drive into Linux. Any ideas? Is there a way to copy the flash drive image that does work onto the UFS drive? Thanks

5 years, 3 months

3
5
0 0

2024

2023

2022

2021

2020

2019

Aarch64-laptops