Getting Build error related to include path. Looks like some Makefile problem
bus/usb/xhci/usb/xhci.c:36:26: fatal error: arch/virtual.h: No such file or directory #include <arch/virtual.h> On Thu, Mar 2, 2017 at 9:42 AM, Gailu Singh <[email protected]> wrote: > I am not using EFI. I am using coreboot with Intel FSP. Intel confirmed > that XHCI controller is initialized by FSP and any standard XHCI driver > should work on top of that. > > Problem Details: > > Requirement: > My requirement is to load GRUB2 as payload from coreboot and Load Linux > using GRUB2 (from USB pen drive and Hard Disk) based on grub menu selection > > Problem I am facing: > 1. GRUB2 does not recognize USB pen drive, so can not boot linux from USB > pen drive > 2. GRUB2 does not recognize USB keyboard so not able to select menu entry > > Board: Intel Oxbohill CRB (Apollo lake) > > > > On Thu, Mar 2, 2017 at 9:29 AM, Andrei Borzenkov <[email protected]> > wrote: > >> 02.03.2017 06:00, Gailu Singh пишет: >> > Thanks for the update. I will try your patches on Apollo lake and report >> > back the results. Intel strategy seems to be XHCI only option on newer >> > boards so sooner or later xhci support is required in Grub. Thanks for >> your >> > effort to take initiative. >> > >> >> On physical platforms grub normally relies on firmware to access >> devices. What exact problem do you solve? Why do you need direct xHCI >> access? What firmware this board has (I presume, EFI)? >> >> > On Wed, Mar 1, 2017 at 4:07 PM, Bjørn Forsman <[email protected]> >> > wrote: >> > >> >> On 1 March 2017 at 07:57, Andrei Borzenkov <[email protected]> >> wrote: >> >>> Yes, Bjørn Forsman intended to work on implementation. >> >> >> >> So now is apparently a good time to tell you about the status of that >> >> implementation :-) >> >> >> >> >> >> The good: >> >> >> >> I ported the xHCI driver from Coreboot / libpayload to GRUB. In basic >> >> tests, it works. (I tested a Lenovo G50-80 laptop with Intel Wildcat >> >> Point-LP USB xHCI controller [8086:9cb1].) >> >> >> >> >> >> The bad: >> >> >> >> The code doesn't support HUBs and completely hangs on one xHCI >> >> controller I tested (Intel NUC6i5SYH Skylake with Sunrise Point-LP >> >> xHCI USB controller [8086:9d2f]). >> >> >> >> The HUB problem is due to GRUB using a different code path for HUBs >> >> than normal devices. I implemented hooks for "control_transfer" and >> >> "bulk_transfer" in GRUB USB stack, because that required little >> >> changes and it made it easy to hook it up with the xHCI driver. But >> >> when GRUB sees a HUB, it uses the "old" setup_transfer code path which >> >> isn't implemented in the xHCI driver. >> >> >> >> I'm thinking the "hanging" issue (the controller never responds to a >> >> basic "NOP" command) is a problem with the Coreboot driver itself, or >> >> more specifically, the lack of a "quirk" handling for this controller. >> >> But blaming that driver doesn't fix it. >> >> >> >> About the implementation. I tried to change as little code as >> >> possible, both in GRUB and the Coreboot driver, thinking that it'd >> >> make maintenance easier. My reasoning was (perhaps wrongly?) that >> >> there is little help to get in the community, and if I reuse enough of >> >> the Coreboot driver, I can easiliy re-import the driver if/when they >> >> fix some bugs. This "change as little as possible" policy means that >> >> now the xHCI driver initializes and tracks some state that also GRUB >> >> USB stack does. It works but it's not something I think is good enough >> >> to integrate in mainline GRUB. (That's one of the reasons why I didn't >> >> tell you about the status earlier. I don't see how to make it "clean" >> >> enough for mainline. Also, the above issues are sort of blockers in >> >> themselves.) >> >> >> >> >> >> The ugly :-) >> >> >> >> https://github.com/bjornfor/grub/tree/add-coreboot-xhci- >> >> driver-2nd-attempt-v2 >> >> >> >> (I just cleaned up history and rebased on master, so it's less ugly >> >> than it was a few hours ago.) >> >> >> >> Best regards, >> >> Bjørn Forsman >> >> >> > >> >> >
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
