Eric Wittmayer [mailto:e...@frescologic.com] wrote:
]Sent: Saturday, June 13, 2015 11:39 AM
]To: edk2-devel@lists.sourceforge.net
]Subject: [edk2] USB3 driver development setup suggestions.
]
]Hello EDK developers,
] I'm looking for suggestions on the easiest development setup for a USB 3
]device Dxe driver. Ideally, I'd prefer a virtualized on a windows host that
]lets me pass through the USB3 device to the UEFI guest.
]I have been using Duet and can build and run a basic driver that will start
]on my device. I haven't been able to get debug output using the DEBUG macro
]from my driver. I check DebugPrintEnabled ( ) and DebugCodeEnabled ( ) in
]my driver and I can see they are both enabled so I'm not sure why I don't
]see output from DEBUG.
]I would also like to see the debug output from the USB stack. Is that
]possible with Duet?
]
]Thanks,
]Eric
For USB, I don't know of a good substitute for debugging on real hardware.
But the good news is that the Duet DEBUG() print macro can be made to work.
The DEBUG() output code was removed to reduce code size. Duet code size is
limited because it uses the MS-DOS 640KB low memory area as a temporary
buffer during boot.
Testing with today's EDK2 trunk (SVN rev 17629) shows that debug output such
as DEBUG (( EFI_D_INFO, "xxx\n")) is not generating any code. Here is one
way to make it work:
1) DuetPkgX64.dsc:
a) replace DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
with
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
b) replace gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x0
with gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|6
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F
I removed the DxeMain.inf overrides for these 3 items so that uniform
values are used through the project.
2) DuetPkg.fdf: Comment out non-essential items to avoid a memory size related
build fail caused by change #1. Standard Duet uses the MS-DOS 640KB low
memory area as a temporary buffer, so code size increases have to be
countered with code size reductions elsewhere.
There is a Windows utility for making a Duet FAT image here:
http://notabs.org/uefi/Edk2DuetBoot.htm
The utility generates the image directly without writing to a physical
drive, so it can streamline the Duet build process.
Thanks,
Scott
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
