Re: device trees.
I will have to look at the code referenced below, But my objective is not to address partial reconfiguration at this time. At Pico we have come to the conclusion that as it is currently done partial reconfiguration has extremely limited use. We are actively looking at other techniques as well as different FPGA technology to impliment usable equivalents. But partial reconfiguration is not the only way to encounter a dynamic environment. A typical pico system has multiple bit files and multiple executables stored in its flash file system. Power up and soft resets might each run through a different sequence of bit files and executables. My issue is that post 2.6.26 unless I can dynamically create the device tree inside our monitor/bootloader we must at minimum have a different device tree for each bitfile, or worse if we wrap the device tree into the executable, a different linux executable for each bit file. We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. Grant Likely wrote: On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman mich...@ellerman.id.au wrote: On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote: On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. dh...@dlasys.net wrote: Is there an example somewhere that shows building a device tree on the fly ? As our products move forward it becomes increasingly clear that static configurations are not going to work. To use device tree with partial reconfiguration would require rework to the device tree infrastructure to prune and graft portions of the device tree. I think it is possible, but it is non-trivial to get working. arch/powerpc/platforms/pseries/reconfig.c Not pretty, but it does more or less what you're talking about. Would need some work to get it going on !pseries obviously. Heh, I didn't even know this existed. :-) Thinking about this more, it seems to me that the tricky bit would be figuring out how to drop all references to a node before it is pruned from the tree. of_platform_devices would probably be the easiest because the bus could walked before pruning the node, but there are also references on the i2c, spi and mdio busses that must be dealt with appropriately. g. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Keep track of emulated instructions if debugfs is enabled
On Mon, 11 May 2009, Michael Ellerman wrote: On Fri, 2009-05-08 at 16:15 +0200, Geert Uytterhoeven wrote: Counters for the various classes of emulated instructions are available under /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs is mounted on /sys/kernel/debug). Optionally (controlled by /sys/kernel/debug/powerpc/emulated_instructions/do_warn), rate-limited warnings can be printed to the console when instructions are emulated. Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- Tested on ppc64 (ps3) and ppc32 (sequoia) using mfpvr. v3: - add generic unaligned - switch from sysfs + sysctl to debugfs. All virtual files now show up under /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs mounted on /sys/kernel/debug) - enable the printing of rate-limited warnings by writing a non-zero value to /sys/kernel/debug/powerpc/emulated_instructions/do_warn - switch from per-CPU to system-wide counters - always use 32-bit counters (was 64-bit on ppc64) - counters are writable, i.e. can be reset (by root) Nice :) My only query is whether it needs its own CONFIG option. Some folks might want other DEBUG_FS things but not this? That's possible. Let's see what the other folks say... With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
On Friday 08 May 2009 09:52:51 David Miller wrote: From: John Rigby jcri...@gmail.com Date: Thu, 7 May 2009 20:02:53 -0600 Also don't forget that the register map is the same on 512x, mx and coldfire platforms but not on the other ppc platforms so if you want to one binary to rule them all you will need to have an offest table or some such. I would suggest using -read_reg() -write_reg() methods for abstracting this. That's how we handle all of the different way ESP scsi chips have their registers wired up. I/O register reads take hundreds, if not thousands of CPU cycles so, relatively speaking, the indirection costs absolutely nothing. I fear the memory-mapped I/O of the PowerPC SoC is *slightly* faster, so in terms of cycle count, this WILL matter, although depending on how much register-I/O the driver does, overall performance impact _may_ still be negligible. I suggest testing this (benchmarks) before and after the change. Best regsards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/15] powerpc/cell: Extract duplicated IOPTE_* to asm/iommu.h
On Sun, 10 May 2009, Christoph Hellwig wrote: On Fri, May 08, 2009 at 04:01:17PM +0200, Geert Uytterhoeven wrote: +/* Cell page table entries */ +#define IOPTE_PP_W 0x8000ul /* protection: write */ +#define IOPTE_PP_R 0x4000ul /* protection: read */ +#define IOPTE_M0x2000ul /* coherency required */ +#define IOPTE_SO_R 0x1000ul /* ordering: writes */ +#define IOPTE_SO_RW 0x1800ul /* ordering: r w */ +#define IOPTE_RPN_Mask 0x07fff000ul /* RPN */ +#define IOPTE_H0x0800ul /* cache hint */ +#define IOPTE_IOID_Mask0x07fful /* ioid */ If this is in a global header it should probably have a CELL_ prefix. Fair enough; I'll use CBE_, as that's shorter and used for the other definitions in arch/powerpc/include/asm/cell-*.h, too. With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Next May 11 : BUG during scsi initialization
Today's Next tree failed to boot on a Power6 box with following BUG : BUG: spinlock bad magic on CPU#1, modprobe/63 Unable to handle kernel paging request for data at address 0xc994838 Faulting instruction address: 0xc035f5a8 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: scsi_mod(+) NIP: c035f5a8 LR: c035f58c CTR: 00136f8c REGS: c000c7d03500 TRAP: 0300 Not tainted (2.6.30-rc5-autotest-next-20090511) MSR: 80009032 EE,ME,IR,DR CR: 28222484 XER: 000f DAR: 0c994838, DSISR: 4000 TASK = c000c7cf0a80[63] 'modprobe' THREAD: c000c7d0 CPU: 1 GPR00: c035f58c c000c7d03780 c0aaeed8 0031 GPR04: 585cf4e0 00673580 8000565a6cc0 GPR08: c09ebf50 c09ebf38 GPR12: 28222482 c0b82600 GPR16: GPR20: 0018 c09bbe40 0010 GPR24: 00210d00 c000c6caff80 c000dfc732a0 c0f61380 GPR28: c07c8350 c08a4280 c0a2f928 0c994550 NIP [c035f5a8] .spin_bug+0x90/0xd4 LR [c035f58c] .spin_bug+0x74/0xd4 Call Trace: [c000c7d03780] [c035f58c] .spin_bug+0x74/0xd4 (unreliable) [c000c7d03810] [c035f890] ._raw_spin_lock+0x48/0x184 [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] [c000c7d03c20] [d0ea13c8] .init_scsi+0x1c/0xe8 [scsi_mod] [c000c7d03ca0] [c00092c0] .do_one_initcall+0x80/0x19c [c000c7d03d90] [c00c0540] .SyS_init_module+0xe0/0x244 [c000c7d03e30] [c0008534] syscall_exit+0x0/0x40 Instruction dump: 7f84e378 e87e8020 38c604d0 e8e902ea 4827fced 6000 2fbf 80bd0004 409e0010 e8de8028 38e0 480c e8ff02ea 38df04d0 7fa4eb78 811d0008 ---[ end trace f725820a6fa9dbb7 ]--- /init: line 21:63 Segmentation fault modprobe $file I have attached the dmesg log here. Let me know if any other information is required. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - Using 007bc904 bytes for initrd buffer Please wait, loading kernel... Allocated 0110 bytes for kernel @ 0230 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 007bc904 @ 0340 OF stdout device is: /vdevice/v...@3000 Preparing to boot Linux version 2.6.30-rc5-autotest-next-20090511 (r...@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Mon May 11 16:01:58 IST 2009 Calling ibm,client-architecture... done command line: root=/dev/sda3 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M IDENT=1242039097 memory layout at init: alloc_bottom : 03bc alloc_top: 0800 alloc_top_hi : 0800 rmo_top : 0800 ram_top : 0800 instantiating rtas at 0x074e... done boot cpu hw idx copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x03bd - 0x03bd15c2 Device tree struct 0x03be - 0x03c0 Calling quiesce... returning from prom_init Crash kernel location must be 0x200 Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB) Phyp-dump disabled at boot time Using pSeries machine description Using 1TB segments Found initrd at 0xc340:0xc3bbc904 console [udbg0] enabled Partition configured for 2 cpus. CPU maps initialized for 2 threads per core Starting Linux PPC64 #1 SMP Mon May 11 16:01:58 IST 2009 - ppc64_pft_size= 0x1a physicalMemorySize= 0x1 htab_hash_mask= 0x7 - Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.30-rc5-autotest-next-20090511 (r...@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Mon May 11 16:01:58 IST 2009 [boot]0012 Setup Arch EEH: No capable adapters found PPC64 nvram contains 15360 bytes Zone PFN ranges: DMA 0x - 0x0001 Normal 0x0001 - 0x0001 Movable zone start PFN for each node early_node_map[2] active PFN ranges 2: 0x - 0xe000 3: 0xe000 - 0x0001 Could not find start_pfn for node 0 [boot]0015 Setup
Re: Next May 11 : BUG during scsi initialization
On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote: Today's Next tree failed to boot on a Power6 box with following BUG : This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried to allocate memory and things went wrong in the memory allocator: [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] Which memory allocator did you have selected (SLAB, SLUB, SLOB, SLQB)? BUG: spinlock bad magic on CPU#1, modprobe/63 Unable to handle kernel paging request for data at address 0xc994838 Faulting instruction address: 0xc035f5a8 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: scsi_mod(+) NIP: c035f5a8 LR: c035f58c CTR: 00136f8c REGS: c000c7d03500 TRAP: 0300 Not tainted (2.6.30-rc5-autotest-next-20090511) MSR: 80009032 EE,ME,IR,DR CR: 28222484 XER: 000f DAR: 0c994838, DSISR: 4000 TASK = c000c7cf0a80[63] 'modprobe' THREAD: c000c7d0 CPU: 1 GPR00: c035f58c c000c7d03780 c0aaeed8 0031 GPR04: 585cf4e0 00673580 8000565a6cc0 GPR08: c09ebf50 c09ebf38 GPR12: 28222482 c0b82600 GPR16: GPR20: 0018 c09bbe40 0010 GPR24: 00210d00 c000c6caff80 c000dfc732a0 c0f61380 GPR28: c07c8350 c08a4280 c0a2f928 0c994550 NIP [c035f5a8] .spin_bug+0x90/0xd4 LR [c035f58c] .spin_bug+0x74/0xd4 Call Trace: [c000c7d03780] [c035f58c] .spin_bug+0x74/0xd4 (unreliable) [c000c7d03810] [c035f890] ._raw_spin_lock+0x48/0x184 [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] [c000c7d03c20] [d0ea13c8] .init_scsi+0x1c/0xe8 [scsi_mod] [c000c7d03ca0] [c00092c0] .do_one_initcall+0x80/0x19c [c000c7d03d90] [c00c0540] .SyS_init_module+0xe0/0x244 [c000c7d03e30] [c0008534] syscall_exit+0x0/0x40 Instruction dump: 7f84e378 e87e8020 38c604d0 e8e902ea 4827fced 6000 2fbf 80bd0004 409e0010 e8de8028 38e0 480c e8ff02ea 38df04d0 7fa4eb78 811d0008 ---[ end trace f725820a6fa9dbb7 ]--- /init: line 21:63 Segmentation fault modprobe $file I have attached the dmesg log here. Let me know if any other information is required. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - Using 007bc904 bytes for initrd buffer Please wait, loading kernel... Allocated 0110 bytes for kernel @ 0230 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 007bc904 @ 0340 OF stdout device is: /vdevice/v...@3000 Preparing to boot Linux version 2.6.30-rc5-autotest-next-20090511 (r...@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Mon May 11 16:01:58 IST 2009 Calling ibm,client-architecture... done command line: root=/dev/sda3 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M IDENT=1242039097 memory layout at init: alloc_bottom : 03bc alloc_top: 0800 alloc_top_hi : 0800 rmo_top : 0800 ram_top : 0800 instantiating rtas at 0x074e... done boot cpu hw idx copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x03bd - 0x03bd15c2 Device tree struct 0x03be - 0x03c0 Calling quiesce... returning from prom_init Crash kernel location must be 0x200 Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB) Phyp-dump disabled at boot time Using pSeries machine description Using 1TB segments Found initrd at 0xc340:0xc3bbc904 console [udbg0] enabled Partition configured for 2 cpus. CPU maps initialized for 2 threads per core Starting Linux PPC64 #1 SMP Mon May 11 16:01:58 IST 2009 - ppc64_pft_size= 0x1a physicalMemorySize
Re: Next May 11 : BUG during scsi initialization
Matthew Wilcox wrote: On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote: Today's Next tree failed to boot on a Power6 box with following BUG : This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried to allocate memory and things went wrong in the memory allocator: [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] Which memory allocator did you have selected (SLAB, SLUB, SLOB, SLQB)? Default one. SLQB CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y Page size is 64K with Config DEBUG_PAGEALLOC set. CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_64K_PAGES=y CONFIG_DEBUG_PAGEALLOC=y Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next May 11 : BUG during scsi initialization
On Mon, May 11, 2009 at 05:34:07PM +0530, Sachin Sant wrote: Matthew Wilcox wrote: On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote: Today's Next tree failed to boot on a Power6 box with following BUG : This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried to allocate memory and things went wrong in the memory allocator: [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] Which memory allocator did you have selected (SLAB, SLUB, SLOB, SLQB)? Default one. SLQB CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y Page size is 64K with Config DEBUG_PAGEALLOC set. CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_64K_PAGES=y CONFIG_DEBUG_PAGEALLOC=y Hm. We've seen some similar problems at Intel while doing database performance tests with SLQB. Any ideas, Nick? -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
On Thu 2009-05-07 12:11:29, Ingo Molnar wrote: * Nicholas Miell nmi...@comcast.net wrote: On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (?) wrote: On Wed, May 6, 2009 at 15:13, Ingo Molnar mi...@elte.hu wrote: doing a (per arch) bitmap of harmless syscalls and replacing the mode1_syscalls[] check with that in kernel/seccomp.c would be a pretty reasonable extension. (.config controllable perhaps, for old-style-seccomp) It would probably be faster than the current loop over mode1_syscalls[] as well. This would be a great option to improve performance of our sandbox. I can detect the availability of the new kernel API dynamically, and then not intercept the bulk of the system calls. This would allow the sandbox to work both with existing and with newer kernels. We'll post a kernel patch for discussion in the next few days, I suspect the correct thing to do would be to leave seccomp mode 1 alone and introduce a mode 2 with a less restricted set of system calls -- the interface was designed to be extended in this way, after all. Yes, that is what i alluded to above via the '.config controllable' aspect. Mode 2 could be implemented like this: extend prctl_set_seccomp() with a bitmap pointer, and copy it to a per task seccomp context structure. a bitmap for 300 syscalls takes only about 40 bytes. Please take care to implement nesting properly: if a seccomp context does a seccomp call (which mode 2 could allow), then the resulting bitmap should be the logical-AND of the parent and child bitmaps. There's no reason why seccomp couldnt be used in hiearachy of sandboxes, in a gradually less permissive fashion. I don't think seccomp nesting (at kernel level) has any value. First, syscalls are wrong level of abstraction for sandboxing. There are multiple ways to read from file, for example. If you wanted to do hierarchical sandboxes, asking your monitor to restrict your seccomp mask would seem like a way to go... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
some questions about the implementation of oprofile of mpc8560 in linux kernel source code
Dear All, I am a user of oprofile. When I use oprofile, I find some problems. Could you please help me? I have some questions about the open source code of the implementation of oprofile in linux kernel 2.6.26, which is presented op_model_fsl_emb.c, and the path in linux kernel source tree is arch/powerpc/oprofile/op_model_fsl_emb.c. To present this question more clearly, It needs the following steps: 1 I give some cpu event and its counter values, which finally will call the function fsl_emb_reg_setup 2 I execute setup, which finally will call the function fsl_emb_cpu_setup 3 I execute start, which finally will call the function fsl_emb_start 4 After calling start, the MPC8560 CPU will continuing increasing the PMCn value until its value reach 0x8000. Basing on what metioned in E500CORERM.pdf, this value should cause a exception, and should goto the interrupt routine:fsl_emb_handle_interrupt. But in fact, It never goto this interrupt routine! It always cause a reboot without any information! But while we using MPC7450 CPU, this situation never happened, it works well. Basing on the information metioned above, my questions are: 1 Is there any bug in op_model_fsl_emb.c and its related source code? 2 If possible, could you please tell me what the reason it is? And How to use op_model_fsl_emb.c correctly? Any feedback is appreciated! Thanks regards Jike 2009-05-11 0x ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. dh...@dlasys.net wrote: But partial reconfiguration is not the only way to encounter a dynamic environment. A typical pico system has multiple bit files and multiple executables stored in its flash file system. Power up and soft resets might each run through a different sequence of bit files and executables. My issue is that post 2.6.26 unless I can dynamically create the device tree inside our monitor/bootloader we must at minimum have a different device tree for each bitfile, This is true or worse if we wrap the device tree into the executable, a different linux executable for each bit file. As you say, this is undesirable. simpleImage does this, but it it intended for the least common denominator case where there is no firmware support at all available and the kernel needs to be completely contained. simpleImage is not intended to be the ideal. We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. That is the direction we are already going in. U-Boot supports this. In fact, I can build a single kernel image which will boot on all of my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot running on a Virtex board, I can build a single image which will boot all of them if the correct .dtb is passed to it. You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. dh...@dlasys.net wrote: We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. This is the same direction that we are headed in as well. For a given core, it is more or less possible to generate one kernel that works on any number of SOCs and boards that use that core. The only difference is which device tree it is given. So all you need to do is have your boot loader create a device tree from scratch. If you're using U-Boot, then you can already do this by making the appropriate libfdt calls. Otherwise, you should probably add libfdt to your boot loader. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. In fact, the code to do this should still be floating around git.xilinx.com, although someone would likely have to bring it up to the current kernel versions. My intention was to treat it as two independent configuration options: 1) .dtb location is in BRAM 2) .dtb is passed compressed (regardless of location) Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next May 11 : BUG during scsi initialization
Matthew Wilcox wrote: Default one. SLQB CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y Page size is 64K with Config DEBUG_PAGEALLOC set. CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_64K_PAGES=y CONFIG_DEBUG_PAGEALLOC=y Hm. We've seen some similar problems at Intel while doing database performance tests with SLQB. Any ideas, Nick? Yeah so the problem seems to be with SLQB. I was able to boot Next 11 with SLUB on the same machine. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next May 11 : BUG during scsi initialization
On Mon, May 11, 2009 at 09:49:55PM +0530, Sachin Sant wrote: Yeah so the problem seems to be with SLQB. I was able to boot Next 11 with SLUB on the same machine. Is it 100% reproducable with SLQB? Our errors were fairly hard to tickle on demand. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Stephen Neuendorffer wrote: You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. Thanks and I will look at it. But if you want my .02, append the .dtb to the bit file in some fashion that it can easily be located. We already use all the bram we are willing to steal from clients (16k) for our monitor/boot loader. In fact, the code to do this should still be floating around git.xilinx.com, although someone would likely have to bring it up to the current kernel versions. My intention was to treat it as two independent configuration options: 1) .dtb location is in BRAM 2) .dtb is passed compressed (regardless of location) Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next May 11 : BUG during scsi initialization
Matthew Wilcox wrote: On Mon, May 11, 2009 at 09:49:55PM +0530, Sachin Sant wrote: Yeah so the problem seems to be with SLQB. I was able to boot Next 11 with SLUB on the same machine. Is it 100% reproducable with SLQB? Our errors were fairly hard to tickle on demand. Yes. I am able to recreate this during every single reboot. I just tested few older next releases (May 6th, 7th and 8th)as well and was able to recreate this issue with every release. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Grant Likely wrote: We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. That is the direction we are already going in. U-Boot supports this. In fact, I can build a single kernel image which will boot on all of my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot running on a Virtex board, I can build a single image which will boot all of them if the correct .dtb is passed to it. I was not aware that u-boot was currently doing that, but I was aware that was possible. It is the most useful alternative to simple image. I was not specifically trying to criticize simple image. My problem is not with specific means of handling device trees. It is that it is a one size fits all solution, and it is not sufficiently flexible for that. You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. I would prefer not to waste bram by filling it with a device tree. The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. But ultimately the problem still exists. Device trees are the ONLY legitimate way to pass information post 2.6.26. That means that if there is a single peice of dynamic information that needs to be passed to linux, at a minimum the device tree must be edited. It is my understanding that u-boot already does some of this to manage command lines, and maybe a few other items. Regardless it still makes my point. The problem with devicetrees as they are is that they handle probably 98% of all cases well. The remaining 2% are a mess. lots of .dtb files lying arround is only a better solution than simpleimage. I will guarantee that unless they are welded together the wrong device tree will get used with the wrong bit file. Inevitably I will make that mistake myself occasionally and waste hours or possibly days trying to debug it. And if I will do it rarely clients will do it frequently. In my expereince if you create a situation where confusion can exist it will. It is also my expereince that time spend coding a solution to a common client problem is well spent. If it takes me a week to work out dynamically creating a device tree, that ill likely save many weeks of support headaches. Even if I do not end up creating the device tree dynamically, I am likely to end up at a minimum doing some validation on it. i.e. once the bitfile is loaded scanning the device tree and probing to ascertain that the hardware that I am supposed to expect it really present. ultimately devicetrees are supposed to be a database not a black box. Anyway, all I was looking for was a leg up on figuring out how to do what I want with them. Rather than starting from scratch. I am not looking to be convinced that I am approaching this all wrong. If you are happy with what you have - great. I am not. While I was not looking to restart a great debate over device trees - I do not actually think they are a bad idea. g. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Timur Tabi wrote: On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. dh...@dlasys.net wrote: So all you need to do is have your boot loader create a device tree from scratch. If you're using U-Boot, then you can already do this by making the appropriate libfdt calls. Otherwise, you should probably add libfdt to your boot loader. As I mentioned before, we do nto use u-boot. I am not looking to start a debate on it either, but it does not meet a number of our needs, and would require significant architectural changes to do so. The difference between it and devicetrees is that u-boot is avaiable to us if we want, I did port u-boot to our hardware at one point and it did everything it promised, but u-boot is optional, device trees are not. I do not have to re-architect u-boot to fit into 16k of bram, or load bit files or . If I want to move past 2.6.26 I have to not only use device trees but actually make them work in a way that will function as we need with our systems. It is likely I will use libdft as a starting point, but I can not see it as more than a short term solution. libdft is orders of magnitude large than our entire monitor, and it is a toolkit rather than the whole solution. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
Jiri Pirko wrote: Fri, May 08, 2009 at 09:57:22PM CEST, da...@davemloft.net wrote: From: Sachin Sant sach...@in.ibm.com Date: Fri, 08 May 2009 18:22:48 +0530 Todays Next failed to boot on a Power6 JS22 blade with following oops. Jiri, I suspect this might be your address list changes. Although that's just a guess. But please take a look. Hmm, only thing I see might cause the problem would be if calling __hw_addr_add in dev_addr_init fails, then dev-dev_addr would contain zeroes (which looks this is not the case). But in this case the oops would appear earlier (in ibmveth_probe dev_addr memcpy). Will do the patch which checks the result to behave correctly in case of oom but this imho this wouldn't help. Strange, I will dig into this more tomorrow. I can recreate this problem with today's Next release as well. Let me know if you want me to try out any thing to debug this problem. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 10:45 AM, David H. Lynch Jr. dh...@dlasys.net wrote: Grant Likely wrote: We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. That is the direction we are already going in. U-Boot supports this. In fact, I can build a single kernel image which will boot on all of my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot running on a Virtex board, I can build a single image which will boot all of them if the correct .dtb is passed to it. I was not aware that u-boot was currently doing that, but I was aware that was possible. It is the most useful alternative to simple image. I was not specifically trying to criticize simple image. My problem is not with specific means of handling device trees. It is that it is a one size fits all solution, and it is not sufficiently flexible for that. What do you mean by one size fits all solution? The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. I would prefer not to waste bram by filling it with a device tree. The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. That sounds like a good solution to me. As for using up BRAM, a gzipped dtb image is smaller than 2k and it can be reclaimed for other uses after the kernel has booted. That may not help your situation, but for my use cases the tradeoff works. Regardless it still makes my point. The problem with devicetrees as they are is that they handle probably 98% of all cases well. The remaining 2% are a mess. No it isn't. It is expected that firmware will fixup the device tree data with board specific values. This is intentional. The device tree is simply the bearer. It makes no determination about where the data comes from. lots of .dtb files lying arround is only a better solution than simpleimage. I will guarantee that unless they are welded together the wrong device tree will get used with the wrong bit file. I agree. Inevitably I will make that mistake myself occasionally and waste hours or possibly days trying to debug it. And if I will do it rarely clients will do it frequently. In my expereince if you create a situation where confusion can exist it will. It is also my expereince that time spend coding a solution to a common client problem is well spent. If it takes me a week to work out dynamically creating a device tree, that ill likely save many weeks of support headaches. Again, it doesn't sound like you want dynamic *creation* of device trees. It sounds like you want a reliable way to make sure the bitstream is welded together with the correct dtb, preferably within the Xilinx toolchain. Even if I do not end up creating the device tree dynamically, I am likely to end up at a minimum doing some validation on it. i.e. once the bitfile is loaded scanning the device tree and probing to ascertain that the hardware that I am supposed to expect it really present. If you like. ultimately devicetrees are supposed to be a database not a black box. I don't understand what you mean by this statement. Anyway, all I was looking for was a leg up on figuring out how to do what I want with them. Rather than starting from scratch. I am not looking to be convinced that I am approaching this all wrong. If you are happy with what you have - great. I am not. While I was not looking to restart a great debate over device trees - I do not actually think they are a bad idea. I still don't understand what you're worried about starting an arguing about. Pretty much any of the PowerPC maintainers can point at warts and problems in the current handling of device trees. I'm not particularly happy with simpleImage (and I wrote it), but it takes time and effort to write something more capable. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org
Re: [PATCH 1/3 v3] Added support for Designware SATA controller driver
Feng Kan wrote:
Signed-off-by: Feng Kan f...@amcc.com
Signed-off-by: Mark Miesfeld miesf...@gmail.com
---
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/sata_dwc.c | 2053
3 files changed, 2064 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/sata_dwc.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 0bcf264..c3d0b24 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -72,6 +72,16 @@ config SATA_FSL
If unsure, say N.
+config SATA_DWC
+ tristate DesignWare Cores SATA support
+ depends on 460EX
+ help
+ This option enables support for the Synopsys DesignWare Cores SATA
+ controller.
+ It can be found on the AMCC 460EX.
+
+ If unsure, say N.
+
config ATA_SFF
bool ATA SFF support
default y
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 7f1ecf9..3d41fc7 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_INIC162X)+= sata_inic162x.o
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
obj-$(CONFIG_SATA_FSL) += sata_fsl.o
+obj-$(CONFIG_SATA_DWC) += sata_dwc.o
obj-$(CONFIG_PATA_ALI) += pata_ali.o
obj-$(CONFIG_PATA_AMD) += pata_amd.o
diff --git a/drivers/ata/sata_dwc.c b/drivers/ata/sata_dwc.c
new file mode 100644
index 000..672f91f
--- /dev/null
+++ b/drivers/ata/sata_dwc.c
@@ -0,0 +1,2053 @@
+/*
+ * drivers/ata/sata_dwc.c
+ *
+ * Synopsys DesignWare Cores (DWC) SATA host driver
+ *
+ * Author: Mark Miesfeld mmiesf...@amcc.com
+ *
+ * Ported from 2.6.19.2 to 2.6.25/26 by Stefan Roese s...@denx.de
+ * Copyright 2008 DENX Software Engineering
+ *
+ * Based on versions provided by AMCC and Synopsys which are:
+ * Copyright 2006 Applied Micro Circuits Corporation
+ * COPYRIGHT (C) 2005 SYNOPSYS, INC. ALL RIGHTS RESERVED
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+#ifdef CONFIG_SATA_DWC_DEBUG
+#define DEBUG
+#endif
+
+#ifdef CONFIG_SATA_DWC_VDEBUG
+#define VERBOSE_DEBUG
+#define DEBUG_NCQ
+#endif
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/libata.h
+
+#include scsi/scsi_host.h
+#include scsi/scsi_cmnd.h
+
+#define DRV_NAMEsata-dwc
+#define DRV_VERSION 1.0
+
+/* SATA DMA driver Globals */
+#define DMA_NUM_CHANS 1
+#define DMA_NUM_CHAN_REGS 8
+
+/* SATA DMA Register definitions */
+#define AHB_DMA_BRST_DFLT 64 /* 16 data items burst length */
+
+struct dmareg {
+ u32 low;/* Low bits 0-31 */
+ u32 high; /* High bits 32-63 */
+};
+
+/* DMA Per Channel registers */
+
+struct dma_chan_regs {
+ struct dmareg sar; /* Source Address */
+ struct dmareg dar; /* Destination address */
+ struct dmareg llp; /* Linked List Pointer */
+ struct dmareg ctl; /* Control */
+ struct dmareg sstat;/* Source Status not implemented in core */
+ struct dmareg dstat;/* Destination Status not implemented in core */
+ struct dmareg sstatar; /* Source Status Address not impl in core */
+ struct dmareg dstatar; /* Destination Status Address not implemented */
+ struct dmareg cfg; /* Config */
+ struct dmareg sgr; /* Source Gather */
+ struct dmareg dsr; /* Destination Scatter */
+};
+
+/* Generic Interrupt Registers */
+struct dma_interrupt_regs {
+ struct dmareg tfr; /* Transfer Interrupt */
+ struct dmareg block;/* Block Interrupt */
+ struct dmareg srctran; /* Source Transfer Interrupt */
+ struct dmareg dsttran; /* Dest Transfer Interrupt */
+ struct dmareg error;/* Error */
+};
+
+struct ahb_dma_regs {
+ struct dma_chan_regschan_regs[DMA_NUM_CHAN_REGS];
+ struct dma_interrupt_regs interrupt_raw;/* Raw Interrupt */
+ struct dma_interrupt_regs interrupt_status; /* Interrupt Status */
+ struct dma_interrupt_regs interrupt_mask; /* Interrupt Mask */
+ struct dma_interrupt_regs interrupt_clear; /* Interrupt Clear */
+ struct dmareg statusInt; /* Interrupt combined */
+ struct dmareg rq_srcreg; /* Src Trans Req */
+ struct dmareg rq_dstreg; /* Dst Trans Req */
+ struct dmareg rq_sgl_srcreg; /* Sngl Src Trans Req */
+ struct dmareg rq_sgl_dstreg; /* Sngl Dst Trans Req */
+ struct dmareg rq_lst_srcreg; /*
Re: question about softirqs
David Miller wrote: You know, for networking over loopback (one of the only real cases that even matters, if we get a hard interrupt then the return from that would process any softints), we probably make out just fine anyways. As long as we hit a local_bh_enable() (and in the return path from device transmit that's exceedingly likely as all of the networking locking is BH safe) we'll run the softints from that and thus long before we get to syscall return. What about the issue I raised earlier? (I don't think you were copied at that point.) Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set (and maybe doing other stuff if there are no messages). In this case, schedule() would re-run the spinning task rather than running ksoftirqd. This could prevent any incoming packets from actually being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device. (And maybe longer if NOHZ is enabled.) Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ps3: remove driver_data direct access of struct device
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Please review. especially note that I removed a
kfree(dev-sbd.core.driver_data);
Is that correct?
arch/powerpc/include/asm/ps3.h |4 ++--
drivers/char/ps3flash.c| 11 +--
drivers/scsi/ps3rom.c | 10 +-
drivers/video/ps3fb.c |6 +++---
4 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index cdb6fd8..a55717e 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -421,12 +421,12 @@ static inline struct ps3_system_bus_driver *
static inline void ps3_system_bus_set_driver_data(
struct ps3_system_bus_device *dev, void *data)
{
- dev-core.driver_data = data;
+ dev_set_drvdata(dev-core, data);
}
static inline void *ps3_system_bus_get_driver_data(
struct ps3_system_bus_device *dev)
{
- return dev-core.driver_data;
+ return dev_get_drvdata(dev-core);
}
/* These two need global scope for get_dma_ops(). */
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index afbe456..6083032 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -108,7 +108,7 @@ static ssize_t ps3flash_read(struct file *file, char __user
*buf, size_t count,
loff_t *pos)
{
struct ps3_storage_device *dev = ps3flash_dev;
- struct ps3flash_private *priv = dev-sbd.core.driver_data;
+ struct ps3flash_private *priv = dev_get_drvdata(dev-sbd.core);
u64 size, start_sector, end_sector, offset;
ssize_t sectors_read;
size_t remaining, n;
@@ -173,7 +173,7 @@ static ssize_t ps3flash_write(struct file *file, const char
__user *buf,
size_t count, loff_t *pos)
{
struct ps3_storage_device *dev = ps3flash_dev;
- struct ps3flash_private *priv = dev-sbd.core.driver_data;
+ struct ps3flash_private *priv = dev_get_drvdata(dev-sbd.core);
u64 size, chunk_sectors, start_write_sector, end_write_sector,
end_read_sector, start_read_sector, head, tail, offset;
ssize_t res;
@@ -366,7 +366,7 @@ static int __devinit ps3flash_probe(struct
ps3_system_bus_device *_dev)
goto fail;
}
- dev-sbd.core.driver_data = priv;
+ dev_set_drvdata(dev-sbd.core, priv);
mutex_init(priv-mutex);
dev-bounce_size = ps3flash_bounce_buffer.size;
@@ -392,7 +392,7 @@ fail_teardown:
ps3stor_teardown(dev);
fail_free_priv:
kfree(priv);
- dev-sbd.core.driver_data = NULL;
+ dev_set_drvdata(dev-sbd.core, NULL);
fail:
ps3flash_dev = NULL;
return error;
@@ -404,8 +404,7 @@ static int ps3flash_remove(struct ps3_system_bus_device
*_dev)
misc_deregister(ps3flash_misc);
ps3stor_teardown(dev);
- kfree(dev-sbd.core.driver_data);
- dev-sbd.core.driver_data = NULL;
+ dev_set_drvdata(dev-sbd.core, NULL);
ps3flash_dev = NULL;
return 0;
}
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index ca0dd33..f2f840a 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -299,7 +299,7 @@ static irqreturn_t ps3rom_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
- host = dev-sbd.core.driver_data;
+ host = dev_get_drvdata(dev-sbd.core);
priv = shost_priv(host);
cmd = priv-curr_cmd;
@@ -387,7 +387,7 @@ static int __devinit ps3rom_probe(struct
ps3_system_bus_device *_dev)
}
priv = shost_priv(host);
- dev-sbd.core.driver_data = host;
+ dev_set_drvdata(dev-sbd.core, host);
priv-dev = dev;
/* One device/LUN per SCSI bus */
@@ -407,7 +407,7 @@ static int __devinit ps3rom_probe(struct
ps3_system_bus_device *_dev)
fail_host_put:
scsi_host_put(host);
- dev-sbd.core.driver_data = NULL;
+ dev_set_drvdata(dev-sbd.core, NULL);
fail_teardown:
ps3stor_teardown(dev);
fail_free_bounce:
@@ -418,12 +418,12 @@ fail_free_bounce:
static int ps3rom_remove(struct ps3_system_bus_device *_dev)
{
struct ps3_storage_device *dev = to_ps3_storage_device(_dev-core);
- struct Scsi_Host *host = dev-sbd.core.driver_data;
+ struct Scsi_Host *host = dev_get_drvdata(dev-sbd.core);
scsi_remove_host(host);
ps3stor_teardown(dev);
scsi_host_put(host);
- dev-sbd.core.driver_data = NULL;
+ dev_set_drvdata(dev-sbd.core, NULL);
kfree(dev-bounce_buf);
return 0;
}
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index e00c1df..55f4250 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -1210,7 +1210,7 @@ static int __devinit ps3fb_probe(struct
ps3_system_bus_device *dev)
if (retval
Re: [PATCH] fix sata_sil compilation on non-DMI platforms
Ideally the DMI subsystem should be provided wrappers for platforms without DMI, rendering patches like this unnecessary. Interesting question - is the PPC OpenFirmware machine information mappable onto the DMI space ? or the various static bits of name information in the various ARM and the like machine descriptions. If not which bits are similar enough we could replace dmi at the high level with an abstract interface for system/vendor/... that was ? ( ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] aoa: remove driver_data direct access of struct device
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index fbf5c93..586965f 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -1037,7 +1037,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev
*sdev)
}
ldev-selfptr_headphone.ptr = ldev;
ldev-selfptr_lineout.ptr = ldev;
- sdev-ofdev.dev.driver_data = ldev;
+ dev_set_drvdata(sdev-ofdev.dev, ldev);
list_add(ldev-list, layouts_list);
layouts_list_items++;
@@ -1081,7 +1081,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev
*sdev)
static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
int i;
for (i=0; iMAX_CODECS_PER_BUS; i++) {
@@ -1114,7 +1114,7 @@ static int aoa_fabric_layout_remove(struct soundbus_dev
*sdev)
#ifdef CONFIG_PM
static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t
state)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
if (ldev-gpio.methods ldev-gpio.methods-all_amps_off)
ldev-gpio.methods-all_amps_off(ldev-gpio);
@@ -1124,7 +1124,7 @@ static int aoa_fabric_layout_suspend(struct soundbus_dev
*sdev, pm_message_t sta
static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
if (ldev-gpio.methods ldev-gpio.methods-all_amps_off)
ldev-gpio.methods-all_amps_restore(ldev-gpio);
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 418c84c..4e3b819 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -358,14 +358,14 @@ static int i2sbus_probe(struct macio_dev* dev, const
struct of_device_id *match)
return -ENODEV;
}
- dev-ofdev.dev.driver_data = control;
+ dev_set_drvdata(dev-ofdev.dev, control);
return 0;
}
static int i2sbus_remove(struct macio_dev* dev)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct i2sbus_dev *i2sdev, *tmp;
list_for_each_entry_safe(i2sdev, tmp, control-list, item)
@@ -377,7 +377,7 @@ static int i2sbus_remove(struct macio_dev* dev)
#ifdef CONFIG_PM
static int i2sbus_suspend(struct macio_dev* dev, pm_message_t state)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct codec_info_item *cii;
struct i2sbus_dev* i2sdev;
int err, ret = 0;
@@ -407,7 +407,7 @@ static int i2sbus_suspend(struct macio_dev* dev,
pm_message_t state)
static int i2sbus_resume(struct macio_dev* dev)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct codec_info_item *cii;
struct i2sbus_dev* i2sdev;
int err, ret = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] Hardware Breakpoint interfaces implementation for PPC64
Hi PPC Dev folks, Please find a patch below that implements the proposed Hardware Breakpoint interfaces for PPC64 architecture. As a brief introduction, the proposed Hardware Breakpoint infrastructure provides generic in-kernel interfaces to which users from kernel- and user-space can request for breakpoint registers. An ftrace plugin that can trace accesses to data variables is also part of the generic HW Breakpoint interface patchset. The latest submission for this patchset along with an x86 implementation can be found here: http://lkml.org/lkml/2009/5/11/159. The following are the salient features of the PPC64 patch. - Arch-specific definitions for kernel and user-space requests are defined in arch/powerpc/kernel/hw_breakpoint.c - Ptrace is converted to use the HW Breakpoint interfaces - The ftrace plugin called ksym_tracer is tested to work fine. For instance when tracing pid_max kernel variable, the following was obtained as output # cat trace # tracer: ksym_tracer # # TASK-PID CPU# Symbol TypeFunction # | | | | | bash4502 3 pid_max RW .do_proc_dointvec_minmax_conv+0x78/0x10c bash4502 3 pid_max RW .do_proc_dointvec_minmax_conv+0xa0/0x10c bash4502 3 pid_max RW .alloc_pid+0x8c/0x4a4 There are however a few limitations/caveats of the patch as identified below: - The patch is currently implemented only for PPC64 architecture. Other architectures (especially Book-E implementations are expected to happen in due course). - HW Breakpoints over data addresses through Xmon (using bd command) and the proposed HW Breakpoint interfaces can now operate in a mutually exclusive manner. Xmon's integration is pending and is dependant on successful triggering of breakpoints through bdops. (Note: On a Power5 machine running 2.6.29, Xmon could not trigger HW Breakpoints when tested). Kindly let me know your comments. Thanks, K.Prasad Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com --- arch/powerpc/Kconfig |1 arch/powerpc/include/asm/hw_breakpoint.h | 52 + arch/powerpc/include/asm/processor.h |1 arch/powerpc/include/asm/reg.h |2 arch/powerpc/include/asm/thread_info.h |2 arch/powerpc/kernel/Makefile |2 arch/powerpc/kernel/hw_breakpoint.c | 271 +++ arch/powerpc/kernel/process.c| 18 ++ arch/powerpc/kernel/ptrace.c | 48 + arch/powerpc/mm/fault.c | 14 - samples/hw_breakpoint/data_breakpoint.c |4 12 files changed, 423 insertions(+), 9 deletions(-) Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig === --- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig +++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig @@ -125,6 +125,7 @@ config PPC select USE_GENERIC_SMP_HELPERS if SMP select HAVE_OPROFILE select HAVE_SYSCALL_WRAPPERS if PPC64 + select HAVE_HW_BREAKPOINT if PPC64 config EARLY_PRINTK bool Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile === --- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/Makefile +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile @@ -33,7 +33,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_p signal_64.o ptrace32.o \ paca.o cpu_setup_ppc970.o \ cpu_setup_pa6t.o \ - firmware.o nvram_64.o + firmware.o nvram_64.o hw_breakpoint.o obj64-$(CONFIG_RELOCATABLE)+= reloc_64.o obj-$(CONFIG_PPC64)+= vdso64/ obj-$(CONFIG_ALTIVEC) += vecemu.o vector.o Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c === --- /dev/null +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c @@ -0,0 +1,271 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * Copyright (C) 2009 IBM Corporation + */ + +/* + *
Re: [PATCH] ps3: remove driver_data direct access of struct device
Hi Roel,
On 05/11/2009 12:34 PM, Roel Kluin wrote:
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Please review. especially note that I removed a
kfree(dev-sbd.core.driver_data);
Is that correct?
Comment below.
arch/powerpc/include/asm/ps3.h |4 ++--
drivers/char/ps3flash.c| 11 +--
drivers/scsi/ps3rom.c | 10 +-
drivers/video/ps3fb.c |6 +++---
4 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index cdb6fd8..a55717e 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -421,12 +421,12 @@ static inline struct ps3_system_bus_driver *
static inline void ps3_system_bus_set_driver_data(
struct ps3_system_bus_device *dev, void *data)
{
- dev-core.driver_data = data;
+ dev_set_drvdata(dev-core, data);
}
static inline void *ps3_system_bus_get_driver_data(
struct ps3_system_bus_device *dev)
{
- return dev-core.driver_data;
+ return dev_get_drvdata(dev-core);
}
/* These two need global scope for get_dma_ops(). */
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index afbe456..6083032 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -108,7 +108,7 @@ static ssize_t ps3flash_read(struct file *file, char
__user *buf, size_t count,
loff_t *pos)
{
struct ps3_storage_device *dev = ps3flash_dev;
- struct ps3flash_private *priv = dev-sbd.core.driver_data;
+ struct ps3flash_private *priv = dev_get_drvdata(dev-sbd.core);
These should all be using ps3_system_bus_get_driver_data() and
ps3_system_bus_set_driver_data():
struct ps3flash_private *priv = ps3_system_bus_get_driver_data(dev-sbd)
@@ -404,8 +404,7 @@ static int ps3flash_remove(struct ps3_system_bus_device
*_dev)
misc_deregister(ps3flash_misc);
ps3stor_teardown(dev);
- kfree(dev-sbd.core.driver_data);
- dev-sbd.core.driver_data = NULL;
+ dev_set_drvdata(dev-sbd.core, NULL);
It seems that will result in a memory leak. Why did you
think the kfree() should be removed?
Won't this work?
kfree(ps3_system_bus_get_driver_data(dev-sbd));
ps3_system_bus_set_driver_data(dev-sbd, NULL);
ps3flash_dev = NULL;
return 0;
}
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Grant Likely wrote: What do you mean by one size fits all solution? The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. First device trees are now the ONLY means of passing information to the kernel. By definition that means it is a one size fits all solution. While there is nothing inherently wrong with that, solutions intended to meet all circumstances need to be simple, powerful, and flexible. They need to work well 100% of the time not 98%. Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. That sounds like a good solution to me. I am glad you like it. If Xilinx would like to offer any advice as to how to prepend a device tree to the end of a bit file without foreclosing any of their future plans or I would be happy to look at implementing it. As for using up BRAM, a gzipped dtb image is smaller than 2k and it can be reclaimed for other uses after the kernel has booted. That may not help your situation, but for my use cases the tradeoff works. If I recall the minimum increment for BRAM is 16K. I am not trying to claim it is not an answer for anyone, or even most people. Though I still have an issue. One of the problem with 98% solutions, is that they result in a chain of work arrounds for the other 2%. Instead of one case or two cases, you end up with a dozen cases each handling increasingly tiny slivers. And it becomes increasingly easy to claim that the problem is with the slivers not the broad solution. Regardless it still makes my point. The problem with devicetrees as they are is that they handle probably 98% of all cases well. The remaining 2% are a mess. No it isn't. It is expected that firmware will fixup the device tree data with board specific values. This is intentional. The device tree is simply the bearer. It makes no determination about where the data comes from. I am not sure what you are saying here ? By firmware do you mean bootloader ? Or do you mean bitfiles ? In large systems like Sun or Apple desktop the OF Device tree need not be static. There is software that may well be larger than the linux kernel. Our firmware bootloader is actually stored in the bitfile - 16K of BRAM basically becomes the boot ROM - except that it is bitfile initialized RAM. I guess this is much like you dtb in BRAM. We are not increasing the size of the BRAM, while most of our systems have NOR flash, or ... or , the all don't. Even the amount of DRAM varies, and our code is written not to use DRAM until we have verified that it works. lots of .dtb files lying arround is only a better solution than simpleimage. I will guarantee that unless they are welded together the wrong device tree will get used with the wrong bit file. I agree. Inevitably I will make that mistake myself occasionally and waste hours or possibly days trying to debug it. And if I will do it rarely clients will do it frequently. In my expereince if you create a situation where confusion can exist it will. It is also my expereince that time spend coding a solution to a common client problem is well spent. If it takes me a week to work out dynamically creating a device tree, that ill likely save many weeks of support headaches. Again, it doesn't sound like you want dynamic *creation* of device trees. It sounds like you want a reliable way to make sure the bitstream is welded together with the correct dtb, preferably within the Xilinx toolchain. Welding the bit file to the dtb might solve 75% of my issues, And it probably would get me to the point where I could move forward and live with the remaining issues untile I was inspired to solve them. but it does not solve everything. It is increasingly clear to me that I am going to have to manipulate device trees. Even if I do not end up creating the device tree dynamically, I
Re: device trees.
Not pretty, but it does more or less what you're talking about. Would need some work to get it going on !pseries obviously. Heh, I didn't even know this existed. :-) Thinking about this more, it seems to me that the tricky bit would be figuring out how to drop all references to a node before it is pruned from the tree. of_platform_devices would probably be the easiest because the bus could walked before pruning the node, but there are also references on the i2c, spi and mdio busses that must be dealt with appropriately. Also, the way userspace manipulates the tree via /proc/ppc64 is quite gross... Some time ago we discussed about moving that to the kernel since the firmware call that gives us the new bits of tree could be done there in a relatively generic way but that's only one option. Maybe it's time to have a proper devicetreefs so one can use standard fs APIs to create nodes properties though we would need a trick to turn them from temporary to online and similar for offlining. Maybe with mv from/to a staging directory that isn't live vs. the kernel. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, 2009-05-11 at 17:38 -0400, David H. Lynch Jr. wrote: Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. To some extend, but the user choice information is well isolated, it's all in /chosen, so it's really only that node that needs to be modified or created from scratch by the bootloader. Thus, your bootloader can pick the right static dtb for a given bitfile, and then just use libfdt to generate the right /chosen node with other informations. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix sata_sil compilation on non-DMI platforms
On Mon, 2009-05-11 at 19:44 +0100, Alan Cox wrote: Ideally the DMI subsystem should be provided wrappers for platforms without DMI, rendering patches like this unnecessary. Interesting question - is the PPC OpenFirmware machine information mappable onto the DMI space ? or the various static bits of name information in the various ARM and the like machine descriptions. If not which bits are similar enough we could replace dmi at the high level with an abstract interface for system/vendor/... that was ? The one thing we could try to map would be the device-tree compatible property which would contain vendor,system tuples from more specific to more generic with which the machine is compatible with. Of course I would argue the other way around and create a device-tree from the DMI data :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. dh...@dlasys.net wrote: Grant Likely wrote: What do you mean by one size fits all solution? The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. First device trees are now the ONLY means of passing information to the kernel. By definition that means it is a one size fits all solution. While there is nothing inherently wrong with that, solutions intended to meet all circumstances need to be simple, powerful, and flexible. They need to work well 100% of the time not 98%. Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. It is the sole means of passing anything *to the kernel*. You can pass whatever you like to the bootwrapper. :-) That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. ...or if you really are constrained, then define a format for the data you want to pass, pass it to the bootwrapper along with the device tree, and use the bootwrapper (which already has libfdt) to update the device tree. cuImage targets do this to support older u-boots which don't understand device trees. You are not forced to put device tree support in your firmware. In other words; having your bootloader support FDT is preferred, but not required. Word of warning; if you do define your own format, be very very very careful. Otherwise you end up with something subtly broken and not future proof. This is one of the reasons adding FDT support to your firmware is preferred; these issues have already been thought about. Though I still have an issue. One of the problem with 98% solutions, is that they result in a chain of work arrounds for the other 2%. Instead of one case or two cases, you end up with a dozen cases each handling increasingly tiny slivers. And it becomes increasingly easy to claim that the problem is with the slivers not the broad solution. No, it's not. Everything you need to do can be done within the bootwrapper if you so desire, passing data in whatever format you like. I am not sure what you are saying here ? By firmware do you mean bootloader ? Or do you mean bitfiles ? Yes, I'm using the terms firmware and bootloader interchangeably. I still don't understand what you're worried about starting an arguing about. Pretty much any of the PowerPC maintainers can point at warts and problems in the current handling of device trees. I'm not particularly happy with simpleImage (and I wrote it), but it takes time and effort to write something more capable. I was not trying to start an argument, my initial question was Is there an example somewhere that shows building a device tree on the fly ? The responses have questioned why I want to do that rather than how can I do that. I was not actually seeking a debate over the merit of device trees, or u-boot, or libdft, or ... but the questions were necessary to understand your problem set. I cannot give good advice without understanding. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
On Mon, May 11, 2009 at 02:28:50PM +1000, Mark Ware wrote: Ben Dooks wrote: On Wed, Apr 29, 2009 at 08:43:14AM -0500, Kumar Gala wrote: On Apr 22, 2009, at 4:56 PM, Ben Dooks wrote: On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote: On Apr 21, 2009, at 7:49 AM, Mark Ware wrote: Recent DMA changes result in a BUG() when NULL is passed to dma_alloc_coherent in place of a device. Signed-off-by: Mark Ware mw...@elphinstone.net --- This patch fixes the BUG() during boot that has appeared during the 2.6.30 window. It has been tested and appears correct on my 8280 based board. Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it belongs. drivers/i2c/busses/i2c-cpm.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org Ben, I'm expecting you to pick this up unless you tell me otherwise. Yes. This go in yet? I've had to do a manual apply due to some changes in the driver, so can someone please do a build of my git tree at: git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-2630-rc5 or tell me which arch and defconfig to build. Ping. Is there anything still blocking this? sorry, have been ill recently, will get this sorted and pushed. -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: question about softirqs
From: Chris Friesen cfrie...@nortel.com Date: Mon, 11 May 2009 12:25:54 -0600 David Miller wrote: You know, for networking over loopback (one of the only real cases that even matters, if we get a hard interrupt then the return from that would process any softints), we probably make out just fine anyways. As long as we hit a local_bh_enable() (and in the return path from device transmit that's exceedingly likely as all of the networking locking is BH safe) we'll run the softints from that and thus long before we get to syscall return. What about the issue I raised earlier? (I don't think you were copied at that point.) I'm sure all of the networking experts on linuxppc-dev will have an answer. And yes that was sarcasm :-) You need to ask this on netdev or similar list. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: question about softirqs
Chris Friesen writes: Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set (and maybe doing other stuff if there are no messages). In this case, schedule() would re-run the spinning task rather than running ksoftirqd. This could prevent any incoming packets from actually being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device. I suggest you ask Ingo Molnar about that. (And maybe longer if NOHZ is enabled.) We still have a timer interrupt every jiffy when stuff is running; we only turn off the timer interrupts when idle. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. That sounds like a good solution to me. I am glad you like it. If Xilinx would like to offer any advice as to how to prepend a device tree to the end of a bit file without foreclosing any of their future plans or I would be happy to look at implementing it. There are options here... For the benefit of the mailing list: they are tied into how the FPGA configuration is loaded, and the particular FPGA family. By far the most portable/generic option is to simply use an initialized BRAM for this. David: If you would like to have a discussion regarding particular design tradeoffs, I'd be happy to, but since I doubt there is anyone on this list who is interested in the vagaries of FPGA configuration methods, I suggest we have the discussion privately. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 5:19 PM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. That sounds like a good solution to me. I am glad you like it. If Xilinx would like to offer any advice as to how to prepend a device tree to the end of a bit file without foreclosing any of their future plans or I would be happy to look at implementing it. There are options here... For the benefit of the mailing list: they are tied into how the FPGA configuration is loaded, and the particular FPGA family. By far the most portable/generic option is to simply use an initialized BRAM for this. David: If you would like to have a discussion regarding particular design tradeoffs, I'd be happy to, but since I doubt there is anyone on this list who is interested in the vagaries of FPGA configuration methods, I suggest we have the discussion privately. I disagree. There are lots of lurkers on this list who care about virtex stuff, not to mention non-lurkers like me. :-) I would at least like to be a fly on the wall of any such discussion. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: question about softirqs
This started out as a thread on the ppc list, but on the suggestion of DaveM and Paul Mackerras I'm expanding the receiver list a bit. Currently, if a softirq is raised in process context the TIF_RESCHED_PENDING flag gets set and on return to userspace we run the scheduler, expecting it to switch to ksoftirqd to handle the softirqd processing. I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device. DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter? Thanks, Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote: Grant Likely wrote: What do you mean by one size fits all solution? The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. First device trees are now the ONLY means of passing information to the kernel. That's not really true in practice. Yes, the device tree is the only way to pass information to the kernel proper, but having a bootwrapper, built along with the kernel, which translates information in some other form into a device tree is a perfectly reasonable solution for the right circumstances. By definition that means it is a one size fits all solution. While there is nothing inherently wrong with that, solutions intended to meet all circumstances need to be simple, powerful, and flexible. They need to work well 100% of the time not 98%. Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. Compared to running Linux, manipulating the device tree is a complete triviality, so I don't see what the problem is here. [snip] Welding the bit file to the dtb might solve 75% of my issues, And it probably would get me to the point where I could move forward and live with the remaining issues untile I was inspired to solve them. but it does not solve everything. It is increasingly clear to me that I am going to have to manipulate device trees. That's probably true. But you don't necessarily have to do it within your BRAM firmware - you can do it inside the Linux bootwrapper. Anyway, all I was looking for was a leg up on figuring out how to do what I want with them. Rather than starting from scratch. I am not looking to be convinced that I am approaching this all wrong. If you are happy with what you have - great. I am not. While I was not looking to restart a great debate over device trees - I do not actually think they are a bad idea. I still don't understand what you're worried about starting an arguing about. Pretty much any of the PowerPC maintainers can point at warts and problems in the current handling of device trees. I'm not particularly happy with simpleImage (and I wrote it), but it takes time and effort to write something more capable. I was not trying to start an argument, my initial question was Is there an example somewhere that shows building a device tree on the fly ? The responses have questioned why I want to do that rather than how can I do that. I was not actually seeking a debate over the merit of device trees, or u-boot, or libdft, or Probably the closest things to suitable examples here are arch/powerpc/kernel/prom_init.c, which builds the dtb from the live OF device tree. At the moment that's a bit of a special case, but there's no inherent reason that logic couldn't be moved to the bootwrapper. The other, not in the main tree, is Paul's restodt, which builds a device tree from old-style PReP residual information. I recall it was sent to the list as a userspace program (we were gathering information on the sorts of PReP out there). I think Paul made at least a first cut at fusing it into the bootwrapper, but I don't know if that ever got sent out to the list. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 12:54:58PM -0400, David H. Lynch Jr. wrote: Timur Tabi wrote: On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. dh...@dlasys.net wrote: So all you need to do is have your boot loader create a device tree from scratch. If you're using U-Boot, then you can already do this by making the appropriate libfdt calls. Otherwise, you should probably add libfdt to your boot loader. As I mentioned before, we do nto use u-boot. I am not looking to start a debate on it either, but it does not meet a number of our needs, and would require significant architectural changes to do so. The difference between it and devicetrees is that u-boot is avaiable to us if we want, I did port u-boot to our hardware at one point and it did everything it promised, but u-boot is optional, device trees are not. I do not have to re-architect u-boot to fit into 16k of bram, or load bit files or . If I want to move past 2.6.26 I have to not only use device trees but actually make them work in a way that will function as we need with our systems. It is likely I will use libdft as a starting point, but I can not see it as more than a short term solution. libdft is orders of magnitude large than our entire monitor, and it is a toolkit rather than the whole solution. I'm very willing to make changes to libfdt, if it helps make it more useful to you without breaking it for other people. I'm a little horrified at the size of libfdt, and a bit baffled as to why it's ending up that large. From some initial poking around, it looks like -fPIC inflates the code size a *lot* (~3x on x86, which I know is not what we're dealing with here, but was the easiest for a quick test). So if you don't need that in your context, that could save a heap. The separation into separate .o files is also deliberate, so that portions you don't use can be omitted. I have considered breaking it up into many more .c files, so that you can omit individual not-needed functions. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64
Hi PPC Dev folks, Please find a patch below that implements the proposed Hardware Breakpoint interfaces for PPC64 architecture. As a brief introduction, the proposed Hardware Breakpoint infrastructure provides generic in-kernel interfaces to which users from kernel- and user-space can request for breakpoint registers. An ftrace plugin that can trace accesses to data variables is also part of the generic HW Breakpoint interface patchset. The latest submission for this patchset along with an x86 implementation can be found here: http://lkml.org/lkml/2009/5/11/159. The following are the salient features of the PPC64 patch. - Arch-specific definitions for kernel and user-space requests are defined in arch/powerpc/kernel/hw_breakpoint.c - Ptrace is converted to use the HW Breakpoint interfaces Will we fall back to use the old method if more than one address is being watched? - The ftrace plugin called ksym_tracer is tested to work fine. For instance when tracing pid_max kernel variable, the following was obtained as output Could you split the patch into a few pieces which implement these different parts. The smaller logical chucks will make it easier to review? # cat trace # tracer: ksym_tracer # # TASK-PID CPU# Symbol TypeFunction # | | | | | bash4502 3 pid_max RW .do_proc_dointvec_minmax_ conv+0x78/0x10c bash4502 3 pid_max RW .do_proc_dointvec_minmax_ conv+0xa0/0x10c bash4502 3 pid_max RW .alloc_pid+0x8c/0x4a4 There are however a few limitations/caveats of the patch as identified below: - The patch is currently implemented only for PPC64 architecture. Other architectures (especially Book-E implementations are expected to happen in due course). - HW Breakpoints over data addresses through Xmon (using bd command) and the proposed HW Breakpoint interfaces can now operate in a mutually exclusive manner. Xmon's integration is pending and is dependant on successful triggering of breakpoints through bdops. (Note: On a Power5 machine running 2.6.29, Xmon could not trigger HW Breakpoints when tested). Kindly let me know your comments. Thanks, K.Prasad Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com --- arch/powerpc/Kconfig |1 arch/powerpc/include/asm/hw_breakpoint.h | 52 + arch/powerpc/include/asm/processor.h |1 arch/powerpc/include/asm/reg.h |2 arch/powerpc/include/asm/thread_info.h |2 arch/powerpc/kernel/Makefile |2 arch/powerpc/kernel/hw_breakpoint.c | 271 +++ arch/powerpc/kernel/process.c| 18 ++ arch/powerpc/kernel/ptrace.c | 48 + arch/powerpc/mm/fault.c | 14 - samples/hw_breakpoint/data_breakpoint.c |4 12 files changed, 423 insertions(+), 9 deletions(-) You've not touched prace32.c. Can we use this for 32 bit apps on a 64 bit kernel? Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig === --- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig +++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig @@ -125,6 +125,7 @@ config PPC select USE_GENERIC_SMP_HELPERS if SMP select HAVE_OPROFILE select HAVE_SYSCALL_WRAPPERS if PPC64 + select HAVE_HW_BREAKPOINT if PPC64 config EARLY_PRINTK bool Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile === --- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/Makefile +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile @@ -33,7 +33,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_p signal_64.o ptrace32.o \ paca.o cpu_setup_ppc970.o \ cpu_setup_pa6t.o \ -firmware.o nvram_64.o +firmware.o nvram_64.o hw_breakpoint.o obj64-$(CONFIG_RELOCATABLE) += reloc_64.o obj-$(CONFIG_PPC64) += vdso64/ obj-$(CONFIG_ALTIVEC)+= vecemu.o vector.o Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c === --- /dev/null +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c @@ -0,0 +1,271 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + *
Re: device trees.
On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. dh...@dlasys.net wrote: Grant Likely wrote: What do you mean by one size fits all solution? The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. First device trees are now the ONLY means of passing information to the kernel. By definition that means it is a one size fits all solution. While there is nothing inherently wrong with that, solutions intended to meet all circumstances need to be simple, powerful, and flexible. They need to work well 100% of the time not 98%. Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. It is the sole means of passing anything *to the kernel*. You can pass whatever you like to the bootwrapper. :-) That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. ...or if you really are constrained, then define a format for the data you want to pass, pass it to the bootwrapper along with the device tree, and use the bootwrapper (which already has libfdt) to update the device tree. cuImage targets do this to support older u-boots which don't understand device trees. You are not forced to put device tree support in your firmware. In other words; having your bootloader support FDT is preferred, but not required. I wouldn't even go so far as to say it's preferred. IMO, people have gone a bit prematurely keen on moving devtree handling into the firmware. Putting it in the firmware has a number of advantages, but it also has a number of non-trivial disadvantages. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
get data failed with DMA
i tried to fetch data from periphial memories with DMA the flow as following flags = claim_dma_lock(); disable_dma(DMA_CH); clear_dma_ff(); set_dma_count(DMA_CH, 4); set_dma_addr(DMA_CH, virt_to_bus(kv_buf)); release_dma_lock(flags); enable_dma(DMA_CH); the code hault at disable_dma(DMA_CH) in addition, i defined DMA_CH as 0 for channel 0 'kv_buf' is an kernel space virtual address. i can red the correct value of periphal from this address i supposed the fault along with the configured of registers about DMA in processer. but i am not sure. give some suggestion about this, thanks! -- View this message in context: http://www.nabble.com/get-data-failed-with-DMA-tp23494879p23494879.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, 2009-05-12 at 08:56 +1000, David Gibson wrote: On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote: Grant Likely wrote: Anyway, all I was looking for was a leg up on figuring out how to do what I want with them. Rather than starting from scratch. I am not looking to be convinced that I am approaching this all wrong. If you are happy with what you have - great. I am not. While I was not looking to restart a great debate over device trees - I do not actually think they are a bad idea. I still don't understand what you're worried about starting an arguing about. Pretty much any of the PowerPC maintainers can point at warts and problems in the current handling of device trees. I'm not particularly happy with simpleImage (and I wrote it), but it takes time and effort to write something more capable. I was not trying to start an argument, my initial question was Is there an example somewhere that shows building a device tree on the fly ? The responses have questioned why I want to do that rather than how can I do that. I was not actually seeking a debate over the merit of device trees, or u-boot, or libdft, or Probably the closest things to suitable examples here are arch/powerpc/kernel/prom_init.c, which builds the dtb from the live OF device tree. At the moment that's a bit of a special case, but there's no inherent reason that logic couldn't be moved to the bootwrapper. The other, not in the main tree, is Paul's restodt, which builds a device tree from old-style PReP residual information. I recall it was sent to the list as a userspace program (we were gathering information on the sorts of PReP out there). I think Paul made at least a first cut at fusing it into the bootwrapper, but I don't know if that ever got sent out to the list. There's also the iseries code, which is not pretty, but shows a very minimal example of constructing a device tree on the fly, some of it based on static config and some that's not. The routines for constructing DT nodes and properties is about 110 lines, and most of that is brackets. arch/powerpc/platforms/iseries/dt.c cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Stephen Neuendorffer wrote: Many of our systems are LX systems but currently we are not running Linux on them. Master SelectMap, I presume? What FPGA family? Does the FPGA have access to the CPLD after boot, other than through the configuration pins? One of the skills I have not had time to develop - because Pico has plenty of qualified firmware/hardware people and not enough OS people, is fluency with Xilinx tools. FPGA Families - currently Spartan, virtex 4 and virtex 5. LX FX, in all kinds of sizes. So that as an example our E14 (1st generation cardbus) comes in FX40's and FX60's and LX## ... I am presuming that is what you mean. Access to the hardware on the cards can be weird. As our cards are often hosted, that means the firmware is often setup to allow host and target access to hardware. In others only the host or only the target does. What I know is that if I send a few magic values to the CPLD and then start reading the bit file out of flash, I will trigger the CPLD to reload the FPGA from the bitfile I selected. OK, so that means the boot monitor can open sector 2 of the flash and read info, right? (Or wherever else the bitstream is coming from. On powerup the CPLD boots from sector 2. IF it is rebooted by the host or target it can reboot from any flash sector. In the normal setup the target has indirect access to the entire NOR flash. Can the CPLD store one 32 bit int that the new bitstream can come back and read later? Off the top of my head I do nto know, but if you are saying I need to find someway of preserving a 32bit value through rebooting the FPGA I can find a way to do it. OK, so the key question seems to be *when* the bitstream is associated with the device tree. If at bitstream generation time, you can prepend the .dtb to the bitstream. As long as the dtb doesn't contain the magic bitstream start code, you can go back and access it later. You really mean prepend ? I was presuming that things would work better if it was appended ? Regardless, I have the means to know exactly what bit file is currently loaded, and I can then look it up in the NOR Flash. I can glue the dtb and the bit file together in anyway that will make xilinx happy. If it is prepended the only case I care about is the power up sequence, because that must start loading the bit file at sector 2. We do cope with the scenario where the sector 2 bit file is completely screwed up. The CPLD STARTS trying to load at sector 2, but it will continue to the end of flash until something actually loads. The dead card scenario is sector 2 is the start of a valid but non-functional bit file. At that point you must load a bit image using JTAG and then write a good bit file to flash. Alright lets say I prepend. I am loosely familar with the magic start code. Does that need to be aligned in anyway ? And just for the sake of argument lets say I append the dtb. Do I need some padding between the bitfile and the dtb to keep the FPGA from loading the dtb as firmware ? Is there a magic stop sequence ? Is the load terminated by the length of the bits. Is this sounding reasonable? I am sure there is something I can work with here. Thanks. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64
+struct arch_hw_breakpoint {
+ char*name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+ u8 type;
+};
Can you reorder this to pack the struct better (ie. put the unsigned
long first).
Oops, this is a char * not just a char. Order is fine.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
-Original Message- From: David H. Lynch Jr. [mailto:dh...@dlasys.net] Sent: Monday, May 11, 2009 7:35 PM To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org Subject: Re: device trees. Stephen Neuendorffer wrote: Many of our systems are LX systems but currently we are not running Linux on them. Master SelectMap, I presume? What FPGA family? Does the FPGA have access to the CPLD after boot, other than through the configuration pins? One of the skills I have not had time to develop - because Pico has plenty of qualified firmware/hardware people and not enough OS people, is fluency with Xilinx tools. FPGA Families - currently Spartan, virtex 4 and virtex 5. LX FX, in all kinds of sizes. So that as an example our E14 (1st generation cardbus) comes in FX40's and FX60's and LX## ... I am presuming that is what you mean. Access to the hardware on the cards can be weird. As our cards are often hosted, that means the firmware is often setup to allow host and target access to hardware. In others only the host or only the target does. What I know is that if I send a few magic values to the CPLD and then start reading the bit file out of flash, I will trigger the CPLD to reload the FPGA from the bitfile I selected. OK, so that means the boot monitor can open sector 2 of the flash and read info, right? (Or wherever else the bitstream is coming from. On powerup the CPLD boots from sector 2. IF it is rebooted by the host or target it can reboot from any flash sector. In the normal setup the target has indirect access to the entire NOR flash. Can the CPLD store one 32 bit int that the new bitstream can come back and read later? Off the top of my head I do nto know, but if you are saying I need to find someway of preserving a 32bit value through rebooting the FPGA I can find a way to do it. OK, so the key question seems to be *when* the bitstream is associated with the device tree. If at bitstream generation time, you can prepend the .dtb to the bitstream. As long as the dtb doesn't contain the magic bitstream start code, you can go back and access it later. You really mean prepend ? I was presuming that things would work better if it was appended ? Yes, actually prepend is simpler because you don't have to know the size of the bitstream. Everything before the SYNC code in the bitstream is ignored. For instance, this is the start of a spartan 3ADSP bitstream: 00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 0b |.a..| 0010 73 79 73 74 65 6d 2e 6e 63 64 00 62 00 0e 33 73 |system.ncd.b..3s| 0020 64 33 34 30 30 61 66 67 36 37 36 00 63 00 0b 32 |d3400afg676.c..2| 0030 30 30 39 2f 20 35 2f 20 31 00 64 00 09 31 34 3a |009/ 5/ 1.d..14:| 0040 34 38 3a 32 31 00 65 00 16 59 d4 ff ff ff ff ff |48:21.e..Y..| 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || 0060 ff ff ff ff ff ff ff ff ff ff ff aa 99 30 a1 00 |.0..| 'FF FF AA 99' is the Spartan 3 DUMMY code/SYNC code combination, everything before that is discarded by the FPGA. Regardless, I have the means to know exactly what bit file is currently loaded, and I can then look it up in the NOR Flash. Yes, so as long as when the bitstream is loaded, it can figure out where in the flash it was loaded *from* and then go back there and get the dtb, then that should work. This would make it difficult to do certain things (like loading a useful bitstream from anywhere OTHER than flash), but if you can make that restriction, then it should work. I can think of several ways of doing this, the simple of which is to have your bootloader go to the CPLD after it has loaded to figure out where the bitstream came from. I can glue the dtb and the bit file together in anyway that will make xilinx happy. Fortunately, you don't have to keep Xilinx happy, only the FPGA.. :) If it is prepended the only case I care about is the power up sequence, because that must start loading the bit file at sector 2. We do cope with the scenario where the sector 2 bit file is completely screwed up. The CPLD STARTS trying to load at sector 2, but it will continue to the end of flash until something actually loads. The dead card scenario is sector 2 is the start of a valid but non-functional bit file. At that point you must load a bit image using JTAG and then write a good bit file to flash. Alright lets say I prepend. I am loosely familar with the magic start code. Does that need to be aligned in anyway ? My understanding is that alignment does matter somewhat if you are using SelectMap32, so if this is what you are doing, it's probably best to preserve the existing alignment, padding the dtb to a number of words divisible by 4. If you're using serial configuration modes, or selectmap8, then it doesn't matter. And just for the sake of argument lets say I append the dtb. Do I need
Re: Next May 11 : BUG during scsi initialization
On Mon, May 11, 2009 at 06:21:35AM -0600, Matthew Wilcox wrote: On Mon, May 11, 2009 at 05:34:07PM +0530, Sachin Sant wrote: Matthew Wilcox wrote: On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote: Today's Next tree failed to boot on a Power6 box with following BUG : This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried to allocate memory and things went wrong in the memory allocator: [c000c7d038b0] [c05d67d8] ._spin_lock+0x10/0x24 [c000c7d03920] [c013fbdc] .__slab_alloc_page+0x344/0x3cc [c000c7d039e0] [c0141168] .kmem_cache_alloc+0x13c/0x21c [c000c7d03aa0] [c0141b04] .kmem_cache_create+0x294/0x2a8 [c000c7d03b90] [d0ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod] Which memory allocator did you have selected (SLAB, SLUB, SLOB, SLQB)? Default one. SLQB CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y Page size is 64K with Config DEBUG_PAGEALLOC set. CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_64K_PAGES=y CONFIG_DEBUG_PAGEALLOC=y Hm. We've seen some similar problems at Intel while doing database performance tests with SLQB. Any ideas, Nick? Hmm, I think (hope) your problems were fixed with the recent memory coruption bug fix for SLQB. (if not, let me know) This one possibly looks like a problem with remote memory allocation or memory hotplug or something like that. I'll do a bit of code review ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 7:12 PM, David Gibson da...@gibson.dropbear.id.au wrote: On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: In other words; having your bootloader support FDT is preferred, but not required. I wouldn't even go so far as to say it's preferred. IMO, people have gone a bit prematurely keen on moving devtree handling into the firmware. Putting it in the firmware has a number of advantages, but it also has a number of non-trivial disadvantages. I disagree. The more I work with it, the more I appreciate the advantage of decoupling the kernel image file from the hardware description. It is valuable being able to build a single image file that boots on a wide range of boards because the device tree passed in by firmware. I'm not downplaying the disadvantages and problems, but I still hold the view that the striving for generic multiplatform kernel images is worth the effort. ... but I do agree that hard linking the .dtb into firmware, or making the .dtb hard to upgrade is the way of madness. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: OK, so the key question seems to be *when* the bitstream is associated with the device tree. If at bitstream generation time, you can prepend the .dtb to the bitstream. As long as the dtb doesn't contain the magic bitstream start code, you can go back and access it later. You really mean prepend ? I was presuming that things would work better if it was appended ? Yes, actually prepend is simpler because you don't have to know the size of the bitstream. Everything before the SYNC code in the bitstream is ignored. ...In this case, might need to preprocess the .dtb the escape out the possibility of a sync code appearing. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next May 11 : BUG during scsi initialization
Hi Nick, On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin npig...@suse.de wrote: Hmm, I think (hope) your problems were fixed with the recent memory coruption bug fix for SLQB. (if not, let me know) This one possibly looks like a problem with remote memory allocation or memory hotplug or something like that. I'll do a bit of code review These are -next kernels which include the two fixes you posted recently (I am pretty sure). I am also getting the network failures that Sachin is seeing on several of my machines here. The previously reported problems have gone away. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpcmsGunBu4o.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
