Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command

["Pete Batard" <pete@akeo.ie>]

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 <devel@edk2.groups.io> on behalf of Pete 
> Batard via groups.io <pete=akeo.ie@groups.io>
> *Sent:* Sunday, April 19, 2020 3:06 PM
> *To:* devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warkentin 
> <awarkentin@vmware.com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer 
> El-Haj-Mahmoud <samer@elhajmahmoud.com>
> *Cc:* Leif Lindholm <leif@nuviainc.com>
> *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 <pete@akeo.ie>
>> *Sent:* Sunday, April 19, 2020 9:19 AM
>> *To:* Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj-Mahmoud 
>> <samer@elhajmahmoud.com>; devel@edk2.groups.io <devel@edk2.groups.io>
>> *Cc:* Leif Lindholm <leif@nuviainc.com>; Andrei Warkentin 
>> <awarkentin@vmware.com>
>> *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&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C56cfed340a494707ab0d08d7e49d2d64%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229236035259614&amp;sdata=Ed8iabD5ARgBBYtsWgGw2Webu7dAW5Q9ju3qyqyVzX4%3D&amp;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
>> 
> 
> 
> 
>