I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
Draft agenda:
* Action item review * EBBR Testing Efforts (SCT, FWTS, etc) * UEFI Exception text changes * Next release schedule * Other business
Time: This is a recurring meeting Meet anytime
Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 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 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys
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 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
Best regards
Heinrich
Draft agenda:
- Action item review
- EBBR Testing Efforts (SCT, FWTS, etc)
- UEFI Exception text changes
- Next release schedule
- Other business
Time: This is a recurring meeting Meet anytime
Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 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 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys
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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 07.12.20 16:07, Heinrich Schuchardt wrote:
On 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
I think it's only in SCT because it's used in Shell.efi, no? So if we can somehow remove it from there, it should also remove the dependency for SCT I hope.
And yes, I agree 100% - HII really shouldn't be necessary for EBBR.
Alex
On 07.12.20 16:24, Alexander Graf wrote:
On 07.12.20 16:07, Heinrich Schuchardt wrote:
On 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
I think it's only in SCT because it's used in Shell.efi, no? So if we can somehow remove it from there, it should also remove the dependency for SCT I hope.
And yes, I agree 100% - HII really shouldn't be necessary for EBBR.
Alex
Alex, you are right it is the shell that is using HII strings and the HII database extensively. But at least all other HII protocols can be removed from the list of requirements.
Best regards
Heinrich
On 07.12.20 17:17, Heinrich Schuchardt wrote:
On 07.12.20 16:24, Alexander Graf wrote:
On 07.12.20 16:07, Heinrich Schuchardt wrote:
On 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
I think it's only in SCT because it's used in Shell.efi, no? So if we can somehow remove it from there, it should also remove the dependency for SCT I hope.
And yes, I agree 100% - HII really shouldn't be necessary for EBBR.
Alex
Alex, you are right it is the shell that is using HII strings and the HII database extensively. But at least all other HII protocols can be removed from the list of requirements.
I would love if we could use that chance to get rid of the coupling of Shell.efi and HII as well :)
Alex
On 07.12.20 17:38, Alexander Graf wrote:
On 07.12.20 17:17, Heinrich Schuchardt wrote:
On 07.12.20 16:24, Alexander Graf wrote:
On 07.12.20 16:07, Heinrich Schuchardt wrote:
On 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
I think it's only in SCT because it's used in Shell.efi, no? So if we can somehow remove it from there, it should also remove the dependency for SCT I hope.
And yes, I agree 100% - HII really shouldn't be necessary for EBBR.
Alex
Alex, you are right it is the shell that is using HII strings and the HII database extensively. But at least all other HII protocols can be removed from the list of requirements.
I would love if we could use that chance to get rid of the coupling of Shell.efi and HII as well :)
Alex
The Unicode strings for the Shell are in the following files. The idea is to make them all translatable. Currently only English texts exist.
ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni ShellPkg/Application/Shell/Shell.uni ShellPkg/DynamicCommand/DpDynamicCommand/Dp.uni ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/TextEditStrings.uni ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/HexeditStrings.uni ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/SmbiosViewStrings.uni ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.uni ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.uni ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.uni ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.uni ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.uni ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni
Best regards
Heinrich
On 07.12.20 17:56, Heinrich Schuchardt wrote:
On 07.12.20 17:38, Alexander Graf wrote:
On 07.12.20 17:17, Heinrich Schuchardt wrote:
On 07.12.20 16:24, Alexander Graf wrote:
On 07.12.20 16:07, Heinrich Schuchardt wrote:
On 07.12.20 14:43, Grant Likely wrote:
I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week.
A topic that interests me is how much HII support we need in EBBR.
Chapter 2.6.2 of the UEFI spec has "If a platform includes a configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped fonts, you must support EFI_HII_FONT_PROTOCOL."
"A configuration infrastructure" in my view should be nothing required by EBBR.
It has only been the UEFI SCT driving U-Boot to implement some HII protocol stubs. I wonder if this dependency could be removed from the SCT.
I think it's only in SCT because it's used in Shell.efi, no? So if we can somehow remove it from there, it should also remove the dependency for SCT I hope.
And yes, I agree 100% - HII really shouldn't be necessary for EBBR.
Alex
Alex, you are right it is the shell that is using HII strings and the HII database extensively. But at least all other HII protocols can be removed from the list of requirements.
I would love if we could use that chance to get rid of the coupling of Shell.efi and HII as well :)
Alex
The Unicode strings for the Shell are in the following files. The idea is to make them all translatable. Currently only English texts exist.
Just a crazy thought: Could Shell.efi provide its own HII implementation as a fallback if the system doesn't have one?
Alex
boot-architecture@lists.linaro.org