Re: EBBR Biweekly (Postponed to 14th Dec)
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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EBBR Biweekly (Postponed to 14th Dec)
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 > ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
EBBR Biweekly (Postponed to 14th Dec)
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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
