Peter Stuge stuge-linuxbios@cdy.org writes:
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
Well, earlyprintk will not work, as you need PCI up and running.
Not all of it though. LinuxBIOS will probably do just enough PCI setup to talk to the EHCI controller and use the debug port _very_ soon after power on.
Right. For LinuxBIOS not a problem for earlyprintk in the kernel somethings might need to be refactored. The challenge in the kernel is we don't know at build to how to do a pci_read_config...
The other hard part early in the kernel is the fact that the bar is memory mapped I/O. Which means it will need to get mapped into the kernels page tables.
And I have some code that barely works for this already, perhaps Eric and I should work together on this :)
I would be interested in having a look at any code for it too.
Sure, I will send it out shortly. I currently have a working user space libusb thing (easy, but useful for my debug) and a rude read/write to the bar from user space program that allowed me to debug the worst of the state machine from user space. I don't think I have the state setup logic correct yet but that is minor in comparison.
I really wish the EHCI spec had made that stupid interface 16 bytes instead of 8 or had a way to chain multiple access together. The we could have used a normal usb cable. As it is most descriptors are 1 byte to big to read.
Yes, that will work just fine today using the usb-serial generic driver.
Ugh. I did not know it was that generic. The irony is that I always ask other libusb users to check the kernel drivers to see if they really need to write a libusb app.
I'll knock up a "real" driver for the device later today and send it to Linus, as it's trivial to do so, and will make it simpler than using the module parameters.
Awesome. Thanks!
Yep. It looks like it sufficient generic. The Maximum packet size appears to be reported correctly for writes which is the tidbit I was worried about but otherwise it is just a pair of bulk transfer endpoints.
Eric