It's part of Tiano, no? We didn't develop it. Yet I see it being used in many Tiano-derived UEFI implementations in the Arm world. I don't see a contract anywhere that all Tiano implementations ought to avoid components that don't fit the UEFI/PI/Shell specs. Can someone point me to such a contract? We're entering the "victimless crime" territory here, and also violating the principle of least surprise. I do agree that DEBUG profile may choose a subset of configuration options, for reasons such as sticking to a smaller configuration (for size, complexity, etc). A ________________________________ From: Pete Batard Sent: Sunday, April 19, 2020 3:24 PM To: Andrei Warkentin ; devel@edk2.groups.io ; Ard Biesheuvel ; Samer El-Haj-Mahmoud Cc: Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command On 2020.04.19 21:21, awarkentin@vmware.com wrote: > So if I understood correctly: > > * If a random person off the street builds edk2 - they don't get TFTP > command out of the box Yup. For the reasons that Ard pointed out (current TFTP being a non-standard hack that should be replaced by something more suitable... eventually). > * Our builds retain TFTP command Yup. > > Correct? > ------------------------------------------------------------------------ > *From:* devel@edk2.groups.io on behalf of Pete > Batard via groups.io > *Sent:* Sunday, April 19, 2020 3:06 PM > *To:* devel@edk2.groups.io ; Andrei Warkentin > ; Ard Biesheuvel ; Samer > El-Haj-Mahmoud > *Cc:* Leif Lindholm > *Subject:* Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] > Platform/RaspberryPi : Enable TFTP shell command > Andrei, > > In case this is your concern, please note that we are not removing TFTP > support at all, which is enabled for the RELEASE builds we produce and > will remain so (and which anyone can enable with the macro if they wish). > > All that will be changed by the updated proposal is that the current > DEBUG ASSERT will be fixed and TFTP support will remain optional, like > it is today. > > So, in this case, I don't think your concern is warranted, because we're > not actually taking any step to deprive anyone of any functionality they > might wish for, and, even with the revised patch, TFTP will remain > enabled in our RELEASE binaries, exactly as it has been before. > > Regards, > > /Pete > > On 2020.04.19 20:56, Andrei Warkentin wrote: >> Hi folks, >> >> If we have to choose abstract goodness over functionality, why wouldn't >> we choose functionality? Functionality that's part of Tiano? The real >> world doesn't care about the TFTP command being an "unsupported hack" or >> not. So there's Tiano-specific code here. Big deal? To rephrase >> differently, why would either Pi 4 developers or Pi 4 UEFI users pay the >> cost of Tiano carrying code that somehow isn't "legit enough" to be enabled? >> >> I mean here we are again, where what goes into the code is being >> dictated by some abstract ideology instead of technical reasons? >> >> A >> ------------------------------------------------------------------------ >> *From:* Pete Batard >> *Sent:* Sunday, April 19, 2020 9:19 AM >> *To:* Ard Biesheuvel ; Samer El-Haj-Mahmoud >> ; devel@edk2.groups.io >> *Cc:* Leif Lindholm ; Andrei Warkentin >> >> *Subject:* Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : >> Enable TFTP shell command >> On 2020.04.19 14:33, Ard Biesheuvel wrote: >>> On 4/19/20 3:04 PM, Samer El-Haj-Mahmoud wrote: >>>> Fix an ASSERT with the TFTP dynamic Shell command on the >>>> RPi3 and RPi4 when running DEBUG builds. Also, enable the >>>> command by default for all builds. >>>> >>> >>> Fixing the ASSERT is fine but I am reluctant to enable this by default. >> >> I'm going to second this. >> >> To answer a question Samer was asking elsewhere, this is actually part >> of the reason why TFTP is not enabled in the DEBUG builds we produce at >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4&data=02%7C01%7Cawarkentin%40vmware.com%7Cff25433f108e490d28fc08d7e49fa694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229246665197560&sdata=rgUNgoQgPZGgfcQaQfzE6hn3WNj1Y5sgv6Zr9pbCJGg%3D&reserved=0 > >> (See build_firmware.sh), the reasoning >> being that if someone encounters an issue with RELEASE and we ask them >> to troubleshoot with the DEBUG artifact, we want to eliminate potential >> troublemakers when they try that. >> >>> It is a non-standard hack that ARM contributed in the past, and is not >>> covered by the EFI of Shell specifications. If RPi4 is intended to be a >>> showcase for UEFI on ARM done right, we should not enable this at all. >> >> Here I have to point out that RPi4 becoming a showcase because we intend >> to is not what we are pursuing (because if it was a matter of "willing" >> a showcase into existence, we would have picked a platform with a lot >> less quirks, more comprehensive documentation, and so on). >> >> Instead, we estimate that due to its price point and widespread >> availability, it *is* going to become a de facto showcase, whether >> everybody likes it or not. And that is the reason we want to treat is as >> a showcase where possible. >> >> Regards, >> >> /Pete >> > > > >