Re: [edk2] Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c?
Hi Bryan, If you were talking about PC architecture, I would suggest that there should be a hierarchy of configuration that needs to occur. Specifically, there should be silicon / board / platform specific configuration that is architecturally independent of the SATA driver. Normally, there would be early initialization to write to silicon specific registers. Later, the PCI bus driver should expose PCI device interfaces. That driver would normally be responsible for writing to the PCI configuration header for the device, as well as for configuring any PCI bridges between the host bus and the device. The SATA driver would then connect to the PCI device interface exposed by the PCI bus driver. However, I think you’re using an ARM based system. The architecture is different from what I am used to. Is what you have is a SATA driver talking directly to the PCI device interface? This skips several levels of the architecture that would be responsible for maintaining platform independence. If it were me, I would only put generic SATA code in the SATA driver. There wouldn’t be anything silicon or platform specific at all. If we were talking about the old IDE interfaces (because CF maybe), there used to be stuff for configuring 80 conductor vs 40 conductor cables that was handled by legacy BIOSes, and configuring high speed DMA and PIO transfer modes was silicon specific. In the legacy architectures I worked on, there was usually an interface for silicon specific configuration that was architecturally independent of the IDE driver itself. If you are facing the same sort of thing, then I would define a protocol for features that may require silicon specific register writes, and make my SATA code call that protocol. This allows you to keep all your silicon/board/platform specific code in one location (perhaps one per design), and you don’t have to touch as many files every time your hardware design changes. Ideally, you should have all the things that need to change boiled down to one particular piece of code, so you can focus on what you need to do to make new hardware work when you get new hardware and don’t have to discover all sorts of files that need editing piecemeal as you discover non-functional hardware features. Regards, -Ken. From: Bryan Rosario [mailto:b...@google.com] Sent: Wednesday, November 21, 2018 5:29 PM To: Ken Taylor Cc: Alain Gefflaut; edk2-devel@lists.01.org Subject: Re: [edk2] Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c? Hi Ken, That's what I had guessed -- thanks for confirming that it's platform specific. In my use case, I actually want the code to work on multiple hardware configurations, so I can't just replace the hardcoded B/D/F with the one used by a particular platform. Does the change to SataController.c that I mentioned in the original email make sense? I've tested it and confirmed that it works on my platform, but I want to get a sanity check that that is an appropriate place to put this code. Thanks, Bryan On Wed, Nov 21, 2018 at 4:48 PM Ken Taylor mailto:ken_tay...@phoenix.com>> wrote: Hi Bryan, That appears to be silicon or platform specific code. It's intended for one specific hardware configuration. Unless you have an identical hardware configuration, those particular register writes are actually nonsensical. I think what you need to do is consult the silicon specific documentation for your particular hardware configuration, and determine what silicon specific registers need to be configured to what specific values to support your specific hardware design. Regards, -Ken. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of Bryan Rosario via edk2-devel Sent: Wednesday, November 21, 2018 4:07 PM To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> Cc: Alain Gefflaut Subject: [edk2] Hardcoded IDE Controller B/D/F (0/1/1) in BdsPlatform.c? 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? 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? I've added some code locally to the IdeInitSetTiming function in SataController.c to set the bit using the PciIo structu
Re: [edk2] Fwd: timer ticks ?
Hi David, I think EVT_TIMER is required functionality. Many drivers depend on it. I know it goes away at runtime, but so do the rest of boot services. There's nothing that can be done about that; even the BIOS timer tick was taken over by all modern operating systems, so it wasn't reliably persistent post boot either. Regards, -Ken. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David F. Sent: Monday, October 23, 2017 4:59 PM To: edk2 developers list Subject: [edk2] Fwd: timer ticks ? Hi, Is there a reliable (always available) way to get a timer tick in an application similar to the old 18.2 per second timer tick from BIOS. That one was always there, high speed access (no slow access to a RTC) and the tick count is known (to approx calculate intervals for polling and other things). In UEFI, EVT_TIMER may not be supported. GetTime may be slow RTC access.It can be a counter only since machine was on. TIA! ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SIMD Instruction supported in UEFI?
Hi Amit,
Maybe in UEFI the code in question crosses a cache line boundary when executed
in UEFI, with the loop or part of the instruction itself on one side of the
boundary and the rest on the other? At what point are you trying to execute
this code, is it still from the UEFI shell or have you moved it into a driver
that runs earlier?
You might try changing the linker flags to force 4k code alignment on your test
binary.
Regards,
-Ken.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Amit
kumar
Sent: Wednesday, March 08, 2017 7:10 AM
To: edk2-devel@lists.01.org
Subject: [edk2] SIMD Instruction supported in UEFI?
Hi ;
I have written a UEFI app in ASM which runs XOR on a block of data using SIMD
instructions ("PXOR") in UEFI environment.
It takes around 2 Seconds to run this code, but when i use normal C XOR
operator ("^") it takes 1 Seconds.
Is there something wrong ? I mean SIMD instructions must be giving me better
performance(my expectation);
But when i do same experiment in Windows environment SIMD code ( _mm_xor_si128
) gives me 9 times better performance than normal XOR instruction.
Have i missed something?.
Regards
Amit Kumar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SmmCommunicationCommunicate question?
I think there are a couple of assumptions here that should be reconsidered... First, it is not always the case that entry into SMM on one CPU will always pull all CPUs into SMM. There are methods to deliver targeted SMIs via the local APIC on some processors. In addition, I have 2nd hand knowledge that some processors don't immediately return to SMM on RSM if other processors are still in SMM; this allows some processors to resume early and continue execution while execution on other cores continues in SMM. Second, CPUs are not the only bus master capable of changing the contents of a CommBuffer that is passed to an SMI handler. I could, for example, schedule a USB or a SATA transaction that will clobber CommBuffer contents some arbitrary amount of time after I've triggered an SMI, and CommBuffer would change on the fly even if all my processors are executing known good code in SMM. If you want your SMI handler code to be safe, as a first step, either copy CommBuffer to a local buffer in SMM, or copy all critical parameters such as pointers, BARs, object lengths and commands to local variables. Operate only on local copies from that point forward. Regards, -Ken. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Anbazhagan, Baraneedharan Sent: Thursday, October 13, 2016 6:20 AM To: Paolo Bonzini; Laszlo Ersek Cc: edk2-devel@lists.01.org Subject: Re: [edk2] SmmCommunicationCommunicate question? > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > > On 13/10/2016 11:07, Laszlo Ersek wrote: > > > > Instead, once the first CPU enters SMM, it brings all the other CPUs > > into SMM as well, where they will be executing known, secure code -- > > i.e., the first CPU to enter SMM forces the other CPUs to temporarily > > abandon any (possibly malicious) code the runtime OS may have prepared. > > Only *then* will the verification of the communication buffer commence. > > If the malicious code managed to race the unpriv part of the service > > successfully, now the privileged part will catch that, undisturbed. > > Even this is not strictly necessary if you can set aside some memory in SMRAM > for a > copy the communication buffer. Then you can do: > >tmp = comm buffer size >if tmp > sizeof(privileged buffer) >return error >copy tmp bytes from comm buffer to privileged buffer > > and not look anymore at the buffer provided by the user. > > Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so > there > may be reasons to do that anyway. > > Paolo Am thinking in BDS phase - if a module have periodic callback and uses SmmCommunicate within the callback, then it could potentially overwrite those gSmmCorePrivate pointer while another module trying to use SmmCommunicate. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] USB Control Transfers
Hi Feng,
Yes, I could initialize the buffer to 0xff or 0. I am concerned that I would
need to do the transaction twice to be sure I have the right length, however.
The last byte(s) could be either 0 or 0xff, so how else could I be sure I have
found the correct end of the transfer?
I am concerned that requesting the same report multiple times could break some
devices. I have seen such bad behavior in the past on other USB devices such
as cheap USB flash drives. I know that is USB mass storage and not HID, but
I'm looking at a category of similarly cheap devices and shortcuts may have
been taken.
If this is not in the UEFI specification, I would suggest that this is an error
in the specification. For example, even the C standard "fread" function
returns how much data has been read independently from the buffer/request size,
and this is a similar function in which the amount of data delivered may be
less than the size of the buffer supplied.
Regards,
-Ken.
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: Monday, July 25, 2016 7:20 PM
To: Ken Taylor; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: USB Control Transfers
Hi, Taylor
As far as I know, there is no UEFI interface to return actual transfer length
for usb control transfer.
As for reusing Request parameter, UEFI spec doesn't say we need update the
actual transfer length through this. So EDKII usb implementation doesn't update
it.
For your case, is it possible to initialize your buffer with 0xFF and then
check the validity of the return buffer through Format & Size field?
typedef struct {
UINT16Format;
UINT8 Size;
UINT8 Type;
UINT8 Tag;
HID_DATA Data;
} HID_ITEM;
Thanks
Feng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ken
Taylor
Sent: Tuesday, July 26, 2016 9:23 AM
To: edk2-devel@lists.01.org
Subject: [edk2] USB Control Transfers
Hi All,
I am working on a USB HID device driver. The devices I want to support aren't
legacy (keyboard or mouse) and at least some of them don't appear to support
HID descriptors. I need to parse the first Report descriptor, but because of
the lack of the HID descriptor, I can't know how long any of the report
descriptors are going to be in advance of the transaction that requests the
descriptor.
I have no problem fetching the first report descriptor using
UsbIoControlTransfer with an extra large buffer to contain the report
descriptor (just in case). The devices I'm working on just fill that report
buffer part way and stop at the end of the report descriptor.
Unfortunately, there doesn't seem to be any mechanism to determine how many
bytes of data a device has actually transferred to the buffer during a control
transfer after that transfer completes. The USB IO control transfer function
takes UINTN DataLength, not a pointer to DataLength. I might expect that the
UsbIo protocol would patch the Length field in the EFI_USB_DEVICE_REQUEST
structure to reflect the actual transfer length after the fact, but that
doesn't seem to happen either.
Am I overlooking some hidden interface here, or am I really going to be forced
to use trial reads and buffer scanning to determine how much of the buffer
pointed to by "Data" is actually filled by the device during a control
transfer? This is really bugging me, as I know there's a mechanism for host
controllers to report this information... I've written USB host controller and
bus drivers for other BIOS implementations, and I remember this being possible.
For reference, here's the definition of the control transfer function from the
UsbIo.h protocol definition:
/**
This function is used to manage a USB device with a control transfer pipe. A
control transfer is
typically used to perform device initialization and configuration.
@param This A pointer to the EFI_USB_IO_PROTOCOL instance.
@param Request A pointer to the USB device request that will
be sent to the USB
device.
@param Direction Indicates the data direction.
@param Timeout Indicating the transfer should be completed
within this time frame.
The units are in milliseconds.
@param Data A pointer to the buffer of data that will be
transmitted to USB
device or received from USB device.
@param DataLengthThe size, in bytes, of the data buffer
specified by Data.
@param StatusA pointer to the result of the USB transfer.
@retval EFI_SUCCESS The control transfer has been successfully
executed.
@retval EFI_DEVICE_ERROR The transfer failed. The transfer status is
returned in Status.
@retval EFI_INVALID_PARAMETE One or more parameters are invalid.
@retval EFI_OUT_OF_RESOURCES The request co
[edk2] USB Control Transfers
Hi All, I am working on a USB HID device driver. The devices I want to support aren't legacy (keyboard or mouse) and at least some of them don't appear to support HID descriptors. I need to parse the first Report descriptor, but because of the lack of the HID descriptor, I can't know how long any of the report descriptors are going to be in advance of the transaction that requests the descriptor. I have no problem fetching the first report descriptor using UsbIoControlTransfer with an extra large buffer to contain the report descriptor (just in case). The devices I'm working on just fill that report buffer part way and stop at the end of the report descriptor. Unfortunately, there doesn't seem to be any mechanism to determine how many bytes of data a device has actually transferred to the buffer during a control transfer after that transfer completes. The USB IO control transfer function takes UINTN DataLength, not a pointer to DataLength. I might expect that the UsbIo protocol would patch the Length field in the EFI_USB_DEVICE_REQUEST structure to reflect the actual transfer length after the fact, but that doesn't seem to happen either. Am I overlooking some hidden interface here, or am I really going to be forced to use trial reads and buffer scanning to determine how much of the buffer pointed to by "Data" is actually filled by the device during a control transfer? This is really bugging me, as I know there's a mechanism for host controllers to report this information... I've written USB host controller and bus drivers for other BIOS implementations, and I remember this being possible. For reference, here's the definition of the control transfer function from the UsbIo.h protocol definition: /** This function is used to manage a USB device with a control transfer pipe. A control transfer is typically used to perform device initialization and configuration. @param This A pointer to the EFI_USB_IO_PROTOCOL instance. @param Request A pointer to the USB device request that will be sent to the USB device. @param Direction Indicates the data direction. @param Timeout Indicating the transfer should be completed within this time frame. The units are in milliseconds. @param Data A pointer to the buffer of data that will be transmitted to USB device or received from USB device. @param DataLengthThe size, in bytes, of the data buffer specified by Data. @param StatusA pointer to the result of the USB transfer. @retval EFI_SUCCESS The control transfer has been successfully executed. @retval EFI_DEVICE_ERROR The transfer failed. The transfer status is returned in Status. @retval EFI_INVALID_PARAMETE One or more parameters are invalid. @retval EFI_OUT_OF_RESOURCES The request could not be completed due to a lack of resources. @retval EFI_TIMEOUT The control transfer fails due to timeout. **/ typedef EFI_STATUS (EFIAPI *EFI_USB_IO_CONTROL_TRANSFER)( IN EFI_USB_IO_PROTOCOL*This, IN EFI_USB_DEVICE_REQUEST *Request, IN EFI_USB_DATA_DIRECTION Direction, IN UINT32 Timeout, IN OUT VOID *Data OPTIONAL, IN UINTN DataLength OPTIONAL, OUT UINT32*Status ); Regards, -Ken Taylor Phoenix Technologies, Ltd. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
