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
On 27/09/2018 22:19, Mark Brown wrote:
> On Thu, Sep 27, 2018 at 04:25:29PM +0100, Grant Likely wrote:
>
>> 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.
>
> Highlighting in case anyone else makes the same mistake I did today: the
> dial in details have changed, if you've copied them into your personal
> calendar or similar you'll need to update!
Oops! The current calendar invite is about to expire, and I'm going to
try and rearrange the meeting to be at the top of the hour (need to
coordinate with Linaro LEDGE SC meeting). There will be a new invite in
the near future.
Mark, I also maintain a regular calendar invite. Would you like me to
add you to that?
g.
>
>> 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
