Re: page size change on MIPS
Hi... On Tue, Feb 8, 2011 at 14:35, naveen yadav yad.nav...@gmail.com wrote: Hi All, I debug this issue further, I check in kernel File name is binfmt_elf.c and function name is create_elf_tables() I put a debug print here to check what kernel is reading from user space. if (__put_user((elf_addr_t)p, argv++)) return -EFAULT; len = strnlen_user((void __user *)p, MAX_ARG_STRLEN); printk(\n Lenght of arg=%ld,%s \n,len,(void __user *)p); if (!len || len MAX_ARG_STRLEN) return -EINVAL; p += len; } when Page size is 16KB o/p is Lenght of arg=6,/init when Page size is 64KB o/p is Lenght of arg=1, so I got null when it read from ELF hum? very strange so essentially it can't read...or to be precise, properly read command arguments (including the executable name itself)? maybe the problem lies somewhere in the initrd/initramfs? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Ad-hoc arm board
Hi, Working on a custom arm based board, I'm currently juggling with mach-types and machine IDs for our ARM boards, but perhaps it came the time to set them in the right way... And moreover, do anyone has a pointer on documentation/articles/somewhat on how to write a good board-*.c and how (and perhaps when) to handle platform devices instead of a classical device driver? I'm currently going by trying, and perhaps it's not the better method to achieve my purposes. thanks. Regards. -- -gaspa- --- https://launchpad.net/~gaspa - - HomePage: http://gaspa.yattaweb.it -- ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Doubt regarding Minor Numbers and alloc_chrdev_region
___
From: kernelnewbies-boun...@kernelnewbies.org
[kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Sankar P
[sankar.curios...@gmail.com]
Sent: Tuesday, February 08, 2011 4:26 PM
To: Kernelnewbies@kernelnewbies.org
Subject: Doubt regarding Minor Numbers and alloc_chrdev_region
Hi,
I am going through LDD3 (scull0 section) and have a doubt regarding
minor numbers. I have the following code-snippet:
#define FIRST_MINOR_NUMBER 0
#define COUNT_OF_CONTIGOUS_DEVICES 1
/* Device that we will use */
dev_t helloworld_device;
/* Initialization Function for the kernel module */
static int helloworld_driver_init(void)
{
printk(KERN_INFO Hello World);
/* Allocate a dynamic device number for your driver. If you want to
hardcode a fixed major number for your
* driver, you should use different APIs 'register_chrdev_region',
'MKDEV'. But the following is better. */
if (!alloc_chrdev_region(helloworld_device, FIRST_MINOR_NUMBER,
COUNT_OF_CONTIGOUS_DEVICES, HelloWorldDriver)) {
printk(KERN_INFO Device Number successfully allocated.);
/* If you do a cat /proc/devices you should be able to find our
Driver registered. */
} else
printk(KERN_ALERT HelloWorldDriver could not get a Device
number);
return 0;
}
==
Now if I compile and insert the .ko file for this module, the driver
gets registered with a major number of 250 (seen from /proc/devices).
However, I don't understand the significance of the FIRST_MINOR_NUMBER
and the COUNT_OF_CONTIGOUS_DEVICES that we pass to the
alloc_chrdev_region function.
If I try to create a file using, 'mknod /dev/scull2 c 250 7' , the
character device file gets created with a minor number of 7.
I have set COUNT_OF_CONTIGOUS_DEVICES to 1. However, I am able to create
multiple files /dev/scull[1-10] using this driver and mknod.
So, what is the significance of these two variables (first minor number
and count of devices) that we pass to the alloc_chrdev_region api, if
they can be over-ridden on mknod time ? Or have I misunderstood
something ?
Any help will be appreciated. Thanks.
As far as i know ,
alloc_chardev_region () helps you register your character driver with the
kernel using particular major number and minor number .. Thats pretty much of
it.
It's your responsibility to create a matching char device file in the user
space .
When you perform any read / write operations on such a file then kernel first
identifies ..Do I have any registrations of such a driver with __these__ major
number and minor number.
and correspondingly the read / write routines of your driver gets called.
In your case the any IO operations done on scull2 will not be mapped to any
character driver in the kernel ..
You can try doing : cat /dev/scull2
Regards,
Smital Desai
--
Sankar P
http://psankar.blogspot.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
__
The contents of this e-mail and any attachment(s) may contain confidential or
privileged information for the intended recipient(s). Unintended recipients are
prohibited from taking action on the basis of information in this e-mail and
using or disseminating the information, and must notify the sender and delete
it from their system. LT Infotech will not accept responsibility or liability
for the accuracy or completeness of, or the presence of any virus or disabling
code in this e-mail
__
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Doubt regarding Minor Numbers and alloc_chrdev_region
On Tue, Feb 8, 2011 at 5:36 PM, Daniel Baluta daniel.bal...@gmail.comwrote: If I try to create a file using, 'mknod /dev/scull2 c 250 7' , the character device file gets created with a minor number of 7. You can create as much /dev/scull2 files using mknod as you want, but they are not linked with your driver. [first_minor, count] pair passed to alloc_chrdev_region reserve for you a range of minors that will be later used by your driver. Next step is to actually create the link between the node and your driver using chrdev_add. Ah okay. I understand this now. On reading a few more pages in the book, I see that the authors explain this phenomenon. However, It seems using register_chrdev is an old way of doing things and new code should use cdev. I just did a grep for cdev on the latest sources and not much seem to be using the cdev* apis. On a sidenote, I believe this whole scull section can be re-written in a way (in the LDD3 book I meant) such that there are some small milestones, which the reader can implement, understand and proceed further. Rightnow, it is too big and theoretical and difficult to visualize and needs us to read a lot of pages before we touch first line of code. Thanks for all your help. I shall update once I make progress. -- Sankar P http://psankar.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Another ISP1761 / FTDI / serial problem
Hi! I get weird problems when I use a null modem cable between the two ports on a FT232BM (2-port FTDI USB-to-serial converter) with an isp1761 host controller. The same thing does not happen with an EHCI host controller. Lengthy details follows: With the EHCI host controller: = [Terminal 1] $ cat /dev/ttyUSB1 [Terminal 2] $ echo Something seems wrong here /dev/ttyUSB0 $ echo Something seems wrong here /dev/ttyUSB0 [Terminal 1] Something seems wrong here Something seems wrong here ^C $ Observe the extra new line after the strings. I'm not sure if this is a bug in the ftdi driver, some other part of the serial subsystem, or if it is the result of some terminal setting; with a USB analyzer I observe the following sequence of packets (#-# == device-endpoint): 3-2 OUT: Something seems wrong here 3-2 OUT: 0x0D 0x0A 4-1 IN: 0x01 0x60 'S' 4-1 IN: 0x01 0x60 'o' ... 4-1 IN: 0x01 0x60 0x0D 4-1 IN: 0x01 0x60 0x0A 4-2 OUT: 'S' # The echo from the reading side starts here 4-2 OUT: 'o' ... 4-2 OUT: 0x0D 0x0A 4-2 OUT: 0x0D 0x0A # The newline pair is echoed twice - perhaps both 'CR' and 'NL' are converted to CRNL in the echo? Anyway, since 3-1 is never read, no feedback loop is created by the two echoing devices. With the isp1761 host controller, driver from 2.6.35.7 backported to 2.6.27.54 and modified for platform endianness: = [Terminal 1] $ cat /dev/ttyUSB1 [Terminal 2] # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 [Terminal 1] This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong and something is wrong (blank line x7) This is isp1761 and something is wrong ^C # echo This is isp1761 and something is wrong /dev/ttyUSB0 # cat /dev/ttyUSB1 is wrong (blank line x30 ca) TThis is isp1761 and something is wrong ^C # The exact look of the error differs, but it is quite easy to trigger by echoing text several times in a row; also breaking the cat execution, echoing some more text, and then starting cat again seems to trigger the error often. On the bus the traffic looks something like this: 7-2 OUT: This is isp1761 and something is wrong 7-2 OUT: 0x0D 7-2 OUT: 0x0A (NAK) # The CRNL pair is split here and the NL is not directly accepted by the device 7-2 OUT: 0x0A (NAK) Following this is lots and lots of 0x0A NAKs intermixed with traffic that looks quite like the EHCI case except that much of the traffic has to be re-sent lots of times before it is accepted. The 0x0A is finally accepted after all text has been received by 8-1 and echoed from 8-2. This exact pattern is repeated every time text is written to the serial port. Device 8 receives the characters and echoes them back to 7-1 as in the EHCI case. But with isp1761, after a while device 7 for some reason starts echoing parts of the received echo-text back. My guess is that this should not happen since device 7 is never read from. Anyway, this creates a feedback loop which would be the source of the spurious characters in the cat run above and that sometimes is powerful enough to make the terminal unresponsible. I've been trying to figure this thing out for a while now but quite frankly I'm stumped; I can't figure out where and why things goes wrong. Any ideas are welcome! Perhaps the NAK problem/bug triggers a problem/bug somewhere in linux' serial terminal code? The terminal settings are the defaults and are the same during all examples above on both serial ports: $ stty -a -F /dev/ttyUSB0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ stty -g -F /dev/ttyUSB0 500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 -- Arvid Brodin Enea Services Stockholm AB ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Another ISP1761 / FTDI / serial problem
Sorry, this was intended for the linux-usb list. -- Arvid Arvid Brodin wrote: Hi! I get weird problems when I use a null modem cable between the two ports on a FT232BM (2-port FTDI USB-to-serial converter) with an isp1761 host controller. The same thing does not happen with an EHCI host controller. Lengthy details follows: With the EHCI host controller: = [Terminal 1] $ cat /dev/ttyUSB1 [Terminal 2] $ echo Something seems wrong here /dev/ttyUSB0 $ echo Something seems wrong here /dev/ttyUSB0 [Terminal 1] Something seems wrong here Something seems wrong here ^C $ Observe the extra new line after the strings. I'm not sure if this is a bug in the ftdi driver, some other part of the serial subsystem, or if it is the result of some terminal setting; with a USB analyzer I observe the following sequence of packets (#-# == device-endpoint): 3-2 OUT: Something seems wrong here 3-2 OUT: 0x0D 0x0A 4-1 IN: 0x01 0x60 'S' 4-1 IN: 0x01 0x60 'o' ... 4-1 IN: 0x01 0x60 0x0D 4-1 IN: 0x01 0x60 0x0A 4-2 OUT: 'S' # The echo from the reading side starts here 4-2 OUT: 'o' ... 4-2 OUT: 0x0D 0x0A 4-2 OUT: 0x0D 0x0A # The newline pair is echoed twice - perhaps both 'CR' and 'NL' are converted to CRNL in the echo? Anyway, since 3-1 is never read, no feedback loop is created by the two echoing devices. With the isp1761 host controller, driver from 2.6.35.7 backported to 2.6.27.54 and modified for platform endianness: = [Terminal 1] $ cat /dev/ttyUSB1 [Terminal 2] # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 # echo This is isp1761 and something is wrong /dev/ttyUSB0 [Terminal 1] This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong This is isp1761 and something is wrong and something is wrong (blank line x7) This is isp1761 and something is wrong ^C # echo This is isp1761 and something is wrong /dev/ttyUSB0 # cat /dev/ttyUSB1 is wrong (blank line x30 ca) TThis is isp1761 and something is wrong ^C # The exact look of the error differs, but it is quite easy to trigger by echoing text several times in a row; also breaking the cat execution, echoing some more text, and then starting cat again seems to trigger the error often. On the bus the traffic looks something like this: 7-2 OUT: This is isp1761 and something is wrong 7-2 OUT: 0x0D 7-2 OUT: 0x0A (NAK) # The CRNL pair is split here and the NL is not directly accepted by the device 7-2 OUT: 0x0A (NAK) Following this is lots and lots of 0x0A NAKs intermixed with traffic that looks quite like the EHCI case except that much of the traffic has to be re-sent lots of times before it is accepted. The 0x0A is finally accepted after all text has been received by 8-1 and echoed from 8-2. This exact pattern is repeated every time text is written to the serial port. Device 8 receives the characters and echoes them back to 7-1 as in the EHCI case. But with isp1761, after a while device 7 for some reason starts echoing parts of the received echo-text back. My guess is that this should not happen since device 7 is never read from. Anyway, this creates a feedback loop which would be the source of the spurious characters in the cat run above and that sometimes is powerful enough to make the terminal unresponsible. I've been trying to figure this thing out for a while now but quite frankly I'm stumped; I can't figure out where and why things goes wrong. Any ideas are welcome! Perhaps the NAK problem/bug triggers a problem/bug somewhere in linux' serial terminal code? The terminal settings are the defaults and are the same during all examples above on both serial ports: $ stty -a -F /dev/ttyUSB0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ stty -g -F /dev/ttyUSB0 500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 -- Arvid Brodin Enea Services Stockholm AB ___ Kernelnewbies
Re: Ad-hoc arm board
Hi gaspa, On Tue, Feb 8, 2011 at 2:47 AM, Andrea Gasparini ga...@yattaweb.it wrote: Hi, Working on a custom arm based board, I'm currently juggling with mach-types and machine IDs for our ARM boards, but perhaps it came the time to set them in the right way... You can request mach-type entries over here: http://www.arm.linux.org.uk/developer/machines/ Generally, I would look at other machines in the arch/arm hiearchy. The omap one is fairly complex. I think I used the mach-integrator as my first example. There are some guides to porting ARM boards. The first one is quite old, and lots of the smaller details have changed. This is what I used to get started. http://www.glomationinc.com/PortingLinuxKernel.pdf Some more recent ones: http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html# http://free-electrons.com/doc/kernel-porting.pdf And moreover, do anyone has a pointer on documentation/articles/somewhat on how to write a good board-*.c and how (and perhaps when) to handle platform devices instead of a classical device driver? I'm currently going by trying, and perhaps it's not the better method to achieve my purposes. Generally speaking, when dealing with an SoC, most (if not all) of the peripherals on the chip should be platform drivers. There is some info in the Documentation directory: http://lxr.linux.no/#linux+v2.6.37/Documentation/driver-model/platform.txt One of the things you can do with platform devices/drivers is to split the data from the code. So all of the things like peripheral base address, irq, etc can all go in the platform data. Then the same platform driver (especially when compiled as a module) can be used on multiple boards. Platform drivers also have some power management hooks for dealing with suspend/resume. Dave Hylands ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Regarding Buddy Allocator
Hi Sri, On Tue, Feb 8, 2011 at 9:33 AM, Sri Ram Vemulpali sri.ram.gm...@gmail.com wrote: Thanks Santosa, Not much is mentioned in the link you mentioned. I looking for more of explanation and optimal implementation. Any reference would be good too. Googling for buddy allocator seems to come up with several good links, including at least one with an implementation http://lmgtfy.com/?q=buddy+allocator Dave Hylands ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Fwd: storing the logs
Am Montag, den 07.02.2011, 00:16 +0530 schrieb mohit verma: i create a socket to communicate to the user space app to listen to and responsible for loggin ... via my_sock=netlink_creat_sock() i create my own logging message format to send it via netlink interface. then how can i let my module know which process to bind it to? i mean to bind my socket to any user space application i need the pid of that one haven't tried netlink so maybe this won't be much help. isn't it possible to just bind to somewhere on the network using int kbind(ksocket_t socket, struct sockaddr *address, int address_len) from http://ksocket.sourceforge.net/ ? if i'm not mistaken you won't need any pid good luck, Lutz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
