Hello! I'm having problems with K-TEK-M275TP-FN-BL-ML keyboard
(http://www.key-tek.cn/Productview.asp?id=777). It is USB device with
keyboard and touchpad combined. It works in OS correctly, but doesn't work
in SeaBIOS.
I've tried to debug this issue and found that "usb_kbd_setup" function fails
on "(epdesc->wMaxPacketSize != 8)" check, cause "epdesc->wMaxPacketSize" is
actually 32. I've modified this "if" statement to pass 32 value also and now
function completes successfully. But it didn't help to solve my issue. There
are no interrupts from keyboard, "ehci_poll_intr" always returns -1 on
check:
if (token & QTD_STS_ACTIVE) {
// No intrs found.
return -1;
}
I don't know what to do now. What should I check next?
Does SeaBIOS support USB keyboard+touchpad devices at all?
From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Hi,
The following series implements a limited TPM CRB driver. The TIS
device with a TPM 2.0 seems to be ignored by Windows 10, so I
implemented a simple CRB device that I will send shortly on the
qemu-devel. With the CRB device, Windows 10 correctly recognized and
exchange with a TPM 2.0.
As long as the device isn't in qemu, I suppose this series should
remain RFC.
Feedback welcome!
Marc-André Lureau (4):
x86: add readq()
tpm: generalize init_timeout()
tpm: use get_tpm_version() callback
WIP: add TPM CRB device support
src/hw/tpm_drivers.c | 226 ++++++++++++++++++++++++++++++++++++++++++++++++---
src/hw/tpm_drivers.h | 26 ++++++
src/x86.h | 5 ++
3 files changed, 245 insertions(+), 12 deletions(-)
--
2.14.1.146.gd35faa819
First, I can running my qemu guest normally,
And i can use keyboard and mouse in my VM,
But i cannot use those after one day.
And cannot find any useful log in my system.
those message is my VM state( with qemu-monitor-command ):
Device 0.1, Port 1, Speed 1.5 Mb/s, Product G100s Gaming Keyboard, ID: hostdev0
Device 0.2, Port 2, Speed 1.5 Mb/s, Product USB Optical Mouse, ID: hostdev1
it show me qemu add device normally,But i cannot use it
Hi,
Quite a few changes accumulated in master. Time to plan a new release
I think, so we can pick up the improvements in qemu 2.11.
Comments?
Anything pending for qemu which needs firmware support?
cheers,
Gerd
On Thu, Oct 26, 2017 at 11:14:53AM -0400, Matt DeVillier wrote:
> On Thu, Oct 26, 2017 at 10:59 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
> > On Thu, Oct 26, 2017 at 10:46:06AM -0400, Matt DeVillier wrote:
> > > On Thu, Oct 26, 2017 at 12:56 AM, Kevin O'Connor <kevin(a)koconnor.net>
> > wrote:
> > >
> > > > Does the patch below help?
> > > >
> > > > -Kevin
> > > >
> > > >
> > > > --- a/src/hw/sdcard.c
> > > > +++ b/src/hw/sdcard.c
> > > > @@ -405,6 +405,7 @@ sdcard_card_setup(struct sddrive_s *drive, int
> > volt,
> > > > int prio)
> > > > if (!ret && param[0] == vrange)
> > > > hcs = (1<<30);
> > > > // Verify SD card (instead of MMC or SDIO)
> > > > +#if 0
> > > > param[0] = 0x00;
> > > > ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param);
> > > > if (ret) {
> > > > @@ -416,6 +417,7 @@ sdcard_card_setup(struct sddrive_s *drive, int
> > volt,
> > > > int prio)
> > > > drive->card_type |= SF_MMC;
> > > > hcs = (1<<30);
> > > > }
> > > > +#endif
> > > > // Init card
> > > > u32 end = timer_calc(SDHCI_POWERUP_TIMEOUT);
> > > > for (;;) {
> > > >
> > >
> > > with the patch applied, neither the internal eMMC nor the large-capacity
> > > external SD card are detected
> >
> > Yeah - this disables MMC. Any chance to get the log from this run?
> > (Let me know if eMMC is needed to get the log.)
> >
> > -Kevin
> >
>
> with the patch, USB devices are not available from the boot menu either (it
> appears to hang?), and therefore device cannot be booted to get said log
That sounds like a bad compile then - nothing in the patch should have
impacted usb.
In any case, the patch below tests the same thing and it should work
on eMMC also.
-Kevin
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -404,19 +404,8 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio)
ret = sdcard_pio(regs, SC_SEND_IF_COND, param);
if (!ret && param[0] == vrange)
hcs = (1<<30);
- // Verify SD card (instead of MMC or SDIO)
- param[0] = 0x00;
- ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param);
- if (ret) {
- // Check for MMC card
- param[0] = 0x00;
- ret = sdcard_pio(regs, SC_SEND_OP_COND, param);
- if (ret)
- return ret;
- drive->card_type |= SF_MMC;
- hcs = (1<<30);
- }
// Init card
+ int firstloop = 1;
u32 end = timer_calc(SDHCI_POWERUP_TIMEOUT);
for (;;) {
param[0] = hcs | volt; // high-capacity support and voltage level
@@ -424,8 +413,18 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio)
ret = sdcard_pio(regs, SC_SEND_OP_COND, param);
else
ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param);
- if (ret)
+ if (ret) {
+ if (firstloop) {
+ // Check for MMC card
+ firstloop = 0;
+ drive->card_type |= SF_MMC;
+ hcs = (1<<30);
+ end = timer_calc(SDHCI_POWERUP_TIMEOUT);
+ continue;
+ }
return ret;
+ }
+ firstloop = 0;
if (param[0] & SR_OCR_NOTBUSY)
break;
if (timer_check(end)) {
On Thu, Oct 26, 2017 at 10:46:06AM -0400, Matt DeVillier wrote:
> On Thu, Oct 26, 2017 at 12:56 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
> > Does the patch below help?
> >
> > -Kevin
> >
> >
> > --- a/src/hw/sdcard.c
> > +++ b/src/hw/sdcard.c
> > @@ -405,6 +405,7 @@ sdcard_card_setup(struct sddrive_s *drive, int volt,
> > int prio)
> > if (!ret && param[0] == vrange)
> > hcs = (1<<30);
> > // Verify SD card (instead of MMC or SDIO)
> > +#if 0
> > param[0] = 0x00;
> > ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param);
> > if (ret) {
> > @@ -416,6 +417,7 @@ sdcard_card_setup(struct sddrive_s *drive, int volt,
> > int prio)
> > drive->card_type |= SF_MMC;
> > hcs = (1<<30);
> > }
> > +#endif
> > // Init card
> > u32 end = timer_calc(SDHCI_POWERUP_TIMEOUT);
> > for (;;) {
> >
>
> with the patch applied, neither the internal eMMC nor the large-capacity
> external SD card are detected
Yeah - this disables MMC. Any chance to get the log from this run?
(Let me know if eMMC is needed to get the log.)
-Kevin
On Wed, Oct 25, 2017 at 11:02:50PM -0500, Matt DeVillier wrote:
> On Mon, Oct 23, 2017 at 12:04 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
> > On Mon, Oct 23, 2017 at 11:59:16AM -0500, Matt DeVillier wrote:
> > > On Mon, Oct 23, 2017 at 11:34 AM, Kevin O'Connor <kevin(a)koconnor.net>
> > wrote:
> > > > On Mon, Oct 23, 2017 at 10:55:57AM -0500, Matt DeVillier wrote:
> > > > > On Mon, Oct 23, 2017 at 10:50 AM, Kevin O'Connor <kevin(a)koconnor.net
> > >
> > > > > > On Mon, Oct 23, 2017 at 10:39:03AM -0400, Kevin O'Connor wrote:
> > > > > > Unfortunately, I can't see anything wrong in the log - the card
> > isn't
> > > > > > coming out of its initialization phase. I can't see any reason why
> > > > > > that would be. Has the user verified the card works under Linux?
> > > > > card is detected/usable under Linux, no problem there
> > > > Can you grab the syslog/dmesg output from Linux as it detects and
> > > > initializes the card?
> > > sure, any special kernel params for debugging?
> >
> > The more info on the sdcard the better. I'm not hopeful, but maybe
> > something Linux does to the sdcard will help point out why seabios
> > isn't able to init the card.
> >
> > -Kevin
> >
>
> dmesg: https://paste.ubuntu.com/25820588/
> cat /sys/kernel/debug/mmc1/ios : https://paste.ubuntu.com/25821138/
Does the patch below help?
-Kevin
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -405,6 +405,7 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio)
if (!ret && param[0] == vrange)
hcs = (1<<30);
// Verify SD card (instead of MMC or SDIO)
+#if 0
param[0] = 0x00;
ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param);
if (ret) {
@@ -416,6 +417,7 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio)
drive->card_type |= SF_MMC;
hcs = (1<<30);
}
+#endif
// Init card
u32 end = timer_calc(SDHCI_POWERUP_TIMEOUT);
for (;;) {
On Mon, Oct 23, 2017 at 11:59:16AM -0500, Matt DeVillier wrote:
> On Mon, Oct 23, 2017 at 11:34 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Mon, Oct 23, 2017 at 10:55:57AM -0500, Matt DeVillier wrote:
> > > On Mon, Oct 23, 2017 at 10:50 AM, Kevin O'Connor <kevin(a)koconnor.net>
> > > > On Mon, Oct 23, 2017 at 10:39:03AM -0400, Kevin O'Connor wrote:
> > > > Unfortunately, I can't see anything wrong in the log - the card isn't
> > > > coming out of its initialization phase. I can't see any reason why
> > > > that would be. Has the user verified the card works under Linux?
> > > card is detected/usable under Linux, no problem there
> > Can you grab the syslog/dmesg output from Linux as it detects and
> > initializes the card?
> sure, any special kernel params for debugging?
The more info on the sdcard the better. I'm not hopeful, but maybe
something Linux does to the sdcard will help point out why seabios
isn't able to init the card.
-Kevin
