Kiper
---
grub-core/bus/usb/ehci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/bus/usb/ehci.c b/grub-core/bus/usb/ehci.c
index 9abebc6bd..2db07c7c0 100644
--- a/grub-core/bus/usb/ehci.c
+++ b/grub-core/bus/usb/ehci.c
@@ -218,7 +218,7 @@ enum
#define
On Thu, Mar 18, 2021 at 08:35:46PM -0500, Glenn Washburn wrote:
> Signed-off-by: Glenn Washburn
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Signed-off-by: Glenn Washburn
---
grub-core/bus/usb/usbhub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/grub-core/bus/usb/usbhub.c b/grub-core/bus/usb/usbhub.c
index a06cce302..85ccf3a4b 100644
--- a/grub-core/bus/usb/usbhub.c
+++ b/grub-core/bus/usb/usbhub.c
trick Rudolph wrote:
> Parse the SS_ENDPOINT_COMPANION descriptor, which is only present on
> USB 3.0 capable devices and xHCI controllers. Make the descendp an
> array of pointers to the endpoint descriptor as it's no longer an
> continous array.
>
> Signed-off-by: Patrick
From: Javier Martinez Canillas
The maximum number of configurations and interfaces are fixed but there is
no out-of-bound checking to prevent a malicious USB device to report large
values for these and cause accesses outside the arrays' memory.
Fixes: CVE-2020-25647
Reported-by: Joseph Ta
27;t mean to. I only meant
to suggest that there were possible unaddressed issues. Glad to hear
those were already taken care of.
> As stated in the commit message, USB 3.1 and USB 3.2 are not
> tested, as I lack hardware to test this. I'm not going to look into
> this any furt
Hi Glenn,
yes it's the same patch series, but has been cleaned and improved a lot.
I've addressed most of the comments received earlier.
As stated in the commit message, USB 3.1 and USB 3.2 are not
tested, as I lack hardware to test this. I'm not going to look into this
any furth
Hi Patrick,
Thanks for the contribution. I think this would be a great addition to
GRUB. However, there are a few issues I see at the moment.
On Mon, 7 Dec 2020 08:41:20 +0100
Patrick Rudolph wrote:
> Add basic support for xHCI USB controllers and non root xHCI hubs.
> The motivation
Add support for xHCI USB controllers.
The code is based on seabios implementation, but has been heavily
modified to match grubs internals.
Changes done in version 2:
* Code cleanup
* Code style fixes
* Don't leak memory buffers
* Compile without warnings
* Add more defines
* Add more h
Tested on Intel PCH C246, the USB3 hub can be configured by grub.
Issues:
* USB3 devices connected behind that hub are sometimes not detected.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/usbhub.c | 40 --
include/grub/usbdesc.h | 1 +
include
The xHCI code needs to be called for attaching or detaching a device.
Introduce two functions pointers and call it from the USB hub code.
Will be used in future commits, currently this doesn't change any functionality.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/ehci.c | 2 ++
Store the root port number, the route, consisting out of the port ID
in each nibble, and a pointer to driver private data.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/usbhub.c | 14 ++
include/grub/usb.h | 5 +
2 files changed, 15 insertions(+), 4 deletions
Will be used in future patches.
Signed-off-by: Patrick Rudolph
---
include/grub/usb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/grub/usb.h b/include/grub/usb.h
index 0527a3e2b..f65ac4f5d 100644
--- a/include/grub/usb.h
+++ b/include/grub/usb.h
@@ -47,7 +47,8 @
Parse the SS_ENDPOINT_COMPANION descriptor, which is only present on USB 3.0
capable devices and xHCI controllers. Make the descendp an array of pointers
to the endpoint descriptor as it's no longer an continous array.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/serial/common.c
Add basic support for xHCI USB controllers and non root xHCI hubs.
The motivation is to use this code on platforms that do not provide
user input by runtime services (like BIOS or UEFI platform) do.
This is the case when GRUB is used as coreboot payload for example.
The code is based on seabios
Parse the SS_ENDPOINT_COMPANION descriptor, which is only present on USB 3.0
capable devices and xHCI controllers. Make the descendp an array of pointers
to the endpoint descriptor as it's no longer an continous array.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/serial/common.c
The xHCI code needs to be called for attaching or detaching a device.
Introduce two functions pointers and call it from the USB hub code.
Will be used in future commits, currently this doesn't change any functionality.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/ehci.c | 2 ++
Add basic support for xHCI USB controllers.
The code is based on seabios implementation, but has been heavily
modified to match grubs internals.
Changes done in version 2:
* Code cleanup
* Code style fixes
* Don't leak memory buffers
* Compile without warnings
* Add more defines
* Add
Will be used in future patches.
Signed-off-by: Patrick Rudolph
---
include/grub/usb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/grub/usb.h b/include/grub/usb.h
index 0527a3e2b..f65ac4f5d 100644
--- a/include/grub/usb.h
+++ b/include/grub/usb.h
@@ -47,7 +47,8 @
Store the root port number, the route, consisting out of the port ID
in each nibble, and a pointer to driver private data.
Signed-off-by: Patrick Rudolph
---
grub-core/bus/usb/usbhub.c | 14 ++
include/grub/usb.h | 5 +
2 files changed, 15 insertions(+), 4 deletions
Add support for xHCI USB controllers.
The code is based on seabios implementation, but has been heavily
modified to match grubs internals.
Changes done in version 2:
* Code cleanup
* Code style fixes
* Don't leak memory buffers
* Compile without warnings
* Add more defines
* Add more h
Hi,
Noted. But whenever I am running "insmod ohci" or other host controller
(ehci or uhci) in grub command line and then "usb", I get always "(hd0,
mdos1) not found error" even for serial modem device.
Please help.
with regards,
Arindam
On Wed, Aug 26, 202
You need to insmod the usb controller driver
вт, 25 авг. 2020 г., 18:06 Arindam Khan :
> Hi,
>
>I am working on a custom STM32 board and have configured the board's
> USB OTG as a serial modem device. In Linux, it is getting detected as a
> "/dev/ttyACM" and
Hi,
I am working on a custom STM32 board and have configured the board's USB
OTG as a serial modem device. In Linux, it is getting detected as a
"/dev/ttyACM" and all read and write is working fine. However, when I load
the "usbtest" module of grub and run it with t
Hi Jan,
I noticed that the code will not handle XHCI controllers with multiple
USB 3 port ranges.
This is no problem with USB 3.0 controllers, but the USB 3.1 and USB
3.2 specs brought additional speeds.
At my workplace we have a Ryzen mainboard with an XHCI controller
where 2 ports support up to
and create a pull request
to your repo with some fixes in the future?
On Thursday, August 13, 2020, 05:52:58 PM GMT+3, Jan Suhr | Nitrokey via
Grub-devel wrote:
Hi!
We just published our development of XHCI (USB 3.0) support for GRUB
[1]. It was tested with Supermicro X11SSH-TF
Hi!
We just published our development of XHCI (USB 3.0) support for GRUB
[1]. It was tested with Supermicro X11SSH-TF. Currently it's a fork of
GRUB and we would like to get it merged into mainline GRUB. Any
interest, feedback?
This fork was developed for us by 9elements. Many thanks to
Hi,
On 8/21/18, Sherry Zhang(BJ-RD) wrote:
> But I have found the USB keyboard module-usb_keyboard.mod that I don't load
> ,
> So why the usb keyboard can be used when I don't load usb modules?
A better question is, why does "module-usb_keyboard.mod" exist in the
0
Bufio 1
Gettext 1
Terminal 2
Crypto2
Extcmd 2
Boot 2
Biosdisk 1
Part_msdos 1
Ext2 1fshelp
Fshelp2
But I have found the USB keyboard module-usb_keyboard.
GRUB, i'm
interesting to know if GRUB implicitily (that is without an explicit command
from a user) can write to a drive attached to a computer.
In other words if, during the boot loader inizialization phase, the GRUB
does, in some way, writing operations into the USB, IDE and SATA
dri
mm ... note that terminal_input/terminal_output also auto-load
>> modules that handle serial ports. So this still will not be
>> equivalent, it will require user to manually pre-load USB. Did you
>> actually test this version of patch? Do you pre-load USB modules
>> somewhe
gt; modules that handle serial ports. So this still will not be
> equivalent, it will require user to manually pre-load USB. Did you
> actually test this version of patch? Do you pre-load USB modules
> somewhere?
Nope, I took your word literally and just changed the function.
Assuming it&#
On Fri, Nov 18, 2016 at 1:36 PM, Joonas Lahtinen
wrote:
> If usbX serial port is missing, try to poll USB devices. This makes them
> appear at least on Intel NUC devices DN2820FYKH and DCCP847DYE.
>
> This fixes cases where you try to configure usbX serial at the beginning
> of
If usbX serial port is missing, try to poll USB devices. This makes them
appear at least on Intel NUC devices DN2820FYKH and DCCP847DYE.
This fixes cases where you try to configure usbX serial at the beginning
of a script, like:
serial usb0 --speed=115200 --word=8 --parity=none --stop=1
10.11.2016 16:45, Joonas Lahtinen пишет:
> If usbX serial port is missing, try to poll USB devices. This makes them
> appear at least on Intel NUC devices DN2820FYKH and DCCP847DYE.
>
> This fixes cases where you try to configure usbX serial at the beginning
> of a script, like
If usbX serial port is missing, try to poll USB devices. This makes them
appear at least on Intel NUC devices DN2820FYKH and DCCP847DYE.
This fixes cases where you try to configure usbX serial at the beginning
of a script, like:
serial usb0 --speed=115200 --word=8 --parity=none --stop=1
This is not meaningless, it is page break.
On Tue, Feb 2, 2016 at 4:16 PM, ByeoungWook Kim wrote:
> The `126 line` was a meaningless blank.
> 126 line was '^L'.
>
> Signed-off-by: Byeoungwook Kim
> ---
> grub-core/bus/usb/usbhub.c | 1 -
> 1 file changed, 1 de
The `126 line` was a meaningless blank.
126 line was '^L'.
Signed-off-by: Byeoungwook Kim
---
grub-core/bus/usb/usbhub.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/grub-core/bus/usb/usbhub.c b/grub-core/bus/usb/usbhub.c
index 34a7ff1..98246b7 100644
--- a/grub-core/bus/us
bootstrap code, which is not executed and thus
is likely not significant.
Wanna bet?
Could you test if the attached patch works for you on newer Mac? Note,
that it still does not detect EFI bootable USB stick if it is inserted
before power on - only when you stop in boot manager and insert stick
ootstrap code, which is not executed and thus
>>> is likely not significant.
>>>
>>
>> Wanna bet?
>>
>> Could you test if the attached patch works for you on newer Mac? Note,
>> that it still does not detect EFI bootable USB stick if it is inserted
>&
?
Could you test if the attached patch works for you on newer Mac? Note,
that it still does not detect EFI bootable USB stick if it is inserted
before power on - only when you stop in boot manager and insert stick.
I cannot confirm this finding. The ISOs made before the fix hang the
boot manager if
23.12.2015 22:37, Alexander E. Patrakov пишет:
> Bytes 0x3e .. 0x1fe: x86 bootstrap code, which is not executed and thus
> is likely not significant.
>
Wanna bet?
Could you test if the attached patch works for you on newer Mac? Note,
that it still does not detect EFI bootable USB stick
23.12.2015 23:44, Andrei Borzenkov пишет:
OK, it turned out to be not related to xorriso, but for the record ...
Mac does not like FAT created by mformat. I can reproduce it easily by
creating single MSDOS partition on USB stick of type 0xef size 2880K,
formatting it with same options as grub
22.12.2015 23:02, Andrei Borzenkov пишет:
> I tested stock grub-mkrescue on MacBook 3,1 (late 2007, Core 2 Duo) and
> iMac 9.1 (2009, same CPU) as USB stick. Neither boots; moreover,
> inserting USB stick when boot manager is shown hangs system (it stops
> reacting to mouse/keyboard);
23.12.2015 01:02, Andrei Borzenkov пишет:
I tested stock grub-mkrescue on MacBook 3,1 (late 2007, Core 2 Duo) and
iMac 9.1 (2009, same CPU) as USB stick. Neither boots; moreover,
inserting USB stick when boot manager is shown hangs system (it stops
reacting to mouse/keyboard); if stick is
I tested stock grub-mkrescue on MacBook 3,1 (late 2007, Core 2 Duo) and
iMac 9.1 (2009, same CPU) as USB stick. Neither boots; moreover,
inserting USB stick when boot manager is shown hangs system (it stops
reacting to mouse/keyboard); if stick is inserted during boot it never
gets as far as even
I tested stock grub-mkrescue on MacBook 3,1 (late 2007, Core 2 Duo) and
iMac 9.1 (2009, same CPU) as USB stick. Neither boots; moreover,
inserting USB stick when boot manager is shown hangs system (it stops
reacting to mouse/keyboard); if stick is inserted during boot it never
gets as far as even
El 25/01/15 a las 09:15, adrian15 escribió:
El 25/01/15 a las 09:03, adrian15 escribió:
El 24/01/15 a las 01:12, adrian15 escribió:
El 22/01/15 a las 22:25, Kris Moore escribió:
(Hopefully I'm not creating new threads when replying)
I had only tested 2.00 version (Where the hard disk is not
El 25/01/15 a las 09:03, adrian15 escribió:
El 24/01/15 a las 01:12, adrian15 escribió:
El 22/01/15 a las 22:25, Kris Moore escribió:
Hey all,
We are trying to create hybrid USB/DVD images, and they work just fine
on BIOS. However it doesn't seem to work when creating UEFI.
We are usin
El 24/01/15 a las 01:12, adrian15 escribió:
El 22/01/15 a las 22:25, Kris Moore escribió:
Hey all,
We are trying to create hybrid USB/DVD images, and they work just fine
on BIOS. However it doesn't seem to work when creating UEFI.
We are using the following:
# grub-mkrescue -d "
El 22/01/15 a las 22:25, Kris Moore escribió:
Hey all,
We are trying to create hybrid USB/DVD images, and they work just fine
on BIOS. However it doesn't seem to work when creating UEFI.
We are using the following:
# grub-mkrescue -d "/usr/local/lib/grub/x86_64-efi" -o
-- -
В Fri, 23 Jan 2015 21:38:27 +0300
Andrei Borzenkov пишет:
> В Fri, 23 Jan 2015 19:29:07 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
> >
> > > But returning (hd0,gpt2) would also be wrong here - ESP on CD image is
> > > empty, we need to somehow jump from ESP to full ISO image.
> > >
В Fri, 23 Jan 2015 19:29:07 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
> > But returning (hd0,gpt2) would also be wrong here - ESP on CD image is
> > empty, we need to somehow jump from ESP to full ISO image.
> >
> Returning hd0,gpt2 is fine. By convention ()/file refers to parent dis
Hi,
Andrei Borzenkov wrote:
> Not eltorito, but normal ESP.
That's somewhat appeasing.
> returning (hd0,gpt2) would also be wrong here - ESP on CD image is
> empty, we need to somehow jump from ESP to full ISO image.
One could allow nested partitions and put whole-ISO partitions
into the vario
> But returning (hd0,gpt2) would also be wrong here - ESP on CD image is
> empty, we need to somehow jump from ESP to full ISO image.
>
Returning hd0,gpt2 is fine. By convention ()/file refers to parent disk
of whatever root partition is (as opposed to /file).
So just including part_gpt in core s
ote:
> >>>
> >>> Hey all,
> >>>
> >>> We are trying to create hybrid USB/DVD images, and they work just fine
> >>> on BIOS. However it doesn't seem to work when creating UEFI.
> >>>
> >> Try this:
> >>
size : 2 1580 18646
APM partition name : 3 Gap1
APM partition type : 3 ISO9660_data
APM start and size : 3 20226 162
So if this does not boot, then El Torito is indeed needed
even on USB stick.
One could also rem
On 01/23/2015 05:14, Thomas Schmitt wrote:
> Hi,
>
> Vladimir wrote:
>> I think his EFI uses eltorito even from the stick. In that case we end
>> up in exactly the same scenario as CD-ROM.
> This contradicts all my beliefs about El Torito
> (and several wikis where i published them).
>
> I would li
Hi,
Vladimir wrote:
> I think his EFI uses eltorito even from the stick. In that case we end
> up in exactly the same scenario as CD-ROM.
This contradicts all my beliefs about El Torito
(and several wikis where i published them).
I would like to see this theory verified:
The first experiment wo
:
>>>>
>>>> Hey all,
>>>>
>>>> We are trying to create hybrid USB/DVD images, and they work just fine
>>>> on BIOS. However it doesn't seem to work when creating UEFI.
>>>>
>>> Try this:
>>> diff -
On 23.01.2015 10:40, Andrei Borzenkov wrote:
> On Fri, Jan 23, 2015 at 1:15 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> On 22.01.2015 22:25, Kris Moore wrote:
>>>
>>> Hey all,
>>>
>>> We are trying to create hybrid USB/DVD image
On Fri, Jan 23, 2015 at 1:15 AM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 22.01.2015 22:25, Kris Moore wrote:
>>
>> Hey all,
>>
>> We are trying to create hybrid USB/DVD images, and they work just fine
>> on BIOS. However it doesn't seem t
On 22.01.2015 22:25, Kris Moore wrote:
>
> Hey all,
>
> We are trying to create hybrid USB/DVD images, and they work just fine
> on BIOS. However it doesn't seem to work when creating UEFI.
>
Try this:
diff --git a/grub-core/disk/efi/efidisk.c b/grub-core/disk/efi/
Hi,
This is a patch for usb mouse support in GRUB.
I cannot take credit for the code. It was written by a former colleague of mine
(Christer Weinigel).
Added some cleanups and a bugfix.
It should be usable as is for most standard protocol mice.
Regards,
Christian
mouse.patch
Description
OK, committed.
I simply removed the line you mentioned...
BR, Ales
Dne 23.9.2013 14:47, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
On 31.08.2013 23:12, Aleš Nesrsta wrote:
- grub_boot_time ("Ownership of EHCI port taken");
+ grub_boot_time ("Ownership of EHCI controller ta
On 31.08.2013 23:12, Aleš Nesrsta wrote:
> - grub_boot_time ("Ownership of EHCI port taken");
> + grub_boot_time ("Ownership of EHCI controller taken");
This has to be after SMI_EN is written as writes to SMI_EN may cause SMI
which would take time and may cause trouble. Other than this
Committed, thanks.
On 09.09.2013 08:22, Melki Christian (consultant) wrote:
> Hi,
>
> I discovered that on some PC's the USB stack would produce an invalid
> descriptor upon query without an error.
> I don't know why this is the case, maybe broken hardware but I seri
Hi Christian,
sorry for delay, I am too busy in last time.
> Hi,
>
> I discovered that on some PC's the USB stack would produce an invalid
> descriptor upon query without an error.
> I don't know why this is the case, maybe broken hardware but I
> seriously doubt it
Hi,
I discovered that on some PC's the USB stack would produce an invalid
descriptor upon query without an error.
I don't know why this is the case, maybe broken hardware but I seriously doubt
it.
GRUB doesn't handle TT's at all, Clearing TT's or resetting them. Mayb
> 2.9.2013 09:01, Melki Christian (consultant) wrote:
> > Exactly.
> > The EHCI handback is provided by the EHCI spec handover state machine.
> Problem is, most BIOS:es don't implement it, or just screw it up trying.
> > The scenario is like this:
> > Load g
Ales,
Yep. The Dell works fine now. :)
I thought it had something to do with missing companion controller.
But it turned out to be the truncation bug.
The Broadcom 5880 works perfectly!
BR,
Christian
> 2.9.2013 10:49, Melki Christian (consultant) wrote:
> > Sorry Ales,
> >
> > Here is a lsusb -v
e scenario is like this:
>> Load grub2 with EHCI usb.
>> Grub2 loads windows 7 or something.
>> Windows 7 goes b0rk and requests input (diskcheck etc).
>> User only has USB-keyboard.
>> Eeep, can't enter anything because windows 7 has not loaded usb-stuff
>> ye
2.9.2013 09:01, Melki Christian (consultant) wrote:
Exactly.
The EHCI handback is provided by the EHCI spec handover state machine. Problem
is, most BIOS:es don't implement it, or just screw it up trying.
The scenario is like this:
Load grub2 with EHCI usb.
Grub2 loads windows 7 or some
2.9.2013 10:49, Melki Christian (consultant) wrote:
Sorry Ales,
Here is a lsusb -vvv dump of the E6430 machine.
I meant to include it the first time.
According to this file, it looks like Smart card reader is connected in
port 8 at internal USB2 hub Bus 002 Device 002: ID 8087:0024.
Did you
Vladimir:
Please, when you will very important review/commit Christian patch,
consider also my two previous latest USB patches - please review them (I
can commit them myself, no problem) or commit.
I mean these two patches:
- simple patch related to reset SMI (sent in ML in thread [PATCH
Found the bug after a couple of hours digging. Quite serious. Patch provided.
Trivial but extremely irritating none the less.
Vladimir: Please apply.
Regards,
Christian
usb_hub_ports_20130902.patch
Description: usb_hub_ports_20130902.patch
___
Grub-de
Sorry Ales,
Here is a lsusb -vvv dump of the E6430 machine.
I meant to include it the first time.
BR,
Christian
dump.gz
Description: dump.gz
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Yes. My patch looked exactly like that. Minus the comment changes. ;)
I can not see any harm from this while running. Maybe this needs to be tested
more?
Linux looks like it has it as default.
linux-3.10/drivers/usb/host/pci-quirks.c. Looks like it hands over from BIOS
and disable the ehci
> Hi,
> what do you mean exactly by "GRUB does not detect this device"?
> 1) Do you mean it is not listed by "usb" command?
> 2) Or do you mean it is not listed by "ls" command as disk?
>
> In the case 2) it is most probably caused by this: Such dev
nd discovered that my machines here, their BIOS:es leave
the OS change bit or not touch the register at all.
One BIOS really made a mess of it all. But also to my dismay, the BIOS:es would
go in and finger the SMI settings after the OS has 0:ed them.
Looking at Linux, the default(?) pci ehci quirk
hats a case for lost devices etc?
Ok, I made a short look into Linux USB source code and I saw there is
USBLEGCTLSTS register reset in any case.
(What is maybe more interesting, Linux driver DOES NOT handover on some
(broken) devices, only reset SMI...)
So I prepared simple "SMI" pa
es however. Why? I can
not think of any case of a successful handover with SMI's still
enabled. To what purpose? A buggy BIOS would maybe act upon such
stuff? Maybe thats a case for lost devices etc?
Ok, I made a short look into Linux USB source code and I saw there is
USBLEGCTLSTS register re
case of a successful handover with SMI's still enabled. To what purpose? A
buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices
etc?
Ok, I made a short look into Linux USB source code and I saw there is
USBLEGCTLSTS register reset in any case.
(What is maybe more int
Hi again,
probably did you mean SD card reader instead of smart card reader?
In this case:
1) SD card reader is PCI device, not USB device:
lspci
...
03:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 21) (prog-if 01)
...
AFAIK, it needs SDHCI PCI driver
Hi,
what do you mean exactly by "GRUB does not detect this device"?
1) Do you mean it is not listed by "usb" command?
2) Or do you mean it is not listed by "ls" command as disk?
In the case 2) it is most probably caused by this: Such device is not
mass storage c
uld be not problem to you... :-) What result did
you get?
Also, I've been toying with the black magic EHCI hand-back. I've gotten it to
work for some machines. The problem with GRUB and USB is that if you enable USB
you have no more control over USB in case a OS needs input before lo
Hi,
Is there a known problem with these devices in GRUB?
I have a core i7 based Dell Latitude 6430 with an integrated broadcom smart
card reader. The devices looks like it is a USB 1.0/1.1 device, probably
sitting behind some hub to the EHCI-controller.
As far as I can tell, this machine does
nabled. To what purpose? A
buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices
etc?
Also, I've been toying with the black magic EHCI hand-back. I've gotten it to
work for some machines. The problem with GRUB and USB is that if you enable USB
you have no more c
some bug related to
> "duplicate/redundant" module loading etc. - that's the main reason why I
> recommended to test another situation. I don't expect such bug - but who
> knows...
>
>
>> I have also removed bios-fw-disk disabling from all usb-drivers.
>> I thi
t; module loading etc. - that's the main reason why I
recommended to test another situation. I don't expect such bug - but who
knows...
I have also removed bios-fw-disk disabling from all usb-drivers.
I think it's just stupid to assume that because you load usb you are doing mas
fine with me. I
don't really care that it loads modules that it think it needs.
I have also removed bios-fw-disk disabling from all usb-drivers.
I think it's just stupid to assume that because you load usb you are doing mass
storage and thus need nativedisk.
Im doing perfectly fine wi
I want grub2 communications with USB KEY in the boot process.
how can i do?
can you help me?
thank you.___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
nclude "insmod usb_keyboard" - this module should be loaded
automatically from usb module.
2.
If Your keyboard is connected to USB controller via hub (it can be
internal, integrated in PC), try my patch which I sent in thread
"[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) el
Hi,
please send output of
lspci -vvv
lsusb -vvv
Run it as root or via sudo.
Some general advices:
1.
Do not include "insmod usb_keyboard" - this module should be loaded
automatically from usb module.
2.
If Your keyboard is connected to USB controller via hub (it can be
internal,
> > Hi.
> >
> > I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI
> controller.
>
> Did it work in earlier versions?
I made a rather big jump...
from a backported usb stack on 1.99 to trunk. :(
Anyway, I solved both my problems.
I solved them
В Wed, 7 Aug 2013 08:16:00 +
"Melki Christian (consultant)" пишет:
> Hi.
>
> I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI controller.
Did it work in earlier versions?
> I load all USB drivers including OHCI. Now with this latest version G
Hi.
I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI controller.
I load all USB drivers including OHCI. Now with this latest version GRUB
doesn't seem to want to talk to my keyboard anymore.
If I replug the device and reload usb_keyboard then it might work, but not
Hi Vladimir,
do you mean something like that ?
Or do you want also to change "int endpoint" to "struct
grub_usb_desc_endp *endpoint" - like in Your patch ?
Additionally some (unrelated) note:
There is also waiting important USB patch in bug
https://savannah.gnu.org/bugs/?3
> What do you prefer - this "improved" bulk transfer limiting or the
> simple original one?
I misread what patch does. It looks better now. Can you propagate the
change to bulk_write as well, like in the patch I sent?
>
> BR,
> Ales
>
>
>
> ___
> G
Please try attached patch
=== modified file 'grub-core/bus/usb/serial/ftdi.c'
--- grub-core/bus/usb/serial/ftdi.c 2013-02-01 20:49:29 +
+++ grub-core/bus/usb/serial/ftdi.c 2013-02-24 18:58:04 +
@@ -128,7 +128,7 @@
real_config (port);
- grub_usb_bulk_write (port->
1 - 100 of 476 matches
Mail list logo
