From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6B46B211944DB for ; Thu, 22 Nov 2018 08:40:47 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0115D7F3EC; Thu, 22 Nov 2018 16:40:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-200.rdu2.redhat.com [10.10.120.200]) by smtp.corp.redhat.com (Postfix) with ESMTP id 224031055007; Thu, 22 Nov 2018 16:40:45 +0000 (UTC) To: Bryan Rosario , edk2-devel@lists.01.org Cc: Alain Gefflaut References: From: Laszlo Ersek Message-ID: Date: Thu, 22 Nov 2018 17:40:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 22 Nov 2018 16:40:47 +0000 (UTC) Subject: Re: Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 16:40:47 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/22/18 01:06, Bryan Rosario via edk2-devel wrote: > Hi all, > > I noticed that there is apparently a hardcoded B/D/F for an IDE Controller > in BdsPlatform.c, when setting bit 15 of a particular register: > https://github.com/tianocore/edk2/blob/14923c1a6bf9940b48feeaf47cb5d6c662b6528c/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c#L1612-L1617 > . > > Why is this hardcoded? Is it just old code that has hung around? It's ancient code that should not exist, arguably. I've always been afraid to rip it out, because I've never known what would break. In general, BDS has zero business writing register of various PCI devices. Even if it does, due to various platform glitches or hacks, BDS should preferably not use PciLib APIs for that, but the UEFI PciIo protocol. (I totally know that OVMF's Platform BDS does not live up to this.) > I noticed > that this code is from this commit, and the surrounding code at the time > had lots of hardcoded B/D/Fs: > https://github.com/tianocore/edk2/commit/40f2c454343be84ab3bacf9955cc8d7842c70b5c > . > > The context of this question is that I'm trying to make this work in a > configuration with an IDE Controller located at a different B/D/F, and so > the hardcoded value of 0/1/1 doesn't work for me. > > If I want to change this so that it's not hardcoded, what is a good > approach? Remove it altogether from BDS (or else move it to the specific UEFI driver) and see if things still work. :) > I've added some code locally to the IdeInitSetTiming function in > SataController.c to set the bit using the PciIo structure which is opened > specifically on the controller in question -- does that sound like the > right approach? Definitely. It certainly helps if you know what those register writes actually mean. (I don't.) Thanks, Laszlo > Link to the function I'm referring to: > https://github.com/tianocore/edk2/blob/f6b0258d25a63ae3d3bc6430abe30fb625abc52a/OvmfPkg/SataControllerDxe/SataController.c#L1091-L1099