From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by mx.groups.io with SMTP id smtpd.web12.5605.1587326800135154778 for ; Sun, 19 Apr 2020 13:06:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=pS1gBrno; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.221.67, mailfrom: pete@akeo.ie) Received: by mail-wr1-f67.google.com with SMTP id d17so9535889wrg.11 for ; Sun, 19 Apr 2020 13:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QEHzHaqrz6lE1W+SJJgW/5GjCqHmMFix1DmJKZ1sx/M=; b=pS1gBrno5gARjqJYTTGQSNPmKHZbM3NG8/ssZXNkGkzoMVW/LRTQ2GLGqsGN4DHKWb qX+JLfbrB9RYdksgbhghh45nlxUdoKDE8aYRXCi8uNQkMhO+WOOHDsLh1Ndk8aKPnDHJ QOeV+BcJLJ/ayWFA6gmrv/NQasqFwue/8guarENuQ+OOYgedkgQCPy9NPmYSj4wEsWrM mMrwGVshOqnWsE7rgoqZ9wbs9k4SjugZEMqnDGe3hSTLUhuCsojKUzifGb0AY2N3/NZE sV5CHuubUtkjrMFc8RbYNddejR5/okeLV8NsTM0VSbCMOV0UlHH8GIa4AmZHuH0iPU9D 1r0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QEHzHaqrz6lE1W+SJJgW/5GjCqHmMFix1DmJKZ1sx/M=; b=LtIsTw+kM9Y9974c6Wi0l/7A/V8pBaBfo1m0hmZeBjIGKEMlTP/GKEagKhC4a4hgx0 IlWVzeiRP3ETI2cboL4nLRVp2sR0fEv42Lmw0ftoMQxB1c+Ii/Qb193s+OtPyDz7Jwcx e3qgoat2zpgsKjBU4rqVIit5WQDuOkKRD06pp9TFBFMUN+Ldg9CqUiUzxxiCCxJNHLmK UU3BmNJzbGo9CS6VkY4JahhkYGMiZ8t6fbbrZ3GNbRY6ZwEZpwr6Gqa//W7tnagORiMo ckPVaH/L5vu140lOjAYvDbTbZ5kZTr91c+PEQA2JqxaWpDFUUDwErOpXLaz2q5A3o9Id JLtw== X-Gm-Message-State: AGi0PubJh/xalXj85uMYOz7ifkT4EZip0HMNHRa9YYpkg/mLloyOMw9E hjLz3D7eBNYTH6B1j5EE9HwA5w== X-Google-Smtp-Source: APiQypLS54moqCAcvIG6GfYf/GTkaPcyOGHnQaxAqybu3uM4LE1IGP6KrF5iYS+xjjjoIT1R9c4jDA== X-Received: by 2002:a5d:464d:: with SMTP id j13mr15197531wrs.269.1587326798674; Sun, 19 Apr 2020 13:06:38 -0700 (PDT) Return-Path: Received: from [10.0.0.122] ([84.203.47.66]) by smtp.googlemail.com with ESMTPSA id y10sm16668204wma.5.2020.04.19.13.06.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 13:06:38 -0700 (PDT) Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command To: devel@edk2.groups.io, awarkentin@vmware.com, Ard Biesheuvel , Samer El-Haj-Mahmoud Cc: Leif Lindholm References: <20200419130417.3298-1-samer@elhajmahmoud.com> <8d59e616-9910-4935-2e1f-5da75fc1d34a@arm.com> <831705c6-0915-ba1a-adc0-3078b2af1a43@akeo.ie> From: "Pete Batard" Message-ID: <28ac6ff0-86eb-fde7-63f6-c1c7dc0f0724@akeo.ie> Date: Sun, 19 Apr 2020 21:06:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit 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%7C27a7ee62d7734fc2000b08d7e46cb8be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229027923593475&sdata=rKm%2BRZE%2FPWkvNTinHgQ5qgA9EDcD4lyIZSZMsHf66d0%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 >