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&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
>>
>
>
>
>