hi All,
Mailing list created! Welcome all!
My notes from talking to Lee this week --------------------------------------
- ACPI: - UFS patches have been sent upstream. - With a patch, battery and AC power detection work!
- General - It seems ISO9660 images will boot, but only from USB 3.1 dev. - Unable to reproduce the trackpad problems - it works fine now. - Maybe this is because of a firmware update?
Distros:
- Ubuntu - 18.04: missing grub 4k alignment patch. - 19.04: boots to grub, kernel does not boot. - Leif's
- openSUSE - missing grub 4k alignment patch.
- Fedora Rawhide - grub boots. Installer hangs with '_' (see below)
Open task items for this week's update --------------------------------------
Please ping this list to share your interest in items so we can avoid duplication of effort.
- Linux support for ACPI PNP0D80 (PEP) - The PNP0D80 is a System Power Management Controller - Very little support resides in Linux at the moment - Thus no ACPI Power Management can currently take place - Accelerated Graphics also depends on it
- UEFI Boot Variables investigation - Grub fails to manipulate them during install - Is it possible for Linux to change them at run-time?
- DMA crash investigation - CRASH IMAGE: https://photos.app.goo.gl/2MGJEALZMyoowr9d6 - HACK PATCH: https://tinyurl.com/y5cnln2j
- Upstream Kernel ACPI check - ACPI tables incorrectly advertise themselves as v5.0 - Kernel should check the presence of PSCI instead - PATCH: https://tinyurl.com/yyq76m47 - NB: Assuming Ard will handle this - needs to be done soon
- Upstream ACPI Battery and AC Power support - Simply a matter of not depending on CONFIG_X86 - PATCH: https://tinyurl.com/yx9kf7e8 - NB: Assuming Ard will handle this - needs to be done soon
- Debug Fedora Rawhide - Kernel currently boots to a black screen with white '_' - NB: Assuming Peter will handle this
- Create UEFI module for persistently loading DTB - We have one which handles this for a single boot - NB: Assuming Leif will handle this
- Test ISO9660 based installers booting from USB - Must be done by someone who has not updated Windows - Fedora Rawhide ISO is a good image to use for testing - LINK: https://tinyurl.com/y2l6bvp9 - If it boots to the Fedora (Grub) menu, it works - Current belief is that USB 3.1 sticks are required - Need to test USB 2.0 and 3.0 sticks too
- Create and upstream a Live Arch Linux ISO/installer for AArch64 - AArch64 support is provided by copying a pre-built roofs to UFS - This is clunky and needs a proper installer like other distos - Get in touch with Richard Henwood directly if you can help.
best regards, Richard
PS. Don't forget to visit #aarch64-laptops on freenode IRC.
-- Richard.Henwood@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.
On Wed, Jun 19, 2019 at 9:19 AM Richard Henwood Richard.Henwood@arm.com wrote:
hi All,
Mailing list created! Welcome all!
My notes from talking to Lee this week
ACPI:
- UFS patches have been sent upstream.
- With a patch, battery and AC power detection work!
General
- It seems ISO9660 images will boot, but only from USB 3.1 dev.
- Unable to reproduce the trackpad problems - it works fine now.
- Maybe this is because of a firmware update?
Distros:
Ubuntu
- 18.04: missing grub 4k alignment patch.
- 19.04: boots to grub, kernel does not boot.
- Leif's
openSUSE
- missing grub 4k alignment patch.
Fedora Rawhide
- grub boots. Installer hangs with '_' (see below)
Open task items for this week's update
Please ping this list to share your interest in items so we can avoid duplication of effort.
I've been working on advancing the support for the 835 (msm8998) based laptops. Since there is no DragonBoard for 835, the state of support is less than that of 845, but progress is being made.
DTs are on list. Right now, I just need the Input maintainer to give the dependency the time of day and hopefully queue it.
GPU support and some display support has been accepted. I still need to cleanup a little bit more in the MDP and DSI areas. I'm chasing folks internally to see if I can get the GPU FW publicly released so that it can be pulled into the linux-firmware package.
The clock controllers for display and GPU are on list, but reviews have been dragging out, so I have no ETA for when they'll likely be accepted.
After GPU/Display is all settled, the next task will likely be wifi.
- Linux support for ACPI PNP0D80 (PEP)
- The PNP0D80 is a System Power Management Controller
- Very little support resides in Linux at the moment
- Thus no ACPI Power Management can currently take place
- Accelerated Graphics also depends on it
In theory, I got pointed to the Spec for this. I need to circle back and review what I got.
UEFI Boot Variables investigation
- Grub fails to manipulate them during install
- Is it possible for Linux to change them at run-time?
DMA crash investigation
- CRASH IMAGE: https://photos.app.goo.gl/2MGJEALZMyoowr9d6
- HACK PATCH: https://tinyurl.com/y5cnln2j
Upstream Kernel ACPI check
- ACPI tables incorrectly advertise themselves as v5.0
- Kernel should check the presence of PSCI instead
- PATCH: https://tinyurl.com/yyq76m47
- NB: Assuming Ard will handle this - needs to be done soon
Upstream ACPI Battery and AC Power support
- Simply a matter of not depending on CONFIG_X86
- PATCH: https://tinyurl.com/yx9kf7e8
- NB: Assuming Ard will handle this - needs to be done soon
Debug Fedora Rawhide
- Kernel currently boots to a black screen with white '_'
- NB: Assuming Peter will handle this
Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
Test ISO9660 based installers booting from USB
- Must be done by someone who has not updated Windows
- Fedora Rawhide ISO is a good image to use for testing
- If it boots to the Fedora (Grub) menu, it works
- Current belief is that USB 3.1 sticks are required
- Need to test USB 2.0 and 3.0 sticks too
Create and upstream a Live Arch Linux ISO/installer for AArch64
- AArch64 support is provided by copying a pre-built roofs to UFS
- This is clunky and needs a proper installer like other distos
- Get in touch with Richard Henwood directly if you can help.
best regards, Richard
PS. Don't forget to visit #aarch64-laptops on freenode IRC.
-- Richard.Henwood@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. _______________________________________________ Aarch64-laptops mailing list Aarch64-laptops@lists.linaro.org https://lists.linaro.org/mailman/listinfo/aarch64-laptops
On Wed, Jun 19, 2019 at 8:19 AM Richard Henwood Richard.Henwood@arm.com wrote:
- Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
So, one question about this approach, is how do we handle kernel upgrades and new dtb.. I'm not 100% sure what other distro's do, but fedora has set of dtb files per kernel version, but something that runs before grub wouldn't know which kernel version grub will load.
Semi-related, I'd suggested[1] addition of dmi-compatible property in DT, to give some mechanism to auto-pick the correct dtb, ie. something like:
dmi-compatible = "LENOVO 81JL/LNVNB161216", "LENOVO 81JL";
on my lenovo c630, the SMBIOS table has:
vendor: LENOVO product: 81JL board: LNVNB161216
(I'd be curios to see "dmesg | grep DMI" output from other laptops, btw.. to confirm these fields are populated in a reasonably sane way)
The idea would be to try to match "$vendor $product/$board" and then fall back to "$vendor $product"..
On Wed, Jun 19, 2019 at 09:15:11AM -0700, Rob Clark wrote:
On Wed, Jun 19, 2019 at 8:19 AM Richard Henwood Richard.Henwood@arm.com wrote:
- Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
So, one question about this approach, is how do we handle kernel upgrades and new dtb.. I'm not 100% sure what other distro's do, but fedora has set of dtb files per kernel version, but something that runs before grub wouldn't know which kernel version grub will load.
2019 and we're still treating the DT as a property of the kernel image? This is something the distros will need to wean themselves off anyway.
Let's hope we won't need to change bindings incompatibly on every rebuild of the kernel.
Semi-related, I'd suggested[1] addition of dmi-compatible property in DT, to give some mechanism to auto-pick the correct dtb, ie. something like:
dmi-compatible = "LENOVO 81JL/LNVNB161216", "LENOVO 81JL";
This will be useful regardless.
on my lenovo c630, the SMBIOS table has:
vendor: LENOVO product: 81JL board: LNVNB161216
(I'd be curios to see "dmesg | grep DMI" output from other laptops, btw.. to confirm these fields are populated in a reasonably sane way)
Yes. We could set up a wiki page. I think we especially need to get examples including non-compatible hw revisions.
But I guess we can prepend better compatible strings in future if it turns out these aren't sufficient?
/ Leif
The idea would be to try to match "$vendor $product/$board" and then fall back to "$vendor $product"..
[1] https://lkml.org/lkml/2019/6/14/641 _______________________________________________ Aarch64-laptops mailing list Aarch64-laptops@lists.linaro.org https://lists.linaro.org/mailman/listinfo/aarch64-laptops
On Thu, Jun 20, 2019 at 10:35:12AM +0100, Leif Lindholm wrote:
on my lenovo c630, the SMBIOS table has:
vendor: LENOVO product: 81JL board: LNVNB161216
My lenovo c630 - extracted with UEFI Shell 'smbiosview > file':
In the "system information" (type 1) structure: Manufacturer: LENOVO ProductName: 81JL Version: Lenovo YOGA C630-13Q50 SKUNumber: LENOVO_MT_81JL_BU_idea_FM_YOGA C630-13Q50
In the "base board information" (type 2) structure: ProductName: LNVNB161216 Version: SDK0R32822 WIN
/ Leif
On Thu, Jun 20, 2019 at 2:35 AM Leif Lindholm leif.lindholm@linaro.org wrote:
On Wed, Jun 19, 2019 at 09:15:11AM -0700, Rob Clark wrote:
On Wed, Jun 19, 2019 at 8:19 AM Richard Henwood Richard.Henwood@arm.com wrote:
- Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
So, one question about this approach, is how do we handle kernel upgrades and new dtb.. I'm not 100% sure what other distro's do, but fedora has set of dtb files per kernel version, but something that runs before grub wouldn't know which kernel version grub will load.
2019 and we're still treating the DT as a property of the kernel image? This is something the distros will need to wean themselves off anyway.
mixed-feelings about this.. on one hand, by the time the dts is upstream it should be fairly safe to just use the most recent one..
But on the other hand, I'm frequently working with stuff which is still in the process of getting upstream, and sometimes bindings change along the way. (And I'm a selfish bastard who cares about his own use-case :-P)
So it would be nice to load a kernel specific dt if present, and then just fallback to whatever the most recent is.
Let's hope we won't need to change bindings incompatibly on every rebuild of the kernel.
Semi-related, I'd suggested[1] addition of dmi-compatible property in DT, to give some mechanism to auto-pick the correct dtb, ie. something like:
dmi-compatible = "LENOVO 81JL/LNVNB161216", "LENOVO 81JL";
This will be useful regardless.
on my lenovo c630, the SMBIOS table has:
vendor: LENOVO product: 81JL board: LNVNB161216
(I'd be curios to see "dmesg | grep DMI" output from other laptops, btw.. to confirm these fields are populated in a reasonably sane way)
Yes. We could set up a wiki page.
that would be a good idea..
fwiw, chatted a bit w/ robher about this on #armlinux.. he suggested maybe just separate dmi-vendor/dmi-product/dmi-board fields.
I don't have a strong opinion one way or another.. I suppose the compatible string type thing makes it easier to prepend something more specific later if needed.
I think we especially need to get examples including non-compatible hw revisions.
I wonder if those exist yet? Maybe we could just look at values on x86 laptops and interpolate..
But I guess we can prepend better compatible strings in future if it turns out these aren't sufficient?
yeah
BR, -R
On Wed, Jun 19, 2019 at 4:19 PM Richard Henwood Richard.Henwood@arm.com wrote:
hi All,
Mailing list created! Welcome all!
My notes from talking to Lee this week
ACPI:
- UFS patches have been sent upstream.
- With a patch, battery and AC power detection work!
General
- It seems ISO9660 images will boot, but only from USB 3.1 dev.
- Unable to reproduce the trackpad problems - it works fine now.
- Maybe this is because of a firmware update?
Distros:
Ubuntu
- 18.04: missing grub 4k alignment patch.
- 19.04: boots to grub, kernel does not boot.
- Leif's
openSUSE
- missing grub 4k alignment patch.
Fedora Rawhide
- grub boots. Installer hangs with '_' (see below)
Open task items for this week's update
Please ping this list to share your interest in items so we can avoid duplication of effort.
Linux support for ACPI PNP0D80 (PEP)
- The PNP0D80 is a System Power Management Controller
- Very little support resides in Linux at the moment
- Thus no ACPI Power Management can currently take place
- Accelerated Graphics also depends on it
UEFI Boot Variables investigation
- Grub fails to manipulate them during install
- Is it possible for Linux to change them at run-time?
DMA crash investigation
- CRASH IMAGE: https://photos.app.goo.gl/2MGJEALZMyoowr9d6
- HACK PATCH: https://tinyurl.com/y5cnln2j
Upstream Kernel ACPI check
- ACPI tables incorrectly advertise themselves as v5.0
- Kernel should check the presence of PSCI instead
- PATCH: https://tinyurl.com/yyq76m47
- NB: Assuming Ard will handle this - needs to be done soon
Upstream ACPI Battery and AC Power support
- Simply a matter of not depending on CONFIG_X86
- PATCH: https://tinyurl.com/yx9kf7e8
- NB: Assuming Ard will handle this - needs to be done soon
Debug Fedora Rawhide
- Kernel currently boots to a black screen with white '_'
- NB: Assuming Peter will handle this
Yes, I am, I was ill the last few weeks so ramping up this week. There's also been some instability in the nightly rawhide compose which is on the way to resolution so expect to hear more soon.
Peter
Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
Test ISO9660 based installers booting from USB
- Must be done by someone who has not updated Windows
- Fedora Rawhide ISO is a good image to use for testing
- If it boots to the Fedora (Grub) menu, it works
- Current belief is that USB 3.1 sticks are required
- Need to test USB 2.0 and 3.0 sticks too
Create and upstream a Live Arch Linux ISO/installer for AArch64
- AArch64 support is provided by copying a pre-built roofs to UFS
- This is clunky and needs a proper installer like other distos
- Get in touch with Richard Henwood directly if you can help.
best regards, Richard
PS. Don't forget to visit #aarch64-laptops on freenode IRC.
-- Richard.Henwood@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. _______________________________________________ Aarch64-laptops mailing list Aarch64-laptops@lists.linaro.org https://lists.linaro.org/mailman/listinfo/aarch64-laptops
aarch64-laptops@lists.linaro.org
-
Jeffrey Hugo -
Leif Lindholm -
Peter Robinson -
Richard Henwood -
Rob Clark