From: ebiederm@xmission.com (Eric W. Biederman)
To: Peter Stuge <stuge-linuxbios@cdy.org>
Cc: Greg KH <gregkh@suse.de>, Andi Kleen <ak@suse.de>,
Stefan Reinauer <stepan@coresystems.de>,
linuxbios@linuxbios.org, linux-kernel@vger.kernel.org, "Lu,
Yinghai" <yinghai.lu@amd.com>
Subject: Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
Date: Fri, 01 Dec 2006 16:02:03 -0700 [thread overview]
Message-ID: <m1wt5bfces.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20061201214631.6991.qmail@cdy.org> (Peter Stuge's message of "Fri, 1 Dec 2006 22:46:31 +0100")
Peter Stuge <stuge-linuxbios@cdy.org> writes:
> On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
>> 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.
>
> I see.
>
>
>> >> 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)
>
> Hm - for driving which end?
Either. The specific device we are talking about doesn't care.
>> and a rude read/write to the bar from user space program that
>
> How does that work? /dev/{port,mem}?
mmap /dev/mem.
>> 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 too big to read.
>
> Which descriptors are you reading?
Minor. I was just wishing for less magic in this process, which
would make these kinds of devices much more available.
> The debug port isn't really supposed to be used with anything but a
> debug device - which can't be enumerated normally anyway.
It depends. If you have a debug cable with magic ends and a hardcoded
address of 127 the normal enumeration doesn't work. I don't think
anyone actually makes one of those. Debug devices are also allowed to
be normal devices that just support the debug descriptor. Which
is what I'm working with.
Eric
next prev parent reply other threads:[~2006-12-01 23:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-01 18:55 [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Lu, Yinghai
2006-12-01 19:19 ` Greg KH
2006-12-01 20:42 ` Peter Stuge
2006-12-01 21:15 ` Eric W. Biederman
2006-12-01 21:46 ` Peter Stuge
2006-12-01 23:02 ` Eric W. Biederman [this message]
2006-12-03 17:00 ` Peter Stuge
2006-12-03 23:03 ` Eric W. Biederman
2006-12-01 23:13 ` Eric W. Biederman
2006-12-03 15:49 ` Eric W. Biederman
2006-12-04 5:09 ` [RFC][PATCH 0/2] x86_64 Early usb debug port support Eric W. Biederman
2006-12-04 5:13 ` [RFC][PATCH 1/2] x86_64: Preallocate the fixmap pud and pmd entries Eric W. Biederman
2006-12-04 5:18 ` [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support Eric W. Biederman
[not found] ` <200612042001.09808.david-b@pacbell.net>
2006-12-05 11:01 ` [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support Eric W. Biederman
2006-12-06 17:31 ` Andi Kleen
2006-12-05 11:18 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2006-12-02 2:43 [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Lu, Yinghai
2006-12-02 14:02 ` Eric W. Biederman
2006-12-02 20:47 ` yhlu
2006-12-03 11:51 ` Eric W. Biederman
2006-12-03 12:01 ` Stefan Reinauer
2006-12-03 12:42 ` Segher Boessenkool
2006-12-03 12:52 ` Stefan Reinauer
2006-12-03 13:11 ` Eric W. Biederman
2006-12-01 22:10 Lu, Yinghai
2006-12-01 18:26 Lu, Yinghai
2006-12-01 18:41 ` Greg KH
2006-12-01 19:04 ` Peter Stuge
2006-12-01 19:17 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1wt5bfces.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxbios@linuxbios.org \
--cc=stepan@coresystems.de \
--cc=stuge-linuxbios@cdy.org \
--cc=yinghai.lu@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox