Project on USB OTG
Hi All, I want to do a project on USB as part of my college project, for the better understanding of the USB working. Can some one please suggest me what project i can do?, i have studied linux device drivers and have played around with it. Now i want to do some real good project. Thanks, Madavan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
On Thu, Sep 15, 2011 at 07:02:59PM +0530, Felix Varghese wrote:
Hi,
I have been trying to communicate with a custom usb device from a
SAM9G20-EK board using the usb-skeleton.c driver example in the linux
source. I modified the driver to add my device's vendor and product
id. The USB device enumerates with two bulk endpoints - one IN and one
OUT. The (modified) skel driver successfully detects my device and I
get a minor number allocated. After creating a device file with that
minor number, I am able to write into the device by typing 'echo HI
/dev/mydevice'. I verified that this data arrives at my device
intact. Next, I started sending data back from the device and tried to
read it back using 'cat /dev/mydevice'. The problem is that read not
only doesn't work, but also makes the app get totally stuck. Ctrl-C
doesn't work and I have to reboot the board.
Some debugging using printk's led me to the following snippet which
seems to be causing the hang. If I change the wait to a
wait_for_completion_interruptible, Ctrl-C starts working, but still no
data is received.
if (!dev-processed_urb) {
/*
* the URB hasn't been processed
* do it now
*/
wait_for_completion(dev-bulk_in_completion);
dev-bulk_in_copied = 0;
dev-processed_urb = 1;
}
Oh, btw I am using linux kernel 2.6.39.4. Any Ideas anyone??
Odds are you need to send the proper command to your device in order to
get it to send data to you. You are hanging, waiting for device to be
sent from the device to userspace, and if no data is sent, then it will
continue to wait.
So, please read the documentation on how to talk to your device and send
the proper USB commands to it and all should be fine.
But note, the usb-skeleton driver really isn't a good framework for a
real USB device in that it doesn't expose the proper userspace
interface for it.
What type of device is this you are wishing to write a driver for? That
will determine the type of interface you need to use, odds are it is not
going to be a simple char device.
greg k-h
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
No human readable MCE decoding support on this CPU type
HI Application was running well on Linux 2.6.36.4 (Linux stdl007 2.6.36.4-0.7-default #1 SMP Thu Jun 16 16:55:08 SGT 2011 x86_64 x86_64 x86_64 GNU/Linux) When I installed it on another box(same machine type and same kernel) It got these massive errors in /var/log/message kernel: [20002.367540] [Hardware Error]: No human readable MCE decoding support on this CPU type have searched this and one answer is: http://www.mcelog.org/faq.html I get kernel hardware error no human readable mce decoding support on this cpu type This is pretty much a bug in newer Linux kernels. They print this message on every corrected error, even though it's useless and also the decoding into the kernel log is not very useful because mcelog can aggregate the information much better. This is fixed with this patch To apply to a kernel: download raw patch , cd kernel source, patch -p1 patchfile, recompile. The newer kernel, I understand it means 2.6.37+, how about 2.6.36.4? why I didn't get this error in the previous machine has same kernel? Does it mean the new machine has hardware problem? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: thread_info address calculation
It's the same thing as you read:
THREAD size is 8kb so the operation looks like the following:
current_stack_pointer ~(8191) == current_stack_pointet 0xFE00
(last 13 bits are 0)
On Fri, Sep 16, 2011 at 3:38 PM, Vijay Chauhan kernel.vi...@gmail.com wrote:
Hi list,
I would like to know how the thread_info address is calculated? As per
the LKD book:
struct thread_info is stored on the kernel stack. On x86, current is
calculated by masking out the 13 least-significant bits of the stack
pointer to obtain the thread_info structure.This is done by the
current_thread_info() function.The assembly is shown here:
movl $-8192, %eax
andl %esp, %eax
This assumes that the stack size is 8KB.
But in code i found that:
/* how to get the thread information struct from C */
static inline struct thread_info *current_thread_info(void)
{
return (struct thread_info *)
(current_stack_pointer ~(THREAD_SIZE - 1));
}
/* how to get the current stack pointer from C */
static inline unsigned long current_stack_pointer(void)
{
unsigned long sp;
asm(mov sp,%0; :=r (sp));
return sp;
}
Could anyone help me in explaining the current_stack_pointer and
(current_stack_pointer ~(THREAD_SIZE - 1)) calculation? This is not
as mentioned in the book.
If page size is 4KB and 2 page per process kernel stack is used then
THREAD_Size will be 8KB.
Thanks,
Vijay
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Denis
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: thread_info address calculation
It's the same thing as you read: THREAD size is 8kb so the operation looks like the following: current_stack_pointer ~(8191) == current_stack_pointet 0xFE00 (last 13 bits are 0) Ok. Got it. But how ANDing it with current stack pointer points to the address of thread_info structure. Suppose stack is growing from higher to lower memory address. Thanks, Vijay ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
using the kmsg_dumper.
Hi, I want to store the kernel logs just before somebody calls the machine reset. I was exploring several ways to implement it. When i am going through the code in printk.c i saw a function kmsg_dump(), which says it will dump the kmsg buffer to all dump devices attached to it. What is a dump device? can we write them to our flash. I also saw in panic() implementation they are using this. TO which dump device those messages will be stored. -- With regards, Sandeep Kumar Anantapalli, ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: thread_info address calculation
Hi Vijay, On Fri, Sep 16, 2011 at 5:16 AM, Vijay Chauhan kernel.vi...@gmail.com wrote: It's the same thing as you read: THREAD size is 8kb so the operation looks like the following: current_stack_pointer ~(8191) == current_stack_pointet 0xFE00 (last 13 bits are 0) Ok. Got it. But how ANDing it with current stack pointer points to the address of thread_info structure. Suppose stack is growing from higher to lower memory address. Since the memory for the stack is allocated using a power-of-2 allocator, when you ask for 8K of memory, it is also 8K aligned. The stack will start at the end of the 8K region and grow towards the beginning. The thread_info will be stored at the beginning. ANDing any valid stack pointer with the mask will return the beginning of the 8K block. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel
hey this is really informative http://www.nbci7hourly.com/?date=09152011article=3030 enjoy yourself ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
