MPC82xx -- DPRAM1
Dan Malek dan at embeddededge.com 19.11.2004 00:11 To: morten.banzon at axxessit.no cc: linuxppc-embedded at ozlabs.org, Wolfgang Denk wd at denx.de Subject:Re: MPC82xx -- DPRAM1 On Nov 18, 2004, at 3:08 PM, morten.banzon at axxessit.no wrote: If you know the reason to why it is a very bad idea to relocate these resources within dpram1 I am very curious to learn. On the other hand if you do not know, then please refrain from giving such a stupid answer. As you have discovered, there are many dependencies on the configuration of the cpm smc from the boot rom to bootloaders to the Linux kernel itself. It's a bad idea to be changing one of these without changing all of the others to match and then you end up with a custom piece of software that you have to constantly maintain. If you make it configurable, then you end up with even more confusion when people mismatch the configurations on a board. I aggree with that, I will strive to avoid such changes. There isn't any reason to change the current SMC buffering configuration on the CPM2 (and future) devices. If you like change for the sake of change, then go ahead and do it. We answered the questions you asked and specifically said the changes you were making at the time weren't a good idea. Just because you didn't agree doesn't make it a stupid response, especially since it's pretty easy to figure out on your own from looking at the code. You might be right that there is no reason to change this cofiguration. I guess you know that no one would change this for the sake of change. No, you did not answer my questions. Just to recap a few questions and answers: 1. I had trouble understanding the use of the CPM_DATAONLY_BASE constant, or more precisely what was located at the addresses below CPM_DATAONLY_BASE. It turns out that it is the smc parameter tables that are placed there. But the real mystery was how the cpm was told where to find these locations. The end of the story is that the cpm uart driver is dependent on this particular configuration (writing these adresses into the SMC1_BASE at 0x87FC and SMC2_BASE at 0x88FC) beeing set-up before being loaded. At one point I was asking if this was intentional or not. The answer to this I still do not know, but maybe it is not important either. 2. I stated that I relocated the buffer descriptors. This was done by replacing cpm_dpalloc with cpm_dpalloc_fixed and an offset adress of my choice. Your reply to this was the very bad idea. Well, on my target I can move these buffer descriptors around as I please within the dpram1, and the smc1/console just keeps working. I do not say that this is not problematic, just that I do not detect any problems neither do I see any problems by reading the code. So, why this is a bad idea remains unclear. What seems to be a bad idea, or at least a little messy, is to relocate the smc parameter ram located below the first 128 bytes of dpram1. Now you go on about just because you didn't agree? Where did that come frome ? Maybe I am expressing myself very unclear, but as far as I know I have not disagreed with anything. I am just asking questions and trying to understand this peace of the system, and to be frank not many correct answers have been provided. Regarding stupid response I am baffled. Wolfgang presents a few very clear statement, which are equally clearly wrong regarding this subject, the cpm uart driver (smc). Your mail contradicts his mail. I have come to the same conclusion as you have summarised in your previous mail. That is why I call read the code a stupid answer. I think somebody else should take a break and read the code. Besides saying stupid about that particular answer, I have not called any other answer, suggestion, or anything else stupid. I hope we are clear on that. How you can say it is pretty easy to figure out on your own from looking at the code I do not get, but that is not important. If you think it is easy, that is fine for you. I think I have described the reason why it is difficult to understand several times now, just a final point; in terms of configuring the smc hardware I think the only thing missing from the driver is to setup the now famous SMCx_BASE pointers. This is ofcourse possible to do, but there might be good reasons why it is not done. How it is supposed to be obvious that some boot code/loader set up these particular pointers I disagree with, especially in light of Wolfgang's mail. Have a nice day, -- Morten
uClibc buildroot system
Hello All ! Have anyone tried subj ? I'm trying to build it for 405GP CPU. It compiles well, but when I'm trying to boot from generated root fs in just silently hungs. -- Best regards, Vladimir
MPC82xx -- DPRAM1
-Original Message- From: linuxppc-embedded-bounces at ozlabs.org [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of morten.banzon at axxessit.no Sent: Thursday, November 18, 2004 20:24 I think the only thing missing from the driver is to setup the now famous SMCx_BASE pointers. This is ofcourse possible to do, but there might be good reasons why it is not done. Send a patch to fix this in the driver. I think most people on this list would like the seriaql drivers to be totally independent of the bootloader (no matter what it is).
Lite5200 FEC Driver on linux 2.6 broken? (fixed again)
What tree are you exactly using ? In mainstream XLB snooping is not configured so if you have the mainstream + added DMA, the problem may come from this. Sylvain I did a bk clone of the linux-2.5 tree (2.6.10-rc2), then a bk pull of your tree. You're probably right about the snooping. Since the driver is working at the moment, I'll wait until your tree is updated before doing more testing. Thanks -rb __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
[PATCH 2.6.10-rc2] ppc32: Update IBM EMAC copyright / emails
The following does 3 things: - Shorten the GPL notice in all of the IBM EMAC driver files - Generally put Matt Porter on the hook as maintainer, and remove Armin Kuster and Johnnie Peters email addrs. - Fix a typo Wolfgang Denk pointed out to me privately (MontaVista Softare). Signed-off-by: Tom Rini trini at kernel.crashing.org --- 1.2/drivers/net/ibm_emac/ibm_emac.h 2004-08-04 08:41:48 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac.h 2004-11-19 09:28:41 -07:00 @@ -1,16 +1,13 @@ /* - * ibm_emac.h + * drivers/net/ibm_emac/ibm_emac.h * + * Author: Armin Kuster source at mvista.com + * Maintainer: Matt Porter mporter at kernel.crashing.org * - * Armin Kuster akuster at mvista.com - * June, 2002 - * - * Copyright 2002 MontaVista Softare 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. + * 2002 (c) MontaVista Software, Inc. 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. */ #ifndef _IBM_EMAC_H_ --- 1.4/drivers/net/ibm_emac/ibm_emac_core.c2004-10-20 01:37:15 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2004-11-19 09:30:15 -07:00 @@ -3,18 +3,18 @@ * * Ethernet driver for the built in ethernet on the IBM 4xx PowerPC * processors. - * - * (c) 2003 Benjamin Herrenschmidt benh at kernel.crashing.org * - * Based on original work by + * Maintainer: Matt Porter mporter at kernel.crashing.org + * + * Based on original work by Armin Kuster and Johnnie Peters + * source at mvista.com * - * Armin Kuster akuster at mvista.com - * Johnnie Peters jpeters at mvista.com + * 2002 (c) MontaVista Software, Inc. 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. + * (c) 2003 Benjamin Herrenschmidt benh at kernel.crashing.org * - * 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. * TODO * - Check for races in the remove code path * - Add some Power Management to the MAC and the PHY --- 1.2/drivers/net/ibm_emac/ibm_emac_core.h2004-08-05 07:26:55 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2004-11-19 09:31:10 -07:00 @@ -1,22 +1,16 @@ /* - * ibm_emac_core.h + * drivers/net/ibm_emac/ibm_emac_core.h * * Ethernet driver for the built in ethernet on the IBM 405 PowerPC * processor. * - * Armin Kuster akuster at mvista.com - * Sept, 2001 + * Authors: Armin Kuster and Johnnie Peters source at mvista.com + * Maintainer: Matt Porter mporter at kernel.crashing.org * - * Orignial driver - * Johnnie Peters - * jpeters at mvista.com - * - * Copyright 2000 MontaVista Softare 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. + * 2000-2001 (c) MontaVista Software, Inc. 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. */ #ifndef _IBM_EMAC_CORE_H_ --- 1.1/drivers/net/ibm_emac/ibm_emac_debug.c 2004-05-22 10:13:08 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_debug.c2004-11-19 09:31:52 -07:00 @@ -1,17 +1,15 @@ /* - * ibm_ocp_debug.c + * drivers/net/ibm_emac/ibm_ocp_debug.c * - * This has all the debug routines that where in *_enet.c + * Debug rountines for the IBM EMAC driver. * - * Armin Kuster akuster at mvista.com - * April , 2002 + * Authors: Armin Kuster source at mvista.com + * Maintainer: Matt Porter mporter at kernel.crashing.org * - * Copyright 2002 MontaVista Softare 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. + * 2002 (c) MontaVista Software, Inc. 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. */ #include linux/config.h --- 1.2/drivers/net/ibm_emac/ibm_emac_mal.c 2004-09-07 23:33:14 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_mal.c 2004-11-19
[PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a bit later
Borut Lukic borutlukic at email.si brought to my attention that in platform_init() on 8260 the board hook was being called too early to allow for overrides (e.g. different memory sizings functions or rtc, or anything else). This moves the call to the end of platform_init() and I suspect fixes some unnoticed yet bugs in a number of 8260 platforms. Signed-off-by: Tom Rini trini at kernel.crashing.org --- 1.26/arch/ppc/syslib/m8260_setup.c 2004-08-24 08:31:20 -07:00 +++ edited/arch/ppc/syslib/m8260_setup.c2004-11-19 11:03:35 -07:00 @@ -241,9 +241,6 @@ strcpy(cmd_line, (char *)(r6+KERNELBASE)); } - /* Call back for board-specific settings. */ - m82xx_board_init(); - ppc_md.setup_arch = m8260_setup_arch; ppc_md.show_cpuinfo = m8260_show_cpuinfo; ppc_md.init_IRQ = m8260_init_IRQ; @@ -259,4 +256,7 @@ ppc_md.find_end_of_memory = m8260_find_end_of_memory; ppc_md.setup_io_mappings= m8260_map_io; + + /* Call back for board-specific settings and overrides. */ + m82xx_board_init(); } -- Tom Rini http://gate.crashing.org/~trini/
[PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code
A trivial fix for the __iomem warnings in arch/ppc/syslib/todc_time.c
Signed-off-by: Randy Vinson rvinson at mvista.com
Signed-off-by: Tom Rini trini at kernel.crashing.org
--- a/arch/ppc/syslib/todc_time.c 2004-10-29 18:29:54.0 -0700
+++ b/arch/ppc/syslib/todc_time.c 2004-10-29 18:40:10.0 -0700
@@ -82,13 +82,13 @@ extern spinlock_t rtc_lock;
u_char
todc_direct_read_val(int addr)
{
- return readb(todc_info-nvram_data + addr);
+ return readb((void __iomem *)(todc_info-nvram_data + addr));
}
void
todc_direct_write_val(int addr, unsigned char val)
{
- writeb(val, todc_info-nvram_data + addr);
+ writeb(val, (void __iomem *)(todc_info-nvram_data + addr));
return;
}
--
Tom Rini
http://gate.crashing.org/~trini/
[PATCH][PPC32] Marvell host bridge support (mv64x60)
This patch adds core support for a line of host bridges from Marvell (formerly Galileo). This code has been tested with a GT64260a, GT64260b, MV64360, and MV64460. Patches for platforms that use these bridges will be sent separately. The patch is rather large so a link is provided. Signed-off-by: Mark A. Greer mgreer at mvista.com -- ftp://source.mvista.com/pub/mgreer/mv64x60.patch
[PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval platform
This patch adds support for a line of evaluation platforms from Marvell that use the Marvell GT64260[ab] host bridges. This patch depends on the Marvell host bridge support patch (mv64x60). This patch is larger than 40KB so a link is provided (as per instructions in SubmittingPatches). Signed-off-by: Mark A. Greer mgreer at mvista.com -- ftp://source.mvista.com/pub/mgreer/ev64260.patch
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Mark A. Greer mgreer at mvista.com wrote:
This patch adds core support for a line of host bridges from Marvell
(formerly Galileo). This code has been tested with a GT64260a,
GT64260b, MV64360, and MV64460. Patches for platforms that use these
bridges will be sent separately.
Shouldn't these guys:
+ u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
+ };
+ u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
+ { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
+ { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
+ { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
+ };
+ u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
be static, and maybe __devinitdata? Right now, the CPU has to populate
them by hand at runtime.
+wait_for_ownership(int chan)
+{
+ int i;
+
+ for (i=0; iMAX_TX_WAIT; i++) {
+ if ((MV64x60_REG_READ(sdma_regs[chan].sdcm)
+ SDMA_SDCM_TXD) == 0)
+ break;
+
+ udelay(1000);
ow, big busywait. Can't use a sleep in here? I guess not :(
+ * arch/ppc/boot/simple/mv64x60_tty.c
hm. Normally we put arch-specific drivers like this into drivers/serial
and do the appropriate Kconfig work. Is there a reason why this serial
driver is buried under arch/ppc?
+#include ../../../../drivers/serial/mpsc_defs.h
erk.
+struct mv64x60_rx_desc {
+ volatile u16 bufsize;
+ volatile u16 bytecnt;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
+
+struct mv64x60_tx_desc {
+ volatile u16 bytecnt;
+ volatile u16 shadow;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
Do these need to be volatile? If so, it indicates that the driver is doing
something wrong.
+gt64260_register_hdlrs(void)
+{
+ /* Register CPU interface error interrupt handler */
+ request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
+ SA_INTERRUPT, CPU_INTR_STR, 0);
request_irq() can fail.
+int
+mv64360_get_irq(struct pt_regs *regs)
+{
+ int irq;
+ int irq_gpp;
+
+#ifdef CONFIG_SMP
+ /*
+* Second CPU gets only doorbell (message) interrupts.
+* The doorbell interrupt is BIT28 in the main interrupt low cause reg.
+*/
+ int cpu_nr = smp_processor_id();
This function has no callers, so I am unable to determine whether it is
called from non-preemptible code. If it is called from preemptible code
then that smp_processor_id() is buggy, because you can switch CPUs at any
time.
+static struct platform_device mpsc_shared_device = { /* Shared device */
+ .name = MPSC_SHARED_NAME,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
+ .resource = mv64x60_mpsc_shared_resources,
+ .dev = {
+ .driver_data = (void *)mv64x60_mpsc_shared_pd_dd,
+ },
+};
The cast to void* is unnecessary.
+ (void)mv64x60_setup_for_chip(bh);
how come you always stick that (void) in there?
+mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
+ struct mv64x60_setup_info *si,
+ u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
+{
+ u32 i, win;
+ u32 prot_tab[] = {
+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
+ };
+ u32 cpu_snoop_tab[] = {
+ MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
+ MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
+ };
static initialisation?
+mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh,
+ struct mv64x60_pci_info *pi, u32 bus)
+{
+ int i;
+ u32 win_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN,
+ MV64x60_CPU2PCI0_MEM_1_WIN,
+ MV64x60_CPU2PCI0_MEM_2_WIN },
+ { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN,
+ MV64x60_CPU2PCI1_MEM_1_WIN,
+ MV64x60_CPU2PCI1_MEM_2_WIN },
+ };
+ u32 remap_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_1_REMAP_WIN,
+
