On Thu, Dec 6, 2018 at 12:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber(a)suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all). This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
Yeah, install needs to remain flat even if the dts files move into
subdirectories. It will be painful for everybody if the install
location moves.
> The issues with the existing install_dtbs sounded unrelated to this.
Agreed.
-Olof
Rob,
Am 04.12.18 um 19:36 schrieb Rob Herring:
> I've put together a script to move the dts files and update the
> makefiles. It doesn't handle files not following a common prefix which
> isn't many and some includes within the dts files will need some fixups
> by hand.
>
> MAINTAINERS will also need updating.
>
> A few questions:
>
> Do we want to move absolutely everything to subdirs?
This refactoring is a terrible idea!
While it would've been nice to have more structure from the start,
bootloaders like U-Boot expect a flat structure for arm .dtb files now.
If you start installing them into subdirs instead, they won't find the
files anymore under the hardcoded name.
Doing this only for new platforms would be much less invasive and allow
to prepare bootloaders accordingly. Alternatively, white-list which ones
are safe to move around. But don't just script a refactoring because it
looks nicer in the source tree, without testing what side effects this
can have for board/distro users of the compiled files in practice.
We already had that discussion for arm64 because Debian chose to ignore
the kernel-installed subdirectories and installed .dtb files into a flat
directory, which collided with openSUSE sticking to the kernel choice.
This topic becomes even more important with EBBR: There is neither a
mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
nor are capsule updates implemented in U-Boot for easily deploying such
bootloaders with new .dts sources or paths yet. And I can assure you
that just getting users to dd the right bootloader can be difficult...
Since DT forward and backward compatibility is often being neglected,
for example with optional properties or renamed compatibles that break
booting with previous drivers, new kernel versions often need updated
Device Trees to make use of new/enhanced drivers. Therefore it is
unfortunately often enough a necessity to load newer kernel-based .dtb
files matching the kernel (as opposed to the dream of kernel-independent
hardware descriptions) when working with the latest -rc or -next kernels
at least. For examples of DTs needing updates, look no further than
Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
.dtb paths may be hardcoded, ditto for arm; and Armada was an example
where the upstream bindings for the network IP changed incompatibly.
DT overlays are another topic that is not making any progress upstream
according to the ELCE BoF, so beyond the Raspberry Pi the only known
working way to apply them is to write a U-Boot boot.scr script, which
can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
hardcode one, the latter two of which would break with your renaming.
So expect people to be using .dtb files, expect them to be affected by
file movements to subdirectories here, and don't expect each user to
understand or be able to fix things themselves if they fall apart as
result of your changes and they suddenly no longer have Ethernet/Wifi.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
I don't have an agenda for today. The one remaining blocker for 1.0 release is still open. I had hoped to get it written this past week, but haven't got it done yet.
I did have a very productive meeting with Qualcomm last week. They have good feedback on the v0.6 draft, but I'll let them speak for themselves.
I'm cancelling todays meeting, but I'll open the call anyway simply because it is so late that I'm sending this email. If you want to chat, feel free to dial in.
If you do have a topic you want to discuss next week, please email me in the next week.
g.
Any agenda items for todays call? Here is what I have so far:
- Updates
- SetVariable()
- Compatibility statement
- EBBR Plugfest?
- Other Business
Next week (15 Nov) we won't have a call, nor will there be a call on 29 Nov.
g.
The UEFI spec already specifies the image format. No need to specify in
EBBR.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 6 ------
1 file changed, 6 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 177a81c..f89ac04 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -73,12 +73,6 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
-UEFI Loaded Images
-------------------
-
-UEFI loaded images for AArch64 must be in 64-bit PE/COFF format and must
-contain only A64 code.
-
Configuration Tables
--------------------
--
2.13.0
This weeks meeting will need to be short as I've got a conflict at the
top of the hour. We'll do a quick round table, and then I'd like to talk
a bit more about the SetVariable() proposal made by Peter J. I
personally am a bit confused as to the scope of the proposal.
Agenda 01/11/2018:
- Release progress
- Round table
- SetVariable() proposal from Peter Jones
Anyone is welcome to join. Feel free to pass this invitation along. Let
me know if anyone has trouble dialling/connecting to the WebEx bridge.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
g.
---
Grant Likely's Personal Room
https://arm-onsite.webex.com/meet/gralik01
Access code: 809 053 990
Join by phone
1-408-792-6300 Call-in toll number (US/Canada)
1-877-668-4490 Call-in toll-free number (US/Canada)
44-203-478-5285 Call-in toll number (UK)
08-002061177 Call-in toll-free (UK)
Access code: 809 053 990
More access numbers:
https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…https://www.webex.com/pdf/tollfree_restrictions.pdf
Hi everyone,
I've tagged v0.7 of EBBR for review. Please feel free to circulate and
solicit feedback. It will certainly be discussed at ELC Europe next week
in Edinburgh.
https://github.com/ARM-software/ebbr/releases/tag/v0.7
Thanks,
g.
ResetSystem() was over-specified in the document. UEFI already documents
the behaviour of ResetSystem() sufficiently. Add notes on expected
behaviour when platform specific or standard interface methods are
available.
Resolves: #29
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 0cbddff..8a3ff1a 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -175,23 +175,16 @@ and the OS must use a device driver to control the RTC.
UEFI Reset and Shutdown
-----------------------
-The UEFI Runtime service ResetSystem() must implement the following commands,
-for purposes of power management and system control.
-
-- EfiResetCold()
-- EfiResetShutdown()
- * EfiResetShutdown must not reboot the system.
-
-If firmware updates are supported through the Runtime Service of
-UpdateCapsule(), then ResetSystem() might need to support the following
-command:
-
-- EfiWarmReset()
-
-.. note:: On platforms implementing the Power State Coordination Interface
- specification [PSCI]_, it is still required that EBBR compliant
- Operating Systems calls to reset the system will go via Runtime Services
- and not directly to PSCI.
+ResetSystem() is required to be implemented in boot services, but it is
+optional for runtime services.
+During runtime services, the operating system should first attempt to
+use ResetSystem() to reset the system.
+If ResetSystem() returns EFI_UNSUPPORTED, then the OS may fall back to
+an architecture or platform specific mechanism.
+
+On AArch64 platforms implementing [PSCI]_,
+if ResetSystem() is not implemented then the Operating System should fall
+back to making a PSCI call to reset or shutdown the system.
Runtime Variable Access
-----------------------
--
2.13.0
For those of you dialing into the weekly EBBR call, the dial in details
have changed (see below). We'll use WebEx instead of Skype for Business
from here on.
Agenda 27/09/2018:
• YVR18 Recap
• Review meeting time
• Release schedule
• Get/SetVariable – once more with feeling
• reference platforms/qemu
Anyone is welcome to join. Feel free to pass this invitation along. Let
me know if anyone has trouble dialling/connecting to the SfB bridge.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
[1]
https://lists.linaro.org/pipermail/boot-architecture/2018-April/000419.html
g.
---
Grant Likely's Personal Room
https://arm-onsite.webex.com/meet/gralik01
Access code: 809 053 990
Join by phone
1-408-792-6300 Call-in toll number (US/Canada)
1-877-668-4490 Call-in toll-free number (US/Canada)
44-203-478-5285 Call-in toll number (UK)
08-002061177 Call-in toll-free (UK)
Access code: 809 053 990
More access numbers:
https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…https://www.webex.com/pdf/tollfree_restrictions.pdf
Hello,
Can we add a discussion in upcoming meetings about the participation
of SMMU in the booting procedure?
In the past there's been a number of proposals on how to mitigate
attacks, were a rogue PCI card is inserted into the system.
Some of them include shutting down external DMA ports until the OS
explicitly powers them up or blocking DMA using BME bit etc
Keeping in mind this will enhance the security of devices would it
make sense to include it as a 'MUST' if the hardware is present or a
recommendation would be enough?
If we enable if a number of questions will rise as well such as, What
happens if the SMMU is already configured? Should the OS reconfigure
it ?
/Ilias
