Hi All,
I have Ubuntu installed from Dmitri's installer. update-grub2 works
well from that OS. I now have Fedora Rawhide in a separate partition
and I would like to do have Fedora take over efi management. I have
read through a bit about EFI management on Linux and it looks like
efibootmgr is the primary tool.
Using efibootmgr from both Ubuntu 19.10 and Fedora Rawhide and I get
identical errors:
$ efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\fedora\\grubaa64.efi -L
skipping unreadable variable "Boot0000": Invalid argument
Could not prepare Boot variable: Invalid argument
Does anyone have a suggestion for the next steps for me to try?
best regards,
Richard
--
Richard.Henwood(a)arm.com
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.
Hi All,
A fellow laptop user has been looking into efi=novamap requirement. I
was sharing with him that I thought only firmware could solve this
problem and he has questioned me on that assertion and pointed me to
this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46…
It appears from my reading that efi=novamap is required because: It is
fiddly to make the kernel function SetVirtualAddressMap() work
correctly on AArch64. Without documentation for the laptops I care
about, it does not appear to be a valuable use of time to make
SetVirtualAddressMap() work. For now, efi=novamap is a good-enough
work-around.
Is that more a more accurate analysis on my part?
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.
Hi all,
I am playing with the Fedora Rawhide aarch64 kernel on my lenovo c630. Today this is a 5.6 kernel. I guess it is missing some config options stuff because the laptop keyboard isn't available. It also seems like systemd userspace is pretty unhappy too, but that is seconday to the keyboard for me currently.
I haven't spent time looking though the know working configs that are already available, but appealing to the knowledge on this list: are there some kernel config options folks can suggest to me to improve the situation?
Best regards
Richard
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.
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.
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.
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.
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
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
