Re: Merge linuxppc-embedded with linuxppc-dev
On Sep 22, 2008, at 11:53 PM, Wolfram Sang wrote: On Mon, Sep 22, 2008 at 06:34:37PM -0500, Kumar Gala wrote: Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? That's not really up to me - more of a community question I think. I imagine Paul would have the final decision though. I'm pretty sure I saw paul gripe about this on irc just the other day. My vote is to kill linuxppc-embedded. I also think one list will suffice nowadays. I also vote to kill the separate embedded list. It has such low traffic, and it seems like a lot of messages end up cross-posted to linuxppc-dev, anyway. Cheers, B ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: issue about CONFIG_PPC_MMU and CONFIG_SMP define
On Mar 10, 2008, at 3:15 PM, jie han wrote: Hi guys, I want to simulate compile mutli-core using sequoia(IBM/AMCC 44x processor) source code under kernel arch/powerpc directory.I want to define CONFIG_SMP, I sould define CONFIG_STD_MMU at first,but AMCC 44x don't need to config CONFIG_STD_MMU.Is CONFIG_STD_MMU just for freescale chip? How can I do next? Thanks ahead for your help, STD_MMU is for all powerpc cpus with a non-BookE MMU. That includes all the 64-bit parts from IBM to date, pasemi's parts, and 32-bit parts from IBM Freescale like the 6xx, 7xx, 7xxx, e600 e300, etc. You cannot set this for 44x, because it is a BookE part. BTW, there's no real relationship between STD_MMU and SMP. It was just a convenient way to restrict the SMP config option in the kernel, since all the Linux configs that currently support SMP are STD_MMU. We will have BookE configs in the future that do support SMP, at which point arch/powerpc/platforms/Kconfig.cputype will be changed to allow SMP to be set for those configs. You can't enable SMP on 44x right now. It's not supported. Cheers, B ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: System crash on boot_e500.S on 2.4Kernel
On Aug 15, 2007, at 8:59 AM, mike zheng wrote: I use BDI to debug these two instructions. And here are the output of BDI just before the rfi. The content of R6, R7 is different from SRR0(SPR26) and SRR1(SPR27). I see you have not printed the pc/nia once you stop. Are you sure you're stopped where you think? Please check this. -B cds8548res run - TARGET: processing user reset request - BDI asserts HRESET - Reset JTAG controller passed - JTAG exists check passed - IDCODE is 0x0003901D - SVR is 0x80390011 - PVR is 0x80210010 - CCSRBAR is 0x0_ff70 - BDI removes HRESET - TARGET: Target PVR is 0x80210010 - TARGET: resetting target passed cds8548halt Target CPU : MPC85xx (e500v2 rev.1) Target state : halted Debug entry cause : COP halt Current PC : 0xfff82560 Current CR : 0x8842 Current MSR : 0x00021200 Current LR : 0xfff8aa4c Current CCSRBAR : 0x0_e000 cds8548ci cds8548bi 0x015c Breakpoint identification is 0 cds8548go - TARGET: stopped cds8548rd GPR00: 0ffabd20 0200 0008 GPR04: 0001 0020 0160 GPR08: 1f8b0808 0148 0ffabace 0ffe08b0 GPR12: 0006 764deddb 1300 007fff00 GPR16: 0001 007fff25 09d8 GPR20: 007ffeb0 0fffaa3c 0ffae490 GPR24: 0003 0240 007fff25 GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0 CR : 24024022 MSR: 00021200 cds8548rdspr 26 SPR 26 : 0xfff81300 - 519424 cds8548rdspr 27 SPR 27 : 0x1000 4096 cds8548 On 8/14/07, Andy Fleming [EMAIL PROTECTED] wrote: On Aug 14, 2007, at 15:21, mike zheng wrote: Hi All, I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have problem in the head_e500.S. The mtspr SRR0, r7; mtspr SRR1 r6 does not work for me. The content of R7 and R6 are not moved to SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6 kernel. Any idea on this issue? Just to check...how do you know it doesn't work? Andy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: boottime kernel relocation, what I missed?
On Jul 13, 2007, at 5:07 PM, meerkat wrote: Figure that out, the bootstrap actually mapped the first 16M from C00 to the physicall address, so calling a c routine, as long as it is in the first 16M, is OK I think you're still not understanding the fact that bl is a *relative* branch - the branch target in the instruction encoding is just an offset from the current address, not an effective address. The bl should work correctly whether the code is actually running at the link address reported by nm (0xcxxx in this case), or if it has been loaded and executed elsewhere. Refer to the 32-bit Programming Environments Manual for PowerPC, or in the EREF (if you're using a BookE part - e500/e200) for more details. If you're just learning PowerPC assembler, you should really give this book a good thourough read. meerkat wrote: Good day all, For the first time I begin working on PPC, and on low level, and right start from boot sequence, one issue puzzled me. After bootstrap code (zImage) uncompressed the kernel vmLinux to physical memory (say from addr 0), it jumps to the kernel entry point, _start, using physically address. If you read the book specified above, you will see that branch instructions always specify an effective address, not a physical address. You can disable translation or map the address so EA=PA, but that's a different issue. -Becky ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: boottime kernel relocation, what I missed?
On Jul 16, 2007, at 2:36 PM, meerkat wrote: So are you saying linker does all the relative reference, that the bl foo is always relative even though the foo is defined in a different module? (In my case, bl call is made in head.S, early_init() is defined in another file setup.c). If you see bl foo, it's relative. It has to be, because that's how the instruction works. Also, it's not really in a different module, it's just a different file, but it's all linked into a single executable image. Cheers, -Becky Regards, Jim Becky Bruce wrote: On Jul 13, 2007, at 5:07 PM, meerkat wrote: Figure that out, the bootstrap actually mapped the first 16M from C00 to the physicall address, so calling a c routine, as long as it is in the first 16M, is OK I think you're still not understanding the fact that bl is a *relative* branch - the branch target in the instruction encoding is just an offset from the current address, not an effective address. The bl should work correctly whether the code is actually running at the link address reported by nm (0xcxxx in this case), or if it has been loaded and executed elsewhere. Refer to the 32-bit Programming Environments Manual for PowerPC, or in the EREF (if you're using a BookE part - e500/e200) for more details. If you're just learning PowerPC assembler, you should really give this book a good thourough read. meerkat wrote: Good day all, For the first time I begin working on PPC, and on low level, and right start from boot sequence, one issue puzzled me. After bootstrap code (zImage) uncompressed the kernel vmLinux to physical memory (say from addr 0), it jumps to the kernel entry point, _start, using physically address. If you read the book specified above, you will see that branch instructions always specify an effective address, not a physical address. You can disable translation or map the address so EA=PA, but that's a different issue. -Becky ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- View this message in context: http://www.nabble.com/boottime-kernel- relocation%2C-what-I-missed--tf4072673.html#a11629480 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 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: where can I find MPC8245 assembler reference?
MPC8245 refers to the integrated product (core + peripherals, all on one chip). The MPC8245 has a powerpc 603e core (also known as the G2). That's a classic 32-bit powerpc, so the assembler reference you want is: http://www.freescale.com/files/product/doc/MPCFPE32B.pdf Hope this helps, Becky On Sep 5, 2006, at 5:22 PM, Reeve Yang wrote: Could anyone point me to online document for MPC8245 assembler reference? I couldn't find it anywhere but the command list in user manual. Thanks! - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
where can I find MPC8245 assembler reference?
MPC8245 refers to the integrated product (core + peripherals, all on one chip). The MPC8245 has a powerpc 603e core (also known as the G2). That's a classic 32-bit powerpc, so the assembler reference you want is: http://www.freescale.com/files/product/doc/MPCFPE32B.pdf Hope this helps, Becky On Sep 5, 2006, at 5:22 PM, Reeve Yang wrote: Could anyone point me to online document for MPC8245 assembler reference? I couldn't find it anywhere but the command list in user manual. Thanks! - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC85xx u-boot definition
On Aug 28, 2006, at 8:54 PM, enorm wrote: Hi, Some naive questions about u-boot for MPC85xx, the definition of some macro in ppc_asm.tmpl. Can anyone there explain them to me please? 1) In GET_GOT(x) what does lwz r0,0b-1b(r14) ; do? what does 0b-1b stands for, or the meaning of the syntax? why move the content of the memory pointing by LR? 0b and 1b refer to the labels 0: and 1:. The b means find the first instance of that label backward from the reference point. #define GET_GOT\ bl 1f ; \ .text 2 ; \ 0: .long .LCTOC1-1f ; \ .text ; \ 1: mflrr14 ; \ lwz r0,0b-1b(r14) ; \ add r14,r0,r14 ; One thing to note when looking at this code that might be confusing: The .text 2 directive says that the code after it should be put in subsection 2 of the .text section. The default is 0 if this is not specified. When you build, this code is no longer sequential - the .text 2 stuff will end up somewhere in the executable *after* the normal .text. To illustrate, here's what you get if you compile just this code and dump it (I just #defined .LCTOC1 to be 0x1000 so it would compile): .text: 0: 48 00 00 05 bl 0x4 4: 7d c8 02 a6 mflrr14 label 1: points here 8: 80 0e 00 0c lwz r0,12(r14) c: 7d c0 72 14 add r14,r0,r14 10: 00 00 10 0c .long 0x100c label 0: points here And what it does, line by line: bl 0x4 /* LR now contains actual address we're running at */ mflrr14 /* copy LR into r14 so we can use it */ lwz r0,12(r14) /* Get the linker-generated value .LCTOC1-1f */ add r14,r0,r14 /* Correct that value for where we're really running */ The whole point here is to be somewhat position-independent - we're calculating where things are rather than using the linker-generated values because we don't necessarily want to assume we're loaded and running at the link address. 2) In START_GOT, any special meaning for the value 32768? .LCTOC1=.+32768 So, I don't have the code for this, but if I had to guess. That value is equivalent to 0x8000 hex. The GOT is usually accessed using a symbol that's in the middle of the GOT so you can use positive and negative indexes from that point to access data in the GOT. The max size of an immediate value in ppc asm is 16 bits. So this is the halfway point that gives you maximum access with a 16-bit immediate. 3) Syntax for GOT_ENTRY(NAME) and GOT(NAME), like. - .LCTOC1 (line 57) and .text 2 (line 50) could not find then in the GNU douments (ld, as, gcc, glibc etc). Most everything you need is in the gas manual at http://www.gnu.org/ software/binutils/manual/gas-2.9.1/html_mono/as.html. and in the C preprocessor documentation at http://gcc.gnu.org/onlinedocs/ gcc-2.95.3/cpp.html#SEC_Top. If you're really interested in understanding this stuff, you should probably also dig up and read the PowerPC Processor ABI Supplement document as well. Cheers, B
stupid linker question.... to remove unused functions in the object file.
I believe you can use -ffunction-sections -Wl,--gc-sections when you compile and link. If you have binutils prior to 2.16, this only works with -static. -B On Jul 24, 2006, at 7:07 AM, Parav Pandit wrote: Hi, I have few functions in a C file but those are not called at present. Even though those function definitions are part of the object file. Those will be called later on. What CFLAGS should I pass to remove unused functions? I cannot enable -Ox at present to have any unpredictable behaviour. Regards, Parav Pandit --- Wade Maxfield wmaxfield at gmail.com wrote: gcc -Wa,-alhs -g main.c main.cs will put interleaved code/assembly into main.cs file. wade On 7/21/06, Steve Iribarne (GMail) netstv at gmail.com wrote: I forgot the flag that generates a list file that has both assembly and c mixed in. Anyone? Thanks... -stv ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Setting ID cache enable in the same mtspr instruction
I think we need to hold off on this particular patch for a few days. I took a look at the manual section you're referencing here, and sure enough, it says that you shouldn't set both bits in the same mtspr instruction. The manual says this in more than one place, in fact. However, that seemed a little bit odd to me, so I talked with a few of the hardware designers for the 745x family. They assure me that the manual statement is false. The normal code that sets ICE/ICFI/ DCE/DCFI all on one mtspr should be fully functional on this processor family. I'm still working on confirming this and getting some history on *why* the manual says that, but for now I'd say it's a pretty good bet that the manual is in error. I will let you know if I find out this is not the case. You are correct, though, in that an isync is needed prior to the write of HID0[ICE]. It's probably missing because it's not listed in the synchronization table in chapter 2 of the manual. For what it's worth, as soon as I can confirm this, I will make sure the publications team here at Freescale is made aware of the error so it can be corrected in the next printing of the manual. I will also have the synchronization table updated as it also has incorrect information. Thanks, B
PPC exception 0x320
Jeanwelly, I'd really like to help you here, but you still haven't explained what you mean by PPC alarmed exception 0x320. Since there is no such exception that I'm aware of on the 750, I'm trying very hard to figure out what you mean, and it's impossible for me to do that without more information from you. I need to know exactly what it is that you're seeing in order to help you. If the kernel is printing out a message, please include the *entire message* in your email. Are you getting a message that says Bad trap at PC: .? A quick mini-tutorial on PPC exceptions: Whenever hardware detects an exception condition, the hardware starts executing at a vector location for that particular exception. On the PPC 750, these exception vectors are, for the most part, aligned at multiples of 0x100. There is a list of exception vectors and their associated causes in Table 4.2 of the User's manual (see below for a URL). Some exceptions are caused by software, and others, like the Decrementer Interrupt, are generated by the hardware itself. There is often more than one way to cause a particular exception. For example, a DSI exception can be caused by a miss in the hardware page table, or by a load to a direct-store segment, among other things. *All* of these events will result in running the exception vector starting at 0x300 because all of these conditions cause a DSI. Although there are multiple causes for DSI, they all go to the same vector address. The system software at that address must use methods described in the user's manual to determine what kind of DSI exception has occurred so it can handle the fault. While the hardware detects the exception, it is the job of the system software to handle it. The User's manual for a processor will list the events that hardware will detect and cause an exception. You have to look at your system software source code to figure out if your operating system supports a given exception. In Linux, this code is mostly in arch/ppc/head.S and arch/ppc/traps.c. You can get a copy of the 750 User's Manual at: http://www.freescale.com/files/32bit/doc/ref_manual/MPC750UM.pdf The exception information is in Chapter 4. Cheers, Becky On May 29, 2006, at 9:22 AM, jeanwelly wrote: Hi Becky Bruce, Sorry for late response. I got mail traffic... I encountered the exception 0x320 which caused the PPC card crash. Based on my understanding, I think exception is a HW behaviour, so I guess there maybe exist some reference on all the supported exceptions of some version of PPC. Do you know this? My system take that exception as an unknown exception and crash the card. So, I think the exception is from the PPC CPU, but don't the concrete meanings. Appreciate your suggestions. --- Jeanwelly Is there some error message you can show me? -B On Apr 25, 2006, at 10:03 AM, jeanwelly wrote: Hi Becky Bruce, I'm using PPC 750... Just as you said, 0x300 is for DSI, and I guess they are a set of exceptions, not just one. And 0x320 is one of them. I got a board crash, and PPC alarmed exception 0x320. Could you show me the mechanism of handling of a special exception not one set. === 2006-04-25 02:53:35 === Could you try to be more specific? What processor do you have, what linux version are you running, and what do you mean exactly when you say you encountered PPC exception 0x320? As far as I know, the powerpc architecture does not define an exception 0x320. 0x300 is usually DSI on classic powerpc parts. BookE parts handle things differently. Thanks, -Becky On Apr 24, 2006, at 8:51 AM, jeanwelly wrote: Hi, I encountered PPC exception 0x320, but don't know what it for. Any one could help me on this? Thanks! jeanwelly jeanwelly at 126.com ??2006-04-24 ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded . = = = = = = = = = = = = = = = = = = = = ? ?? jeanwelly jeanwelly at 126.com ??2006-04-25 . = = = = = = = = = = = = = = = = = = = = ? ?? jeanwelly jeanwelly at 126.com ??2006-05-29
PPC exception 0x320
Is there some error message you can show me? -B On Apr 25, 2006, at 10:03 AM, jeanwelly wrote: Hi Becky Bruce, I'm using PPC 750... Just as you said, 0x300 is for DSI, and I guess they are a set of exceptions, not just one. And 0x320 is one of them. I got a board crash, and PPC alarmed exception 0x320. Could you show me the mechanism of handling of a special exception not one set. === 2006-04-25 02:53:35 === Could you try to be more specific? What processor do you have, what linux version are you running, and what do you mean exactly when you say you encountered PPC exception 0x320? As far as I know, the powerpc architecture does not define an exception 0x320. 0x300 is usually DSI on classic powerpc parts. BookE parts handle things differently. Thanks, -Becky On Apr 24, 2006, at 8:51 AM, jeanwelly wrote: Hi, I encountered PPC exception 0x320, but don't know what it for. Any one could help me on this? Thanks! jeanwelly jeanwelly at 126.com ??2006-04-24 ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded . = = = = = = = = = = = = = = = = = = = = ? ?? jeanwelly jeanwelly at 126.com ??2006-04-25
PPC exception 0x320
Could you try to be more specific? What processor do you have, what linux version are you running, and what do you mean exactly when you say you encountered PPC exception 0x320? As far as I know, the powerpc architecture does not define an exception 0x320. 0x300 is usually DSI on classic powerpc parts. BookE parts handle things differently. Thanks, -Becky On Apr 24, 2006, at 8:51 AM, jeanwelly wrote: Hi, I encountered PPC exception 0x320, but don't know what it for. Any one could help me on this? Thanks! jeanwelly jeanwelly at 126.com ??2006-04-24 ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
about ppc asm/string.h
Hi! There's no string.h in include/asm-ppc because this is one of the header files that has been merged between 32 and 64-bit powerpc. It now lives in include/asm-powerpc with all the other merged headers. Only headers specific to 32-bit ppc have been left in include/asm- ppc. For a kernel build with ARCH=ppc, the build uses headers from both include/asm-ppc and include/asm-powerpc. This is accomplished through the use of a temporary include directory that is created in the arch dir. Check out arch/ppc/Makefile for details. Cheers, -Becky On Apr 17, 2006, at 2:08 AM, HappyPhot wrote: Hi, Under linux kernel, the file /include/linux/string.h will include asm/string.h. But I didn't found string.h under asm-ppc, my asm is link to asm-ppc (CPU is ppc). This makes me compile some code failed. (kernel version 2.6.x) Anybody knows about this ? Why there is no string.h under asm-ppc directory. thanks a lot, /Phot ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
cpu features testing 32 vs 64 bit
So,
in include/asm-ppc64/cacheflush.h is the following:
static inline void flush_icache_range(unsigned long start, unsigned
long stop)
{
if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
__flush_icache_range(start, stop);
}
On the 32-bit side, we don't need the feature test -
CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
in the upper 32.
There's a couple of ways to deal with merging this:
1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
test
2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
always fail for 32-bit.
I'd like to get some opinions on this. Do folks feel like the
performance hit of doing the compare is enough to justify going with
method 1? Should we be using likely/unlikely with the feature test?
This is just one code example - I suspect there will be others as we
continue the merge, and the importance of performance may differ
depending on where in the code we are.
Thanks!
-B
