From: Laszlo Ersek <lersek@redhat.com>
To: Bryan Rosario <bcr@google.com>, edk2-devel@lists.01.org
Cc: Alain Gefflaut <alaingef@google.com>
Subject: Re: Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c?
Date: Thu, 22 Nov 2018 17:40:45 +0100 [thread overview]
Message-ID: <ba01df50-f3fc-e13d-95f4-e918d8791eb2@redhat.com> (raw)
In-Reply-To: <CAAz1XL+dsHPrjeFqfvcx36wHBT_igDDqEb2H4gZLhMgcDwafZA@mail.gmail.com>
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
prev parent reply other threads:[~2018-11-22 16:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 0:06 Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c? Bryan Rosario
[not found] ` <8147e54ded6e405abdafbed45bd52199@SCL-EXCHMB-13.phoenix.com>
2018-11-22 1:28 ` Bryan Rosario
2018-11-22 2:06 ` Ken Taylor
2018-11-22 3:05 ` Bryan Rosario
2018-11-22 16:40 ` Laszlo Ersek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba01df50-f3fc-e13d-95f4-e918d8791eb2@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox