Re: How to map addresses beyond 4GB
Thanks Dan Malek [EMAIL PROTECTED] wrote: On Nov 22, 2007, at 2:42 AM, Dell Query wrote: May I know how to map this one? Just call ioremap() as usual. It will understand the 4G physical address and return a useful virtual address to you. -- Dan - Never miss a thing. Make Yahoo your homepage.___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
I wrote: Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect. I tried this with the current powerpc.git tree on my mpc8548cds, and the reboot command works for me. The system rebooted just fine. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
Hi Paul, I'm just wondering what are your latest thoughts about this patch (http://patchwork.ozlabs.org/linuxppc/patch?id=14707). Cheers, Emil. -Original Message- From: Medve Emilian Sent: Tuesday, November 13, 2007 10:24 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Cc: Medve Emilian Subject: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections When a module has relocation sections with tens of thousands worth of entries, counting the distinct/unique entries only (i.e. no duplicates) at load time can take tens of seconds and up to minutes. The sore point is the count_relocs() function which is called as part of the architecture specific module loading processing path: - load_module()generic - module_frob_arch_sections() arch specific - get_plt_size() 32-bit - get_stubs_size() 64-bit - count_relocs() (Not sure why the relocation tables could contain lots of duplicates and why they are not trimmed at compile time by the linker. In some test cases, out of 35K relocation entries only 1.5K were distinct/unique) The previous counting algorithm was having O(n^2) complexity. Basically two solutions were proposed on the e-mail list: a hash based approach and a sort based approach The hash based approach is the fastest (O(n)) but the has it needs additional memory and for certain corner cases it could take lots of memory due to the degeneration of the hash. One such proposal was submitted here: http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html In this proposal, the symbol + addendum are hashed to generate a key and a pointer to the relocation entry will be stored in it. The hash is implemented as a linked list of memory pages with PAGE_SIZE / sizeof(Elfxx_Rela *) entries. In case of collisions in all the existing pages, a new page is added to the list to accommodate the new distinct relocation entry For 32-bit PowerPCs with 4K pages, a page can accommodate 1K worth of pointers to relocation entries. In the 35K entries scenario, as much/little of six (6) pages could be allocated using 24K of extra memory during the module load The sort based approach is slower (O(n * log n + n)) but if the sorting is done in place it doesn't need additional memory. A proposal was submitted here: http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045854.html (http://patchwork.ozlabs.org/linuxppc/patch?filter=defaultid=14573) In this proposal an array of pointers to the relocation entries is built and then is sorted using the kernel sort() utility function. This is basically a heap sort algorithm with a stable O(n * log n) complexity. With this counting the distinct/unique entries is just linear (O(n)) complexity. The problem is the extra memory needed in this proposal, which in the 35K relocation entries test case it can be as much as 140K (for 32-bit PowerPCs; double for 64-bit). This is much more then the memory needed by the hash based approach described above/earlier but it doesn't hide potential degenerative corner cases The current patch is a happy compromise between the two proposals above: O(n + n * log n) performance with no additional memory requirements due to sorting in place the relocation table itself Signed-off-by: Emil Medve [EMAIL PROTECTED] --- This patch only tries to address counting the distinct R_PPC_REL24 entries for the purpose of sizing the PLT. This operation was/can be detected by the proper kernel logic as a soft lockup for large relocation tables A related optimization (that could cause rewriting the this patch) is to optimize the PLT search from do_plt_call() but that doesn't seem to be a problem right now The errors below are false positives due to the fact that Elfxx_Rela are falsely assumed to be variables/operands instead of types: linux-2.6 scripts/checkpatch.pl 0001-POWERPC-Optimize-counting-distinct-entries-in-the.patch ERROR: need consistent spacing around '*' (ctx:WxV) #116: FILE: arch/powerpc/kernel/module_32.c:78: + const Elf32_Rela *x, *y; ^ ERROR: need consistent spacing around '*' (ctx:WxV) #228: FILE: arch/powerpc/kernel/module_64.c:122: + const Elf64_Rela *x, *y; ^ total: 2 errors, 0 warnings, 218 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. arch/powerpc/kernel/module_32.c | 77 ++--- arch/powerpc/kernel/module_64.c | 81 ++ 2 files changed, 127 insertions(+), 31
Re: The question about the high memory support on MPC8360?
vijay baskar wrote: The kernel maps the last 1 GB of the virtual address space one to one to the physical memory. No, it maps 768MB of RAM in this manner. This is called the kernel space. After the one to one mapping is done for the available physical memory, the remaining virtual addresses are used for vmalloc and ioremap. And highmem mappings. The kernel also allows hardcoded mapping of IO regions into its virtual address space through the io_block_mapping interface. Not in current arch/powerpc kernels. Many boards use the block IO mapping to map the CCSRBAR/IMMR into the kernel address space, such that the physical address and the virutal address is the same. Virtual addresses beyond these hardcoded mappings cannot be used by vmalloc/ioremap. And this is why. Now as more and more memory is added to the system the addresses available for vmalloc and ioremap gets reduced, and memory allocations start to fail, due to the lack of availability of virtual addresses. How so? The size of lowmem is constant once you reach the threshold, as is the size of the highmem mapping area. What *does* start to fail eventually, if you have a *lot* of highmem, is that you run out of lowmem for pagetables and such. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote: I wrote: Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git- bisect. I tried this with the current powerpc.git tree on my mpc8548cds, and the reboot command works for me. The system rebooted just fine. I'm wondering if there is an issue rebooting if we are in an oops. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linuxppc-embedded Digest, Vol 39, Issue 48
Thanks Ben,
Here it is
static struct fsl_spi_platform_data k_platform_data = {
.initial_spmode = 0,
.bus_num = 1,
.max_chipselect = 1,
/* board specific information */
.activate_cs = k_cs_activate,
.deactivate_cs = k_cs_deactivate,
.sysclk =266,
};
static struct spi_board_info spi_board_info[] __initdata = { {
.modalias= kplus,
.platform_data= k_platform_data,
.max_speed_hz= 12,
.bus_num= 1,
.chip_select= 0,
},
};
struct platform_device k_plus = {
.name= kplus,
.id= 1,
.dev= {
.platform_data = k_platform_data,
},
};
platform_device_register(k_plus);
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
and then calls spi_register_driver(k_driver);
I can't get the into the *probe functions.
Thanks
fabio777 wrote:
Has anyone been using this driver ?
I use it, on ARCH=powerpc, though.
For legacy reasons I need to keep the ppc=arch however I haven't found
out how to get this driver probed at start-up even basing my init on
Lublock.
The driver's expecting a platform device with name mpc83xx_spi to be
registered in board init code. If you post your init code I may be able
to help.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SPI driver for spi_mpc83xx
Fabio,
Note: I've changed the e-mail subject back to the original. In the
future, please ensure that it remains intact.
fabio777 wrote:
Thanks Ben,
Here it is
static struct fsl_spi_platform_data k_platform_data = {
.initial_spmode = 0,
.bus_num = 1,
Probably should be bus_num = 0
.max_chipselect = 1,
/* board specific information */
.activate_cs = k_cs_activate,
.deactivate_cs = k_cs_deactivate,
.sysclk = 266,
};
static struct spi_board_info spi_board_info[] __initdata = { {
.modalias = kplus,
.platform_data = k_platform_data,
.max_speed_hz = 12,
.bus_num = 1,
Again, bus_num probably should be 0
.chip_select = 0,
},
};
struct platform_device k_plus = {
.name = kplus,
name should be mpc83xx_spi. At initialization, the SPI controller
driver searches the registered platform devices (models of board
hardware) for a match. Without a match, it gives up.
.id = 1,
.dev = {
.platform_data = k_platform_data,
},
};
platform_device_register(k_plus);
Do you add the SPI controller's resources (base address and IRQ?) You'll
need to in order for this to work. On my board, I use
'platform_device_register_simple()', passing the name and the two
resources, then call 'platform_add_data()', passing in the platform data
structure.
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
Good
and then calls spi_register_driver(k_driver);
I don't think this last call is needed.
I can't get the into the *probe functions.
Thanks
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Debugging with gdbserver slow
Fixed. It turns out it was because I'm using VMWare to run Linux on my windows computer. I booted up Linux natively and it stepped through code very fast even in multi threaded apps. -- View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13980499 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
Hi,
I am creating a simple program which will try to read the board ID of the
PPC440EPx thru BCSR but when I load it, it gives me Data Read PLB Error.
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
--
#include linux/module.h
#include linux/kernel.h
#include linux/ioport.h
#include linux/delay.h
#include linux/init.h
#include linux/interrupt.h
#include linux/platform_device.h
#include asm/irq.h
#include asm/io.h
#include linux/i2c.h
#include linux/i2c-id.h
#include asm/ocp.h
#include asm/ibm4xx.h
MODULE_LICENSE(GPL);
#define BCSR_BASE 0xC0002000
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk(1 Calling init function.\n);
printk(1 bcsrbase value %p...\n,bcsrbase);
printk(1 Remapping %x...\n,BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
printk(1 bcsrbase new value %p...\n,bcsrbase);
/*read value*/
/*based on PPC440EPx document, BCSR0 is BoardID*/
tmp = in_be32(bcsrbase + BCSR0 /* BCSR0 */);
printk(1 BCSR0 %x...\n,tmp);
/*try to output something*/
//out_be32(bcsrbase , /*LED_ON*/);
return 0;
}
static void __exit cleanupFunction(void) {
printk(1 Calling cleanup function.\n);
/*unmap*/
iounmap(bcsrbase);
}
module_init(initFunction);
module_exit(cleanupFunction);
--
ERROR MESSAGE:
--
/mnt/flash_fs/var/ftp # insmod bcsr.ko
Calling init function.
bcsrbase value ...
Remapping c0002000...
bcsrbase new value d50fe000...
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT= 0x
PLB3 to PLB4: BEAR=0x7fff BESR0=0x BESR1=0x
PLB4 to PLB3: BEAR=0xfd7f BESR0=0x BESR1=0x
PLB3 to OPB: BEAR=0x BESR0=0x BESR1=0x
PLB3 arbiter: BEAR=0xbfef ACR=0x9000 BESR=0x
PLB4 to OPB1: BEAR=0x000efffbfffb BESR0=0x BESR1=0x
PLB40 Arbiter: BEAR=0xc0002000 ACR=0xde00 BESR0=0x0f00
PLB41 Arbiter: BEAR=0xfffa ACR=0xdf00 BESR0=0x
POB0: BEAR=0xc27e3194 BESR0=0x BESR1=0x
OPB0: BEAR=0x BSTAT=0x
Oops: machine check, sig: 7 [#1]
NIP: D50FC07C LR: D50FC070 CTR:
REGS: c02bcf50 TRAP: 0202 Not tainted (2.6.21-rc4)
MSR: 00029000 EE,ME CR: 24004022 XER:
TASK = c05fe490[115] 'insmod' THREAD: cdc6c000
GPR00: D50FC070 CDC6DE80 C05FE490 0023 0A00C100 0001 0031
GPR08: D50FE000 17E4 C029 04004022 1016F458
GPR16: 0030 0030 0124 D51132BC C0035E2C
GPR24: 0022 D5108000 0022 D50F7500 CF68A21C D50F CF68A000 C0279CEC
NIP [D50FC07C] initFunction+0x7c/0x128 [bcsr]
LR [D50FC070] initFunction+0x70/0x128 [bcsr]
Call Trace:
[CDC6DE80] [D50FC070] initFunction+0x70/0x128 [bcsr] (unreliable)
[CDC6DEA0] [C003731C] sys_init_module+0xe4/0x1458
[CDC6DF40] [C0001AC4] ret_from_syscall+0x0/0x3c
Instruction dump:
60842000 3860 4865 7c601b78 3c60d50f 7c040378 386370e8 901d76a0
483d 813d76a0 7c0004ac 8089 0c04 4c00012c 3c60d50f 38637108
Bus error
--
-
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Tue, Nov 27, 2007 at 10:26:59AM -0600, Kumar Gala wrote: On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote: I wrote: Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git- bisect. I tried this with the current powerpc.git tree on my mpc8548cds, and the reboot command works for me. The system rebooted just fine. I'm wondering if there is an issue rebooting if we are in an oops. I still can't reproduce it. Current powerpc.git reboots OK after an oops on my 8548cds. As long as I make it to Rebooting in 180 seconds.., it resets 3 minutes later. It may be hw-dependent as well as sw-dependent. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Hi folks, Stephen Neuendorffer wrote: Binding it to a kernel, is a non-starter for us. I agree that this is not the best way of leveraging the power of device trees. The point is that by using a device tree, you haven't lost anything you can do currently. In the future we might have one kernel which supports all versions of all our IP, along with all flavors of microblaze and powerpc... You would only ever need to recompile this kernel as a final optimization, if at all. I strongly support the OF / device tree work being done, from its own perspective and also as a path to MicroBlaze/PPC unification, however there is one critical difference that I have not seen adequately addressed yet. MicroBlaze is a highly configurable CPU in terms of its instruction set, features and so on. To make use of this, it is essential that each kernel image be compiled to match the CPU configuration. While a generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc) would run on any CPU, performance would be abysmal. In my view it's not acceptable to present these as options for the user to select at kernel config time. With N yes/no parameters, there is 1 correct configuration, and 2^N-1 incorrect ones. The odds of the user falling upon a configuration that at worst fails to boot, or at best is not optimally matched to the hardware, are high. This same issue also applies to C libraries and apps - they must be compiled with prior knowledge of the CPU. This is why our microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg! Wrapping every mul, div, shift etc in a function call is clearly not feasible. Things like the msrset/msrclr ops have a modest but measurable impact on kernel code size and performance - it's just not reasonable to add any level of indirection in there. I have thought about dynamic (boot-time) code re-writing as one possibility here, but it very quickly gets nasty. All of the optimised opcodes (MUL/DIV/Shift etc) are smaller than their emulated counterparts, so in principle we could re-write the text segment with the optimised opcode, then NOP pad, but that's still inefficient. As soon as we start talking about dynamic code relocation, re-writing relative offsets in loops, ... yuck.. We'd be putting half of mb-ld into the arch early boot code (or bootloader...) The opposite approach, to build with all instructions enabled and install exception handlers to deal with the fixups, is also pretty awful. I find myself asking the question - for what use cases does the current static approach used in MicroBlaze (with the PetaLinux BSP / Kconfig.auto) *not* work? One compromise approach might be to have a script in arch/microblaze/scripts, called by the arch Makefile, that cracks open the DT at build time and extracts appropriate cpu flags. Finally, what is the LKML position on DT files going into the kernel source tree? Regards, John ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
On 11/27/07, John Williams [EMAIL PROTECTED] wrote: Hi folks, Stephen Neuendorffer wrote: Binding it to a kernel, is a non-starter for us. I agree that this is not the best way of leveraging the power of device trees. The point is that by using a device tree, you haven't lost anything you can do currently. In the future we might have one kernel which supports all versions of all our IP, along with all flavors of microblaze and powerpc... You would only ever need to recompile this kernel as a final optimization, if at all. I strongly support the OF / device tree work being done, from its own perspective and also as a path to MicroBlaze/PPC unification, however there is one critical difference that I have not seen adequately addressed yet. MicroBlaze is a highly configurable CPU in terms of its instruction set, features and so on. To make use of this, it is essential that each kernel image be compiled to match the CPU configuration. While a generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc) would run on any CPU, performance would be abysmal. Looks like you've found the point of diminishing returns. :-) It is probably not appropriate to try and encode CPU configuration into the device tree *unless* it is only used to determine whether or not the kernel as compiled will run on that CPU; but even by then you're already running code on the platform. :-) In my view it's not acceptable to present these as options for the user to select at kernel config time. With N yes/no parameters, there is 1 correct configuration, and 2^N-1 incorrect ones. The odds of the user falling upon a configuration that at worst fails to boot, or at best is not optimally matched to the hardware, are high. This same issue also applies to C libraries and apps - they must be compiled with prior knowledge of the CPU. This is why our microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg! Wrapping every mul, div, shift etc in a function call is clearly not feasible. Things like the msrset/msrclr ops have a modest but measurable impact on kernel code size and performance - it's just not reasonable to add any level of indirection in there. I have thought about dynamic (boot-time) code re-writing as one possibility here, but it very quickly gets nasty. All of the optimised opcodes (MUL/DIV/Shift etc) are smaller than their emulated counterparts, so in principle we could re-write the text segment with the optimised opcode, then NOP pad, but that's still inefficient. As soon as we start talking about dynamic code relocation, re-writing relative offsets in loops, ... yuck.. We'd be putting half of mb-ld into the arch early boot code (or bootloader...) The opposite approach, to build with all instructions enabled and install exception handlers to deal with the fixups, is also pretty awful. I find myself asking the question - for what use cases does the current static approach used in MicroBlaze (with the PetaLinux BSP / Kconfig.auto) *not* work? One compromise approach might be to have a script in arch/microblaze/scripts, called by the arch Makefile, that cracks open the DT at build time and extracts appropriate cpu flags. Finally, what is the LKML position on DT files going into the kernel source tree? arch/powerpc is awash with .dts files in the kernel tree. It's a practice that is encouraged for most of the embedded boards. :-) However, for something like xilinx virtex ppc and microblaze it probably doesn't make much sense for anything other than the Xilinx reference design bitstreams. (at least in mainline) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Xilinx devicetrees
-Original Message- From: John Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 3:55 PM To: Stephen Neuendorffer Cc: David H. Lynch Jr.; linuxppc-embedded; Michal Simek Subject: Re: Xilinx devicetrees MicroBlaze is a highly configurable CPU in terms of its instruction set, features and so on. To make use of this, it is essential that each kernel image be compiled to match the CPU configuration. While a generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc) would run on any CPU, performance would be abysmal. I think the userspace is actually much more critical than the kernel for most of these things (with the exception of msrset/msrclr, and the barrel shifter perhaps). Unfortunately, even if you implement an alternatives-style mechanism for the kernel, you're still hosed for userspace. Once I a big enough system, it's just unfeasible to recompile everything anyway. I think this is where autoconfig starts to break down. In my view it's not acceptable to present these as options for the user to select at kernel config time. With N yes/no parameters, there is 1 correct configuration, and 2^N-1 incorrect ones. The odds of the user falling upon a configuration that at worst fails to boot, or at best is not optimally matched to the hardware, are high. Yes. Autoconfig does handle this in a fairly nice way. This same issue also applies to C libraries and apps - they must be compiled with prior knowledge of the CPU. This is why our microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg! Wrapping every mul, div, shift etc in a function call is clearly not feasible. Things like the msrset/msrclr ops have a modest but measurable impact on kernel code size and performance - it's just not reasonable to add any level of indirection in there. I have thought about dynamic (boot-time) code re-writing as one possibility here, but it very quickly gets nasty. All of the optimised opcodes (MUL/DIV/Shift etc) are smaller than their emulated counterparts, so in principle we could re-write the text segment with the optimised opcode, then NOP pad, but that's still inefficient. As soon as we start talking about dynamic code relocation, re-writing relative offsets in loops, ... yuck.. We'd be putting half of mb-ld into the arch early boot code (or bootloader...) The opposite approach, to build with all instructions enabled and install exception handlers to deal with the fixups, is also pretty awful. It's not nice, I agree. I think the key principle should be that I should be able to get a system working as quickly as possible, and I might optimize things later. One thing that device trees will allow is for *all* the drivers to get compiled in to the kernel, and only as a late stage operation does a designer need to start throwing things away. Using traps I can easily start with a 'kitchen sink' design, and start discarding processor features, relying on the traps. When I get low enough down on the performance curve, I can uas an autoconfig-type mechanism to regain a little of what I lost by optimizing away the trap overhead. Personally, I think the easiest way out of all this is to just have less configurability. For microblaze in general, this is too much of a restriction, but microblaze used as a control processor running linux, there are probably just a few design points that really make sense (probably size optimized: no options except maybe msrset/msrclr, and the kitchen sink). If we go that far, we don't really need people to ever run autoconfig, or kernels, or anything. Especially considering there is no easy way of selecting which of the 2^N design points I want *anyway*. :) I find myself asking the question - for what use cases does the current static approach used in MicroBlaze (with the PetaLinux BSP / Kconfig.auto) *not* work? One compromise approach might be to have a script in arch/microblaze/scripts, called by the arch Makefile, that cracks open the DT at build time and extracts appropriate cpu flags. Hmm... interesting idea, although parsing the source is likely difficult... It's probably not worth it to go this far, I think. As you say, why doesn't autoconfig of today work fine for this. Finally, what is the LKML position on DT files going into the kernel source tree? Source .dts go in and get compiled to binary blobs at compile time. The 'big' recent controversy is whether the source-binary compiler dtc should be mirrored in the Linux tree or not. Steve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Stephen Neuendorffer wrote: From: John Williams [mailto:[EMAIL PROTECTED] MicroBlaze is a highly configurable CPU in terms of its instruction set, features and so on. To make use of this, it is essential that each kernel image be compiled to match the CPU configuration. While a generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc) would run on any CPU, performance would be abysmal. I think the userspace is actually much more critical than the kernel for most of these things (with the exception of msrset/msrclr, and the barrel shifter perhaps). Unfortunately, even if you implement an alternatives-style mechanism for the kernel, you're still hosed for userspace. I haven't benchmarks each option on the kernel - you are right that shift is a big one, but mul I think is also important, given that every array access generates an integer multiply, Once I a big enough system, it's just unfeasible to recompile everything anyway. I think this is where autoconfig starts to break down. I'm not sure I agree, here, given that most people building MicroBlaze systems are doing so with uClinux-dist (or PetaLinux), you can do a full rebuilt, kernel libs apps, in a couple of minutes. Much shorter than sythnesis and PR, that's for sure (and runtime is linear in size, unlike PR :) It's not nice, I agree. I think the key principle should be that I should be able to get a system working as quickly as possible, and I might optimize things later. One thing that device trees will allow is for *all* the drivers to get compiled in to the kernel, and only as a late stage operation does a designer need to start throwing things away. Using traps I can easily start with a 'kitchen sink' design, and start discarding processor features, relying on the traps. When I get low enough down on the performance curve, I can uas an autoconfig-type mechanism to regain a little of what I lost by optimizing away the trap overhead. OK, but now we have a kernel dependent on *3* files - a DTS, a Kconfig.auto, and (indirectly) the bitstream itself. Personally, I think the easiest way out of all this is to just have less configurability. For microblaze in general, this is too much of a restriction, but microblaze used as a control processor running linux, there are probably just a few design points that really make sense (probably size optimized: no options except maybe msrset/msrclr, and the kitchen sink). If we go that far, we don't really need people to ever run autoconfig, or kernels, or anything. Especially considering there is no easy way of selecting which of the 2^N design points I want *anyway*. :) My experience tells me that if the microblaze can be configured in a particular way, *someone* will want to do it (and still boot linux on it!) We still have people building MicroBlaze 3.00 in Spartan2E, with EDK 6.3. And autoconfig works! Exceptions on/off, MMU on/off (runtime configurable on that?). Our ability to plug into the backend design database of EDK presents a great opportunity - truly automatically configured kernels. I think we have a responsibility to leverage that power.We are already there with the static approach, I think we just need to make sure that persists into the dynamic approach, and that we find a good mix of the two. There are of course some semantic issues that the EDK cannot automatically resolve - relative ordering and priority of multiple peripheral instances for example. One compromise approach might be to have a script in arch/microblaze/scripts, called by the arch Makefile, that cracks open the DT at build time and extracts appropriate cpu flags. Hmm... interesting idea, although parsing the source is likely difficult... It's probably not worth it to go this far, I think. As you say, why doesn't autoconfig of today work fine for this. Well, copying multiple configuration files into the kernel is not ideal. Surely a little perl or python script would do the trick? DTS syntax is pretty clean, just find the CPU node and off we go. Multiple CPU, well... :) Finally, what is the LKML position on DT files going into the kernel source tree? Source .dts go in and get compiled to binary blobs at compile time. The 'big' recent controversy is whether the source-binary compiler dtc should be mirrored in the Linux tree or not. OK. Another thing I suggested to Michal recently, perhaps we need kernel/lib/libof to store common OF / DT handling code. Much better than duplicating it accross microblaze and PPC, and maybe other arch's would also see the light.. That would also add a claim for the DTC to go in scripts/ John ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query [EMAIL PROTECTED] wrote:
Hi,
I am creating a simple program which will try to read the board ID of the
PPC440EPx thru BCSR but when I load it, it gives me Data Read PLB Error.
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
--
#include linux/module.h
#include linux/kernel.h
#include linux/ioport.h
#include linux/delay.h
#include linux/init.h
#include linux/interrupt.h
#include linux/platform_device.h
#include asm/irq.h
#include asm/io.h
#include linux/i2c.h
#include linux/i2c-id.h
#include asm/ocp.h
#include asm/ibm4xx.h
MODULE_LICENSE(GPL);
#define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk(1 Calling init function.\n);
printk(1 bcsrbase value %p...\n,bcsrbase);
printk(1 Remapping %x...\n,BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: The question about the high memory support on MPC8360?
Hi, The kernel also allows hardcoded mapping of IO regions into its virtual address space through the io_block_mapping interface. Can u tell me how this is in current arch/powerpc. Also does it mean that whatever be the size of the ram 768 MB there is not going to be much improvement in performance in kernel space irrespective of invoking CONFIG_HIGHMEM or not? Also do you think this low mem be enough if i have lots of kernel space processes each invoking lots of kmallocs. Will there be bottle necks?? Also what alternative do we have if low mem of 768 MB is not enough?? Scott Wood wrote: vijay baskar wrote: The kernel maps the last 1 GB of the virtual address space one to one to the physical memory. No, it maps 768MB of RAM in this manner. This is called the kernel space. After the one to one mapping is done for the available physical memory, the remaining virtual addresses are used for vmalloc and ioremap. And highmem mappings. The kernel also allows hardcoded mapping of IO regions into its virtual address space through the io_block_mapping interface. Not in current arch/powerpc kernels. Many boards use the block IO mapping to map the CCSRBAR/IMMR into the kernel address space, such that the physical address and the virutal address is the same. Virtual addresses beyond these hardcoded mappings cannot be used by vmalloc/ioremap. And this is why. Now as more and more memory is added to the system the addresses available for vmalloc and ioremap gets reduced, and memory allocations start to fail, due to the lack of availability of virtual addresses. How so? The size of lowmem is constant once you reach the threshold, as is the size of the highmem mapping area. What *does* start to fail eventually, if you have a *lot* of highmem, is that you run out of lowmem for pagetables and such. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
