Re: Kernel Linux updating
Thanks for the advices. Yes, I agree with you about keeping kernel updates is better. But I am new to my company and they did not update the kernel so they are "stuck" with the old 2.6.32 kernel. So, here I am ! Asking questions to know how it would be the nice way to update it :) Mylène Le 28/06/2013 11:36, Alexandru Juncu a écrit : > Though the kernel is the heart of the operating system, it's not the > only thing that makes the things go. Putting in a new kernel, isn't > necessarily the answer to all the problems of a system. > Because the userspace utilities are just as important, and you need to > keep them too up to date. Because some versions of a (core) program > might use things that were supported in a version, but not anymore > (this shouldn't happen in a perfect world, but since we're living in > real life, this could happen). > > As a best practice, I find that you should update your system > regularly. Updating from version 1 to 2, then to 3 after a couple of > months, then to 4 when that is release usually goes a lot smoother > than going from 1 to 4. Reinstalling the entire distribution would be > a better option, but not always possible in production. > > You could just try each version (starting with the LTS ones) until you > find one that works for you. > > On 28 June 2013 12:23, Mylene Josserand wrote: >> okay ! Thank you for the explanation, Alexandru. >> I see it more clearly :) >> >> What I really want ? Hum, it is for a production purpose. >> We already use a kernel but it a 2.6.32.59 version. >> >> We have some problems and we thought to update it. I had updated it to a >> 3.8 kernel but, of what you say, I should have updated it to a longterm >> version. Which one should I use ? >> In the links you gave me, I see that the 2.6.32 will become EOL in 2014 >> and 2.6.34 and 3.0 in 2013. The 3.2 will become an EOL in 2016. Should I >> update to this one ? >> >> And we encountered some problems (about CAN controller to be precise). >> In the CAN mailist, Luka Rahne has the same problem has ours with the >> 3.0.3 kernel. He tested the 3.0.81 and the problem seems to be gone. So, >> also, I wanted to know if the possibly fix between 3.0.3 and 3.0.81 >> would have been spreaded to other kernels ? other long term ? stable ? >> >> Thank you again ! >> >> >> Mylène >> >> >> >> Le 28/06/2013 10:51, Alexandru Juncu a écrit : >>> On 28 June 2013 11:37, Mylene Josserand >>> wrote: >>>> Hi everyone, >>>> >>>> >>>> I would like to know how the Linux Kernel are updated. >>>> I know that there is the long term kernels, the last stables and the >>>> mainline. >>>> First, what is the real difference between stable and longterm ? >>>> >>>> I see in the Linux Kernel website that the date of the long term (and >>>> the revision number) is changing so I was thinking that there are some >>>> updates on it, right ? >>>> >>>> For example, when an important bug has been fixed, is it fixed in the >>>> new release kernel only ? Or is it applied on old kernels ? Only the >>>> long term ? All ? >>>> >>>> So if I am using the long term 3.4.49 for example (and the current is >>>> 3.4.51), I can just update the 3.4.49 to get the important bugs fix that >>>> have been fixed in the new release (so 3.9.8 right now ?). >>>> >>>> >>>> And if you have some documentation about it, it would be nice ! >>>> >>>> >>>> Thank you in advance ! >>> >>> Hello! >>> >>> kernel.org [0] is your friend. There is a page explaining the release types >>> [1]. >>> >>> In short, Malnline is the newest but somewhat unstable. It's where >>> everything is tested with new features. It compiles, but it not real >>> world tested. >>> When a version is battle tested and does good without doing bad in the >>> real world, it's called stable. >>> >>> The long term versions are ones that are considered milestones. Those >>> kernels could be used in production for many years because they will >>> be patched with security updates, but nothing major will change in >>> their architecture, so the administrator won't have to worry that if >>> he applies a patch it will break the production server. >>> >>> Hopefully I'm not offending anyone with this comparison, but think >>> ab
Re: Kernel Linux updating
okay ! Thank you for the explanation, Alexandru. I see it more clearly :) What I really want ? Hum, it is for a production purpose. We already use a kernel but it a 2.6.32.59 version. We have some problems and we thought to update it. I had updated it to a 3.8 kernel but, of what you say, I should have updated it to a longterm version. Which one should I use ? In the links you gave me, I see that the 2.6.32 will become EOL in 2014 and 2.6.34 and 3.0 in 2013. The 3.2 will become an EOL in 2016. Should I update to this one ? And we encountered some problems (about CAN controller to be precise). In the CAN mailist, Luka Rahne has the same problem has ours with the 3.0.3 kernel. He tested the 3.0.81 and the problem seems to be gone. So, also, I wanted to know if the possibly fix between 3.0.3 and 3.0.81 would have been spreaded to other kernels ? other long term ? stable ? Thank you again ! Mylène Le 28/06/2013 10:51, Alexandru Juncu a écrit : > On 28 June 2013 11:37, Mylene Josserand wrote: >> Hi everyone, >> >> >> I would like to know how the Linux Kernel are updated. >> I know that there is the long term kernels, the last stables and the >> mainline. >> First, what is the real difference between stable and longterm ? >> >> I see in the Linux Kernel website that the date of the long term (and >> the revision number) is changing so I was thinking that there are some >> updates on it, right ? >> >> For example, when an important bug has been fixed, is it fixed in the >> new release kernel only ? Or is it applied on old kernels ? Only the >> long term ? All ? >> >> So if I am using the long term 3.4.49 for example (and the current is >> 3.4.51), I can just update the 3.4.49 to get the important bugs fix that >> have been fixed in the new release (so 3.9.8 right now ?). >> >> >> And if you have some documentation about it, it would be nice ! >> >> >> Thank you in advance ! > > Hello! > > kernel.org [0] is your friend. There is a page explaining the release types > [1]. > > In short, Malnline is the newest but somewhat unstable. It's where > everything is tested with new features. It compiles, but it not real > world tested. > When a version is battle tested and does good without doing bad in the > real world, it's called stable. > > The long term versions are ones that are considered milestones. Those > kernels could be used in production for many years because they will > be patched with security updates, but nothing major will change in > their architecture, so the administrator won't have to worry that if > he applies a patch it will break the production server. > > Hopefully I'm not offending anyone with this comparison, but think > about it as the Ubuntu versions, if you are familiar with them. You > have a new release every 6 months, that has new features, That's > stable. Like 13.04. But once every two years they have a long term > support version (like 10.04, 12.04, 14.04) that you can rely on for > many years. They will be patched for vulnerabilities (ex. 12.04.1 > probably has secutiy patches like 12.10, but won't have it's new > features). > > So now it's a matter of what you want? Do you want to use it in > production? Maybe you would want a tong term version. Want to use it > for your own use? Probably you want the stable. Want to develop new > features? You might go for the mainline. > > Hope it helps. > > [0] https://www.kernel.org/ > [1] https://www.kernel.org/category/releases.html ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [I2C] informations + advice about messages handling
Hi Jean, Le 24/05/2013 14:20, Jean Delvare a écrit : > On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote: >> - an audio codec tlv320aic3204 : There is a driver for this device but >> for some reasons, we did not use it. Did not find a "SMBus compliant" in >> its datasheet. > > The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to > i2c_transfer. However it seems to only send 2 bytes on the bus at once, > the same could be achieved with i2c_smbus_write_byte_data if needed. Okay, thanks to have looked at it ! > > For completeness: a device might use transactions which are compliant > with SMBus without being formally "SMBus-compliant", because SMBus has > more constraints than just transaction types (I kept things simple > originally to not confuse you.) This may explain why it isn't mentioned > in the datasheet. Or just because the manufacturer did not care because > they target fully I2C-capable systems anyway. > > What you have to look at is the transaction types. They are usually > described in the datasheet. Then compare with either the SMBus > specification or > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol > and if they match then you can use the i2c_smbus_*() calls. I have checked the PIC18F24201 according to your advice and, of what I have seen, it can handle the SMBus protocol. Thank you for the explanation and trying to keep it simple for me :) -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [I2C] informations + advice about messages handling
Le 24/05/2013 11:07, Jean Delvare a écrit : > On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote: >> Ah okay ! And if there are not SMBus compliant, what function I will >> have to use ? > > i2c_transfer() Okay, logic name ;) >> What is it doing if I use this function and that my device is not SMbus >> compliant ? > > This would make no sense. Your device understands only specific message > formats, which should be documented in its datasheet. You have to use > exactly that in your driver. If the message format matches SMBus, you > can use the SMBus API, otherwise you must use i2c_transfer() instead. Very interesting ! Right now, my company uses the "i2c_smbus_read/write_byte_data" functions to talk to devices through an application. On the datasheet of these devices, I search but did not seem to be SMBus compliant. As it was a software which was using these functions, we thought that a driver (that I would write) should be better. And here I am ! I prefer to understand well the mechanism before coding anything and it is interesting ! >> I have some difficulties to understand the differences >> between SMbus and I2C :( > > SMBus is a subset of I2C. With I2C you can have messages of any length > and any format, with no attached semantics. SMBus restricts the > possibilities to a few standardized messages formats with semantics. If > you'd just tell us what your device is, we would be able to tell you if > SMBus will work or if I2C will be needed. Thanks for the explanation. No problem, we have 2 devices used without drivers : - an odometer PIC18F24201 : In the datasheet, there is a SMBus select bit but I don't know if it is SMBus compliant. - an audio codec tlv320aic3204 : There is a driver for this device but for some reasons, we did not use it. Did not find a "SMBus compliant" in its datasheet. >> (...) >> In my case, I have 2 segments but if I understand, the bus will not be >> used at the same time. > > I can't comment on that without knowing the exact topology. In > particular, do you have two independent segments each with its own > controller, or are they interconnected in some way? I2C/SMBus is very > simple with basic topologies but can become difficult with complex ones. Yes of course, I understand. For that, I will ask to our "hardware guy". >> (...) >> Okay. So the mutex blocks the I2C bus. And is it locking the bus at the >> beginning of a message (so when a START is send) and unlocking it after >> the STOP ? > > Yes. > >> So a complete message will be sent to a same device (the one which >> address is in the data frame) ? A device can not receive a beginning of >> one message (so with his address) and the end of another message >> destined to another device [because of "collision"], for example ? > > No, this cannot happen. Thanks a lot for your help ! -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [I2C] informations + advice about messages handling
Thanks, both of you, for your answers ! It helps me a lot to understand it ! Le 24/05/2013 09:22, anish singh a écrit : > On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand > wrote: >> Hi all, >> >> >> I am learning how i2c is working and I read that, to write in an i2c >> register, I need to use the function "i2c_smbus_write_byte_data". > Only in case your device is smbus compliant. Ah okay ! And if there are not SMBus compliant, what function I will have to use ? What is it doing if I use this function and that my device is not SMbus compliant ? I have some difficulties to understand the differences between SMbus and I2C :( Le 24/05/2013 09:44, Jean Delvare a écrit : > Hi Anish, Mylène, > > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: >> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand >> wrote: >>> I have read that this function "i2c_smbus_write_byte_data" uses >>> "i2c_smbus_xfer" which uses "i2c_lock_adapter". >>> In this function, there is a mutex so I thought that it will handle it >>> but it says "Get exclusive access to an I2C bus segment". What is >>> exactly an I2C segment ? Is it the device we are talking about ? Or is >>> it the use of the i2c bus ? >> Don't know what you are referring here. > > In the most simple case, your I2C bus has a single segment so "segment" > or "bus" mean the same thing. > > It only starts mattering when I2C bus multiplexing comes into play. > Then your bus is split into segments, with one segment (trunk) between > the master (controller) and the multiplexer, and one or more segments > (branches) hanging off the multiplexer. > > Take look at > https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing > for a sample topology. > > But anyway the comment in front of i2c_lock_adapter() is somewhat > misleading. If you read the code you'll see that it always locks the > whole bus tree, because it uses the root segment's mutex. Thanks ! I understand now. In my case, I have 2 segments but if I understand, the bus will not be used at the same time. >>> I will certainly have to create an i2c driver and I would like to know >>> if this "collision" handling (if it is handled) is done in old kernel >>> (2.6.32) or is it handled only in new kernel versions ? >> AFAIK collision handling and detection was not supported till now >> in linux kernel until recently but I think this patch is doing that. >> I may be wrong but I didn't see collision handling in earlier linux >> kernels. >> http://thread.gmane.org/gmane.linux.kernel/1410276 > > This is for a specific case. The general case is handled by the > per-adapter mutex for years now. 2.6.32 should be just fine in this > respect. Okay. So the mutex blocks the I2C bus. And is it locking the bus at the beginning of a message (so when a START is send) and unlocking it after the STOP ? So a complete message will be sent to a same device (the one which address is in the data frame) ? A device can not receive a beginning of one message (so with his address) and the end of another message destined to another device [because of "collision"], for example ? >>> If you have any documentation on how the i2c messages are handled in >>> case of different devices uses, it will help me a lot ! I will search in >>> the kernel documentation but there is many files about i2c. >>> And if you know a good i2c driver that I can use as an example to design >>> mine, it will be great ! > > Best is to look at a driver for a device which is similar in > functionality to yours. I will search that, thanks for the advice. -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[I2C] informations + advice about messages handling
Hi all, I am learning how i2c is working and I read that, to write in an i2c register, I need to use the function "i2c_smbus_write_byte_data". I wanted to know how the message are handled by using this function. If I use this function to talk with 2 different i2d devices, how it will handle "message collision" ? should I have to add a kind of mutex on the access of the i2c bus ? Is it possible that the message destined for one device is sent to another one ? Or a "mix" of messages is impossible ? I have read that this function "i2c_smbus_write_byte_data" uses "i2c_smbus_xfer" which uses "i2c_lock_adapter". In this function, there is a mutex so I thought that it will handle it but it says "Get exclusive access to an I2C bus segment". What is exactly an I2C segment ? Is it the device we are talking about ? Or is it the use of the i2c bus ? I will certainly have to create an i2c driver and I would like to know if this "collision" handling (if it is handled) is done in old kernel (2.6.32) or is it handled only in new kernel versions ? If you have any documentation on how the i2c messages are handled in case of different devices uses, it will help me a lot ! I will search in the kernel documentation but there is many files about i2c. And if you know a good i2c driver that I can use as an example to design mine, it will be great ! Thank you in advance, -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[help] USB - kernel 3.8 : ULPI timeout
Hi everyone, I have a USB problem. I have already posted it on USB mailing list where Fabio Estevam can reproduce it on mx27pdk and mx31pdk (see http://www.spinics.net/lists/linux-usb/msg84305.html). I thought that it is maybe a "newbie" question/error (because I am) so here I am :) My configuration is an IMX27 with an ISP1504 with a 3.8.2 kernel. I tested it with a SMSC USB3340 transceiver where the same error appears with ULPI (for a OTG and H2 port) : ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing I have read the datasheet of the two USB transceiver. On the SMSC USB3340, we have some gpios on RESET_B and I put it in high in the init board code. With this, it should have been correctly initialiazed (right ?) but there is again this "timeout" of ULPI. Do you have already seen this "error" ? What is it due to ? A mistake in the init configuration ? Thank you in advance for any help to understand how ULPI is working and what I am certainly doing wrong. -- Mylène JOSSERAND Navocap ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [help] kernel oops in function gpio_to_irq
Hi everyone, Just to update you that I have found my problem ! The problem was, in fact, the "gpio_request" function which was every time failing and so the "gpio_to_irq" and "request_irq" functions. After some research and a reading of the gpio documentation (in case I would have missed something), I noticed a difference between my code and the other IMX27 boards : "imx27_soc_init();" A very very important function that I have forgotten ! And now, all is okay with "gpio_request" and so on ! So happy ! :D And thank you again, Matthias, for your help / advice :) Best regards, -- Mylène JOSSERAND Navocap Le 02/04/2013 11:45, Mylene Josserand a écrit : > Hi Matthias, > > > Le 30/03/2013 14:09, Matthias Brugger a écrit : >> >> El 27/03/2013 18:16, "Mylene Josserand"> <mailto:mylene.josser...@navocap.com>> va escriure: >> > >> > Hi everyone, >> > >> > >> > I have a problem with gpio functions. >> > My kernel version is 3.8.2 and my SoC is a imX27 on a "home-made" board. >> > >> > First, when I boot, I had only the "Starting kernel..." message. >> > So I rebuild my kernel with CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL and >> > CONFIG_EARLY_PRINTK. I have also add the line >> > "earlyprintk=console,UART0,115200" on the bootargs of my Barebox. >> > >> > With that, I can see more messages : >> > >> > [...] >> > Unable to handle kernel NULL pointer dereference at virtual address >> 002c >> > pgd = c0004000 >> > [002c] *pgd= >> > Internal error: Oops: 5 [#1] PREEMPT ARM >> > Modules linked in: >> > CPU: 0Not tainted (3.8.2+ #4) >> > PC is at __gpio_to_irq+0x1c/0x44 >> > LR is at navocap_baseboard_init+0xd8/0x2c8 >> > pc : []lr : []psr: 6053 >> > sp : c7835ef0 ip : 0079 fp : c05a5628 >> > r10: c04f817c r9 : r8 : c05a562c >> > r7 : c7834000 r6 : 0004 r5 : c05158c4 r4 : c0578844 >> > r3 : 05ac r2 : c05b0410 r1 : c7834000 r0 : >> > Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel >> > Control: 0005317f Table: a0004000 DAC: 0017 >> > Process swapper (pid: 1, stack limit = 0xc78341b8) >> > Stack: (0xc7835ef0 to 0xc7836000) >> > 5ee0: c05158c4 c04fd468 0002 >> > 10009000 >> > 5f00: 10009fff 0200 c05158c4 >> > c04fd348 >> > 5f20: c0578844 c04f819c c04d23dc c00087f8 0003 0003 c04d1b2c >> > c06bd6a0 >> > 5f40: c0578844 c05158c4 0004 008b c05a562c c0515898 >> > c04f6378 >> > 5f60: c05a5620 c04f62a0 0003 0003 c04f6378 c00403e0 >> > >> > 5f80: c03cfee0 >> > c03cfeec >> > 5fa0: c03cfee0 c00093b0 >> > >> > 5fc0: >> > >> > 5fe0: 0013 0010 >> > 000a1000 >> > [] (__gpio_to_irq+0x1c/0x44) from [] >> > (navocap_baseboard_init+0xd8/0x2c8) >> > [] (navocap_baseboard_init+0xd8/0x2c8) from [] >> > (customize_machine+0x20/0x30) >> > [] (customize_machine+0x20/0x30) from [] >> > (do_one_initcall+0x2c/0x168) >> > [] (do_one_initcall+0x2c/0x168) from [] >> > (kernel_init_freeable+0xf4/0x1cc) >> > [] (kernel_init_freeable+0xf4/0x1cc) from [] >> > (kernel_init+0xc/0x164) >> > [] (kernel_init+0xc/0x164) from [] >> > (ret_from_fork+0x14/0x24) >> > Code: e0433100 e1a0c000 e7920003 e24dd004 (e590302c) >> > ---[ end trace 61bb09c25216d85b ]--- >> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b >> > >> > >> > The problem is in the function "gpio_to_irq" in my board init functions >> > (navocap_baseboard_init). >> > >> > To know which lines the opps appears, I have followed this tutorial : >> > https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks >> > >> > Thanks to it, I can notice that the opps appears when I called the >> > &qu
Re: [help] kernel oops in function gpio_to_irq
Hi Matthias, Le 30/03/2013 14:09, Matthias Brugger a écrit : > > El 27/03/2013 18:16, "Mylene Josserand" <mailto:mylene.josser...@navocap.com>> va escriure: > > > > Hi everyone, > > > > > > I have a problem with gpio functions. > > My kernel version is 3.8.2 and my SoC is a imX27 on a "home-made" board. > > > > First, when I boot, I had only the "Starting kernel..." message. > > So I rebuild my kernel with CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL and > > CONFIG_EARLY_PRINTK. I have also add the line > > "earlyprintk=console,UART0,115200" on the bootargs of my Barebox. > > > > With that, I can see more messages : > > > > [...] > > Unable to handle kernel NULL pointer dereference at virtual address > 002c > > pgd = c0004000 > > [002c] *pgd= > > Internal error: Oops: 5 [#1] PREEMPT ARM > > Modules linked in: > > CPU: 0Not tainted (3.8.2+ #4) > > PC is at __gpio_to_irq+0x1c/0x44 > > LR is at navocap_baseboard_init+0xd8/0x2c8 > > pc : []lr : []psr: 6053 > > sp : c7835ef0 ip : 0079 fp : c05a5628 > > r10: c04f817c r9 : r8 : c05a562c > > r7 : c7834000 r6 : 0004 r5 : c05158c4 r4 : c0578844 > > r3 : 05ac r2 : c05b0410 r1 : c7834000 r0 : > > Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel > > Control: 0005317f Table: a0004000 DAC: 0017 > > Process swapper (pid: 1, stack limit = 0xc78341b8) > > Stack: (0xc7835ef0 to 0xc7836000) > > 5ee0: c05158c4 c04fd468 0002 > > 10009000 > > 5f00: 10009fff 0200 c05158c4 > > c04fd348 > > 5f20: c0578844 c04f819c c04d23dc c00087f8 0003 0003 c04d1b2c > > c06bd6a0 > > 5f40: c0578844 c05158c4 0004 008b c05a562c c0515898 > > c04f6378 > > 5f60: c05a5620 c04f62a0 0003 0003 c04f6378 c00403e0 > > > > 5f80: c03cfee0 > > c03cfeec > > 5fa0: c03cfee0 c00093b0 > > > > 5fc0: > > > > 5fe0: 0013 0010 > > 000a1000 > > [] (__gpio_to_irq+0x1c/0x44) from [] > > (navocap_baseboard_init+0xd8/0x2c8) > > [] (navocap_baseboard_init+0xd8/0x2c8) from [] > > (customize_machine+0x20/0x30) > > [] (customize_machine+0x20/0x30) from [] > > (do_one_initcall+0x2c/0x168) > > [] (do_one_initcall+0x2c/0x168) from [] > > (kernel_init_freeable+0xf4/0x1cc) > > [] (kernel_init_freeable+0xf4/0x1cc) from [] > > (kernel_init+0xc/0x164) > > [] (kernel_init+0xc/0x164) from [] > > (ret_from_fork+0x14/0x24) > > Code: e0433100 e1a0c000 e7920003 e24dd004 (e590302c) > > ---[ end trace 61bb09c25216d85b ]--- > > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b > > > > > > The problem is in the function "gpio_to_irq" in my board init functions > > (navocap_baseboard_init). > > > > To know which lines the opps appears, I have followed this tutorial : > > https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks > > > > Thanks to it, I can notice that the opps appears when I called the > > "gpio_to_irq" function in : > > > > ret = request_irq(gpio_to_irq(IMX_GPIO_NR(2,14)), detect_irq, > > IRQF_TRIGGER_FALLING, "imx-mmc-detect", data); > > Make sure your arguments are not NULL (IMX_GPIO_NR, detect_irq and data). > > Some extra printk's before calling request_irq should do. Thank you very much for your help ! I will try that. > > > > > > > I have checked in other boards how to use this function and it is > > configured in the same way. > > I did see where I have made a mistake. Maybe in my config file where I > > have missed a configuration option ? How to solve this opps problem ? It > > would be very great if someone could give me some helps / feedbacks on > > this problem. > > > > Thank you in advance ! > > > > Best regards, > > > > > > -- > > Mylène JOSSERAND > > Navocap > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org> > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Best regards, -- Mylène JOSSERAND Navocap ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[help] kernel oops in function gpio_to_irq
Hi everyone, I have a problem with gpio functions. My kernel version is 3.8.2 and my SoC is a imX27 on a "home-made" board. First, when I boot, I had only the "Starting kernel..." message. So I rebuild my kernel with CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK. I have also add the line "earlyprintk=console,UART0,115200" on the bootargs of my Barebox. With that, I can see more messages : [...] Unable to handle kernel NULL pointer dereference at virtual address 002c pgd = c0004000 [002c] *pgd= Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0Not tainted (3.8.2+ #4) PC is at __gpio_to_irq+0x1c/0x44 LR is at navocap_baseboard_init+0xd8/0x2c8 pc : []lr : []psr: 6053 sp : c7835ef0 ip : 0079 fp : c05a5628 r10: c04f817c r9 : r8 : c05a562c r7 : c7834000 r6 : 0004 r5 : c05158c4 r4 : c0578844 r3 : 05ac r2 : c05b0410 r1 : c7834000 r0 : Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: a0004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc78341b8) Stack: (0xc7835ef0 to 0xc7836000) 5ee0: c05158c4 c04fd468 0002 10009000 5f00: 10009fff 0200 c05158c4 c04fd348 5f20: c0578844 c04f819c c04d23dc c00087f8 0003 0003 c04d1b2c c06bd6a0 5f40: c0578844 c05158c4 0004 008b c05a562c c0515898 c04f6378 5f60: c05a5620 c04f62a0 0003 0003 c04f6378 c00403e0 5f80: c03cfee0 c03cfeec 5fa0: c03cfee0 c00093b0 5fc0: 5fe0: 0013 0010 000a1000 [] (__gpio_to_irq+0x1c/0x44) from [] (navocap_baseboard_init+0xd8/0x2c8) [] (navocap_baseboard_init+0xd8/0x2c8) from [] (customize_machine+0x20/0x30) [] (customize_machine+0x20/0x30) from [] (do_one_initcall+0x2c/0x168) [] (do_one_initcall+0x2c/0x168) from [] (kernel_init_freeable+0xf4/0x1cc) [] (kernel_init_freeable+0xf4/0x1cc) from [] (kernel_init+0xc/0x164) [] (kernel_init+0xc/0x164) from [] (ret_from_fork+0x14/0x24) Code: e0433100 e1a0c000 e7920003 e24dd004 (e590302c) ---[ end trace 61bb09c25216d85b ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b The problem is in the function "gpio_to_irq" in my board init functions (navocap_baseboard_init). To know which lines the opps appears, I have followed this tutorial : https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks Thanks to it, I can notice that the opps appears when I called the "gpio_to_irq" function in : ret = request_irq(gpio_to_irq(IMX_GPIO_NR(2,14)), detect_irq, IRQF_TRIGGER_FALLING, "imx-mmc-detect", data); I have checked in other boards how to use this function and it is configured in the same way. I did see where I have made a mistake. Maybe in my config file where I have missed a configuration option ? How to solve this opps problem ? It would be very great if someone could give me some helps / feedbacks on this problem. Thank you in advance ! Best regards, -- Mylène JOSSERAND Navocap ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel updating : export gpio not working ?
Hi, Thank you for your answer ! :) No problem to post back my solution. I think it can always be useful to know the solution of a problem even if it is a specific one. And I would be happy if it could help other kernel-newbies not to do the same "error" ;) Best regards, -- Mylène JOSSERAND Le 27/02/2013 18:42, Mulyadi Santosa a écrit : > On Wed, Feb 27, 2013 at 10:19 PM, Mylene Josserand > wrote: >> Just to update you that I have found my problem ! >> >> In my config file, I did not notice that my own board and an other imx27 >> board was enabled ! So the gpios configured was the one from this board >> and not mine's (thanks debugfs !). That is why it did not act like I wanted. > > This is the kind of post that I like most some one has problem but > he/she also still find a way to solve. Then post it back to > kernelnewbies. > > Nice info to know. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel updating : export gpio not working ?
Just to update you that I have found my problem ! In my config file, I did not notice that my own board and an other imx27 board was enabled ! So the gpios configured was the one from this board and not mine's (thanks debugfs !). That is why it did not act like I wanted. Otherwise, the gpios are still exported as "gpioXX" and not with "name_of_gpio". The label "name_of_gpio" can be found in the debugfs but not printed in the sysfs. I don't know if there is a way to change that, I will search for it if I have time. Best regards, -- Mylène JOSSERAND Le 27/02/2013 11:51, Mylene Josserand a écrit : > Hi everyone ! > > > I am currently updating the kernel of my company and I have some > problems about gpios so I am asking you some help ! :) > I think I am in the good mailist because it is the first time I update a > kernel and a board configuration ! :D > > The previous kernel used was 2.6.31.14 and I am trying to update it to > last stable version 3.7.9. > > In the previous kernel for a "home-made" board (with a IMx27 and a > ARM9), we used these methods to export gpios in sysfs (for example for > Gpio OUT) : > > mxc_gpio_mode(gpio_number | GPIO_GPIO | GPIO_OUT); > gpio_request(gpio_number, name_of_gpio); > gpio_export(gpio_number, 0); > gpio_direction_output(gpio_number, gpio_value); > > In the sysfs, the gpio exported was visible under "name_of_gpio". > > Now, if I use the same methods, I can not get anything in sysfs except > "gpiochip0, gpiochip32" etc. > I tried to use these functions in a module and I could export a gpio but > under "gpioXX" and not "name_of_gpio". Moreover, I tried to export a > gpio using the sysfs interface. I succeeded to export it and set > direction to "out" but when I try to set the value, it did not work and > the value is always set to 0 (and this gpio was configured as OUT in the > board). > > I make a diff about the gpio documentation and the old kernel used did > not seem to have many differences with the new kernel ! There is only > some methods added such as "gpio_resquest_one" and "gpio_export_link". I > tried them without good results. > > > What am I doing wrong ? > What am I missing to make it work ? > Is there some other configurations to add in the board configuration ? > > > Thank you for any help/explanation ! > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel updating : export gpio not working ?
Hi everyone ! I am currently updating the kernel of my company and I have some problems about gpios so I am asking you some help ! :) I think I am in the good mailist because it is the first time I update a kernel and a board configuration ! :D The previous kernel used was 2.6.31.14 and I am trying to update it to last stable version 3.7.9. In the previous kernel for a "home-made" board (with a IMx27 and a ARM9), we used these methods to export gpios in sysfs (for example for Gpio OUT) : mxc_gpio_mode(gpio_number | GPIO_GPIO | GPIO_OUT); gpio_request(gpio_number, name_of_gpio); gpio_export(gpio_number, 0); gpio_direction_output(gpio_number, gpio_value); In the sysfs, the gpio exported was visible under "name_of_gpio". Now, if I use the same methods, I can not get anything in sysfs except "gpiochip0, gpiochip32" etc. I tried to use these functions in a module and I could export a gpio but under "gpioXX" and not "name_of_gpio". Moreover, I tried to export a gpio using the sysfs interface. I succeeded to export it and set direction to "out" but when I try to set the value, it did not work and the value is always set to 0 (and this gpio was configured as OUT in the board). I make a diff about the gpio documentation and the old kernel used did not seem to have many differences with the new kernel ! There is only some methods added such as "gpio_resquest_one" and "gpio_export_link". I tried them without good results. What am I doing wrong ? What am I missing to make it work ? Is there some other configurations to add in the board configuration ? Thank you for any help/explanation ! -- Mylène JOSSERAND ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
