Re: MPC8572 - IPR Register
On Dec 16, 2008, at 1:54 PM, Morrison, Tom wrote: We are having a problem with an external interrupt not actually being received / detected on the MPC8572. This external device 'believes' that it has sent an interrupt (over PCIe) to the MPC8572 and we believe that the associated ExVPR register has correctly unmasked/configured this correctly. But, still NO interrupt... If you read the documentation about this configuration register, it indicates that there is some type of IPR register internal to the 8572 that indicates if an interrupt has been received by the PIC... We want to read that IPR register to verify that: a) the external device has sent the interrupt and we have configured something wrong in the chip b) there is no pending interrupt (thus none received) from this external device... Is there any way (hook (indirection) or crook (aka: secret register)) that would allow us to read this register? From all my investigations it looks like there isn't a 'straight forward' / documented way to do so...I am hoping you guys have gone beyond the 'straight forward' means and have found a way... Thanks in Advance... 1. Which PCIe port is the device on? 2. is this a INT-X style or MSI interrupt? 3. if INT-X is INT-A, B, C, D? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: some (MPC8313) Freescale patches not in latest kernel
On Dec 10, 2008, at 8:00 AM, Norbert van Bolhuis wrote: I'm preparing the latest (2.6.28-rc7) linux kernel for an MPC8313 based project that's about to start. Things seems to work great with the base 2.6.28-rc7 kernel. On our MPC8313E-RDB the kernel boots without problems, ethernet (with eTSEC2/eth1) works and even eTSEC1/eth0 has a 1gbit link. Most other peripherals seems to work as well, I never really tried them though. However, the Freescale MPC8313 BSP (and http://www.bitshrine.org/ gpp/) includes a few patches which I believe I need and/or are useful, for instance: linux-fsl-2.6.23-MPC8313ERDB-ETSEC27-errata-workaround.patch linux-fsl-2.6.23-MPC8313ERDB-IEEE-1588.patch linux-fsl-2.6.23-GIANFAR_PARAMETER_ADJUST.patch linux-fsl-2.6.23-GIANFAR_SKB_BUFFER_RECYCLING_SUPPORT.patch linux-fsl-2.6.23-GIANFAR_SKB_BUFFER_RECYCLING_SUPPORT-2.patch These patches are not in the latest (2.6.28-rc7) linux kernel nor in any of the powerpc devlopment trees (e.g. git://git.kernel.org/pub/scm/linux/kernel/git/paulus/ powerpc.git) Of course users like me can simply check out the patches and apply them if needed for the project. Before I do that I would just like to understand why they're not in. They're not MPC8313(-RDB) specific and they seem very useful to me. Is it lack of time/importance ? Simply put the reason is that some of these patches have never been posted to the open source for acceptance into the kernel. I would suggest requesting that of Freescale through whatever sales contact you have. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [MPC8313ERDB] Remove duplicate DMA entry from device tree
On Oct 29, 2008, at 5:10 AM, Mike Dyer wrote: Signed-off-by: Mike Dyer [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc8313erdb.dts | 39 - 1 files changed, 0 insertions(+), 39 deletions(-) applied for 2.6.28 - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8313E RDB: Badness at fs/sysfs/dir.c:463
On Oct 14, 2008, at 9:12 AM, Mike Dyer wrote: Hi All, Apologies for the bad formatting of the previous message... I've just pulled the 2.6.27 kernel from git and am trying it out on my MPC8313E RDB dev kit. I get the following badness during boot (the complete boot record is attached later) : can you enable kernel symbols in your build (CONFIG_KALLSYMS) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New Patchwork beta
On Aug 21, 2008, at 5:52 PM, Josh Boyer wrote: On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote: Some feedback: * Can we increase the font size a bit? NOO. Just use CTRL-SHIFT-+. ok * For the list of patches can we change the background of every other line (light gray) That would work well. thanks this looks better, easier to read. * Parsing subject header for determining state -- [RFC] That is going to fail miserably because people tend to do silly things like post final patches in the middle of an [RFC] thread. gotcha. Now that I can log in, can I get maintainer privileges (user: galak) also is it possible to put the patch controls in a separate frame so they are always visible (dont have to scoll to the bottom to find them). - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New Patchwork beta
Some feedback: * Can we increase the font size a bit? * For the list of patches can we change the background of every other line (light gray) * Parsing subject header for determining state -- [RFC] w/o being able to log in that's my initial two cents. Both otherwise it looks good and seem much faster than the old version. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8313 ERDB has proper interrupt mapping for TSEC?
On Jul 14, 2008, at 7:14 AM, selvamuthukumar v wrote:
From, arch/powerpc/boot/dts/mpc8313erdb.dts,
212 enet0: [EMAIL PROTECTED] {
.
.
219 interrupts = 37 0x8 36 0x8 35 0x8;
.
.
222 };
223
224 enet1: [EMAIL PROTECTED] {
.
.
231 interrupts = 34 0x8 33 0x8 32 0x8;
.
234 };
235
But as per 8313 Reference manual interrups 32, 33, 34 are for
[EMAIL PROTECTED] and 35, 36, 37 are for [EMAIL PROTECTED] Any idea why
interrupt
numbers are swapped for enet0 and enet1?
I believe different revisions of the part had different mappings.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Rapidio interface in recent kernels
On Jun 25, 2008, at 11:33 PM, Alex Dubov wrote: Greetings. I was trying to make use of rapidio on recent (2.6.25) kernel (I have a 8548 cpu). However, it seems that changes to the powerpc arch had broken it. Therefore, the question: is there an anticipated fix or I'm on my own here? Is there a compile error? if so please post it. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip
Is the LSI chipset something you guys have on an add-on card (something we can put into a reference board) or is hard wired into your boards? If its an add on card a pointer to one would be appreciated. - k On Jun 25, 2008, at 5:20 PM, Siva Prasad wrote: I am also having problems with PCI-E device LSI 1064E on 2.6.24-rc6 kernel. This is running on 8641D processor. I can see the device, access the config space, but seems access from device to memory is not working. Same device (same exact hardware) works fine for 2.6.15 kernel. - Siva -Original Message- Date: Wed, 25 Jun 2008 10:30:35 -0500 From: Kumar Gala [EMAIL PROTECTED] Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SASchip To: Vince Asbridge [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes On Jun 24, 2008, at 10:51 AM, Vince Asbridge wrote: All, I'm new to this mailing list, but have not had any luck finding information on this issue. Please be kind if I break the forum rules on my first post. We recently tried to upgrade our Freescale CDS 8548 look-alike module (code name ATCA1000) from the 2.6.11 based BSP to the 2.6.23 based BSP. The upgrade went fairly smoothly, until we tried using SOME pci-e devices (some work fine, some don't show up to lspci). LSI pci-e controllers no longer show up at all! We see the ixgbe (intel 10G), SiliconImage SATA controller but do not see LSI devices (Specifically 1068 SAS, FC949-E fibrechannel). We're guessing it's a resource issue behind the bridge, because the LSI devices try to allocate 1 - 3M behind the bridge, but we can't find the bug, or where we would debug such an issue. The devices seem to train correctly, because we have an LED on the pci-e switch (PLX 8 port pci-e switch), and it's ON indicating pci-e link between the bridge and the 1068 device). We're totally at a loss as to why this always worked on the 2.6.11 kernel but doesn?t work on 2.6.23. Using lspci, the LSI adapters do not show up in the list at all, as though they are not plugged into the system. Is there something that needs to be done with respect to PCI-E devices that is new in the 2.6.23 based BSP that did not need to be done in the 2.6.11 based kit? For example, are pci resources allocated by a different piece of code, that may have some issue allocating resources for the LSI adapters? Can you tree 2.6.25? There are some fixes in that kernel related to PCIe support: [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx However, its odd that lspci doesn't even show the device. Are you using u-boot? if so what version? and does u-boot see the LSI? - k ___ 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: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip
On Jun 24, 2008, at 10:51 AM, Vince Asbridge wrote: All, I'm new to this mailing list, but have not had any luck finding information on this issue. Please be kind if I break the forum rules on my first post. We recently tried to upgrade our Freescale CDS 8548 look-alike module (code name ATCA1000) from the 2.6.11 based BSP to the 2.6.23 based BSP. The upgrade went fairly smoothly, until we tried using SOME pci-e devices (some work fine, some don't show up to lspci). LSI pci-e controllers no longer show up at all! We see the ixgbe (intel 10G), SiliconImage SATA controller but do not see LSI devices (Specifically 1068 SAS, FC949-E fibrechannel). We're guessing it's a resource issue behind the bridge, because the LSI devices try to allocate 1 - 3M behind the bridge, but we can't find the bug, or where we would debug such an issue. The devices seem to train correctly, because we have an LED on the pci-e switch (PLX 8 port pci-e switch), and it's ON indicating pci-e link between the bridge and the 1068 device). We're totally at a loss as to why this always worked on the 2.6.11 kernel but doesn’t work on 2.6.23. Using lspci, the LSI adapters do not show up in the list at all, as though they are not plugged into the system. Is there something that needs to be done with respect to PCI-E devices that is new in the 2.6.23 based BSP that did not need to be done in the 2.6.11 based kit? For example, are pci resources allocated by a different piece of code, that may have some issue allocating resources for the LSI adapters? Can you tree 2.6.25? There are some fixes in that kernel related to PCIe support: [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx However, its odd that lspci doesn't even show the device. Are you using u-boot? if so what version? and does u-boot see the LSI? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Graphic Card on Freescale MPC837x-rdb
On Jun 24, 2008, at 12:17 PM, Bizhan Gholikhamseh (bgholikh) wrote: HI all, Has anyone tried using a Graphic card on Freescale MPC837x-rdb board? If so I appreciate any hints and information that I can use. Nope, but you'll most likely need some form of x86 emulation for the video bios init. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D Msi
On Jun 16, 2008, at 10:16 AM, Marco Stornelli wrote: Hi, I've got a device connected with Pci-express to an mpc8641d_hpcn evaluation board (rev. 2.0) and I'm using the latest kernel. This device use MSI to generate an interrupt, but it seems possible that the only MSI that can be triggered through the standard PCI Express is interrupt 0. Is there a way to solve it? Some workaround or something like it? what exactly do you mean by using the latest kernel? The powerpc-next tree or 2.6.26? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Jun 12, 2008, at 6:45 AM, David Jander wrote:
Your commit message isn't exactly helpful as most people dont know
what LTIB is and its not terribly relevant. It just seems like you
are adding support for the FEC on MPC5121 and this point.
Signed-off-by: David Jander [EMAIL PROTECTED]
---
arch/powerpc/platforms/Kconfig |2 +-
drivers/net/fec.h | 43
drivers/net/fs_enet/Kconfig| 22 +-
drivers/net/fs_enet/fs_enet-main.c | 76 +++
+++--
drivers/net/fs_enet/fs_enet.h | 17 +---
drivers/net/fs_enet/mac-fec.c | 22 +-
drivers/net/fs_enet/mii-fec.c | 10 -
7 files changed, 167 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/
Kconfig
index 87454c5..a96937f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -288,7 +288,7 @@ config CPM2
config PPC_CPM_NEW_BINDING
bool
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
default y
config AXON_RAM
diff --git a/drivers/net/fec.h b/drivers/net/fec.h
index 292719d..5c9fe34 100644
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -59,6 +59,7 @@ typedef struct fec {
} fec_t;
#else
+#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
/*
* Define device register set address map.
@@ -97,6 +98,48 @@ typedef struct fec {
unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
} fec_t;
+#else /* CONFIG_FS_ENET_MPC5121_FEC */
+
+typedef struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+} fec_t;
+
+#endif /* CONFIG_FS_ENET_MPC5121_FEC */
#endif /* CONFIG_M5272 */
I'm not exactly clear as to why this was done this way but this not
acceptable as it means we can't build a multiplatform kernel that
needs this driver.
I'm also not clear to me if the MPC5121 FEC is really the same device
or close to it that it should be sharing this driver or have its own.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question about native compiling
On May 22, 2008, at 4:30 PM, [EMAIL PROTECTED] wrote: Hi all, I apologize if the list finds this off topic, but I'm at a loss of who to ask the question and thought this would be a good place to start. Our target is an MPC8347E PowerQUICC II Pro, and we're using the latest kernel (2.6.25). We started this project by building on x86 and doing cross-compiling to the powerpc target. As the project progressed and we started adding applications we found that we couldn't cross-compile postgress among other things. So we switched to native compilation on the target. Problem is, it's extreamly slow. Now our idea is to get our hands on a PowerPC based Mac, load it up with Ubuntu and do native builds on that. The question is, which Mac to get? The concern is this: a G5 is 64-bit but the 8347E is 32-bit. If we do our compiles on a G5 is it really a 'native' compile or is it a cross-compile and we're back in the same boat as we were with the x86? Should we use a G4 instead? Thanks for any advice or pointers to other places where I can find information. Do you plan on running the same Ubuntu install (for ppc32) on the 8347e? If not you'll need to be careful to ensure libraries, etc are the same or compatible. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help needed in debugging the crash of kernel stack overflow
On May 22, 2008, at 8:08 AM, sandeep malik wrote: Hi, We are using MSC7120 (e300 based) board running Montavista Linux 2.4. We are observing a random crash with the following dump: Kernel stack overflow in process c5b22000, r1=c5b22460 NIP: XER: 2000 LR: SP: C5B22460 REGS: c5b223b0 TRAP: 0400Tainted: P MSR: 20001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c5b22000[175] 'insmod' Last syscall: -1 last math last altivec GPR00: C5B22460 C5B22000 C5B22470 20001032 GPR08: F700 0008 0001 24224482 1033BB30 GPR16: 0001 1032 05B22460 GPR24: 0200 C7B09400 C016A240 C5B23D80 0010 C7B09400 Call backtrace: 70536574 34205220 5551 5551 494C450A 66363531 4F4E455F 35382054 38383053 20542056 43686563 53797353 35632052 70383830 74205670 0A636230 436D640A 38383053 24108028 C5C740C8 C00059AC Kernel panic: kernel stack overflow In interrupt handler - not syncing Any idea what might be going wrong or how to approach this problem as it is not getting reproduced and the behaviour is very random. Any pointers will be helpful. You really need to take these up with MontaVista. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Add the PC speaker only when requested so
On May 22, 2008, at 6:27 PM, Grant Likely wrote: On Thu, May 22, 2008 at 4:40 PM, Emil Medve [EMAIL PROTECTED] wrote: This will cause this minor boot-time debugging error message to go away: [1.316451] calling add_pcspkr+0x0/0x84 [1.316478] initcall add_pcspkr+0x0/0x84 returned -19 after 0 msecs What situation are you hitting this in? The code should only run if there is a pnpPNP,100 compatible node in the device tree. The code always runs, the -19 is from the fact that the code returns - ENODEV when it doesn't find the device in the tree. I don't see any reason we should be ALWAYS be probing for a PC speaker. Seems like a reasonable patch. Also, where is CONFIG_PCSPKR_PLATFORM defined? I don't see it anywhere in powerpc code and only a reference to it in an x86 Makefile. As it stands, it looks like this patch unconditionally disables the pcspkr code. Its defined in init/Kconfig. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: EABI
On Apr 24, 2008, at 11:13 AM, Brian Silverman wrote: Is it possible to compile a Linux application using an EABI compiler (specfically, Xilinx's EDK powerpc-eabi-gcc.exe)? The issue at hand is that we'd like for our customers to be able to use the Xilinx EDK toolchain (which we know they will have) to compile Linx apps without having to install another toolchain (crosstool, ELDK, etc). So, what I'm hoping is that the EDK toolchain can be configured to be Linux compatible binaries, or that there is some kind of wrapper that will handle the incompatible interfaces. Searching around, I've seen some mention of Linux EABI compatibility (for Debian ARM releases), but I haven't found any clear concensus... P.S. My apologies if this message appears on the mailing list twice... The EABI and Linux ABI are not compatible and if you want to link with any libraries you will need a different compiler for linux. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
removal of arch/ppc in 2.6.27?
This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. PPC_PREPe6xx PQ2ADS 82xxin arch/powerpc? TQM8260 82xx CPCI690 e6xx/mv64x60 EV64260 e6xx/mv64x60 CHESTNUTe6xx/mv64x60 LOPEC e6xx KATANA e6xx/mv64x60 HDPUe6xx/mv64x60 MVME5100e6xx PAL4e6xx POWERPMC250 e6xx PPLUS e6xx PRPMC750e6xx PRPMC800e6xx RADSTONE_PPC7D e6xx SANDPOINT e6xx SBC82xx 82xx SPRUCE e6xx LITE520052xx EV64360 e6xx/mv64x60 MPC86XADS 8xx in arch/powerpc MPC885ADS 8xx in arch/powerpc ADS8272 82xxin arch/powerpc 4xx: BAMBOO 44x in arch/powerpc CPCI405 40x EBONY 44x in arch/powerpc EP405 40x in arch/powerpc BUBINGA 40x LUAN44x YUCCA 44x OCOTEA 44x REDWOOD_5 40x REDWOOD_6 40x SYCAMORE40x TAISHAN 44x in arch/powerpc WALNUT 40x in arch/powerpc XILINX_ML30040x XILINX_ML40340x - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: io_block_mapping ioremap question
On Apr 15, 2008, at 11:25 AM, Gutson Daniel-ADG035 wrote: Hi, I'm doing some work on 2.6.10, and got this problem: - there are some io_block_mapping calls in the setup_io_mapping callback, that use the BATs, and passing same va and pa each one. Problem arises later when vmallocs gets a a pointer within the mapped ranges. In other words, seems like the VMM is not aware of the BATs mapping. So what I did is: called first ioremap and then io_block_mapping in the callback thus not hardcoding the va, something like: va = ioremap(pa, size); io_block_mapping(pa, va, size); Questions: 1) Is it right? 2) Should I unmap that address sometime later? (i.e. after mem_init_done). You should look at getting ride of your io_block_mapping calls as we've removed that in new kernels. However, ioremap() should work properly in that it should lookup the address you are mapping via p_mapped_by_bats(). - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
On Mar 14, 2008, at 6:01 PM, Sebastian Siewior wrote: This is a modified entry I found in the documentation for the 8544. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc8544ds.dts | 41 + + arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 + 2 files changed, 54 insertions(+), 0 deletions(-) applied. I also added updating the defconfig to enable the driver by default. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
On Apr 10, 2008, at 10:12 AM, Sebastian Siewior wrote: * Kumar Gala | 2008-04-10 09:46:39 [-0500]: This is a modified entry I found in the documentation for the 8544. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc8544ds.dts | 41 +++ ++ + arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 + 2 files changed, 54 insertions(+), 0 deletions(-) applied. Thank you. I also added updating the defconfig to enable the driver by default. I just noticed that commit 049c9d455 renamed the ids. I couldn't find this commit in your git tree. Did you rename the ids in the .dts file (or want me to do this)? I think they are already in sync am I missing something? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: TSEC3/4 broken on MPC8548?
On Apr 8, 2008, at 8:40 AM, Wolfgang Grandegger wrote: Hello, in the dts file for the MPC8548CDS the nodes for TSEC3/4 are commented out because they seem to be broken: $ grep broken arch/powerpc/boot/dts/* arch/powerpc/boot/dts/mpc8548cds.dts:/* eTSEC 3/4 are currently broken Is it still true? This was a board issue and not a chip issue. However I'm not sure if the board issues have been resolved. Hopefully Andy will know. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Fix a mm compile error
On Apr 2, 2008, at 6:05 PM, Emil Medve wrote: arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr' arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here Signed-off-by: Emil Medve [EMAIL PROTECTED] --- arch/powerpc/mm/init_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 555bb7e..63c5e3d 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM; * address of the limit of what is accessible with initial MMU setup - * 256MB usually, but only 16MB on 601. */ -unsigned long __initial_memory_limit_addr = 0x1000; +phys_addr_t __initial_memory_limit_addr = 0x1000; I should have fixed this in my tree, if there are still issues let me know. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express problem
On Mar 25, 2008, at 8:03 AM, Marco Stornelli wrote: Kumar Gala ha scritto: On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote: Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a machine check exception: transfer error ack signal 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. Where are you loading the FPGA microcode (linux, u-boot)? Also, is the FPGA the only device connected over PCIe? - k I load the FPGA with JTAG and with a Xilinx program without a specific linux driver or u-boot. Yes, it is the only device connected over PCIe. The issue may be related to the PCIe link training. Are you able to access the FPGA in u-boot? Can you try reseting the PCIe controller after you've loaded up the FPGA (see u-boot code in drivers/pci/ fsl_pci_init.c and look for CONFIG_FSL_PCIE_RESET) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express problem
On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote: Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a machine check exception: transfer error ack signal 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. Where are you loading the FPGA microcode (linux, u-boot)? Also, is the FPGA the only device connected over PCIe? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC/PATCH] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
On Mar 11, 2008, at 5:39 AM, Sebastian Siewior wrote:
The DT entry is copy / paste from the documentation.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8544ds.dts | 41 +
+
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 +
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/
dts/mpc8544ds.dts
index 688af9d..fdaf793 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -116,6 +116,47 @@
};
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8540-dma, fsl,eloplus-dma;
+ reg = 21300 4;
+ ranges = 0 21100 200;
+ cell-index = 0;
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8540-dma-channel,
+ fsl,eloplus-dma-channel;
this should be mpc8544-dma everywhere.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.25-rc3 on mpc8548amc doesn't boot
On Feb 28, 2008, at 2:31 AM, maxime louvel wrote: Hi, I have a question for submitting my changes: As I said I have commented a few line in arch/powerpc/boot/Makefile #$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405 #$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405 #$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405 #$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405 #$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=40 I guess that shouldn't be integrated in my patch, should I ? For what I have found on websearch that should come from my gcc version (3.4.3 with specific stuff). But still I needed that... I thought Josh published a patch to work around the toolchain issues people had. But yes, this shouldn't be part of the patch :) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.25-rc3 on mpc8548amc doesn't boot
On Feb 28, 2008, at 1:56 AM, maxime louvel wrote: Hi, I wanted first to check how the kernel is behaving, with a few tests. Then what is the best solution to do this ? A patch from the 2.6.25-rc3 vanilla kernel ? 2.6.25-rc3 is fine. The best solution is against my git-tree (git:// git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git). -k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.25-rc3 on mpc8548amc doesn't boot
On Feb 27, 2008, at 10:25 AM, maxime louvel wrote: Hi again, I am answering my self sorry for the spam... Just to say that my problem has been solve if someone has something similar... My changes were good, I just didn't compile the good file... Any plans to submit patches to add support for this board to the kernel? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.24 for mpc8458amc
On Feb 20, 2008, at 7:00 AM, maxime louvel wrote: Hi, yes It has something like 16550 UART. the compiler version is gcc-3.4.3 with some specific stuff for the platform. I also have a gcc-4.1.2 vanilla which has been compiled with the previous one. The 4.1.2 works if you tell it to emulate the floating point instructions. thanks Scott, without the treeboot-walnut it compiled I have still my first problem though: AMC= bootm 0x100 ## Booting image at 0100 ... Image Name: Linux-2.6.24 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1802038 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK and nothing else... Any idea ? This may become from the fact that the uboot installed on the cards is old and it apparently doesn't support the newer version of the kernel image... (I have got that from an another mailing list) Yes, you'll either need to look at updating u-boot and including support for the device tree in it or look at the cuImage wrappers in arch/powerpc/boot as a mechanism to boot a kernel w/an old fw. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express error
On Feb 20, 2008, at 10:13 AM, Marco Stornelli wrote: Kumar Gala wrote: Marco Stornelli wrote: No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it could help. What do you think about it? Do you think this problem could be not present in 2.6.24? I have no idea there, honestly. Sorry. As Jon said, try 2.6.24 and see if it has an issue, if so we can look at helping. if not, you know you need to back port the fixes. - k I've backported the PCI-Express code from 2.6.24 to 2.6.18, but it still doesn't work, I have the same problem (sigh), could you give me any suggestions? did 2.6.24 work for you or not? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.24 for mpc8458amc
On Feb 19, 2008, at 6:19 AM, [EMAIL PROTECTED] wrote: Hello Maxime, if your board is still running, although you can't see the messages that means you don't have any console. Try to set one (I think you can use a SCM of the CPM) in the kernel configuration (characters devices) or in the command line (console=). If you really have a mpc8548 than there is no CPM. It has 16550 style UARTs on it. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx immap_qe.h - SIR type def error?
On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
All Freescale,
Not sure if this is the place to post this, but I have run across
what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field
out with
upper 8 bits last night.
Thoughts?
I'm guessing it was done this way since they are just looked as base
offsets. Where in the UM do you see anything about them being 16-bit
quantities? (I'm really know little about this).
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Jan 31, 2008, at 4:54 PM, Mark A. Greer wrote: On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. /me's $0.02. this is where I poke you about the sandpoint port ;) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
git tree rebased
Now that all the changes I had in my tree are in Linus's tree I'm rebasing the master branch of my git tree to match linus. git.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git Anyone using my tree should do a git-pull -f. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Reminder: removal of arch/ppc
Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: PREP PQ2ADS TQM8260 CPCI690 EV64260 CHESTNUT LOPEC KATANA HDPU MVME5100 PAL4 POWERPMC250 PPLUS PRPMC750 PRPMC800 RADSTONE_PPC7D SANDPOINT SBC82xx SPRUCE LITE5200 EV64360 MPC86XADS MPC885ADS ADS8272 4xx: BAMBOO CPCI405 EBONY EP405 BUBINGA LUAN YUCCA OCOTEA REDWOOD_5 REDWOOD_6 SYCAMORE TAISHAN WALNUT XILINX_ML300 XILINX_ML403 - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CONFIG_PCI interaction with pata_platform driver on MPC834x board
On Jan 23, 2008, at 9:06 AM, Johns Daniel wrote: I am asking this question once more since my previous try -- right before the Christmas break -- did not elicit any responses! ;~) Without PCI support configured in the kernel, the CompactFlash card is discovered and configured by the kernel. With PCI support configured in the kernel, it fails to discover the CF card through the pata_platform driver. (Note that both PCI and CF work fine on this same board with the generic IDE driver!) There are only two differences that I notice between the two kernel setups that might be significant: 1.) The libata virq changes from 19 to 20. 2.) The isa_io_base changes from 0x0 to 0xfcfff000. Are either of these two changes significant? I am using the arch/powerpc kernel, version 2.6.20.21. The CF is wired directly to the local bus in True IDE mode. I have some debug info included in my previous message at: http://www.nabble.com/CONFIG_PCI-interaction-with-pata_platform-driver-on-MPC834x-board-tc14457502.html I suggest putting some prints in the driver to see if the addresses that are ioremap() are the same. then I'd track down if/where actual register read/writes are occurring and see if the same address is being used. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: framebuffer swap endianess
On Jan 23, 2008, at 1:39 AM, Roman Fietze wrote: Hello ANgelo, On Tuesday 22 January 2008 16:46:47 Angelo wrote: I have just create a framebuffer for an embedded system: - powerpc (little endian) with a GPU (big endian). Are you sure? Isn't it the other way around? we are sure. Linux only supports PPC in big endian mode. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPIC ISU
On Jan 18, 2008, at 12:44 PM, vb wrote: Kumar, thank you for your reply! On Jan 18, 2008 7:54 AM, Kumar Gala [EMAIL PROTECTED] wrote: What is it, at the very least - what does ISU stand for? I would really appreciate any hints, Interrupt service unit. I believe its an IBM concept. For 8245 can you look at what the linkstation port is doing and mimic that. I believe its an 8245 or 8241 so it should be close to what you need. what platform is linkstation and what kernel version can I find it in? arch/powerpc/platforms/embedded6xx/linkstation.c you should be able to find it 2.6.23 or newer. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux with e500 v2 core, can we support Ram base address starting at 0x1_0000_0000
On Jan 15, 2008, at 2:16 PM, Subbu Linux wrote: Hi I am currently working on MPC8548 core, would like to know wheather current Linux with e500v2 core supporting Physical Address of RAM at 0x1__, I know in current linux with large Page table support we can access devices at 0x1__ for e500v2, but I wanted to move RAM base address to 0x1__, so that I can support larger RAM. Can any body suggest me if their is any patch available for this or is it possible to implement from scratch. The HW supports this. I don't believe there is any code that exists today that sets this all up. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPIC ISU
On Jan 16, 2008, at 12:03 AM, vb wrote: Greetings, I am trying to write a BSP for an 8245 based device. One thing which really gets me puzzled is the 'ISU' facility in arch/powerpc/sysdev/mpic.c, there is also a notion of ISU-less platforms, etc. I looked through the chip's programmer's reference, even read the original AMD/Cypress OpenPIC specification - not a clue. What is it, at the very least - what does ISU stand for? I would really appreciate any hints, Interrupt service unit. I believe its an IBM concept. For 8245 can you look at what the linkstation port is doing and mimic that. I believe its an 8245 or 8241 so it should be close to what you need. mpic = mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC_WANTS_RESET, 4, 32, EPIC ); BUG_ON(mpic == NULL); /* PCI IRQs */ mpic_assign_isu(mpic, 0, paddr + 0x10200); /* I2C */ mpic_assign_isu(mpic, 1, paddr + 0x11000); /* ttyS0, ttyS1 */ mpic_assign_isu(mpic, 2, paddr + 0x11100); mpic_init(mpic); - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: A file of 5 MB on tmpfs file system uses 5 MB of RAM or more?
On Jan 18, 2008, at 7:15 AM, DI BACCO ANTONIO - technolabs wrote: I have a linux-2.6.19.2 board with an MPC880 with 16MB ram and 16 MB flash. Normally I have 9-10 MB of free RAM. If I allocate 5 MB of ram memory, the system continues to work normally, but if, instead of allocating 5 MB directly, I fill the / tmp directory (that has a tmpfs file system) with a 5MB file the system becomes slow and after some minutes the oom_killer is invoked. Before it dies I had the time to see that mtdblockd is taking a lot of CPU (20%), what could be the problem? Posting any output from OOM, etc would be useful. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Toolchain for Freescale e200
On Jan 9, 2008, at 3:47 AM, Per-Erik Johansson wrote: Hi I need a new toolchain since my old one hasn't got support for the (as) -me200 and book-e stuff I need to compile a kernel for the e200 core. What flags do I specify to get what I need? --target=powerpc-e200-linux-gnu --with-cpu=?? --enable-threads=posix --enable-languages=c,c++ --with-gnu-as --with-gnu-ld And should I use a particular version of gcc, binutils..? I'm not that familiar with building cross-toolchains, have tried with tools like crosstool and buildroot but cant seem to get it to build what I need. From what I understand the e200 and e500 are code compatible so maybe I could a toolchain for e500 instead, --with-cpu=8540? Any help is much appreciated! if you aren't using VLE than an e500 toolchain should be sufficient. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device tree and /proc/iomem question
On Nov 26, 2007, at 12:26 PM, robert lazarski wrote:
Hi all, I'm using a recent pull of the paulus tree 2.6.24RC2 on my
custom 85xx board. I'm trying to test my PCI1, PCI2 and PCIe . My
device tree for PCI is:
[EMAIL PROTECTED] {
compatible = fsl,mpc8540-pci;
device_type = pci;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 mpic 2 1
8800 0 0 2 mpic 3 1
8800 0 0 3 mpic 4 1
8800 0 0 4 mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 mpic 3 1
9000 0 0 2 mpic 4 1
9000 0 0 3 mpic 2 1
9000 0 0 4 mpic 1 1;
interrupt-parent = mpic;
interrupts = 18 2;
bus-range = 0 ff;
ranges = 0200 0 8000 8000 0 2000
0100 0 e200 0 0010;
clock-frequency = 3f940aa;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 8000 1000;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8540-pci;
device_type = pci;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 mpic 2 1
8800 0 0 2 mpic 3 1
8800 0 0 3 mpic 4 1
8800 0 0 4 mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 mpic 3 1
9000 0 0 2 mpic 4 1
9000 0 0 3 mpic 2 1
9000 0 0 4 mpic 1 1;
interrupt-parent = mpic;
interrupts = 18 2;
bus-range = 0 ff;
ranges = 0200 0 c000 c000 0 2000
0100 0 e280 0 0010;
clock-frequency = 3f940aa;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = c000 1000;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8548-pcie;
device_type = pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = a000 1000;
bus-range = 0 ff;
ranges = 0200 0 a000 a000 0 2000
0100 0 e300 0 0010;
clock-frequency = 1fca055;
interrupt-parent = mpic;
interrupts = 19 2;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x0 */
0 0 1 mpic 0 1
0 0 2 mpic 1 1
0 0 3 mpic 2 1
0 0 4 mpic 3 1
;
};
Take a look at the device trees in the kernel source. You'll see we
moved PCI around so its at the root level. Not sure if that's your
issue.
I see all the above in /proc/device-tree/[EMAIL PROTECTED] when booting
the kernel. I double checked my memory mapping in u-boot and it
appears to match my device tree. Yet I don't see any pci here:
root:~ cat /proc/iomem
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0024000-e0024fff : ethernet
e0024520-e002453f : mdio
e0025000-e0025fff : ethernet
e0026000-e0026fff : ethernet
e0027000-e0027fff : ethernet
cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
and all I see from dmesg is PCI: Probing PCI hardware . Any ideas?
It seems like its not even really probing or finding the buses.
Can you post what your board/platform code looks like?
- k
___
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: 85xx software reset problems from paulus.git
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? ACK. Exactly the same over here (mpc8540ads compatible). I added the global-utilities today as well, but reboot fails. if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer). Why is the guts stuff missing i.e. in most of the shipped mpc85xx*.dts? Does it depend on some hardware connections external to the CPU? Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we use to reset. (8540, 8560, 8541, 8555 do not). - k ___ 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 16, 2007, at 4:01 PM, robert lazarski wrote:
On Nov 16, 2007 4:46 PM, Kumar Gala [EMAIL PROTECTED] wrote:
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
On Nov 16, 2007 3:44 PM, robert lazarski [EMAIL PROTECTED]
wrote:
On Nov 16, 2007 10:27 AM, Clemens Koller
[EMAIL PROTECTED] wrote:
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core (RTFM)
That's what we are doing. The 85xx docs say Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500
core
is not configured to process machine check interrupts, the
assertion
of SRESET causes a core checkstop. SRESET need not be asserted
during
a hard reset.
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
1. do you have the following in your dts:
[EMAIL PROTECTED] {//global utilities reg
compatible = fsl,mpc8548-guts;
reg = e 1000;
fsl,has-rstcr;
};
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Nov 15, 2007, at 11:35 PM, Benjamin Herrenschmidt wrote: On Thu, 2007-11-15 at 22:37 -0600, Kumar Gala wrote: PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device :00:12.0 PCI: Cannot allocate resource region 1 of device :00:12.0 PCI: Cannot allocate resource region 2 of device :00:12.0 PCI: Cannot allocate resource region 3 of device :00:12.0 PCI: Cannot allocate resource region 4 of device :00:12.0 PCI: Cannot allocate resource region 0 of device :00:14.0 PCI: Cannot allocate resource region 2 of device :00:14.0 this isn't really an error. Its more of a warning, the kernel will try and allocate these later and I'm guessing based on what you are seeing it succeeded. Benh, can we possibly change these messages in pci_32.c? Heh, well, I've been working on 44x PCI lately and got annoyed by the exact same messages, though I'm still pondering what would be a better replacement. Well, for one the generic pci code will complain if its not able to allocate the resource which is the true failure. I'm thinking maybe we just make these pr_debug() instead of standard printk? - k ___ 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 16, 2007, at 3:28 PM, robert lazarski wrote: On Nov 16, 2007 3:44 PM, robert lazarski [EMAIL PROTECTED] wrote: On Nov 16, 2007 10:27 AM, Clemens Koller [EMAIL PROTECTED] wrote: The SRESET# (pin AF20) is the soft reset input, causes an mcp assertion to the core (RTFM) That's what we are doing. The 85xx docs say Soft reset. Causes a machine check interrupt to the e500 core. Note that if the e500 core is not configured to process machine check interrupts, the assertion of SRESET causes a core checkstop. SRESET need not be asserted during a hard reset. Sorry for replying to myself, but thought I'd mention SRESET works fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It doesn't work for me on 2.6.24rc2 . What actual 85xx are you using? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Nov 16, 2007, at 3:09 PM, Benjamin Herrenschmidt wrote: On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote: Well, for one the generic pci code will complain if its not able to allocate the resource which is the true failure. I'm thinking maybe we just make these pr_debug() instead of standard printk? I was thinking about changing the message to cannot allocate initial resource, will reallocate or something like that. That is, make it clear it's non fatal. Yeah, something that on those lines would be good, and maybe mark them KERN_WARNING instead of KERN_ERR. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Nov 15, 2007, at 11:20 AM, Clemens Koller wrote: Hi there! I try to use the latest Linux-2.6.24-rc2-ge6a5c27f from paulus.git for my mpc8540ads compatible board. $ dmesg contains some nasty messages, which look like something is wrong. PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device :00:12.0 PCI: Cannot allocate resource region 1 of device :00:12.0 PCI: Cannot allocate resource region 2 of device :00:12.0 PCI: Cannot allocate resource region 3 of device :00:12.0 PCI: Cannot allocate resource region 4 of device :00:12.0 PCI: Cannot allocate resource region 0 of device :00:14.0 PCI: Cannot allocate resource region 2 of device :00:14.0 this isn't really an error. Its more of a warning, the kernel will try and allocate these later and I'm guessing based on what you are seeing it succeeded. Benh, can we possibly change these messages in pci_32.c? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
On Oct 3, 2007, at 2:34 PM, Rune Torgersen wrote: From: Dale Farnsworth The CONFIG_FSL_BOOKE mmu setup code fails when CONFIG_HIGHMEM=y and the 3 fixed TLB entries cannot exactly map the lowmem size. Each TLB entry can map 4MB, 16MB, 64MB or 256MB, so the failure is observed when the kernel lowmem size is not equal to the sum of up to 3 of those values. Does this mean you cannot run 1G of lowmem on a 85xx? On 82xx I run 1G of lowmem, and when we finaly upgrade our product to a 85xx something, Iw was planning on doing the same. The code would have to change to allow for 1G of lowmem. Max lowmem with KERNELBASE @ 0xc000_ is 768M. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
On Oct 3, 2007, at 4:45 PM, Rune Torgersen wrote: From: Kumar Gala The code would have to change to allow for 1G of lowmem. Max lowmem with KERNELBASE @ 0xc000_ is 768M. Which is why I asked. On 82xx it is supported without a codechange by setting KERNELBASE to 0xa000_ in Kconfig menu (and also changing start of virtual mem, also done by config option). we could make this work. Its just no one's griped about needing it to date. Its a bit of testing to make sure we respect the kernel config changes and a slight be of code to handle using up to 1G TLB sizes on e500v2 or greater. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
Begin forwarded message: From: Jochen Friedrich [EMAIL PROTECTED] Date: September 24, 2007 12:15:35 PM CDT To: linuxppc-embedded@ozlabs.org Cc: [EMAIL PROTECTED], Marcelo Tosatti [EMAIL PROTECTED] Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver Jeff, Please pick up for 2.6.23 if you don't mind. - k Add #include asm/cacheflush.h for flush_dcache_range to make the driver compile again. CC arch/ppc/8xx_io/enet.o arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit': arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function 'flush_dcache_range' make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1 make: *** [arch/ppc/8xx_io] Error 2 Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/ppc/8xx_io/enet.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c index 703d47e..eace3bc 100644 --- a/arch/ppc/8xx_io/enet.c +++ b/arch/ppc/8xx_io/enet.c @@ -44,6 +44,7 @@ #include asm/mpc8xx.h #include asm/uaccess.h #include asm/commproc.h +#include asm/cacheflush.h /* * Theory of Operation ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: really old glibc on 8xx or 403 with bleeding-edge kernel - anyone care?
On Sep 26, 2007, at 6:25 PM, Paul Mackerras wrote: Since about May 2001, we have put two AT_IGNOREPPC entries at the beginning of the ELF auxiliary vector. The reason for this is that glibc prior to April 2001 rounded up the address of the base of the aux vector to a multiple of 16. I think we can now get rid of the AT_IGNOREPPC entries. Well, in fact what old glibc did was a little more complex than that. It worked out the standard aux vector base (i.e. the address of the word after the end of the environment pointers), and then chose either that or that address rounded up to a multiple of 16 bytes. The way it chose was by checking the word at the rounded address - if it was more than 16 it used the standard base address, otherwise it used the rounded address. So the way the AT_IGNOREPPC hack worked was by putting 4 words (two aux vector entries) at the beginning of the aux vector that all contained the value 22 (AT_IGNOREPPC). That made the old glibc code choose the standard aux vector base address. However, what comes after that is an AT_DCACHEBSIZE (19) entry and an AT_ICACHEBSIZE (20) entry. Thus, as long as the data cache blocksize and the instruction cache blocksize are greater than 16, these two entries will serve just as well as the AT_IGNOREPPC entries at making old glibc choose the standard aux vector base address. The only CPUs that we support with cache line sizes of 16 bytes or less are the 8xx family and the 403 family. So my question is, does anyone care about running ancient userland binaries (from 2001 or earlier) on 8xx or 403 with future kernels (2.6.x for x = 24)? If not then we can remove the AT_IGNOREPPC aux vector entries. What's the benefit to removing them? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Sep 27, 2007, at 2:53 PM, Mark A. Greer wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I'm all for it, but we should see about killing linuxppc-embedded and just move everyone to linuxppc-dev. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Sep 27, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote:
From: Joe D'Abbraccio [EMAIL PROTECTED]
The MPC837x RDB is a new member of the Freescale MPC83xx reference
design
boards.
Signed-off-by: Joe D'Abbraccio [EMAIL PROTECTED]
Please base your patch against an external tree (like my for-2.6.24
branch).
See comments inline.
- k
---
arch/powerpc/boot/dts/mpc8377_rdb.dts | 306 ++
arch/powerpc/boot/dts/mpc8378_rdb.dts | 286 +
arch/powerpc/boot/dts/mpc8379_rdb.dts | 281 +
arch/powerpc/configs/mpc837x_rdb_defconfig | 886 +
+++
arch/powerpc/platforms/83xx/Kconfig|8 +-
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 102
7 files changed, 1869 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8377_rdb.dts
create mode 100644 arch/powerpc/boot/dts/mpc8378_rdb.dts
create mode 100644 arch/powerpc/boot/dts/mpc8379_rdb.dts
create mode 100644 arch/powerpc/configs/mpc837x_rdb_defconfig
create mode 100644 arch/powerpc/platforms/83xx/mpc837x_rdb.c
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/
boot/dts/mpc8377_rdb.dts
new file mode 100644
index 000..1ee2a06
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -0,0 +1,306 @@
+/*
+ * MPC8377E RDB Device Tree Source
+ *
+ * Copyright 2005, 2006, 2007 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/ {
+ model = fsl,mpc8377erdb;
+ compatible = fsl,mpc8377erdb,fsl,mpc837xrdb;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 20;
+ i-cache-line-size = 20;
+ d-cache-size = 8000; // L1, 32K
+ i-cache-size = 8000; // L1, 32K
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 1000; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 e000 0010;
+ reg = e000 0200;
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = watchdog;
+ compatible = mpc83xx_wdt;
+ reg = 200 100;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = i2c;
+ compatible = fsl-i2c;
+ reg = 3000 100;
+ interrupts = e 8;
+ interrupt-parent = ipic ;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = i2c;
+ compatible = fsl-i2c;
+ reg = 3100 100;
+ interrupts = f 8;
+ interrupt-parent = ipic ;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = spi;
+ compatible = mpc83xx_spi;
+ reg = 7000 1000;
+ interrupts = 10 8;
+ interrupt-parent = ipic ;
+ mode = 0;
+ };
+
+ /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
+ [EMAIL PROTECTED] {
+ device_type = usb;
+ compatible = fsl-usb2-dr;
+ reg = 23000 1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupt-parent = ipic ;
+ interrupts = 26 8;
+ phy_type = utmi_wide;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = mdio;
+ compatible = gianfar;
+ reg = 24520 20;
+ #address-cells = 1;
+ #size-cells = 0;
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = ipic ;
+ interrupts = 11 8;
+ reg = 2;
+ device_type = ethernet-phy;
+ };
+
Re: [PATCH] adds support for Micrel KS8721BL PHY
On Sep 14, 2007, at 4:25 AM, Sergej Stepanov wrote: The patch adds the support for Micrel KS8721BL PHY Signed-off-by: Sergej Stepanov [EMAIL PROTECTED] -- Such patches should be sent to the netdev list. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote: On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote: cpm2_clk_setup() supports setting FCC clocks only, even though the cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock support. Any chance this patch (and its 2/2 brother) could be committed ? Have you looked at Scott Wood's cleanup patches. They seem to do some of this. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Patches for 2.6.24 ??
Guys, If you have things you want or think should go into 2.6.24 please speak up now! - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 7448 pll registers
On Sep 5, 2007, at 4:24 PM, Leisner, Martin wrote:
I'm going to get DFS into the 7448 (it looks like I'm going to take a
different
tactic then I see in 2.6.20.16 -- it hinges on powermac, and I don't
know if it
even compiles).
In include/asm-powerpc, its missing definitions for HID1/{PC4,PC5}.
bash2 :2 [EMAIL PROTECTED] 05:18:58; rcsdiff -u reg.h
===
RCS file: reg.h,v
retrieving revision 1.1
diff -u -r1.1 reg.h
--- reg.h 2007/09/05 20:45:36 1.1
+++ reg.h 2007/09/05 20:46:56
@@ -253,6 +253,8 @@
#define HID1_PC1 (115) /* 7450 PLL_CFG[1] */
#define HID1_PC2 (114) /* 7450 PLL_CFG[2] */
#define HID1_PC3 (113) /* 7450 PLL_CFG[3] */
+#define HID1_PC4 (112) /* PLL_CFG[4] */
7455 for PLL_CFG[4]
+#define HID1_PC5 (117) /* 7448 specific bit --
PLL_CFG[5] */
#define HID1_SYNCBE(111) /* 7450 ABE for sync, eieio */
#define HID1_ABE (110) /* 7450 Address Broadcast
Enable
*/
#define HID1_PS(116) /* 750FX PLL selection
*/
PC4 seems generic, PC5 is a MPC7448 specific bit
I'm not sure what HID1_PS means ( 750FX PLL selection ), its the same
bit as
HID1_PC0.
Do you want this patch in the kernel? If so we'll need a signed-off-by.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Fix CPM1 uart console
On Aug 29, 2007, at 12:04 PM, Jochen Friedrich wrote:
The powerpc version of commproc.c doesn't export cpm_dpram_phys due to
a typo. The ppc version of cpm_dpram_addr returns a usable virtual
address
mapped to a physical address at the same location. cpm_dpram_phys
returns
complete garbage as it tries to calculate an offset based on an
otherwise
unused virtual adress returned by ioremap.
This patch fixes the typo for powerpc and removes the unnecessary
ioremap
and corresponding virtual address for ppc.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/sysdev/commproc.c |2 +-
arch/ppc/8xx_io/commproc.c |4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/
commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..593b939 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -379,14 +379,12 @@ static rh_block_t cpm_boot_dpmem_rh_block[16];
static rh_info_t cpm_dpmem_info;
#define CPM_DPMEM_ALIGNMENT 8
-static u8* dpram_vbase;
static uint dpram_pbase;
void m8xx_cpm_dpinit(void)
{
spin_lock_init(cpm_dpmem_lock);
- dpram_vbase = immr_map_size(im_cpm.cp_dpmem, CPM_DATAONLY_BASE +
CPM_DATAONLY_SIZE);
dpram_pbase = (uint)((immap_t *)IMAP_ADDR)-im_cpm.cp_dpmem;
/* Initialize the info header */
@@ -465,6 +463,6 @@ EXPORT_SYMBOL(cpm_dpram_addr);
uint cpm_dpram_phys(u8* addr)
{
- return (dpram_pbase + (uint)(addr - dpram_vbase));
+ return (uint)addr;
this doesn't seem quite right.
}
EXPORT_SYMBOL(cpm_dpram_phys);
___
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: PCI:cannot allocate resource region 0 of device 0001:01:00.0?
On Sep 3, 2007, at 8:45 AM, dnl wrote: Hi all, I using Montavista kernel for custom MPC8555CDS board and one PCI slot on the Board. When my kernel boots i am getting the following Messages : PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device 0001:01:00.0 PCI: Cannot allocate resource region 1 of device 0001:01:00.0 PCI: Failed to allocate mem resource #1:[EMAIL PROTECTED] for 0001:01:00. please find attached Kernel boot messages and corresponding pci directory after kernel boots. could anyone face similar problem? You'll need to take up MV kernel issues up with MV. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppc/powerpc, remote debugging (ptrace), floating point variables
On Aug 28, 2007, at 4:40 AM, Visser, Udo RD-IS-E23 wrote: Hello world, ;-) when stepping through my own software, which is using floating point variables, gdb showed weird results (mostly NAN´s) for these variables. Running the software without gdb did not show any problems. The software is compiled with floating point instructions and the results (without gdb) are OK. My setup: MPC8349 target, home grown, much like the MPC8349EMDS, running 2.6.16 (ppc) GDB, gdbserver 6.3 connected via ethernet with my Linux Host. What I did to get rid of the described problem: In module: arch/powerpc/kernel/process.c In function: void flush_fp_to_thread(struct tast_struct *tsk) I changed the line: giveup_fpu(current); to: giveup_fpu(tsk); Now my questions: Has anybody else had such problems? Have I found a bug, or will I encounter any yet unknown problems in the near future? I would appreciate any comment on my changes, especially from the maintainers. I have a patch to fix just this issue. take a look at: http://patchwork.ozlabs.org/linuxppc/patch?id=13219 - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
On Aug 28, 2007, at 6:20 AM, Jochen Friedrich wrote: Instantiation of 8MB pages on the TLB cache for the kernel static mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations. This ensures r3 gets saved and restored. This has been posted to linuxppc-embedded by Marcelo Tosatti [EMAIL PROTECTED], but only an incomplete version of the patch has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4. This patch adds the rest of the fix. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/ppc/kernel/head_8xx.S |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) This can be pulled from git://git.bocc.de/dbox2.git ppc-fixes diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index 944c35c..eb8d26f 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -495,9 +495,7 @@ LoadLargeDTLB: lwz r11, 4(r0) lwz r12, 16(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is the data TLB error on the MPC8xx. This could be due to do we need this in arch/powerpc as well? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote: Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman [EMAIL PROTECTED] --- Please ignore the last patch - I missed a cut paste error on the range that my testing didn't catch. I think we'd rather this came from the device tree. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
On Aug 9, 2007, at 1:54 PM, Grant Likely wrote: On 8/6/07, Arnd Bergmann [EMAIL PROTECTED] wrote: On Tuesday 07 August 2007, Wolfgang Reissnegger wrote: Make support for Xilinx boards more generic, making it easier to add new boards. Add initial support for xupv2p and ml410 boards. I really think we shouldn't add stuff to arch/ppc at this point, it has been deprecated for over two years now. Naahh, this is pretty benign stuff. I say let it go in. :-) These changes are low risk and they don't hurt anything. If Virtex support worked in arch/powerpc then I'd agree, but for now it allows us to keep the virtex device driver support somewhat current. We've clearly stated for a while that only bug fixes should be going into arch/ppc. This looks like new board support. Also, be aware that arch/ppc is going away in Jun 2008. :) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux PPC 8555--TSec initialisation
On Aug 7, 2007, at 1:51 AM, Shashikumar wrote: Hi, I am using PPC8555. I need to initialize TSEC. Can anybody help me How to initialize TSEC on chip of ppc8555. Thanks in advance It should be initialized by the driver in drivers/net/gianfar* - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reboot Command Makes kernel to hang (MPC8560)
On Aug 2, 2007, at 1:48 AM, Ansari wrote: Hi Koller Kumar Thanks for ur reply. Is there a way to reset the full chip (MPC8560) whenever core reset occurs (using hardware or software) ?? what do you mean by core reset? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add support for Wind River SBC8641D board
On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
Add support for Wind River's SBC8641D reference board.
Is this a single core or dual core chip?
Signed-off by: Joe Hamman [EMAIL PROTECTED]
diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
--- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts 1969-12-31
18:00:00.0 -0600
+++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts 2007-07-31
13:15:15.0 -0500
@@ -0,0 +1,160 @@
+/*
+ * SBC8641D Device Tree Source
+ *
+ * Copyright 2007 Embedded Specialties, Inc.
+ * Joe Hamman [EMAIL PROTECTED]
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+
+/ {
+ model = SBC8641D;
+ compatible = mpc86xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 20; // 32 bytes
+ i-cache-line-size = 20; // 32 bytes
+ d-cache-size = 8000; // L1, 32K
+ i-cache-size = 8000; // L1, 32K
+ timebase-frequency = 0; // 33 MHz, from uboot
+ bus-frequency = 0;// From uboot
+ clock-frequency = 0; // From uboot
+ 32-bit;
+ };
if this is really an 8641D I'd expect a 2nd cpu node.
+ };
+
+ memory {
+ device_type = memory;
+ reg = 2000; // 512M at 0x0
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ #interrupt-cells = 2;
+ device_type = soc;
+ ranges = 0 f800 0010;
+ reg = f800 0010; // CCSRBAR 1M
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = gianfar;
+ reg = 24520 20;
+ phy1f: [EMAIL PROTECTED] {
+ reg = 1f;
+ device_type = ethernet-phy;
+ };
+ phy0: [EMAIL PROTECTED] {
+ reg = 0;
+ device_type = ethernet-phy;
+ };
+ phy1: [EMAIL PROTECTED] {
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ phy2: [EMAIL PROTECTED] {
+ reg = 2;
+ device_type = ethernet-phy;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 24000 1000;
+ mac-address = [ 00 E0 0C 00 73 00 ];
+ interrupts = 1d 2 1e 2 22 2;
+ interrupt-parent = mpic;
+ phy-handle = phy1f;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 25000 1000;
+ mac-address = [ 00 E0 0C 00 73 01 ];
+ interrupts = 23 2 24 2 28 2;
+ interrupt-parent = mpic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 26000 1000;
+ mac-address = [ 00 E0 0C 00 02 FD ];
+ interrupts = 1F 2 20 2 21 2;
+ interrupt-parent = mpic;
+ phy-handle = phy1;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type =
Re: [PATCH] Add support for Wind River SBC8641D board
On Aug 1, 2007, at 9:53 AM, Joe Hamman wrote:
Sorry, I replied to only the first question.
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 01, 2007 9:18 AM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] Add support for Wind River SBC8641D board
On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
Add support for Wind River's SBC8641D reference board.
Is this a single core or dual core chip?
The board I have is single core. I would have to see if I could
get access
to a dual core board.
You may want to think about having both core's in the .dts and build
with !CONFIG_SMP for single and CONFIG_SMP for dual.
+void
+sbc8641d_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ uint memsize = total_memory;
+ const char *model = ;
+ uint svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, Vendor\t\t: Wind River Systems\n);
+
+ root = of_find_node_by_path(/);
+ if (root)
+ model = get_property(root, model, NULL);
+ seq_printf(m, Machine\t\t: %s\n, model);
+ of_node_put(root);
+
+ seq_printf(m, SVR\t\t: 0x%x\n, svid);
+ seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
+}
+
This is mostly redundant with the basic show cpu info, do you need
your own?
The plan is to add code to read the EEPROM device and show more info.
Ok thats fine than.
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init sbc8641d_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, mpc86xx))
+ return 1; /* Looks good */
the check you have is too generic, you probably need something more
specific in the top level compatible property.
Will do.
+
+ return 0;
+}
+
+
+void
+sbc8641d_restart(char *cmd)
+{
+ void __iomem *rstcr;
+
+ rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
+
+ local_irq_disable();
+
+ /* Assert reset request to Reset Control Register */
+ out_be32(rstcr, 0x2);
+
+ /* not reached */
+}
+
+
+long __init
+sbc8641d_time_init(void)
+{
+ unsigned int temp;
+
+ /* Set the time base to zero */
+ mtspr(SPRN_TBWL, 0);
+ mtspr(SPRN_TBWU, 0);
+
+ temp = mfspr(SPRN_HID0);
+ temp |= HID0_TBEN;
+ mtspr(SPRN_HID0, temp);
+ asm volatile(isync);
+
+ return 0;
+}
+
+
+define_machine(sbc8641d) {
+ .name = SBC8641D,
+ .probe = sbc8641d_probe,
+ .setup_arch = sbc8641d_setup_arch,
+ .init_IRQ = sbc8641d_init_irq,
+ .show_cpuinfo = sbc8641d_show_cpuinfo,
+ .get_irq= mpic_get_irq,
+ .restart= sbc8641d_restart,
+ .time_init = sbc8641d_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+
+#ifdef CONFIG_GEN_RTC
+ /* RTC interface, using functions in include/asm-generic/rtc.h */
+ .get_rtc_time = get_rtc_time,
+ .set_rtc_time = set_rtc_time,
+#endif
+};
Noticed you didn't have an PCIe support. Is that something that
exists on the board? is wired to anything?
diff -purN -X dontdiff linux-2.6/drivers/net/gianfar.h linux-2.6-
esi/drivers/net/gianfar.h
--- linux-2.6/drivers/net/gianfar.h 2007-07-31 10:15:39.0
-0500
+++ linux-2.6-esi/drivers/net/gianfar.h 2007-07-31
10:39:10.0 -0500
@@ -131,7 +131,7 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE0x1f
+#define TBIPA_VALUE0x1e
we need to turn this into a config option or something.
I was a little concerned when I saw a hard-coded address. I never
would
have found the conflict with the QUAD PHY (it starts at 0x1f and
increments
for each device) without your help.
Let me know what you think and I'll put something together.
I'll talk to someone here and see. I think a simple thing would be
to make it a Kconfig'ble option to what the value is for TBIPA_VALUE
and default to 0x1f but changeable in your defconfig.
#define MIIMCFG_INIT_VALUE 0x0007
#define MIIMCFG_RESET 0x8000
#define MIIMIND_BUSY0x0001
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reboot Command Makes kernel to hang (MPC8560)
On Jul 31, 2007, at 6:44 AM, Clemens Koller wrote: Hi, Ansari! Ansari schrieb: Hi Kumar, First of all thanks for ur reply . Even i went through the linux source . And i have observe that the reboot command used to hard reset the core . I have few doubts can u please clarify me. 1. Is there any way to reset the full chip with out using any external signal (MPC8560) ? (like any register that can be used for reseting the processor) I RTFM: It should be the bits RST[1:0] in the Debug Control Register 0 (DBCR0). This only resets the core on the 8560. I didn't find details how the external signals are affected: HRESET_REQ# and friends. The HRESET_REQ# is usually fed back to the CPU's HRESET#. So if the HRESET_REQ# gets asserted by writing to above registers it should really bring down the CPU, it's internal as well as it's external components, which are usually connected to a replication of that signal. This is roughly correct. The only way on 8560 to generate HRESET_REQ# is to cause a core watchdog timeout. However the existence of cpm2_reset() and a qe_reset() (QuiccEngine?) in the code tells me that the above expectations could be wrong. Would be nice to have that verified by some hardware guys from freescale... cpm2_reset/qe_reset are more related to SW than any HW reset. 2. Even same reboot command works fine for MPC8540 Processor ?. ...because it doesn't have a cpm ? That's more luck than anything else. 3. what are the factors that makes ramdisk hangs . When its uncompressing ? Well, side effects ? Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: I2C interrupts on 8541
On Jul 30, 2007, at 11:51 AM, Charles Krinke wrote: I'm puzzled about how to setup interrupts for the second I2C interface in an 8541. This is the CPM interface, the one with buffer descriptors. I see mention of its I2CER/I2CMR registers, but am having trouble figuring out how to enable and interrupt so that when the interface is in slave mode and a packet is received, it will vector to an interrupt service routine. I am using Linux-2.7.17.11 and I know you-all have gone past this a bit, but in the midst of a project, we are constrained to finish with the kernel we started with. A few pointers on enabling an interrupt from this interface would be greatly appreciated. To get interrupts you need to use the BD rings. Look at the section 'I2C Buffer Descriptors' in the 8555 UM and it shows 'I' bits in both the TX RX rings that should cause interrupts. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Decermenter overflow interrupt atfer the init.d launch.
On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote: Hi, I want to know how the kernel switch the task. Because my kernel start very well, and it launch the init.d. With the log, i can see that the kernel launch the getty task. But after, there is a decrementer overflow interrupt ( vector at adress 900 ). Is it the task switch? Or is it an error in the decrementer init. This should be a task switch. The decrementer is used to handle the periodic interrupt to switch processes. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reboot Command Makes kernel to hang (MPC8560)
On Jul 26, 2007, at 1:55 AM, Ansari wrote: Hi all, Processor (MPC8560) Whenever reboot command is given in the linux console. The processor gets reset and it loads bootloader , kernel and when uncompressing the ramdisk it gets hang. The sample log is given below. Any u please tell me what are the factors that can makes this to happen. This is very board dependant. The MPC8560 doesn't have a clean way to request reset, and odds are you're only getting the core reset and not the full chip. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Machine check exception. 2.6.20 powerpc tree.
On Jul 18, 2007, at 4:27 AM, Ramirez-Ortiz, Jorge wrote: Hi Kumar The address we are trying to access corresponds to a mapped device in the PCI space Attached some additional debugging information (we have instrumented the kernel) Thanks jorge INFO [_probe]: Found Device [irq=58] INFO [_open]: device opened with irq 58 INFO [_read]: waiting for interrupt INFO [_intr]: ISR 58 PCI1: Error! ERR_DETECT=0040, ATTR=00516001, addr=80020034, data=0005 So you are getting a master abort from the target. I think you need to look at your PCI device and see what's going on there. machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530 Machine check in user mode. Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx. Bus - Read Data Bus Error Call Trace: [C7355EF0] [C0006E64] show_stack+0x48/0x19c (unreliable) [C7355F20] [C000C04C] machine_check_exception+0x294/0x484 [C7355F40] [C000E48C] ret_from_mcheck_exc+0x0/0xe0 cat /proc/cpuinfo processor : 0 cpu : e500v2 clock : 799.50MHz revision: 2.0 (pvr 8021 0020) bogomips: 99.84 timebase: 49968750 platform: MPC85xx CDS Vendor : Freescale Semiconductor Machine : MPC85xx CDS (0xff) PVR : 0x80210020 SVR : 0x80390220 PLL setting : 0x4 Memory : 256 MB LAW 1 : , 2000 - DDR SDRAM LAW 2 : 8000, 1000 - PCI1 LAW 3 : 9000, 1000 - PCI2 LAW 4 : a000, 1000 - PCI Express LAW 5 : e100, 0100 - PCI1 LAW 6 : e200, 0100 - PCI2 LAW 7 : e300, 0100 - PCI Express LAW 8 : f000, 1000 - Local bus DDR 0 : , 2000 - 2/14/10 addr bits PCI1 Out_1 : 8000, 1000 - Mem: 8000 PCI1 Out_2 : e100, 0100 - I/O: PCI2 Out_1 : 9000, 1000 - Mem: 9000 PCI2 Out_2 : e200, 0100 - I/O: PCI3 Out_1 : a000, 1000 - Mem: a000 PCI3 Out_2 : e300, 0100 - I/O: PCI1 In_1 : , 2000 (Internal,R:snoop,W:snoop) - PF PCI2 In_1 : , 2000 (Internal,R:snoop,W:snoop) - PF PCI3 In_1 : , 2000 (Internal,R:snoop,W:snoop) - PF __ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: 17 July 2007 17:29 To: Ramirez-Ortiz, Jorge Cc: linuxppc-embedded@ozlabs.org Subject: Re: Machine check exception. 2.6.20 powerpc tree. On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote: Running our multithreaded application on ppc8548 (E500 core) generates a machine check exception when trying to access some ASIC's registers mapped on the PCI space (This application maps a PCI device to access its registers) machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530 Machine check in user mode. Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx. Bus - Read Data Bus Error Here is the assembly dump of the region of code containing the offending instruction in user-space, with SRR0 pointing us at 0x10153530 when the exception is raised: 0x10153528 _ZN2vk7in_le32EPVKj+16:lwz r0,8(r31) 0x1015352c _ZN2vk7in_le32EPVKj+20:lwz r9,8(r31) 0x10153530 _ZN2vk7in_le32EPVKj+24:lwbrx r0,0,r0 0x10153534 _ZN2vk7in_le32EPVKj+28:twi 0,r0,0 0x10153538 _ZN2vk7in_le32EPVKj+32:isync Can you get the code to dump the value of r0. I'm wondering if you're really getting a read data bus error due to the fact that r0 is pointing to a PCI address that doesn't have a device that will respond. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Machine check exception. 2.6.20 powerpc tree.
On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote: Running our multithreaded application on ppc8548 (E500 core) generates a machine check exception when trying to access some ASIC’s registers mapped on the PCI space (This application maps a PCI device to access its registers) machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530 Machine check in user mode. Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx. Bus - Read Data Bus Error Here is the assembly dump of the region of code containing the offending instruction in user-space, with SRR0 pointing us at 0x10153530 when the exception is raised: 0x10153528 _ZN2vk7in_le32EPVKj+16:lwz r0,8(r31) 0x1015352c _ZN2vk7in_le32EPVKj+20:lwz r9,8(r31) 0x10153530 _ZN2vk7in_le32EPVKj+24:lwbrx r0,0,r0 0x10153534 _ZN2vk7in_le32EPVKj+28:twi 0,r0,0 0x10153538 _ZN2vk7in_le32EPVKj+32:isync Can you get the code to dump the value of r0. I'm wondering if you're really getting a read data bus error due to the fact that r0 is pointing to a PCI address that doesn't have a device that will respond. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ask two question about e500 implementation in arch/ppc/kernel/head_fsl_booke.S
On Jul 11, 2007, at 5:21 AM, kang shuo wrote: hi,galak: I have two question about e500 part of linux kernel. I can not get reponse from maillist . So I sent the questions to you directly. 1. in arch/ppc/kernel/head_fsl_booke.S 603 FIND_PTE 604 andi. r13, r11, _PAGE_PRESENT /* Is the page present? */ 605 beq 2f /* Bail if not present */ That seems _PAGE_PRESENT should be set before enter DataTLBError exception handler(Or the following finish_tlb_load function will not execute), but in __ioremap function of e500 implementation, _PAGE_PRESENT bit is not set for an io address map.Why? _PAGE_PRESENT is sent when we use the page not when we map it. So on the first fault we set _PAGE_PRESENT. 2. still in arch/ppc/kernel/head_fsl_booke.S 791 #ifdef CONFIG_E200 792 /* Round robin TLB1 entries assignment */ 793 mfspr r12, SPRN_MAS0 794 795 /* Extract TLB1CFG(NENTRY) */ 796 mfspr r11, SPRN_TLB1CFG 797 andi. r11, r11, 0xfff 798 799 /* Extract MAS0(NV) */ 800 andi. r13, r12, 0xfff 801 addir13, r13, 1 802 cmpw0, r13, r11 803 addir12, r12, 1 804 805 /* check if we need to wrap */ 806 blt 7f 807 808 /* wrap back to first free tlbcam entry */ 809 lis r13, [EMAIL PROTECTED] 810 lwz r13, [EMAIL PROTECTED](r13) 811 rlwimi r12, r13, 0, 20, 31 812 7: 813 mtspr SPRN_MAS0,r12 814 #endif /* CONFIG_E200 */ 815 816 tlbwe That seems original tlb entry will be overwritten in the above code for e500? Why , I thought a free tlb entry should be select and fill for e500. Just like CONFIG_E200. Huh? The above code is for E200 only. Maybe the issue you're missing is that on E500 the NV bit is updated by HW. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: cuImage question
On Jun 28, 2007, at 4:54 PM, Bizhan Gholikhamseh ((bgholikh)) wrote: Hi All, I am kind of new to the concept of cuImage and I am not able to find any info on the net(?). We are using older version of the uboot: 1.1.2. I have compiled the latest kernel from git tree for MPC8541E from freescale. I would appreciate any hints on how to use 'cuImage to load this image with our legacy uboot version? Take a look at arch/powerpc/boot/ and the Kconfig DEVICE_TREE option. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ARCH=ppc or ARCH=powerpc
On Jun 28, 2007, at 3:36 AM, Erik Christiansen wrote: On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote: Encountering a kernel build error with ARCH=ppc, after configuring as much as possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this slightly scary result: Oh dear. Please excuse the noise. That was clearly acute lack of familiarity with menuconfig. blush Minus fingerfumbling, ARCH=powerpc starts to build, before coughing up a bunch of compiler errors: cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared Is that due to this patch not being accepted?: http://patchwork.ozlabs.org/linuxppc/patch?id=8891 If the patch's State Superseded means something else fixes the build failure, then how could I lay my grubby paws on that little gem? It probably means there was a newer version of the patch w/changes made to it based on feedback. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ARCH=ppc or ARCH=powerpc
On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote: Hi All, Sorry for asking this question again, I am still not clear on some of the issues. Background: We have developed a custom board based on Freescale reference board: MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and uboot 1.1.2 version. I would like to update the Linux kernel to the latest available kernel 2.6.21. Here are my questions: 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel? Move to ARCH=powerpc. 2- I have seen similar filenames under arch/ppc and arch/powerpc, which one applies to MPC8541E? There is support for MPC8541e in both arch/ppc arch/powerpc. 3- Once I build the kernel, could I load the kernel with uboot version 1.1.2 or not? if not what I should do? I can't remember if u-boot 1.1.2 had support for the device tree or not. If not you can use the cuImage target in arch/powerpc and use your existing u-boot. (or upgrade u-boot) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] mpc5200: /dev/watchdog driver for GPT0
On Jun 12, 2007, at 3:59 AM, Domen Puncer wrote:
Driver for internal mpc5200 watchdog on general purpose timer 0.
For IPB clock of 132 MHz the maximum timeout is about 32 seconds.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Should really be submitted to the watchdog maintainer if you want
this in the kernel
---
Hi!
I also have some generic GPT code that one could extend with
what he/she needs. Mail me if you'd find it useful.
drivers/char/watchdog/Kconfig |4
drivers/char/watchdog/Makefile |1
drivers/char/watchdog/mpc5200_wdt.c | 257
3 files changed, 262 insertions(+)
Index: work-powerpc.git/drivers/char/watchdog/Kconfig
===
--- work-powerpc.git.orig/drivers/char/watchdog/Kconfig
+++ work-powerpc.git/drivers/char/watchdog/Kconfig
@@ -521,6 +521,10 @@ config 8xx_WDT
tristate MPC8xx Watchdog Timer
depends on 8xx
+config MPC5200_WDT
+ tristate MPC5200 Watchdog Timer
+ depends on PPC_MPC52xx
+
config 83xx_WDT
tristate MPC83xx Watchdog Timer
depends on PPC_83xx
Index: work-powerpc.git/drivers/char/watchdog/Makefile
===
--- work-powerpc.git.orig/drivers/char/watchdog/Makefile
+++ work-powerpc.git/drivers/char/watchdog/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc
# PowerPC Architecture
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
+obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
Index: work-powerpc.git/drivers/char/watchdog/mpc5200_wdt.c
===
--- /dev/null
+++ work-powerpc.git/drivers/char/watchdog/mpc5200_wdt.c
@@ -0,0 +1,257 @@
+#include linux/init.h
+#include linux/module.h
+#include linux/miscdevice.h
+#include linux/watchdog.h
+#include linux/io.h
+#include asm/of_platform.h
+#include asm/uaccess.h
+#include asm/mpc52xx.h
+
+
+#define GPT_MODE_WDT (115)
+#define GPT_MODE_CE (112)
+#define GPT_MODE_MS_TIMER(0x4)
+
+
+struct mpc5200_wdt {
+ unsigned count; /* timer ticks before watchdog kicks in */
+ long ipb_freq;
+ struct miscdevice miscdev;
+ struct resource mem;
+ struct mpc52xx_gpt __iomem *regs;
+ struct mpc52xx_gpt saved_regs;
saved_regs isn't used anywhere
[snip]
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: anyone have a good config file for a taiga/hpc2 with a 7448?
On May 22, 2007, at 1:41 PM, Leisner, Martin wrote: Before I tried to do one myself, I figured I'd bounce it off to see if anyone has a working .config (the newer kernel, the better). Does arch/powerpc/configs/mpc7448_hpc2_defconfig not work for you? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Accessing 8541 registers from user space
On May 16, 2007, at 4:59 PM, Charles Krinke wrote: I have a need to be able to read and write the gpio data registers PDATC and PDATD from a user space program. We have a userspace program that succesfully mmaps an offset in / dev/mem and reads/writes registers in a CPLD at 0xFF00_. The issue seems to be that when I mmap /dev/mem to 0xE000_0D50 to read the PDATC register, Linux-2.6.17.11 just locks up. Can anyone shed a little light on why this could be happening? One theory is you aren't reading PDATC at the right offset. Not sure what happens if you read a non-existent register offset. I'm think you want 0xe009_0d50. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
On May 11, 2007, at 9:12 AM, Ben Warren wrote:
Alex,
On Fri, 2007-05-11 at 10:29 +0100, Alex Zeffertt wrote:
Hi,
Thanks for your reply Ben, but I think my problem is slightly
different. It is not
that the sense (high/low/rising/falling) of the interrupt is
wrong, but that the
kernel will not allow me to register the handler.
I've changed my code to:
struct device_node *np = of_find_node_by_type(NULL, ipic);
struct irq_host *host = irq_find_host(np);
int rc;
unsigned int virq = irq_find_mapping(host, 5);
set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
rc = request_irq(virq, mpc832xemds_phy_interrupt,
IRQF_SHARED, pm5384, dev);
but the last line still returns a non-zero error code.
Is there a new way of requesting to install a handler for external
interrupts? I
can't find any powerpc examples in the kernel tree
Sorry, I missed a bit of the implementation. You need to register the
IRQs before attempting to attach an ISR. Here's some sample code that
works for me. You'll probably need different IRQs, based on what your
board does:
/* All external IRQs + Generic timer IRQs must be initialized by
BSP */
const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84,
72};
Add this to your BSP IRQ init code (void __init xxx_init_IRQs())
for (i=0;isizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
virq = irq_create_mapping(NULL, bsp_irqs[i]);
I assume you're code doesn't look exactly like this. You'll need to
use the virq in the request_irq()... its most likely just random luck
if things are working and you aren't using the virq returned from
irq_create_mapping()
(Well its more than random luck, its because most 83xx systems only
have one PIC and this hw_irq # == virq)
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
On May 11, 2007, at 3:29 PM, Ben Warren wrote: On Fri, 2007-05-11 at 15:15 -0500, Kumar Gala wrote: I assume you're code doesn't look exactly like this. You'll need to use the virq in the request_irq()... its most likely just random luck if things are working and you aren't using the virq returned from irq_create_mapping() (Well its more than random luck, its because most 83xx systems only have one PIC and this hw_irq # == virq) - k In the code that registers the ISR I do this: virq = irq_find_mapping(NULL, MY_IRQ); request_irq(virq ...) Since I only have one interrupt controller, host is NULL, right? Should be ok. I've been doing the irq_create_mapping() in _init_IRQ () and saving off the return. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] phy_ethtool_{sset,gset} -- check phydev for NULL
On May 10, 2007, at 3:57 AM, Matvejchikov Ilya wrote:
Good Day!
The command 'brctl addbr br0 eth0' brings the kernel oops if the eth0
has PHY, but the phydev is NULL (for ex., ifconfig eth0 0.0.0.0 was
not issued firstly)
Call Trace:
[C02CFBD0] [7FFF] 0x7fff (unreliable)
[C02CFBE0] [C0109634] dev_ethtool+0x1b0/0xfac
[C02CFCD0] [C0155EF0] port_cost+0x5c/0x130
[C02CFD40] [C01561FC] br_add_if+0x17c/0x308
[C02CFD70] [C01569E0] add_del_if+0x70/0xa0
[C02CFD90] [C0156A58] br_dev_ioctl+0x48/0x9fc
[C02CFE10] [C0106FCC] dev_ifsioc+0x144/0x3ac
[C02CFE30] [C01080D8] dev_ioctl+0x3b8/0x4c8
[C02CFEB0] [C00F9BC0] sock_ioctl+0x78/0x260
[C02CFED0] [C006889C] do_ioctl+0x38/0x84
[C02CFEE0] [C006896C] vfs_ioctl+0x84/0x3d8
[C02CFF10] [C0068D00] sys_ioctl+0x40/0x74
[C02CFF40] [C000EF48] ret_from_syscall+0x0/0x38
The following patch fixes the problem.
Signed-off-by: Matvejchikov Ilya matvejchikov at gmail.com
while you're patch looks reasonable, this is best sent to the netdev
list and jeff garzik as its not ppc specific at all.
- k
===
diff -purN linux-2.6.21-clean/drivers/net/phy/phy.c
linux-2.6.21/drivers/net/phy/phy.c
--- linux-2.6.21-clean/drivers/net/phy/phy.c 2007-04-26
07:08:32.0 +0400
+++ linux-2.6.21/drivers/net/phy/phy.c2007-05-04
08:22:01.0 +0400
@@ -245,6 +245,9 @@ EXPORT_SYMBOL(phy_sanitize_settings);
*/
int phy_ethtool_sset(struct phy_device *phydev, struct
ethtool_cmd *cmd)
{
+ if (unlikely(NULL == phydev))
+ return -EINVAL;
Would -ENODEV; make more sense?
+
if (cmd-phy_address != phydev-addr)
return -EINVAL;
@@ -289,6 +292,9 @@ EXPORT_SYMBOL(phy_ethtool_sset);
int phy_ethtool_gset(struct phy_device *phydev, struct
ethtool_cmd *cmd)
{
+ if (unlikely(NULL == phydev))
+ return -EINVAL;
+
Would -ENODEV; make more sense?
cmd-supported = phydev-supported;
cmd-advertising = phydev-advertising;
___
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: [PATCH] TurboStation support (Properly)
On May 8, 2007, at 4:56 PM, Øyvind Repvik wrote:
On Sunday 06 May 2007 14:46:05 Øyvind Repvik wrote:
Hi,
This patch adds support for the QNAP TurboStation TS-101 and
TS-201 devices.
Of course, it probably helps if my mail client doesn't break the
patch completely.
Comments below.
Out of interesting, what's the difference between the TS-101 and TS-201?
Signed-off-by: Øyvind Repvik [EMAIL PROTECTED]
Signed-off-by: Alessandro Zummo [EMAIL PROTECTED]
--- linux-2.6.21.1/arch/powerpc/boot/dts/qnap-ts101.dts 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.21.1.ts/arch/powerpc/boot/dts/qnap-ts101.dts
2007-05-03 22:44:59.0 +0200
@@ -0,0 +1,166 @@
+/*
+ * Device Tree Souce for QNAP Turbostation 101/201
+ *
+ * Choose CONFIG_TURBOSTATION to build a kernel for turbostation
+ *
+ *
+ * Based on kuroboxHD.dts by G. Liakhovetski
+ *
+ * 2007 (c) Oyvind Repvik [EMAIL PROTECTED]
+ *
+ * This file is licensed under
+ * the terms of the GNU General Public License version 2. This
program
+ * is licensed as is without any warranty of any kind, whether
express
+ * or implied.
+ *
+ * build with: dtc -f -I dts -O dtb -o qnap-ts101.dtb -V 16 qnap-
ts101.dts
+ *
+ *
+ */
+
+/ {
+ linux,phandle = 1000;
+ model = TurboStation TSx01;
+ compatible = turbostation;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ linux,phandle = 2000;
Can you removal all linux,phandle's and use the new reference syntax.
+ #cpus = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,603e { /* Really 8241 */
+ linux,phandle = 2100;
+ device_type = cpu;
+ reg = 0;
+ clock-frequency = fdad680;/* 266 MHz */
+ timebase-frequency = 1fca055; /* 33.333 MHz */
+ bus-frequency = 0;
+ /* Following required by dtc but not used */
+ i-cache-line-size = 0;
+ d-cache-line-size = 0;
No reason not to set the line-size properly to 20
+ i-cache-size = 4000;
+ d-cache-size = 4000;
+ };
+ };
+
+ /* 64MB @ 0x0 */
+ memory {
+ linux,phandle = 3000;
+ device_type = memory;
+ reg = 0400;
+ };
+
+ [EMAIL PROTECTED] {
+ linux,phandle = 3100;
+ device_type = rom;
+ compatible = direct-mapped;
+ probe-type = CFI;
+ reg = ff00 0100;
+ bank-width = 1;
+ partitions =
+ 0020
+ 0020 00d0
+ 00f0 00040001
+ 00f4 0002
+ 00f6 0004
+ 00fa 0002
+ 00fc 0004
+ ;
+ partition-names = kernel\0rootfs\0uboot1\0uboot1-env\0uboot2
\0uboot2-env\0SysConf;
+ };
+
+
+ soc10x { /* AFAICT need to make soc for 8245's uarts to be
defined */
+ linux,phandle = 4000;
+ #address-cells = 1;
+ #size-cells = 1;
+ #interrupt-cells = 2;
+ device_type = soc;
+ compatible = mpc10x;
+ store-gathering = 0; /* 0 == off, !0 == on */
+ reg = 8000 0010;
+ ranges = 8000 8000 7000/* pci mem space */
+ fc00 fc00 0010/* EUMB */
+ fe00 fe00 00c0/* pci i/o space */
+ fec0 fec0 0030/* pci cfg regs */
+ fef0 fef0 0010; /* pci iack */
+
+ [EMAIL PROTECTED] {
+ linux,phandle = 4300;
+ device_type = i2c;
+ compatible = fsl-i2c;
+ reg = fc003000 1000;
+ interrupts = 5 2;
+ interrupt-parent = 4400;
+ };
+
+ [EMAIL PROTECTED] {
+ linux,phandle = 4511;
+ device_type = serial;
+ compatible = ns16550;
+ reg = fc004500 8;
+ clock-frequency = 7ed6b40;/* 133 MHz */
+ current-speed = 1c200;/* 115200 */
+ interrupts = 9 2;
+ interrupt-parent = 4400;
+ };
+
+ [EMAIL PROTECTED] {
+ linux,phandle = 4512;
+ device_type = serial;
+ compatible = ns16550;
+ reg = fc004600 8;
+
Re: [PATCH] TurboStation support (Properly)
On May 9, 2007, at 9:18 AM, Kumar Gala wrote: On May 8, 2007, at 4:56 PM, Øyvind Repvik wrote: On Sunday 06 May 2007 14:46:05 Øyvind Repvik wrote: Hi, This patch adds support for the QNAP TurboStation TS-101 and TS-201 devices. Of course, it probably helps if my mail client doesn't break the patch completely. Comments below. Out of interesting, what's the difference between the TS-101 and TS-201? Also, can you provide a defconfig. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Try to Disable PPC Interrupt
On Mar 28, 2007, at 11:20 PM, Zhou Rui wrote:
Hi
Sorry for my silly mistake, and I modify it like this:
#ifndef MODULE
#define MODULE
#endif
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include linux/module.h
#include linux/kernel.h
#include linux/types.h
#include linux/errno.h
void hw_disable_irq (void) {
int c;
__asm__ __volatile__(
mfmsr %%r0; \
wrteei 0; \
mfmsr %0;:=r(c) : );
Why don't use use local_irq_disable() ?
printk(%x\n,c);
}
int init_module(void)
{
hw_disable_irq();
}
void cleanup_module(void)
{
}
MODULE_LICENSE(GPL);
I can get the output is 0x21030. But I also use BDI2000 here and
when I halt the board from BDI2000, I get
405EPhalt
Core number: 0
Core state : debug mode
Debug entry cause : JTAG stop request
Current PC : 0xc00042d8
Current CR : 0x22004082
Current MSR : 0x00029030
Current LR : 0xc00042d8
Hope my understanding for big endian is right. It seems 0x00029030
in MSR is
0010 1001 0011, but 0x21030 is
0010 0001 0011.
It seems the 16th bit (EE) has been set to 0, but what should I do
to make sure whether the external interrupt is disabled or not?
Thank you very much.
What exactly are you asking? If MSR[EE] = 0, interrupts are disabled.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8347 PQ2 I2C driver
On Mar 20, 2007, at 8:57 PM, Adrian Craine wrote: Hi all, Just a quick one, does any-one know if the i2c-mpc i2c driver will function on a Freescale MPC8347? Cheers, Adrian. Yes it will. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Exception in kernel mode
On Mar 16, 2007, at 9:45 AM, Charles Krinke wrote: It this a system you are just bringing up or one that's been running for a while. It really seems like memory corruption of some form. I'd suggest checking memory controller settings. Also, what happens if you disassemble the kernel image and look at the addresses pointed to by NIP: C00DEE18 C002CE68. - k Dear Kumar: We have two systems. One based on an 8241, and one based on an 8541. The 8241 has been running for some time with Linux 2.4 and the 8541 is coming up. Both are using the 2.6.17.11 kernel from kernel.org with modifications for our hardware. In the case of the 8241, I started out with the 2.4 modifications, which were originally based on the 8260 and ported them to 2.6. In the case of the 8541, I started out with the embedded planet 8555EP 2.6 kernel source and added that to the 2.6. I dont see this exception in the 8541, although extensive testing has not yet been completed. The 8241 exhibits this exception on three different 8241 boards, so I dont suspect the hardware. We are using the Montavista toolchain and their root filesystem including 'tar' and 'cp' which are the programs that currently exhibit the fault. Yesterday, when I saw an NIP at 0x900, I was ready to jump on the interrupts not being setup correctly, but after a few hours of going through that, I am now convinced the interrupts are setup correctly, so it is something more subtle. Certainly, memory corruption is the next thing to be concerned with. One thing that has concerned me a bit is that we have no swap space available at all. This is an embedded system with 64MByte of RAM and JFFS2 NAND flash with no swap partitions. I suspect auditing the MMU setup differences between the original 2.4 kernel and the new 2.6 kernel for the 8241 board is the next step. The three exceptions I saw yesterday were 1)0x900 in the timer_interrupt, 2) C00DEE18 (inside the tar program) and 3) C002CE68 (in one of the kernel routines). #2 is inside the kernel as well. Look at the System.map or objdump - d vmlinux to see what exactly is at those instructions. I suspect the actual addresses are red-herrings and this exception can occur at any address. This certainly would tend to indicate some sort of memory setup issue. I think it's useful to know if the instructions at the two offsets C00DEE18 C002CE68 are similar in some way before jumping to that conclusion. Changing the Oops logic to printout the NextInstruction as well as the NIP might be helpful so I could discern the difference between what the program is trying to do and what it is really doing. Are there any other thoughts you might have on diagnosis techniques at this point? Try turning on KALLSYMS, this should provide more info on the oops as well. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Exception in kernel mode
On Mar 15, 2007, at 1:55 PM, Charles Krinke wrote: mtspr SPRN_SPRG0, r10 mtspr SPRN_SPRG1, r11 Which is, I believe, moving r10 to SPRG0 and r11 to SPRG1. So, how do we know that r10 and r11 are always valid in an interrupt context? Are we setting aside r10 and r11 somewhere else in That doesn't matter to kernel at all -- they are just *saved* in SPRG regs to avoid being trashed by the exception handler. WBR, Sergei Well, unfortunately, now I am more confused. The original Oops was at an NIP of 0900, which I think means it faulted on the first mtspr from r10. I suppose one could argue that pipeline issues might make it fault on the second one and appear to be the first. But, maybe I am confusing myself here. Would I be correct in assuming that some further instruction in the ISR at 0x900 is the culprit? Could there possibly be some user versus supervisor mode thing going on? My key assumption is that the timer_tick (aka Decrementer) has worked for many hundreds of thousands of interrupts and only when running some particular user application, like tar is there a side effect from either a mode or some register value, race condition, or other. Can you post the oops that you are seeing, what you need to find out is what instruction image that is causing the illegal instruction exception. Once you have that it will be easier to figure out what's going on. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Exception in kernel mode
On Mar 15, 2007, at 4:17 PM, Charles Krinke wrote: I ran a couple of more tests and the system did not Oops in the timer_interupt except for the first test this morning. The last two times, the NIP was Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: C002CE68 LR: C002CEC8 CTR: 3B25 REGS: c3119a00 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081032 ME,IR,DR CR: 88022484 XER: TASK = c3ecd870[920] 'tar' THREAD: c3118000 And Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: C00DEE18 LR: C00DEDD8 CTR: REGS: c299dbc0 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081032 ME,IR,DR CR: 84022488 XER: 2000 TASK = c3e2b7d0[925] 'tar' THREAD: c299c000 For comparision, this is the original one from this morning Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: 0900 LR: C00E579C CTR: 3A55 REGS: c37f3b00 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081000 ME CR: 24022484 XER: TASK = c3eaf810[940] 'tar' THREAD: c37f2000 I have to conclude this is not necessarily a timer_interrupt problem. Also, commenting out the innards of the timer_interrupt causes the kernel to hang in its boot right after the message Memory: xxxK available So a properly functioning timer_interrupt is essential to the the kernel booting. But, ... At this point, I really don't know which way to jump. It this a system you are just bringing up or one that's been running for a while. It really seems like memory corruption of some form. I'd suggest checking memory controller settings. Also, what happens if you disassemble the kernel image and look at the addresses pointed to by NIP: C00DEE18 C002CE68. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Serial console not working on EP8343M
On Mar 12, 2007, at 10:05 PM, Ed Swierk wrote: I'm having trouble getting the serial console to work on an EP8343M board when using U-Boot 1.2.0 to start Linux 2.6.20.1. I'm using arch powerpc and platform MPC834x_SYS (which is perhaps wishful thinking, as my board is different, although it should at least have the same serial port configuration). The symptoms are exactly the same as those in http://ozlabs.org/pipermail/linuxppc-embedded/2006-September/ 024457.html: the console stops working after the call to console_init(). The suggested solution was to ensure that U-Boot is setting timebase-frequency, bus-frequency and clock-frequency and passing those properties to the kernel, and this does indeed seem to be happening in my case. I've attached the output from U-Boot (including a dump of the flat device tree), as well as my kernel config and U-Boot board settings. Any help would be appreciated. --Ed Have you tried make the bootargs just console=ttyS0,115200 (or whatever your baud rate is)? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reset cause API
On Mar 5, 2007, at 3:22 PM, Ben Warren wrote: Hello, Is there an API call, either Linux or PowerPC-specific, for determining the cause of the last reset? I can certainly read the RSR myself, but why bother if the information's available elsewhere. There isnt anything like this since we don't have any consistent way of maintaining information across a reset. Something like kexec could possibly do something. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
On Mar 5, 2007, at 4:53 AM, Sylvain Munaut wrote: Domen Puncer wrote: Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC. Tested to work with built-in eeprom on lite5200b. Signed-off-by: Domen Puncer [EMAIL PROTECTED] Acked-by: Sylvain Munaut [EMAIL PROTECTED] I'll make sure this is included in my next merge batch to Paul. Driver patches should go via the driver subsystem maintainers and not Paul. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
On Mar 5, 2007, at 8:53 AM, Kumar Gala wrote: On Mar 5, 2007, at 4:53 AM, Sylvain Munaut wrote: Domen Puncer wrote: Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC. Tested to work with built-in eeprom on lite5200b. Signed-off-by: Domen Puncer [EMAIL PROTECTED] Acked-by: Sylvain Munaut [EMAIL PROTECTED] I'll make sure this is included in my next merge batch to Paul. Driver patches should go via the driver subsystem maintainers and not Paul. Sorry, ignore me. I was looking at Domen's initial patch which touched drivers/i2c/busses/i2c-mpc.c - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Endianness versus too many byte swaps??
On Mar 5, 2007, at 9:02 AM, Charles Krinke wrote: You do understand that readl is in fact a call to in_le32() on ppc (cf. include/asm-ppc/io.h). The question now is, what endianness you would like in that register? Regards -- Stephane Dear Stephane: Your point is well made. I can see that readl is in fact a call to in_le32. Maybe there is a more basic problem here. If I change the call to readl to a call to in_be32, things make sense again. So, maybe I don't quite understand the endianness setup of this Linux project. readl/writel are for PCI bus accesses. PCI is inherently little endian. I am told that we are running this ppc in big endian, so would this mean that readl writel should actually be resolving to in_be32/out_be32 respectively? Is there some other setup that may be wrong? Nope, readl/writel are doing the write thing, they will ALWAYS be little endian. You truly want in_be*/out_be* when accessing 85xx CCSR registers since all of them are big endian. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360E - PCI - BRIDGE
On Mar 2, 2007, at 4:59 PM, Russell McGuire wrote: I was wondering if anyone had a small suggestion of PCI cards to begin testing Linux with for debugging a PCI bus / software / setup. Basically I am looking for a couple of cards that are known to have good working PPC drivers for PCI, hopefully built-in into the kernel. Preferable that somebody has first has experience with. I seem to be having issues with Linux only, and getting my PCI stuff to work. Still not sure if these are DTV blob issues, or incompatibility with the PCI-PCI bridge chip I have in the PPC system. Questions: 1) Can somebody provide the names of just a few cards that have been tested with these 82xx 83xx PCI busses that have worked in Linux 2.6.xx? I hope to not be fighting endian issues in the drivers at first. Intel e100/e1000 cards are usually pretty good candidates. 2) What is available / known about PCI bridge compatibility / enumeration when it comes to PPC architecture? I know Linux sees the bridge, but are there mapping compatibility issues introduced if an extra bridge is in place? The main issue is related to setting up the bridge. We seem to handle this before linux is involved in most cases. 3) Directly related to Question 2, is there any special options have to be enabled in the Linux 2.6.xx kernel 2.6.20 specifically to make this happen? PreP compliance, G5 support, no idea I am just throwing ideas. Nope, just PCI support. The key as mentioned above is having the P2P bridge setup properly. Any help appreciated, I was hoping originally that once the PCI was happy inside U-boot that Linux wouldn't be such a far target. That's true, if you have u-boot setup and seeing your devices than it shouldn't be too far for the linux. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
