From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (NAM10-MW2-obe.outbound.protection.outlook.com [40.107.94.78]) by mx.groups.io with SMTP id smtpd.web11.5520.1587326195211379808 for ; Sun, 19 Apr 2020 12:56:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=HTQCc4zI; spf=pass (domain: vmware.com, ip: 40.107.94.78, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VBt7OG5PYWO4Ti2Jgzq1VuDGPFwr/98xweHHIwC/UsN9dBSDeV/5Y1ORqMNc/+i1FEqvsjeN+DPWJLDnG7k5br/8XhUolDK9e0ofHAYJ1fuTlJC9GZ0W8FV9HrTr/1gG5j+OzqNTd7NDvcpsugr1kAKCgUDNmx+R8vPrABvNS6aAscSYBUi2WeXULpO+wffBlPgz7VU/81WeFnjT7F/anSZZLaFsWgadQCHd1+r2BZy6+cCynUJgfB25iMreXD9OmwP/60sp47p6EToDrko6WFYLpEH+b1tSG7wUy1bbbMP3pwgKeplxD5vzHAB8gf79a+VAtj8LoKFNK8lgDI9qpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vQbuSKAhpFXKLVgWQOi9snFgd0VzMR2TUXtR5JhUT8o=; b=Md6Gm/2o+W05o68gDS3XABMd1tdS7fZGHa+2PsCRJrJszQj9oA4jdcphRiNk1N4LTFgL9ASrV2p9etiiALSN4Xk3nhktZQ+M49ZfbXAT1KmWsFVS1NCxCl0seIhgn1/BaXBYZ4DNIipp9AXH3MiuVSFcAxDodloS82+sEG/0r35mLp0U+SE5opJ2OraI/AFsy+IG4OEXaz2PF7D1VMMMQo7J9xOnedD8fRsuOvtOtDIz3rLuXkfvfKI2KDi43GV04UZdknWRXoLyKTTCo/+FtDnyFQYle4jafySHkqqn/8Mv+lAAdK2iiUb3D4yjwIcvAWcZ4GNFIOm/oR2B42l7Ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vQbuSKAhpFXKLVgWQOi9snFgd0VzMR2TUXtR5JhUT8o=; b=HTQCc4zIogeBuRYw2Jdb94Irws43dTFuUimUYGAKWKnHTdZaMsvYSE//nvuTUAbwvb4RRAvvU3AZ2CTQ+AlfHcSt7YcDfxCg0s4RjzrtRV1lCjV1FQr4vFQqFexNsTgqrxBqIy0ew4O3hWLHJ4YbhgviLDY6QD8KhH4Yibffw6Y= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB2914.namprd05.prod.outlook.com (2603:10b6:404:35::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Sun, 19 Apr 2020 19:56:32 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84%5]) with mapi id 15.20.2921.027; Sun, 19 Apr 2020 19:56:32 +0000 From: "Andrei Warkentin" To: Pete Batard , Ard Biesheuvel , Samer El-Haj-Mahmoud , "devel@edk2.groups.io" CC: Leif Lindholm Subject: Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Topic: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Index: AQHWFksLVB8KW5eI1E6krRdTNHmDgaiAcbcAgAAM2gCAAFvq3g== Date: Sun, 19 Apr 2020 19:56:32 +0000 Message-ID: References: <20200419130417.3298-1-samer@elhajmahmoud.com> <8d59e616-9910-4935-2e1f-5da75fc1d34a@arm.com>,<831705c6-0915-ba1a-adc0-3078b2af1a43@akeo.ie> In-Reply-To: <831705c6-0915-ba1a-adc0-3078b2af1a43@akeo.ie> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=awarkentin@vmware.com; x-originating-ip: [98.214.99.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d96f8f2a-7602-4352-c70c-08d7e49bc246 x-ms-traffictypediagnostic: BN6PR05MB2914: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(366004)(76116006)(478600001)(52536014)(2906002)(71200400001)(186003)(86362001)(4326008)(8936002)(316002)(5660300002)(966005)(110136005)(66476007)(66946007)(8676002)(81156014)(66446008)(64756008)(66556008)(53546011)(6506007)(55016002)(26005)(19627405001)(45080400002)(9686003)(7696005)(33656002);DIR:OUT;SFP:1101; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CzhgJmQd1ei479m/4oQd71qqfRSL8rnAyErA3jOvEjApvN45s+QncI/2KvnCiEqCnNXhBUOndQp0yO6KKO4b0bLAiBkeSftTHNSwhrAghQUmz5xLkBa0bPm5BMt48BXfzI93qy7vIg9TWsAcl1PQAZghp7jAeXkA7mHJJoxoweTShxaUBnjPIV1swqwyOpkEo81GnAfSNMXdtxNSKUCILYhUyFtCEQNHozR3xA4SLRKEjoxA/qy12YK4/jMs1RYLvdK5vGTp5hRf+IobwgjFck7KGVkqqmZ7zS3F8TwKwEgM5tnoPH2+3ZjUBADZuljG/B8DPmTDv6nWfaIlMxzNQ0hVUdAyljP8nSaoGDnqMtf75g+l6Ys0+XlNJGuvhhs/XQ3LMz0IJ1x9ZBNI8LHUMayQSwbtBUSegMBsOp5aQXCgXA2sMYfdJjxwNjM28z/DTJeJiJaw6ZtBEtIxtiFmv0FNqm+s8Y/84XXPVLPJMjhkyAAjiidSGwgUb/Jv5WKJGjPmLPQovCxbBGUH0Kd6mg== x-ms-exchange-antispam-messagedata: yWaRM/20TDjKJGZpwIwwPrSlQGv3IfWuRaBh6OQgx2pGKlAjjfxRwPyB4R0Htj8rfUpLFWrIpz9+4KRSi0PPzcOXCaD2fotQ0vaK53mlY5BxUzuZGVn/RZ2oDp2bo7m7YaABIytmKrgFG+132csjNg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: d96f8f2a-7602-4352-c70c-08d7e49bc246 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 19:56:32.4418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Stxc1sWw9MwwAurpCDbKKGSCL5vqWQp58wyqxYyIjiMVwT7lONbJjOIPAHBib6NhHRDsrwqnD72b8Oh5kgMB8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2914 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB34114BA7A2CC295D657EEEAAB9D70BN6PR05MB3411namp_" --_000_BN6PR05MB34114BA7A2CC295D657EEEAAB9D70BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 do= esn't care about the TFTP command being an "unsupported hack" or not. So th= ere's Tiano-specific code here. Big deal? To rephrase differently, why woul= d 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 b= y 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 TF= TP 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=3Dhttps%3A%2F%2Fgithub.= com%2Fpftf%2FRPi4&data=3D02%7C01%7Cawarkentin%40vmware.com%7C27a7ee62d7= 734fc2000b08d7e46cb8be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C6372290= 27923593475&sdata=3DrKm%2BRZE%2FPWkvNTinHgQ5qgA9EDcD4lyIZSZMsHf66d0%3D&= amp;reserved=3D0 (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 --_000_BN6PR05MB34114BA7A2CC295D657EEEAAB9D70BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 do= esn'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 "l= egit enough" to be enabled?

I mean here we are again, where what goes into the code is being dictated b= y 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-Mahm= oud <samer@elhajmahmoud.com>; devel@edk2.groups.io <devel@edk2.gro= ups.io>
Cc: Leif Lindholm <leif@nuviainc.com>; Andrei Warkentin <aw= arkentin@vmware.com>
Subject: Re: [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : En= able 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=3Dhttps%3A%2F%2Fgithub.com%2Fpftf%2FRPi4&amp;data=3D0= 2%7C01%7Cawarkentin%40vmware.com%7C27a7ee62d7734fc2000b08d7e46cb8be%7Cb3913= 8ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637229027923593475&amp;sdata=3DrK= m%2BRZE%2FPWkvNTinHgQ5qgA9EDcD4lyIZSZMsHf66d0%3D&amp;reserved=3D0 (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
--_000_BN6PR05MB34114BA7A2CC295D657EEEAAB9D70BN6PR05MB3411namp_--