ioremap() fails for 64 MB
I think 64MB limitation of ioremap() is due to the kernel's page size. When compiling kernel, it has an option to choose the memory page size which is default 64MB. To use memory greater than 64MB, there is two methods. One is to make the kernel's page size larger as Phil Nitschke said. Another is to modify ioremap() a little bit --- just make it use another file for mmap while larger than 64MB. Since the central concept of linux is file-based, I think more files are not harmful that only waste a little bit inode structure. And it is much more feasible that one can choose to use file in memory or harddisk or mounted device harddisk/memory ... ... -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+vows_siu=yahoo.com.hk at ozlabs.org] On Behalf Of Phil Nitschke Sent: Wednesday, August 23, 2006 6:01 PM To: Matt Porter Cc: linuxppc-embedded at ozlabs.org Subject: Re: ioremap() fails for 64 MB On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote: On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote: Hi all, I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk of it at boot-time, then ioremap() it into the kernel space inside a device driver. So far I've succeeded with 64 MB, but can't go any higher, as mm/vmalloc.c tells me: allocation failed: out of vmalloc space - use vmalloc=size to increase size. So I tried adding a vmalloc line to the kernel command line as follows: Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=... Yeah, that suggestion is bogus. That option can't help with getting more vmalloc space in this case. So the vmalloc=size argument has made no difference. What do I need to do to make this work? Go to the Advanced setup menu. There's a number of options to provide fine-grained control of the PPC kernel virtual address space. SNIP Thanks Matt (and others) for your suggestions. Matt has given me the answers I was looking for. Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit processor, why do I need high memory at all? Are there performance implications on this platform from having a non optimal low/high ratio? That said, why don't you just use alloc_bootmem() to reserve memory for your driver at boot time? I avoided this simply because I wanted to load/unload my driver (during development), and alloc_bootmem() seemed better suited to drivers compiled into the kernel. But I'll look again at this idea if further problems arise with the approach above. Thanks again, -- Phil ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 2006/8/22 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 2006/8/23
I2C driver for SAA7121 on MPC855 and linux-2.4.25
Hi, I am trying to setup i2c driver for saa7121 on my mpc855 based board normally the address for saa7121 is 0x88, but when I enable i2c bus scan, the driver detect it's address is 0x34, so I just stick to 0x34. Anyway, I can write to saa7121via i2c bus successfully, but I can't enable color bar, so I don't know whether the driver is working properly or not? BTW, I setup I2C driver for SAA7113 and it works fine. Tim
atomic operations in user space
Why do you need atomic operations in user land? IPC will be sufficient to deal with race conditions between processes. Best Regards, Leo -Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Terry Liang Sent: Thursday, August 24, 2006 3:04 AM To: linuxppc-embedded at ozlabs.org Subject: atomic operations in user space Thanks. Arnd. My main concern is whether the operations are really atomic as they are in the kernel space. I have read some discussion in another forum that on other platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. from an user space application, they don't guarantee to be atomic. Thanks. Regards, Terry Liang
I2C driver for SAA7121 on MPC855 and linux-2.4.25
-Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Xu, Li (GE, Research) Sent: Thursday, August 24, 2006 4:02 PM To: linuxppc-embedded at ozlabs.org Subject: I2C driver for SAA7121 on MPC855 and linux-2.4.25 Hi, I am trying to setup i2c driver for saa7121 on my mpc855 based board normally the address for saa7121 is 0x88, but when I enable i2c bus scan, the driver detect it's address is 0x34, so I just stick to 0x34. Is it the only device on i2c bus? Anyway, I can write to saa7121via i2c bus successfully, but I can't enable color bar, so I don't know whether the driver is working properly or not? Are you sure you are operating on the correct device? What operation can you do successfully on the device? Can you read from the i2c bus? BTW, I setup I2C driver for SAA7113 and it works fine. Tim
ARCH=ppc or ARCH=powerpc
Hello, I'm new to Linux PowerPC platform, and I'm wondering what ARCH we should use to build the kernel. There seems to be 'ppc' and 'powerpc'. What's the difference between the two ? Thank you ! Benjamin
ARCH=ppc or ARCH=powerpc
ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. Parav Benjamin Delagoutte BDE at teamlog.com wrote: Hello, I'm new to Linux PowerPC platform, and I'm wondering what ARCH we should use to build the kernel. There seems to be 'ppc' and 'powerpc'. What's the difference between the two ? Thank you ! Benjamin ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/8ce76255/attachment.htm
ARCH=ppc or ARCH=powerpc
On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote: ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. They did originally. The new direction is to have everything under arch/powerpc, both 32 and 64 bit. The reason arch/ppc still exists is because some 32 bit platforms have not been fully migrated to the requirements to be merged into arch/powerpc. Namely, the code has to boot from an OpenFirmware like flattened device tree. The PPC 4xx family of processors, as an example, does not do this yet though there is work going on to adapt it. Eventually, arch/ppc will go away and all of PowerPC will be under arch/powerpc. That's the goal anyway. josh
MPC8555 PCI interrupts are not coming
Hi, Can someone give light on PCI interrupts routing to the OS from the openPIC? Basically I am able to talk to PCI end device connected on MPC8555 board in 2.6.13 but not getting interrupts reported by my device. When I read the INTERRUPT_LINE byte, it comes as 0. pdev-irq is also reporting 0. Due to that request_irq() fails. But now I request for IRQ line 8 + openPIC offset. Handler gets registered but still not getting the interrupts. (PCI interrupt line is 8,9 in case of MPC8555). Can anyone please guide me, what are the different things need be configure in the platform code to receive the PCI interrupts in the driver? I don't understand the pci_irq_table, and what it should represent? Currrently no one is writing the INTERRUPT LINE value in the config space. In which function I should configure that value? pcibios_fixup?? Regards, Parav Pandit - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/068788be/attachment.htm
ARCH=ppc or ARCH=powerpc
Le jeudi 24 ao?t 2006 ? 07:49 -0500, Josh Boyer a ?crit : On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote: ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. They did originally. The new direction is to have everything under arch/powerpc, both 32 and 64 bit. The reason arch/ppc still exists is because some 32 bit platforms have not been fully migrated to the requirements to be merged into arch/powerpc. Namely, the code has to boot from an OpenFirmware like flattened device tree. The PPC 4xx family of processors, as an example, does not do this yet though there is work going on to adapt it. I'm currently working on a PPC 405 based developement card. Does it mean I have to work using the arch/ppc tree ? What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? Eventually, arch/ppc will go away and all of PowerPC will be under arch/powerpc. That's the goal anyway. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ARCH=ppc or ARCH=powerpc
Thanks for correcting my understanding. We would also move our code to powerpc from ppc next release onwards. Parav Josh Boyer jdub at us.ibm.com wrote: On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote: ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. They did originally. The new direction is to have everything under arch/powerpc, both 32 and 64 bit. The reason arch/ppc still exists is because some 32 bit platforms have not been fully migrated to the requirements to be merged into arch/powerpc. Namely, the code has to boot from an OpenFirmware like flattened device tree. The PPC 4xx family of processors, as an example, does not do this yet though there is work going on to adapt it. Eventually, arch/ppc will go away and all of PowerPC will be under arch/powerpc. That's the goal anyway. josh - Stay in the know. Pulse on the new Yahoo.com. Check it out. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/54a92665/attachment.htm
ARCH=ppc or ARCH=powerpc
On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote: I'm currently working on a PPC 405 based developement card. Does it mean I have to work using the arch/ppc tree ? For now, yes. Set ARCH=ppc when you compile the kernel. What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? I believe there are some hacks in the makefiles to pull common asm files from include/asm-powerpc when needed. Basically, you should be able to just do: #include asm/foo.h and it should work. If you're adding new .h files, I suppose asm-ppc is the place to add them for now. That's just my opinion though :) josh
ARCH=ppc or ARCH=powerpc
On Thu, Aug 24, 2006 at 02:58:15PM +0200, Benjamin Delagoutte wrote: Le jeudi 24 ao?t 2006 ? 07:49 -0500, Josh Boyer a ?crit : On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote: ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. They did originally. The new direction is to have everything under arch/powerpc, both 32 and 64 bit. The reason arch/ppc still exists is because some 32 bit platforms have not been fully migrated to the requirements to be merged into arch/powerpc. Namely, the code has to boot from an OpenFirmware like flattened device tree. The PPC 4xx family of processors, as an example, does not do this yet though there is work going on to adapt it. I'm currently working on a PPC 405 based developement card. Does it mean I have to work using the arch/ppc tree ? PPC405 is only supported in the arch/ppc tree currenty. Unless you want to contribute to the effort to move to arch/powerpc, you'll have to work with arch/ppc/ What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? When you do an arch/ppc build it automagically includes shared includes from asm-powerpc as necessary. There's nothing to worry about there. The goal is to have the new 4xx arch/powerpc support not break 4xx arch/ppc support. So as boards are merged and verified working, we'll remove the equivalent support from arch/ppc... Some boards/chips may just die if no maintainer step up to port them over...but all the important stuff should get an interested party once we get the initial 4xx support in arch/powerpc working. -Matt
ARCH=ppc or ARCH=powerpc
On Thu, Aug 24, 2006 at 08:07:20AM -0500, Josh Boyer wrote: On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote: What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? I believe there are some hacks in the makefiles to pull common asm files from include/asm-powerpc when needed. Basically, you should be able to just do: #include asm/foo.h and it should work. If you're adding new .h files, I suppose asm-ppc is the place to add them for now. That's just my opinion though :) That's what I would recommend too. If this is for an out-of-tree custom port then there's no real concern anyway. -Matt
ioremap() fails for 64 MB
On Thu, Aug 24, 2006 at 10:54:23AM +0800, alva wrote: I think 64MB limitation of ioremap() is due to the kernel's page size. When compiling kernel, it has an option to choose the memory page size which is default 64MB. To use memory greater than 64MB, there is two methods. One is to make the kernel's page size larger as Phil Nitschke said. Another is to modify ioremap() a little bit --- just make it use another file for mmap while larger than 64MB. Since the central concept of linux is file-based, I think more files are not harmful that only waste a little bit inode structure. And it is much more feasible that one can choose to use file in memory or harddisk or mounted device harddisk/memory ... ... This is incorrect. There is no 64MB page size. Unless you are ioremapping a region overed by a BAT/CAM, the mapping is composed of default 4KB PTEs. The reason it fails is because of what I explained earlier. Just wanted to clarify so nobody was confused by these statements. We can map arbitrary sizes to the limit of what the kernel virtual address space settings allow. This varies from platform to platform. -Matt
ioremap() fails for 64 MB
On Wed, Aug 23, 2006 at 07:30:37PM +0930, Phil Nitschke wrote: On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote: On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote: Hi all, I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk of it at boot-time, then ioremap() it into the kernel space inside a device driver. So far I've succeeded with 64 MB, but can't go any higher, as mm/vmalloc.c tells me: allocation failed: out of vmalloc space - use vmalloc=size to increase size. So I tried adding a vmalloc line to the kernel command line as follows: Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=... Yeah, that suggestion is bogus. That option can't help with getting more vmalloc space in this case. So the vmalloc=size argument has made no difference. What do I need to do to make this work? Go to the Advanced setup menu. There's a number of options to provide fine-grained control of the PPC kernel virtual address space. SNIP Thanks Matt (and others) for your suggestions. Matt has given me the answers I was looking for. Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit processor, why do I need high memory at all? Dan answered this one... Are there performance implications on this platform from having a non optimal low/high ratio? It depends. In PPC, we've always has kernelbase at 0xc000, however, the dirty secret is that we still haven't have a 3:1 user:kernel split like some other arches. We've always had TASK_SIZE at 0x8000 which really results in a 1:1 split. So, as long as you don't modify TASK_SIZE, there's no chance of starving memory hungry user space applications. There's already this waste space from 0x8000-0xbfff that was left due to legacy PReP reasons. Even if you do modify TASK_SIZE down to something like 0x4000, for a 1:3 split, many embedded apps are perfectly happy with this space, YMMV. It's important that you understand how the userspace works at the low level, plus VSIDs (on classic PPC), and the general concepts of the virtual memory organization between kernel and userspace before you mess with all these advanced options. They are under advanced options since they can easily make your system inoperable with the improper settings. That said, why don't you just use alloc_bootmem() to reserve memory for your driver at boot time? I avoided this simply because I wanted to load/unload my driver (during development), and alloc_bootmem() seemed better suited to drivers compiled into the kernel. But I'll look again at this idea if further problems arise with the approach above. I see. It doesn't have any bearing on using a loadable module since alloc_bootmem() is only called by your board port code. Your loadable module just uses that reserved area and manages it on its own. In any case, either approach will work. -Matt
MontaVista 2.6 Kernel support for Xilinx ML40x
I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank
atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote: Why do you need atomic operations in user land? IPC will be sufficient to deal with race conditions between processes. Best Regards, Leo What about multiple threads within a process updating a counter? Of course, if you look at these functions in the kernel header, they're just 2 or 3 inline assembly calls - you could easily rewrite them. Google for 'PowerPC atomic increment' and grab one of the unencumbered implementations if you need to use it in a non-GPL program. On the other hand, I see no license at the top of my /usr/include/asm-i386/atomic.h file at all, same for PowerPC - are Linux header files actually GPL or are they more like the glibc headers, with exceptions made for userspace programs? The atomic operations on x86 were accidentally exported early on, so they have to hang around apparently for compatibility (there are some mailing list threads out there to this effect.) Currently, you just have to assume in Linux that if you include something from /usr/include/linux or asm that it will not necessarily be cross-version or cross-architecture compatible. Not every arch in Linux even has atomic operations of this nature, which I guess is the main reason why they are not exported in general. - Brent -Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Terry Liang Sent: Thursday, August 24, 2006 3:04 AM To: linuxppc-embedded at ozlabs.org Subject: atomic operations in user space Thanks. Arnd. My main concern is whether the operations are really atomic as they are in the kernel space. I have read some discussion in another forum that on other platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. from an user space application, they don't guarantee to be atomic. Thanks. Regards, Terry Liang ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/4f60ee9d/attachment.htm
CompactFlash on PQII Pro
Thanks Kumar, As always, you're several steps ahead of me. On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote: I know I posted a patch for cf-ide.c to lkml some time ago, this was to do a CF in true ide mode using the 83xx localbus. http://marc.theaimsgroup.com/?l=linux-kernelm=113877891224982w=2 We did some UPM setup in u-boot to use two CS on Localbus for this. In our case, we only have one CS available but it's going to a CPLD that will decode and provide two CSs to the CF. This will work as long as the UPM setup is identical for the two chip selects. Should be... Off-topic to this list, but do you have the U-boot code that you can share? If not, no worries. thanks, Ben
MontaVista 2.6 Kernel support for Xilinx ML40x
Frank, due to my understanding of the GPL (and i have already invested some time in understanding the various flavours of open source licences), you should contact Montavista, and ask them for the sources. This board adaption is derivative work of the GPL Kernel, so the result of this work also falls under the GPL, and has to be made freely available under the terms of the GPL. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org] On Behalf Of Frank D Lombardo Sent: Donnerstag, 24. August 2006 15:59 To: linuxppc-embedded at ozlabs.org Subject: MontaVista 2.6 Kernel support for Xilinx ML40x I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MontaVista 2.6 Kernel support for Xilinx ML40x
I too had high hopes when I heard an LSP for the ML40x was imminent, I nabbed it and was disappointed to find that their drivers still only support relatively old versions of the Xilinx IP. It would seem that they are still creating the design they ported to with EDK/ISE v7.2 rather than the newer 8.1 or 8.2 with updated IP libraries. This is from the xparameters_ml40x.h file they distribute. /*** * * CAUTION: This file is automatically generated by libgen. * Version: Xilinx EDK 7.1.2 EDK_H.12.5.1 * DO NOT EDIT. * * Copyright (c) 2005 Xilinx, Inc. All rights reserved. * * Description: Driver parameters * ***/ Sigh. -michael I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank
MontaVista 2.6 Kernel support for Xilinx ML40x
I've got the LSP, and have booted it on the ML40X. In my opinion it is currently unstable, but that is my opinion. I've not been able to keep it powered up for 24 hours without it locking up on the RS232 serial terminal. Also, running updatedb over nfs causes it to abort with a kernel panic, although that might be an interraction with the nfs server. (Although even if the nfs server dies (which it did not), I don't expect a kernel panic). I have had it run over 6 hours without issue, so I expect subtle memory leaks, not serious problems. On 8/24/06, Claus Gindhart claus.gindhart at kontron.com wrote: Frank, due to my understanding of the GPL (and i have already invested some time in understanding the various flavours of open source licences), you should contact Montavista, and ask them for the sources. This board adaption is derivative work of the GPL Kernel, so the result of this work also falls under the GPL, and has to be made freely available under the terms of the GPL. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -Original Message- From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org [mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org] On Behalf Of Frank D Lombardo Sent: Donnerstag, 24. August 2006 15:59 To: linuxppc-embedded at ozlabs.org Subject: MontaVista 2.6 Kernel support for Xilinx ML40x I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/053fa0d2/attachment.htm
MontaVista 2.6 Kernel support for Xilinx ML40x
Note that Xilinx plans to update the MV drivers to support the latest IP in EDK 8.2.2 (due out around October), and these drivers would be part of the BSP generation process of Platform Studio. Sorry, the timing of the MV ML40x work and our EDK 8.1.x release was such that MV had no choice but to use older IP and drivers. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Michael Galassi Sent: Thursday, August 24, 2006 9:18 AM To: Frank D Lombardo Cc: linuxppc-embedded at ozlabs.org Subject: Re: MontaVista 2.6 Kernel support for Xilinx ML40x I too had high hopes when I heard an LSP for the ML40x was imminent, I nabbed it and was disappointed to find that their drivers still only support relatively old versions of the Xilinx IP. It would seem that they are still creating the design they ported to with EDK/ISE v7.2 rather than the newer 8.1 or 8.2 with updated IP libraries. This is from the xparameters_ml40x.h file they distribute. /*** * * CAUTION: This file is automatically generated by libgen. * Version: Xilinx EDK 7.1.2 EDK_H.12.5.1 * DO NOT EDIT. * * Copyright (c) 2005 Xilinx, Inc. All rights reserved. * * Description: Driver parameters * ***/ Sigh. -michael I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MontaVista 2.6 Kernel support for Xilinx ML40x
Wade, are you sure that you did not build your hardware with evaluation cores of the licenses? If you are using the evaluation licenses the hardware (FPGA design) will stop working after a certain amount of time and you will see a lock-up. - Peter Wade Maxfield wrote: I've got the LSP, and have booted it on the ML40X. In my opinion it is currently unstable, but that is my opinion. I've not been able to keep it powered up for 24 hours without it locking up on the RS232 serial terminal. Also, running updatedb over nfs causes it to abort with a kernel panic, although that might be an interraction with the nfs server. (Although even if the nfs server dies (which it did not), I don't expect a kernel panic). I have had it run over 6 hours without issue, so I expect subtle memory leaks, not serious problems. On 8/24/06, Claus Gindhart claus.gindhart at kontron.com mailto:claus.gindhart at kontron.com wrote: Frank, due to my understanding of the GPL (and i have already invested some time in understanding the various flavours of open source licences), you should contact Montavista, and ask them for the sources. This board adaption is derivative work of the GPL Kernel, so the result of this work also falls under the GPL, and has to be made freely available under the terms of the GPL. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -Original Message- From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org mailto:kontron.com at ozlabs.org [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org] On Behalf Of Frank D Lombardo Sent: Donnerstag, 24. August 2006 15:59 To: linuxppc-embedded at ozlabs.org mailto:linuxppc-embedded at ozlabs.org Subject: MontaVista 2.6 Kernel support for Xilinx ML40x I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org mailto:Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org mailto:Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/05ebc36d/attachment.htm
Platform device style question
Hello, A 'newbie-to-platform-devices' question: In a patch that Kumar just sent for a compact flash device, the resource data (I/O addresses, IRQ # etc.) are retrieved from the platform system. I guess I can either modify the device tree in U-boot by adding additional nodes, or instantiate a platform device in Linux __init code based on static information. The former gives the advantage of having the bootloader pass the info to the OS. (Somebody please correct me if I'm off-base here!) Are device trees meant to only contain information about the CPU and tightly-coupled peripherals, or is it considered OK-form to also include board-level hardware info? I guess they can really hold anything, but I'm trying to figure out the original intent. regards, Ben
MontaVista 2.6 Kernel support for Xilinx ML40x
Good question. How long before lockup? The only core that should be licensed is the ethernet, and I know it was sysgened on a system with a license. This is the Xilinx reference design for the ml403 board. On 8/24/06, Peter Ryser peter.ryser at xilinx.com wrote: Wade, are you sure that you did not build your hardware with evaluation cores of the licenses? If you are using the evaluation licenses the hardware (FPGA design) will stop working after a certain amount of time and you will see a lock-up. - Peter Wade Maxfield wrote: I've got the LSP, and have booted it on the ML40X. In my opinion it is currently unstable, but that is my opinion. I've not been able to keep it powered up for 24 hours without it locking up on the RS232 serial terminal. Also, running updatedb over nfs causes it to abort with a kernel panic, although that might be an interraction with the nfs server. (Although even if the nfs server dies (which it did not), I don't expect a kernel panic). I have had it run over 6 hours without issue, so I expect subtle memory leaks, not serious problems. On 8/24/06, Claus Gindhart claus.gindhart at kontron.com wrote: Frank, due to my understanding of the GPL (and i have already invested some time in understanding the various flavours of open source licences), you should contact Montavista, and ask them for the sources. This board adaption is derivative work of the GPL Kernel, so the result of this work also falls under the GPL, and has to be made freely available under the terms of the GPL. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -Original Message- From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org ] On Behalf Of Frank D Lombardo Sent: Donnerstag, 24. August 2006 15:59 To: linuxppc-embedded at ozlabs.org Subject: MontaVista 2.6 Kernel support for Xilinx ML40x I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/d020126a/attachment.htm
Platform device style question
On Thu, 24 Aug 2006 13:53:17 -0400 Ben Warren bwarren at qstreams.com wrote: Hello, A 'newbie-to-platform-devices' question: In a patch that Kumar just sent for a compact flash device, the resource data (I/O addresses, IRQ # etc.) are retrieved from the platform system. I guess I can either modify the device tree in U-boot by adding additional nodes, or instantiate a platform device in Linux __init code based on static information. The former gives the advantage of having the bootloader pass the info to the OS. (Somebody please correct me if I'm off-base here!) I'd suggest to make a look at LDD concerning linux device model... For platform device, there's no need to cope with u-boot at all. You'll prolly need to register the respective platform device from the board-specific code, with proper name and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static PD definitions usage. Are device trees meant to only contain information about the CPU and tightly-coupled peripherals, or is it considered OK-form to also include board-level hardware info? I guess they can really hold anything, but I'm trying to figure out the original intent. I'd make sense to figure out the platform device bus before digging into device trees. It's slightly different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with your case afaiu. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Sincerely, Vitaly
CompactFlash on PQII Pro
On Aug 24, 2006, at 9:44 AM, Ben Warren wrote: Thanks Kumar, As always, you're several steps ahead of me. On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote: I know I posted a patch for cf-ide.c to lkml some time ago, this was to do a CF in true ide mode using the 83xx localbus. http://marc.theaimsgroup.com/?l=linux-kernelm=113877891224982w=2 We did some UPM setup in u-boot to use two CS on Localbus for this. In our case, we only have one CS available but it's going to a CPLD that will decode and provide two CSs to the CF. This will work as long as the UPM setup is identical for the two chip selects. Should be... Off-topic to this list, but do you have the U-boot code that you can share? If not, no worries. The only code in u-boot was the UPM setup code, I'm happy to send that to you. - kumar
CompactFlash on PQII Pro
Kumar, On Thu, 2006-08-24 at 13:25 -0500, Kumar Gala wrote: The only code in u-boot was the UPM setup code, I'm happy to send that to you. If it's no trouble, that would be great. My HW guy is calculating the settings, but this stuff can be frustrating to debug. BTW - was the system bus speed for your CPU 33 or 66 MHz? We're targeting for a 400MHz 8349 which has a 33MHz system bus.
Platform device style question
Thanks Vitaly, On Thu, 2006-08-24 at 22:06 +0400, Vitaly Bordug wrote: I'd suggest to make a look at LDD concerning linux device model... Thanks. I'll read it again. My little brain absorbs this stuff very slowly. For platform device, there's no need to cope with u-boot at all. You'll prolly need to register the respective platform device from the board-specific code, with proper name and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static PD definitions usage. My particular platform (MPC8349) gets its hardware info (CPU, IMMBAR, PCI, I2C, SPI resources etc.) from an OF device tree that is generated alongside U-boot and I guess embedded in the uImage file. (I apologize if I'm getting my jargon mixed up here) The OF device tree idea seemed like a slick way to abstract away some HW settings from Linux. I was imagining writing board-side platform device registration that gets its settings from the device tree, allowing a bit of re-use between similar but not identical boards. I'd make sense to figure out the platform device bus before digging into device trees. It's slightly different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with your case afaiu. I definitely have much learning to do. Thanks very much for the pointers! regards, Ben
MontaVista 2.6 Kernel support for Xilinx ML40x
The ml403 reference design has several evaluation cores: opb_uart16550, opb_iic and opb_ethernet. They seem to time-out after about eight hours. Frank Wade Maxfield wrote: Good question. How long before lockup? The only core that should be licensed is the ethernet, and I know it was sysgened on a system with a license. This is the Xilinx reference design for the ml403 board. On 8/24/06, *Peter Ryser* peter.ryser at xilinx.com mailto:peter.ryser at xilinx.com wrote: Wade, are you sure that you did not build your hardware with evaluation cores of the licenses? If you are using the evaluation licenses the hardware (FPGA design) will stop working after a certain amount of time and you will see a lock-up. - Peter Wade Maxfield wrote: I've got the LSP, and have booted it on the ML40X. In my opinion it is currently unstable, but that is my opinion. I've not been able to keep it powered up for 24 hours without it locking up on the RS232 serial terminal. Also, running updatedb over nfs causes it to abort with a kernel panic, although that might be an interraction with the nfs server. (Although even if the nfs server dies (which it did not), I don't expect a kernel panic). I have had it run over 6 hours without issue, so I expect subtle memory leaks, not serious problems. On 8/24/06, *Claus Gindhart* claus.gindhart at kontron.com mailto:claus.gindhart at kontron.com wrote: Frank, due to my understanding of the GPL (and i have already invested some time in understanding the various flavours of open source licences), you should contact Montavista, and ask them for the sources. This board adaption is derivative work of the GPL Kernel, so the result of this work also falls under the GPL, and has to be made freely available under the terms of the GPL. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -Original Message- From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org mailto:kontron.com at ozlabs.org [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org] On Behalf Of Frank D Lombardo Sent: Donnerstag, 24. August 2006 15:59 To: linuxppc-embedded at ozlabs.org mailto:linuxppc-embedded at ozlabs.org Subject: MontaVista 2.6 Kernel support for Xilinx ML40x I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org mailto:Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org mailto:Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org mailto:Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MontaVista 2.6 Kernel support for Xilinx ML40x
[top-posting fixed :-) ] On Thu, 24 Aug 2006, Wade Maxfield wrote: On 8/24/06, Peter Ryser peter.ryser at xilinx.com wrote: Wade, are you sure that you did not build your hardware with evaluation cores of the licenses? If you are using the evaluation licenses the hardware (FPGA design) will stop working after a certain amount of time and you will see a lock-up. Good question. How long before lockup? The only core that should be licensed is the ethernet, and I know it was sysgened on a system with a license. This is the Xilinx reference design for the ml403 board. When we were using the eval version of Xilinx's 10/100 EMAC it would time- out after 8 hours (and the kernel would panic since our root fs was NFS- mounted). If your only [to-be-]licensed core is Ethernet, then I take it you're using the UARTLite, or a non-Xilinx UART? We used Xilinx's 16550-compatible UART, which is licensed, but I never ran with the eval version of that IP block and so have no idea how long it will function before shutting down. Tom -- A: Because it breaks the logical| flow of the message.| Email to user 'CTZ001' | at 'email.mot.com' Q: Why is top posting frowned upon? |
communication with i2c client
Hi, I've create an i2c client and my questions is how to access it from userspace. This client is sitttng on adapter that I was able to access via /dev interface. After the client were successfuly loaded and detected, ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work and error messages like device busy or ioctl error have occured. Also my debug messages from i2c client didn't arise when I am accessing device only adapter's. How to (standardly) access a an i2c client? Do I need to create an ioctl interface or exports some helper function for access it from user space and also from kernel space? regards, Ladislav.
MontaVista 2.6 Kernel support for Xilinx ML40x
sorry! ;) See my reply at the right location! On 8/24/06, T Ziomek ctz001 at email.mot.com wrote: [top-posting fixed :-) ] On Thu, 24 Aug 2006, Wade Maxfield wrote: On 8/24/06, Peter Ryser peter.ryser at xilinx.com wrote: Wade, are you sure that you did not build your hardware with evaluation cores of the licenses? If you are using the evaluation licenses the hardware (FPGA design) will stop working after a certain amount of time and you will see a lock-up. Good question. How long before lockup? The only core that should be licensed is the ethernet, and I know it was sysgened on a system with a license. This is the Xilinx reference design for the ml403 board. When we were using the eval version of Xilinx's 10/100 EMAC it would time- out after 8 hours (and the kernel would panic since our root fs was NFS- mounted). If your only [to-be-]licensed core is Ethernet, then I take it you're using the UARTLite, or a non-Xilinx UART? We used Xilinx's 16550-compatible UART, which is licensed, but I never ran with the eval version of that IP block and so have no idea how long it will function before shutting down. We are doing an evaluation right now. We have operational 8 hours 55 minutes so far and counting on the Xilinx 16550 compatible uart. I think that is the cause of the problem for us, but not sure so far. Tom -- A: Because it breaks the logical| flow of the message.| Email to user 'CTZ001' | at 'email.mot.com' Q: Why is top posting frowned upon? | xy A2. but only for algebraic. RPN likes it that way. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/98b158bc/attachment.htm
ip= command line strangeness...
On my previous project, a 2.4 kernel on PPC, I frequently used ip=w.x.y.z on the kernel command line to specify a static IP address for my target board (when booting with a flash- or RAM-based root filesystem). Similarly, when using an NFS-mounted root fs, I would use ip=w.x.y.z:a.b.c.d, along with the appropriate nfsroot=... setting, with my NFS server having IP a.b.c.d . Now I am working with a 2.6.10-based kernel on ARM. Using an NFS root fs works fine when I use the expected ip=w.x.y.z:a.b.c.d. And booting off with root=/dev/hda1 works fine with ip=dhcp. I'd expect to be able to use root=/dev/hda1 ip=w.x.y.z if I want the target using a static IP address. But this fails, and in a VERY weird way: (1) It tries doing DHCP, which it shouldn't, and (2) the DHCP fails, which it shouldn't because it works when I want DHCP to be used. Here's a snippet of console output: . . . NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 Sending DHCP requests .. timed out! EMAC: TX Complete: Starting queue IP-Config: Reopening network devices... Sending DHCP requests ... Okay, that's two weird things. There is a third -- this problem goes a- way if I change the command line to something like root=/dev/hda1 ip=w.x.y.z:a.b.c.d. The only change is adding an NFS server IP address to the ip= command, which should have no effect be- cause NFS is not being used. Yet when I do that the board boots as ex- pected -- it does not try to do DHCP, it does use /dev/hda1 for its root fs, and it does take the specified IP address. In fact, it works even if I use a command line with, literally, root=/dev/hda1 ip=199.5.233.72:gobbledygook: . . . NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=eth0, addr=199.5.233.72, mask=255.255.255.0, gw=255.255.255.255, host=199.5.233.72, domain=, nis-domain=(none), bootserver=232.0.0.0, rootserver=232.0.0.0, rootpath= . . . This isn't a big problem, but can anybody explain what the heck is going on? Thanks, Tom -- /\ ASCII Ribbon Campaign | \ / | Email to user 'CTZ001' XAgainst HTML | at 'email.mot.com' / \ in e-mail news |
communication with i2c client
Hi, I've create an i2c client and my questions is how to access it from userspace. This client is sitttng on adapter that I was able to access via /dev interface. After the client were successfuly loaded and detected, ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work and error messages like device busy or ioctl error have occured. Also my debug messages from i2c client didn't arise when I am accessing device only adapter's. How to (standardly) access a an i2c client? Do I need to create an ioctl interface or exports some helper function for access it from user space and also from kernel space? regards, Ladislav.
Help with booting with very large initrd
Hi, I'm developing a PPC440GX based board that uses U-Boot to boot a multi-file boot image composed of the kernel and a very large ( 96MB uncompressed) initrd file. The board has 512MB of RAM of which the upper 16MB is reserved for dedicated hardware. The 16MB block is reserved via mem=496M and U-Boot is told to stay out of that area by setting initrd_high=1f00. Before anyone asks there are several reasons for doing things this way. NFS is not an option in the target environment. I can tftp the combined boot image to my board. I checked the crc with the crc32 command and it agrees exactly with the result obtained on the host machine using the boot file. Therefore there is not a TFTP 32MB problem here. If I boot I get the following: = boot Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection Using ppc_4xx_eth2 device TFTP from server 192.168.168.108; our IP address is 192.168.168.111 Filename 'pMulti-ramdisk'. Load address: 0x40 Loading: * done Bytes transferred = 38825407 (2506dbf hex) Automatic boot of image at addr 0x0040 ... ## Booting image at 0040 ... Image Name: Linux-2.6.10_mvl401-440gx_eval-I Created: 2006-08-25 1:01:29 UTC Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:38825343 Bytes = 37 MB Load Address: Entry Point: Contents: Image 0: 1137986 Bytes = 1.1 MB Image 1: 37687343 Bytes = 35.9 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK Loading Ramdisk to 1cc0e000, end 1efff02f ... OK Linux version 2.6.10_mvl401-440gx_eval (cram at toaster.kla-tencor.com) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46 Thu Aug 24 17:28:09 PDT 2006 IBM Ocotea port (MontaVista Software, Inc. source at mvista.com) Built 1 zonelists Kernel command line: ramdisk_size=262144 root=/dev/ram rw console=ttyS0,115200 ip=192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: off mem=496M PID hash table entries: 2048 (order: 11, 32768 bytes) ..stuff deleted.. RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksize loop: loaded (max 8 devices) ..more stuff deleted.. eth0: link is down eth0: link is up, 1000 FDX, pause enabled IP-Config: Complete: device=eth0, addr=192.168.168.111, mask=255.255.255.0, gw=255.255.255.255, host=scpu2, domain=, nis-domain=(none), bootserver=192.168.168.108, rootserver=192.168.168.108, rootpath= RAMDISK: Compressed image found at block 0 crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring! length error (orig = 0x0c00, bytes_out = 0x0c15 -- ignored VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 120k init Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init= option to kernel. 0Rebooting in 180 seconds.. (I modified lib/inflate.c so that the crc and length checks would provide more info). Since the overall file CRC is good and U-Boot checksums are also okay this looks like some sort of size limitation with the inflate routine. BTW, The kerenel was made assuming a 256MB ramdisk; likewise the command line specs one as well. The initrd image would fit easily in that space. Have any of you worked on this problem before and come up with a solution? Thanks, Marc Howard
communication with i2c client
--- Ladislav Klenovi? lk99336 at pobox.sk wrote: Hi, I've create an i2c client and my questions is how to access it from userspace. This client is sitttng on adapter that I was able to access via /dev interface. After the client were successfuly loaded and detected, ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work and error messages like device busy or ioctl error have occured. Also my debug messages from i2c client didn't arise when I am accessing device only adapter's. How to (standardly) access a an i2c client? Do I need to create an ioctl interface or exports some helper function for access it from user space and also from kernel space? regards, Ladislav. You might get an answer here: http://www.lm-sensors.org/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
