Hi everyone.
I have to do this, but I have another unexpected conflict for the EBBR biweekly on the 14th.
Rather than cancelling outright, does anyone else want to chair the meeting? The major planned orientatio item on the agenda was to talk about EBBR testing, with Heinrich sharing what he is currently doing.
If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our next meeting will be in January as I believe most of us will already be on Christmas holiday on the 21st
g.
Get Outlook for Androidhttps://aka.ms/ghei36 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.
Ilias has offered to host the meeting today. I'm hoping to join part way through if I can.
g.
On 13/12/2020 19:06, Grant Likely wrote:
Hi everyone.
I have to do this, but I have another unexpected conflict for the EBBR biweekly on the 14th.
Rather than cancelling outright, does anyone else want to chair the meeting? The major planned orientatio item on the agenda was to talk about EBBR testing, with Heinrich sharing what he is currently doing.
If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our next meeting will be in January as I believe most of us will already be on Christmas holiday on the 21st
g.
Hi all,
Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far:
* Update on specific required protocols * https://github.com/ARM-software/ebbr/issues/60 * https://github.com/ARM-software/ebbr/issues/61 * https://github.com/ARM-software/ebbr/issues/64 * Firmware update requirements * https://github.com/ARM-software/ebbr/issues/69 * DT fixup protocol proposal * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL * https://github.com/ARM-software/ebbr/issues/68 * Other business
If you would like to discuss anything else, please reply to this email.
Dial in details are here:
---
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
Hi Grant
I’d like EBBR to specify a solution to identify the default serial console out of existing optional indications.
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will get the info from SPCR table.
Regardless of the method , this is required to just boot and do not have to care about clumsy command lines with early_console or console parameters.
I like this topic be added to the agenda ?
Cheers
FF
Le sam. 16 janv. 2021 à 13:59, Grant Likely grant.likely@arm.com a écrit :
Hi all,
Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far:
- Update on specific required protocols
- Firmware update requirements
- DT fixup protocol proposal
- Other business
If you would like to discuss anything else, please reply to this email.
Dial in details are here:
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston)Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 1/17/21 4:01 PM, François Ozog wrote:
Hi Grant
I’d like EBBR to specify a solution to identify the default serial console out of existing optional indications.
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will get the info from SPCR table.
Regardless of the method , this is required to just boot and do not have to care about clumsy command lines with early_console or console parameters.
I like this topic be added to the agenda ?
Dear François,
we are keeping suggestions for new requirements as issues on https://github.com/ARM-software/ebbr/issues. Maybe you want to create a new entry.
For a system using a serial console as main access method I appreciate your suggestion. But would it mean that an EBBR compliant system MUST have a serial interface? Couldn't a system with a USB key board and HDMI or using a network console also be compliant? - Unfortunately I would not know how to encode these as stdout-path to fulfill your requirement.
Best regards
Heinrich
Cheers
FF
Le sam. 16 janv. 2021 à 13:59, Grant Likely grant.likely@arm.com a écrit :
Hi all,
Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far:
- Update on specific required protocols
- Firmware update requirements
- DT fixup protocol proposal
- Other business
If you would like to discuss anything else, please reply to this email.
Dial in details are here:
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston)Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Le dim. 17 janv. 2021 à 17:05, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 1/17/21 4:01 PM, François Ozog wrote:
Hi Grant
I’d like EBBR to specify a solution to identify the default serial
console
out of existing optional indications.
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will
get
the info from SPCR table.
Regardless of the method , this is required to just boot and do not have
to
care about clumsy command lines with early_console or console parameters.
I like this topic be added to the agenda ?
Dear François,
we are keeping suggestions for new requirements as issues on https://github.com/ARM-software/ebbr/issues. Maybe you want to create a new entry.
ok
For a system using a serial console as main access method I appreciate your suggestion. But would it mean that an EBBR compliant system MUST have a serial interface?
I wonted to say if it has an uart console, it must conform to the above so that a Linux distro can boot without specific command like.
Couldn't a system with a USB key board and HDMI or using a network console also be compliant? - Unfortunately I would not know how to encode these as stdout-path to fulfill your requirement.
For efi/acpi systems I would say this is certainly solved today as part of sbsa/sbbr. Is there a similar solution for efi/fdt ? Need to check.
Best regards
Heinrich
Cheers
FF
Le sam. 16 janv. 2021 à 13:59, Grant Likely grant.likely@arm.com a
écrit :
Hi all,
Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far:
- Update on specific required protocols
- Firmware update requirements
- DT fixup protocol proposal
- Other business
If you would like to discuss anything else, please reply to this email.
Dial in details are here:
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston)Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On 17/01/2021 15:01, François Ozog wrote:
Hi Grant
I’d like EBBR to specify a solution to identify the default serial console out of existing optional indications.
Hi Francois,
This is a good topic. EBBR starts from the assumption that whether ACPI or DT is used for the system description, the data will follow the requirements of the technology. For ACPI I don't think we need to add any language, but it would be worthwhile to require stdout-path is specified in the DT. Do you want to propose some language?
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will get the info from SPCR table. > Regardless of the method , this is required to just boot and do not have to care about clumsy command lines with early_console or console parameters.
Agree. Mucking with the commandline should not be required.
I like this topic be added to the agenda ?
yes. Can you also add an issue to track this topic please?
g.
Le sam. 16 janv. 2021 à 13:59, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> a écrit :
Hi all, Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far: * Update on specific required protocols * https://github.com/ARM-software/ebbr/issues/60 <https://github.com/ARM-software/ebbr/issues/60> * https://github.com/ARM-software/ebbr/issues/61 <https://github.com/ARM-software/ebbr/issues/61> * https://github.com/ARM-software/ebbr/issues/64 <https://github.com/ARM-software/ebbr/issues/64> * Firmware update requirements * https://github.com/ARM-software/ebbr/issues/69 <https://github.com/ARM-software/ebbr/issues/69> * DT fixup protocol proposal * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL <https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL> * https://github.com/ARM-software/ebbr/issues/68 <https://github.com/ARM-software/ebbr/issues/68> * Other business If you would like to discuss anything else, please reply to this email. Dial in details are here: --- Grant Likely is inviting you to a scheduled Zoom meeting. Topic: EBBR Biweekly Time: 18 Jan 2021, 16:00-17:00 GMT Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 <https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09> Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW <https://armltd.zoom.us/u/aelJgr9ZAW> _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/boot-architecture <https://lists.linaro.org/mailman/listinfo/boot-architecture>-- François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog
Hi
During the call you mentioned that SBBR had some defined values for console.
I can only find that the _HID="ARMH0011" identifies a SBSA com port but I don't find any standard object path that would point to the UART to use.
let's assume:
Device (COM0) { Name (_HID, "ARMH0011") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x09000000, // Address Base 0x00001000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000021, } }) Name (_ADR, 0x09000000) // _ADR: Address }
Device (COM1) { Name (_HID, "ARMH0011") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x09002000, // Address Base 0x00001000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000022, } }) Name (_ADR, 0x09002000) // _ADR: Address }
Which port to use as a console?
by definition we could say that _SB_.COM0 is the port to use. Or we could define _SB_.SOUT as a reference object to any of the defined UARTs.
Cheers
FF
On Mon, 18 Jan 2021 at 16:32, Grant Likely grant.likely@arm.com wrote:
On 17/01/2021 15:01, François Ozog wrote:
Hi Grant
I’d like EBBR to specify a solution to identify the default serial console out of existing optional indications.
Hi Francois,
This is a good topic. EBBR starts from the assumption that whether ACPI or DT is used for the system description, the data will follow the requirements of the technology. For ACPI I don't think we need to add any language, but it would be worthwhile to require stdout-path is specified in the DT. Do you want to propose some language?
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will get the info from SPCR table. > Regardless of the method , this is required to just boot and do not have to care about clumsy command lines with early_console or console
parameters.
Agree. Mucking with the commandline should not be required.
I like this topic be added to the agenda ?
yes. Can you also add an issue to track this topic please?
g.
Le sam. 16 janv. 2021 à 13:59, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> a écrit :
Hi all, Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've gotfor
the agenda so far: * Update on specific required protocols * https://github.com/ARM-software/ebbr/issues/60 <https://github.com/ARM-software/ebbr/issues/60> * https://github.com/ARM-software/ebbr/issues/61 <https://github.com/ARM-software/ebbr/issues/61> * https://github.com/ARM-software/ebbr/issues/64 <https://github.com/ARM-software/ebbr/issues/64> * Firmware update requirements * https://github.com/ARM-software/ebbr/issues/69 <https://github.com/ARM-software/ebbr/issues/69> * DT fixup protocol proposal * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL <https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL> * https://github.com/ARM-software/ebbr/issues/68 <https://github.com/ARM-software/ebbr/issues/68> * Other business If you would like to discuss anything else, please reply to thisemail.
Dial in details are here: --- Grant Likely is inviting you to a scheduled Zoom meeting. Topic: EBBR Biweekly Time: 18 Jan 2021, 16:00-17:00 GMT Join Zoom Meetinghttps://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
<https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09%3E
Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW <https://armltd.zoom.us/u/aelJgr9ZAW> _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/boot-architecture <https://lists.linaro.org/mailman/listinfo/boot-architecture>--
François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org
| Skype: ffozog
There is also the SPCR table https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-po... This is the primary serial console
From: boot-architecture boot-architecture-bounces@lists.linaro.org on behalf of François Ozog francois.ozog@linaro.org Date: Monday, January 18, 2021 at 2:43 PM To: Grant Likely Grant.Likely@arm.com Cc: Jeff Booher-Kaeding Jeff.Booher-Kaeding@arm.com, Samer El-Haj-Mahmoud Samer.El-Haj-Mahmoud@arm.com, mbrugger@suse.com mbrugger@suse.com, Jose Marinho Jose.Marinho@arm.com, sjg@google.com sjg@google.com, bill.mills@linaro.org bill.mills@linaro.org, boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org, takahiro.akashi@linaro.org takahiro.akashi@linaro.org, nd nd@arm.com, Mark Brown Mark.Brown@arm.com, atishp@atishpatra.org atishp@atishpatra.org, joakim.bech@linaro.org joakim.bech@linaro.org, daniel.thompson@linaro.org daniel.thompson@linaro.org, duwe@suse.de duwe@suse.de, Reed Hinkel Reed.Hinkel@arm.com Subject: Re: EBBR Biweekly for 18 Jan 2021 Hi
During the call you mentioned that SBBR had some defined values for console.
I can only find that the _HID="ARMH0011" identifies a SBSA com port but I don't find any standard object path that would point to the UART to use.
let's assume:
Device (COM0) { Name (_HID, "ARMH0011") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x09000000, // Address Base 0x00001000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000021, } }) Name (_ADR, 0x09000000) // _ADR: Address }
Device (COM1) { Name (_HID, "ARMH0011") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x09002000, // Address Base 0x00001000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000022, } }) Name (_ADR, 0x09002000) // _ADR: Address }
Which port to use as a console?
by definition we could say that _SB_.COM0 is the port to use. Or we could define _SB_.SOUT as a reference object to any of the defined UARTs.
Cheers
FF
On Mon, 18 Jan 2021 at 16:32, Grant Likely grant.likely@arm.com wrote:
On 17/01/2021 15:01, François Ozog wrote:
Hi Grant
I’d like EBBR to specify a solution to identify the default serial console out of existing optional indications.
Hi Francois,
This is a good topic. EBBR starts from the assumption that whether ACPI or DT is used for the system description, the data will follow the requirements of the technology. For ACPI I don't think we need to add any language, but it would be worthwhile to require stdout-path is specified in the DT. Do you want to propose some language?
On DT systems , we shall state that /chosen/stdout-path must point to a valid path.
On ACPI, we may get the info form _SB_.COM0 @ DSDT or specify we will get the info from SPCR table. > Regardless of the method , this is required to just boot and do not have to care about clumsy command lines with early_console or console
parameters.
Agree. Mucking with the commandline should not be required.
I like this topic be added to the agenda ?
yes. Can you also add an issue to track this topic please?
g.
Le sam. 16 janv. 2021 à 13:59, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> a écrit :
Hi all, Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've gotfor
the agenda so far: * Update on specific required protocols * https://github.com/ARM-software/ebbr/issues/60 <https://github.com/ARM-software/ebbr/issues/60> * https://github.com/ARM-software/ebbr/issues/61 <https://github.com/ARM-software/ebbr/issues/61> * https://github.com/ARM-software/ebbr/issues/64 <https://github.com/ARM-software/ebbr/issues/64> * Firmware update requirements * https://github.com/ARM-software/ebbr/issues/69 <https://github.com/ARM-software/ebbr/issues/69> * DT fixup protocol proposal * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL <https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL> * https://github.com/ARM-software/ebbr/issues/68 <https://github.com/ARM-software/ebbr/issues/68> * Other business If you would like to discuss anything else, please reply to thisemail.
Dial in details are here: --- Grant Likely is inviting you to a scheduled Zoom meeting. Topic: EBBR Biweekly Time: 18 Jan 2021, 16:00-17:00 GMT Join Zoom Meetinghttps://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
<https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09%3E
Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW <https://armltd.zoom.us/u/aelJgr9ZAW> _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/boot-architecture <https://lists.linaro.org/mailman/listinfo/boot-architecture>--
François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org
| Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture 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 Tue, 19 Jan 2021 at 05:54, Dong Wei Dong.Wei@arm.com wrote:
There is also the SPCR table https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-po... This is the primary serial console
One of the issues we still have not fixed in Linux is the inconsistency in interpretation of what 'serial console' actually means.
On Windows, the serial console is a low-level admin interface that may be exposed in addition to the full blown graphical user interface, which is always available. The SPCR describes how this admin interface is exposed, but does not affect what happens on the GUI.
In Linux, the console *is* the primary interface, either graphical or serial. Currently, the mere presence of a SPCR is taken as an indication that only the serial console should be enabled; for this reason, the UEFI ports we have for platforms with PCIe expansion carry a driver that removes the SPCR again if UEFI detects the presence of a graphical interface.
Unfortunately, this is not something we can easily change without breaking existing systems. Note that annotating device objects in the DSDT is probably not the right approach here, given that this requires the AML interpreter to be up and running before we can decide where the console lives.
As Heinrich points out, we have a similar problem today when it comes to the graphical interface on DT systems, i.e., it is not clear how to convey that the user expects the interaction with the system to occur via the graphical UI and not via a serial port. For a bootloader such as u-boot, it should be fairly easy to suppress the stdout-path if u-boot itself is running on the graphical display, but it would be better to communicate the presence of this GUI *in addition to* a serial port serving as a console.
On 19.01.21 09:30, Ard Biesheuvel wrote:
On Tue, 19 Jan 2021 at 05:54, Dong Wei Dong.Wei@arm.com wrote:
There is also the SPCR table https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-po... This is the primary serial console
One of the issues we still have not fixed in Linux is the inconsistency in interpretation of what 'serial console' actually means.
On Windows, the serial console is a low-level admin interface that may be exposed in addition to the full blown graphical user interface, which is always available. The SPCR describes how this admin interface is exposed, but does not affect what happens on the GUI.
In Linux, the console *is* the primary interface, either graphical or serial. Currently, the mere presence of a SPCR is taken as an indication that only the serial console should be enabled; for this reason, the UEFI ports we have for platforms with PCIe expansion carry a driver that removes the SPCR again if UEFI detects the presence of a graphical interface.
Unfortunately, this is not something we can easily change without breaking existing systems. Note that annotating device objects in the DSDT is probably not the right approach here, given that this requires the AML interpreter to be up and running before we can decide where the console lives.
As Heinrich points out, we have a similar problem today when it comes to the graphical interface on DT systems, i.e., it is not clear how to convey that the user expects the interaction with the system to occur via the graphical UI and not via a serial port. For a bootloader such as u-boot, it should be fairly easy to suppress the stdout-path if u-boot itself is running on the graphical display, but it would be better to communicate the presence of this GUI *in addition to* a serial port serving as a console.
In U-Boot you can use the serial console and keyboard/video in parallel.
It is not defined how we should decide which of the consoles shall be used for the Linux kernel messages and rescue console.
Even if you detect a monitor via the EDID I2C interface you would not be able to tell if the user is sitting in front of the system or remote controlling via the serial port.
Furthermore GRUB interferes with the console. I had to set
GRUB_TERMINAL_OUTPUT="console"
to get serial output on a system without a monitor attached.
Best regards
Heinrich
Hi
So we need another issue in the EBBR tracker:
console guidance (serial or graphical) from firmware to OS in both DT and ACPI. The firmware may use programatic or runtime advanced techniques such as HDMI monitor presence and use a "to be specified" method to signal the right selection.
When it comes to the issue I added, we can say it is targeted at system that we know in advance the console is on serial. so with DT:/chosen/stdout-path and ACPI:/SPCR (without AML interpreter) we have simple ways to detect the device to use. Is it a safe first step to add to EBBR ?
Cheers
FF
On Tue, 19 Jan 2021 at 09:30, Ard Biesheuvel ardb@kernel.org wrote:
On Tue, 19 Jan 2021 at 05:54, Dong Wei Dong.Wei@arm.com wrote:
There is also the SPCR table
https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-po...
This is the primary serial console
One of the issues we still have not fixed in Linux is the inconsistency in interpretation of what 'serial console' actually means.
On Windows, the serial console is a low-level admin interface that may be exposed in addition to the full blown graphical user interface, which is always available. The SPCR describes how this admin interface is exposed, but does not affect what happens on the GUI.
In Linux, the console *is* the primary interface, either graphical or serial. Currently, the mere presence of a SPCR is taken as an indication that only the serial console should be enabled; for this reason, the UEFI ports we have for platforms with PCIe expansion carry a driver that removes the SPCR again if UEFI detects the presence of a graphical interface.
Unfortunately, this is not something we can easily change without breaking existing systems. Note that annotating device objects in the DSDT is probably not the right approach here, given that this requires the AML interpreter to be up and running before we can decide where the console lives.
As Heinrich points out, we have a similar problem today when it comes to the graphical interface on DT systems, i.e., it is not clear how to convey that the user expects the interaction with the system to occur via the graphical UI and not via a serial port. For a bootloader such as u-boot, it should be fairly easy to suppress the stdout-path if u-boot itself is running on the graphical display, but it would be better to communicate the presence of this GUI *in addition to* a serial port serving as a console.
In the old Itanium days, I created a PCDP table that also includes GUI console https://coral.googlesource.com/linux-imx/+/refs/tags/4-2/drivers/firmware/pc... for non-Windows OSes.
Unfortunately, it did not get widely accepted, Linux on x86 still prefers to adopt Microsoft standards 😊.
From: Ard Biesheuvel ardb@kernel.org Date: Tuesday, January 19, 2021 at 12:30 AM To: Dong Wei Dong.Wei@arm.com Cc: François Ozog francois.ozog@linaro.org, Grant Likely Grant.Likely@arm.com, Jeff Booher-Kaeding Jeff.Booher-Kaeding@arm.com, Samer El-Haj-Mahmoud Samer.El-Haj-Mahmoud@arm.com, mbrugger@suse.com mbrugger@suse.com, Jose Marinho Jose.Marinho@arm.com, sjg@google.com sjg@google.com, bill.mills@linaro.org bill.mills@linaro.org, boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org, Reed Hinkel Reed.Hinkel@arm.com, takahiro.akashi@linaro.org takahiro.akashi@linaro.org, daniel.thompson@linaro.org daniel.thompson@linaro.org, Mark Brown Mark.Brown@arm.com, atishp@atishpatra.org atishp@atishpatra.org, joakim.bech@linaro.org joakim.bech@linaro.org, duwe@suse.de duwe@suse.de Subject: Re: EBBR Biweekly for 18 Jan 2021 On Tue, 19 Jan 2021 at 05:54, Dong Wei Dong.Wei@arm.com wrote:
There is also the SPCR table https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-po... This is the primary serial console
One of the issues we still have not fixed in Linux is the inconsistency in interpretation of what 'serial console' actually means.
On Windows, the serial console is a low-level admin interface that may be exposed in addition to the full blown graphical user interface, which is always available. The SPCR describes how this admin interface is exposed, but does not affect what happens on the GUI.
In Linux, the console *is* the primary interface, either graphical or serial. Currently, the mere presence of a SPCR is taken as an indication that only the serial console should be enabled; for this reason, the UEFI ports we have for platforms with PCIe expansion carry a driver that removes the SPCR again if UEFI detects the presence of a graphical interface.
Unfortunately, this is not something we can easily change without breaking existing systems. Note that annotating device objects in the DSDT is probably not the right approach here, given that this requires the AML interpreter to be up and running before we can decide where the console lives.
As Heinrich points out, we have a similar problem today when it comes to the graphical interface on DT systems, i.e., it is not clear how to convey that the user expects the interaction with the system to occur via the graphical UI and not via a serial port. For a bootloader such as u-boot, it should be fairly easy to suppress the stdout-path if u-boot itself is running on the graphical display, but it would be better to communicate the presence of this GUI *in addition to* a serial port serving as a console. 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,
Samer reminded me that today is a holiday in the US, so not everyone will be able to join. I'm going to hold the call regardless because I think there is enough to discuss, and I'll make sure good notes are taken.
g.
On 16/01/2021 12:58, Grant Likely wrote:
Hi all,
Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think there is quite a backlog of items to discuss. Here's what I've got for the agenda so far:
- Update on specific required protocols
* https://github.com/ARM-software/ebbr/issues/60 * https://github.com/ARM-software/ebbr/issues/61 * https://github.com/ARM-software/ebbr/issues/64
- Firmware update requirements
* https://github.com/ARM-software/ebbr/issues/69
- DT fixup protocol proposal
* https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL * https://github.com/ARM-software/ebbr/issues/68
- Other business
If you would like to discuss anything else, please reply to this email.
Dial in details are here:
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Dong Wei -
François Ozog -
Grant Likely -
Grant Likely
-
Heinrich Schuchardt