From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mx.groups.io with SMTP id smtpd.web11.6039.1587327864624779986 for ; Sun, 19 Apr 2020 13:24:25 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=BN9mrzg2; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.128.65, mailfrom: pete@akeo.ie) Received: by mail-wm1-f65.google.com with SMTP id 188so2528371wmc.2 for ; Sun, 19 Apr 2020 13:24:24 -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=tD4NYjTB1S4v0elfWnpX+BrMq/tuo2IDg67DZ49DTBM=; b=BN9mrzg2PrnDxo5Q/gU8ebMgqMqLmM+VgL7A3A1oILZk1Tqpg0T8E0yC2n7XJ0pOkE 9MG8bBrq1ITK6vxxCT50QgYnP/GWBe+wKtE9hi7MP6QcKkLV1VOHy1umuiouz1X/aAHZ /wuE6f8grSTPcBFLUbUm0TEhBLXssOx7pVa3+o3iV7ipmP35GK7rcYx8zwPmKtfft6qN 895Fy6gb71LQq3POs7hjf6F39tuyv0j7uKoffcroO7TmZN44gcvp23W+hwIZbV6rw3gN IjRUWXb7rfXw8gl5fcI8fZE/S00wId60XZ6Ipw7x7dzNgbUlI1B9Gr0ryG5IZeEzD0Fb QerA== 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=tD4NYjTB1S4v0elfWnpX+BrMq/tuo2IDg67DZ49DTBM=; b=sdjzFJRCTThHtcws7YIANsQ916oOilUmXgBLZn7idZs6b6dFXfJvb+h59rvcxEQi/n PR7VEZ9j+VG/bNrN7QjavnuxZXhGasTQX0GdQOf65Q67h+G/mh2Q5k2jC7mp+Fzdx7b5 Jq/963ZSBuCVNT59RXxAUST4+JXmxrH8AA694E3DKneL9MCKVKQpF8V+I50cW5obUd1R KeHkHg5e6y5ws8YsvyYxQ5iygZ6J6HjsAa/v/fYUK2/XhcXBTaw+McBiZPGRKAmir/Bh Pq+rR6eZYnv5dQbOYUmr9OsXONgU/9ZaI+He+pChrElD99QqPTA21jAjlPNIMFedwJjF uUYw== X-Gm-Message-State: AGi0PuZM4ixvE+SlHvftdwxLHsxTHPEvS4/iMiyoVtZflksky5yii25l z6kE0OMigZMrgVjYIuPaJGRCfQ== X-Google-Smtp-Source: APiQypJM5lugQsp3aZPeq9o0ettJa4LqHCLSCqIFtEb+7Jg85qtm+dgRXbgy1Sk2a7gRS1iFf8SvVw== X-Received: by 2002:a1c:5502:: with SMTP id j2mr1467491wmb.56.1587327863111; Sun, 19 Apr 2020 13:24:23 -0700 (PDT) Return-Path: Received: from [10.0.0.122] ([84.203.47.66]) by smtp.googlemail.com with ESMTPSA id t20sm14530365wmi.2.2020.04.19.13.24.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 13:24:22 -0700 (PDT) Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command To: awarkentin@vmware.com, "devel@edk2.groups.io" , 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> <28ac6ff0-86eb-fde7-63f6-c1c7dc0f0724@akeo.ie> From: "Pete Batard" Message-ID: <2046f801-45c2-f591-fdf8-18e2edb093d3@akeo.ie> Date: Sun, 19 Apr 2020 21:24:21 +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 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%7C56cfed340a494707ab0d08d7e49d2d64%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229236035259614&sdata=Ed8iabD5ARgBBYtsWgGw2Webu7dAW5Q9ju3qyqyVzX4%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 >> > > > >