Thanks for the code.
In LinuxBIOS, I put usbdevice_direct.c in lib/, and call it from usb2_init in mcp55_usb2.c
Got "No device in debug port"
Waiting for cable, hope to get that cable next Tuesday.
Will create usbdebug_direct_console.c in console/ for linuxbios_ram code. also usbdebug_direct_serial.c in pc80/ for cache_as_ram.c
YH
"Lu, Yinghai" yinghai.lu@amd.com writes:
Thanks for the code.
In LinuxBIOS, I put usbdevice_direct.c in lib/, and call it from usb2_init in mcp55_usb2.c
Got "No device in debug port"
Waiting for cable, hope to get that cable next Tuesday.
Will create usbdebug_direct_console.c in console/ for linuxbios_ram code. also usbdebug_direct_serial.c in pc80/ for cache_as_ram.c
Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS.
Eric
On 12/2/06, Eric W. Biederman ebiederm@xmission.com wrote:
Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS.
Yes, I adapted the code to used in LinuxBIOS, including CAR stage code and RAM satge code.
I didn't have debug cable plugged yet.
BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded.
YH
yhlu yinghailu@gmail.com writes:
On 12/2/06, Eric W. Biederman ebiederm@xmission.com wrote:
Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS.
Yes, I adapted the code to used in LinuxBIOS, including CAR stage code and RAM satge code.
I didn't have debug cable plugged yet.
Even if you did it wouldn't work right now. My initial version does initialize the ehci properly so it won't find any usb devices. I almost have that fixed, but it looks like for the usb device reset I need a usable delay function, so I can delay 50ms. Grr...
BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded.
Yep thanks that seems to be working. Now I just need to find an early delay and I can try this mess out!
Eric
* Eric W. Biederman ebiederm@xmission.com [061203 12:51]:
BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded.
Yep thanks that seems to be working. Now I just need to find an early delay and I can try this mess out!
you could use io delay, one outb uses roughly 1us iirc.
you could use io delay, one outb uses roughly 1us iirc.
On LPC, yes -- or 0.5us or something like that. On ISA it's a lot faster, on PCI too -- better do 20 or so outb's to be safe. Or use a *real* timer instead, you'll have to abstract this for portability anyway...
Segher
* Segher Boessenkool segher@kernel.crashing.org [061203 13:42]:
On LPC, yes -- or 0.5us or something like that. On ISA it's a lot faster, on PCI too -- better do 20 or so outb's to be safe.
The value's actually something we have been using as a rule of thumb while doing outb to port 80. Don't think these are routed to LPC, are they?
Stefan Reinauer stepan@coresystems.de writes:
- Segher Boessenkool segher@kernel.crashing.org [061203 13:42]:
On LPC, yes -- or 0.5us or something like that. On ISA it's a lot faster, on PCI too -- better do 20 or so outb's to be safe.
The value's actually something we have been using as a rule of thumb while doing outb to port 80. Don't think these are routed to LPC, are they?
Depends on the destination address. For 0x80 you can be fairly certain it will be an unacknowledged cycle subtractively decoded to the slowest bus on the system. Or routed to 32 PCI or the LPC bus if there is something to actually looking at the value so it is slow.
Since all I need is something that delays for about 50ms 50,000 outb to port 0x80 looks like a good first approximation, and since it only happens once it is probably better to just bump that count up instead of trying to be precise about it and have an accurate timer.
I'm not at all convinced a usb console can be made sufficiently solid to be useful. But it is at least worth trying so we can clearly say it doesn't work well.
Eric
-
ebiederm＠xmission.com -
Lu, Yinghai -
Segher Boessenkool -
Stefan Reinauer -
yhlu