* " Problem in copying files into /mnt/jffs2 directory "
From: nreddy @ 2005-10-06 9:17 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: u-boot-users
Hi All,
I am working on PPC405ep (walnut board) board which has 4MB AMD flash and
working fine .
Recently we have increased FLASH size to 8MB and modified Flash drivers
accordingly.
I have taken some help from uboot users.
Thanks for giving such kind of invaluable help.
Now the system is up and running well, but i get into some other problem
like when copying files to /mnt/jffs2 directory it is taking so much extra
time to copy files.
But when i was using 4MB flash it was taking 1/4 of this time.
Can some one throw a lite on this.
Thanks & Regards,
--Nagi
^ permalink raw reply
* Re: [U-Boot-Users] " Problem in copying files into /mnt/jffs2 directory "
From: Wolfgang Denk @ 2005-10-06 9:38 UTC (permalink / raw)
To: nreddy; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <54964.61.95.208.3.1128590223.squirrel@61.95.208.3>
In message <54964.61.95.208.3.1128590223.squirrel@61.95.208.3> you wrote:
>
> Now the system is up and running well, but i get into some other problem
> like when copying files to /mnt/jffs2 directory it is taking so much extra
> time to copy files.
> But when i was using 4MB flash it was taking 1/4 of this time.
This is off topic *both* on the U-Boot and on the linuxppc-embedded
mailing lists. The MTD mailing list would be a much better place for
such questions (linux-mtd@lists.infradead.org). But before posting
ther make sure to include some detail about your system: type of
flash chips used, which versionof the MTD / JFFS2 driver code, which
exact kernel version. And make sure to read the instructions at
http://www.linux-mtd.infradead.org/mail.html, especially the section
about kernel versions
http://www.linux-mtd.infradead.org/source.html#kernelversions
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Nothing ever becomes real until it is experienced. - John Keats
^ permalink raw reply
* Re: [PATCH 2/3][PPC32] PCI-X support for Yucca
From: Ruslan V. Sushko @ 2005-10-06 10:32 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051003161559.GA21682@gate.ebshome.net>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
This is updated PCIX patch after Eugene comments. Now the
ppc4xx_uic_ext_irq_cfg and ppc4xx_core_uic_cfg structures are used to
initialize Yucca Interrupt controllers
On Mon, 2005-10-03 at 09:15 -0700, Eugene Surovegin wrote:
> On Mon, Oct 03, 2005 at 12:36:08PM +0400, Ruslan V. Sushko wrote:
> > This patch adds PCIX support for Yucca PPC440SPe board. The patch is
> > implemented for Roland Dreier git tree for Yucca PPC440SPe board.
> >
> > Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
>
> [snip]
>
> > + mtdcr(DCRN_UIC_PR(UIC1),
> > + mfdcr(DCRN_UIC_PR(UIC1)) & ~0x00004000); /* Set PCI interrupt
> > + (EXT IRQ12) plarity
> > + to Negative */
>
> Don't mess with UIC registers directly. Take a look how this type of
> setup is done in other 4xx ports (e.g. Ebony) and use the same
> approach (hint: ppc4xx_uic_ext_irq_cfg).
>
[-- Attachment #2: yucca_pcix2.patch --]
[-- Type: text/x-patch, Size: 8777 bytes --]
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -58,6 +58,25 @@ bd_t __res;
static struct ibm44x_clocks clocks __initdata;
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ15: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ14: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ13: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ12: PCI-X slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ11: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ10: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ9: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ8: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ7: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ6: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ5: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ4: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ3: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ2: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ1: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ0: EXT */
+};
+
static void __init
yucca_calibrate_decr(void)
{
@@ -86,19 +105,19 @@ yucca_map_irq(struct pci_dev *dev, unsig
struct pci_controller *hose = pci_bus_to_hose(dev->bus->number);
/* PCIX */
- if (hose->index == 3) {
+ if (hose->index == 0) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
- { 81, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
+ { 49, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
};
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
- return PCI_IRQ_TABLE_LOOKUP;
+ return PCI_IRQ_TABLE_LOOKUP;
/* PCIE0 */
- } else if (hose->index == 0) {
+ } else if (hose->index == 1) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -110,7 +129,7 @@ yucca_map_irq(struct pci_dev *dev, unsig
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
/* PCIE1 */
- } else if (hose->index == 1) {
+ } else if (hose->index == 2) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -122,7 +141,7 @@ yucca_map_irq(struct pci_dev *dev, unsig
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
/* PCIE2 */
- } else if (hose->index == 2) {
+ } else if (hose->index == 3) {
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
@@ -150,10 +169,123 @@ static void __init yucca_set_emacdata(vo
memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
}
+#define PCIX_READW(offset) \
+ (readw((void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEW(value, offset) \
+ (writew(value, (void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEL(value, offset) \
+ (writel(value, (void *)((u32)pcix_reg_base+offset)))
+
+static void __init
+yucca_setup_pcix(void)
+{
+ void *pcix_reg_base;
+
+ pcix_reg_base = ioremap64(PCIX0_REG_BASE, PCIX_REG_SIZE);
+
+ /* Disable all windows */
+ PCIX_WRITEL(0, PCIX0_POM0SA);
+ PCIX_WRITEL(0, PCIX0_POM1SA);
+ PCIX_WRITEL(0, PCIX0_POM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SAH);
+ PCIX_WRITEL(0, PCIX0_PIM1SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SAH);
+
+ /*
+ * Setup 512MB PLB->PCI outbound mem window
+ * (a_n000_0000->0_n000_0000)
+ * */
+ PCIX_WRITEL(0x0000000d, PCIX0_POM0LAH);
+ PCIX_WRITEL(0x80000000, PCIX0_POM0LAL);
+ PCIX_WRITEL(0x00000000, PCIX0_POM0PCIAH);
+ PCIX_WRITEL(0x80000000, PCIX0_POM0PCIAL);
+ PCIX_WRITEL(0xe0000001, PCIX0_POM0SA);
+
+ /* Setup 1GB PCI->PLB inbound memory window at 0, enable MSIs */
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAH);
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAL);
+ PCIX_WRITEL(0xc0000007, PCIX0_PIM0SA);
+ PCIX_WRITEL(0xffffffff, PCIX0_PIM0SAH);
+
+ /* Enable PCIX0 I/O, Mem, and Busmaster cycles */
+ PCIX_WRITEW(PCIX_READW(PCIX0_COMMAND) | PCI_COMMAND_MEMORY |
+ PCI_COMMAND_MASTER, PCIX0_COMMAND);
+
+ iounmap(pcix_reg_base);
+ eieio();
+}
+
+static void __init
+yucca_setup_hose(struct pci_controller *hose,
+ int lower_mem,
+ int upper_mem,
+ int cfga,
+ int cfgd,
+ u64 pcix_io_base)
+{
+ char name[20];
+
+ sprintf(name, "PCIX%d host bridge", hose->index);
+
+ hose->pci_mem_offset = YUCCA_PCIX_MEM_OFFSET;
+
+ pci_init_resource(&hose->io_resource,
+ YUCCA_PCIX_LOWER_IO,
+ YUCCA_PCIX_UPPER_IO,
+ IORESOURCE_IO,
+ name);
+
+ pci_init_resource(&hose->mem_resources[0],
+ lower_mem,
+ upper_mem,
+ IORESOURCE_MEM,
+ name);
+
+ hose->io_space.start = YUCCA_PCIX_LOWER_IO;
+ hose->io_space.end = YUCCA_PCIX_UPPER_IO;
+ hose->mem_space.start = lower_mem;
+ hose->mem_space.end = upper_mem;
+ isa_io_base =
+ (unsigned long)ioremap64(pcix_io_base, PCIX_IO_SIZE);
+ hose->io_base_virt = (void *)isa_io_base;
+
+ setup_indirect_pci(hose, cfga, cfgd);
+ hose->set_cfg_type = 1;
+}
+
+
static void __init
yucca_setup_hoses(void)
{
+ struct pci_controller *hose;
+
+ /* Configure windows on the PCI-X host bridge */
+ yucca_setup_pcix();
+
+ /* Allocate hoses for PCIX0 */
+ hose = pcibios_alloc_controller();
+ if (!hose)
+ return;
+
+ /* Setup PCIX0 */
+ hose->first_busno = 0;
+ hose->last_busno = 0xff;
+
+ yucca_setup_hose(hose,
+ YUCCA_PCIX_LOWER_MEM,
+ YUCCA_PCIX_UPPER_MEM,
+ PCIX0_CFGA,
+ PCIX0_CFGD,
+ PCIX0_IO_BASE);
+
+ hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+ ppc_md.pci_swizzle = common_swizzle;
+ ppc_md.pci_map_irq = yucca_map_irq;
}
TODC_ALLOC();
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_GT64260) += gt64260_pic.o
obj-$(CONFIG_LOPEC) += i8259.o pci_auto.o todc_time.o
obj-$(CONFIG_HDPU) += pci_auto.o
obj-$(CONFIG_LUAN) += indirect_pci.o pci_auto.o todc_time.o
+obj-$(CONFIG_YUCCA) += indirect_pci.o pci_auto.o
obj-$(CONFIG_KATANA) += pci_auto.o
obj-$(CONFIG_MV64360) += mv64360_pic.o
obj-$(CONFIG_MV64X60) += mv64x60.o mv64x60_win.o indirect_pci.o
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -64,6 +64,11 @@
#define PPC44x_PCICFG_PAGE 0x0000000900000000ULL
#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
#define PPC44x_PCIMEM_PAGE 0x0000000a00000000ULL
+#elif defined(CONFIG_440SPE)
+#define PPC44x_IO_PAGE 0x0000000400000000ULL
+#define PPC44x_PCICFG_PAGE 0x0000000C00000000ULL
+#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
+#define PPC44x_PCIMEM_PAGE 0x0000000D00000000ULL
#elif defined(CONFIG_440EP)
#define PPC44x_IO_PAGE 0x0000000000000000ULL
#define PPC44x_PCICFG_PAGE 0x0000000000000000ULL
@@ -552,12 +557,19 @@
#define PCIX1_CFGD 0x1ec00004UL
#define PCIX2_CFGD 0x2ec00004UL
+#if defined (CONFIG_440SPE)
+#define PCIX0_IO_BASE 0x0000000C08000000ULL
+#else /* !CONFIG_440SPE */
#define PCIX0_IO_BASE 0x0000000908000000ULL
#define PCIX1_IO_BASE 0x0000000908000000ULL
#define PCIX2_IO_BASE 0x0000000908000000ULL
+#endif /* CONFIG_440SPE */
+
#define PCIX_IO_SIZE 0x00010000
-#ifdef CONFIG_440SP
+#if defined (CONFIG_440SPE)
+#define PCIX0_REG_BASE 0x0000000c0ec80000ULL
+#elif defefined(CONFIG_440SP)
#define PCIX0_REG_BASE 0x000000090ec80000ULL
#else
#define PCIX0_REG_BASE 0x000000020ec80000ULL
diff --git a/arch/ppc/platforms/4xx/ppc440spe.c b/arch/ppc/platforms/4xx/ppc440spe.c
--- a/arch/ppc/platforms/4xx/ppc440spe.c
+++ b/arch/ppc/platforms/4xx/ppc440spe.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <platforms/4xx/ppc440spe.h>
#include <asm/ocp.h>
+#include <asm/ppc4xx_pic.h>
static struct ocp_func_emac_data ppc440spe_emac0_def = {
.rgmii_idx = -1, /* No RGMII */
@@ -132,3 +133,23 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_INVALID
}
};
+
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0xffbfdfff,
+ .triggering = 0x010f0004,
+ .ext_irq_mask = 0x00402000, /* IRQ15 - IRQ14 */
+ },
+ { .polarity = 0x7fff83cf,
+ .triggering = 0x001f8004,
+ .ext_irq_mask = 0x80007c30, /* IRQ13 - IRQ6 */
+ },
+ { .polarity = 0xebebeb00,
+ .triggering = 0x74747400,
+ .ext_irq_mask = 0x000000fc, /* IRQ5 - IRQ0 */
+ },
+ { .polarity = 0xffffffff,
+ .triggering = 0x001fffff,
+ .ext_irq_mask = 0x00000000, /* No external interrupts */
+ },
+};
+
^ permalink raw reply
* Re: problems with dma_alloc_coherent and consistent_alloc
From: Marcelo Tosatti @ 2005-10-05 23:05 UTC (permalink / raw)
To: Earl Olsen; +Cc: linuxppc-embedded
In-Reply-To: <B8561865DB141248943E2376D0E8521501420346@DHOST001-17.DEX001.intermedia.net>
On Wed, Oct 05, 2005 at 02:21:01PM -0700, Earl Olsen wrote:
>
> (Sorry, I had trouble outlook and messed up the subject line)
>
> We are using a PPC 750 with 512m of RAM.
I dont know much about your hardware, but I'll shoot anyway.
> 1) When we try to allocate memory using consistent_alloc we get a
> failure with get_pteptr - there is no pte.
>
> 2) When we try using dma_alloc_coherent the system locks up when
> we try to access that memory.
>
> I'm guessing these problems stem from the memory being allocated
> is from the 384 bytes of RAM that gets handed over to BATs 2 AND 3,
You mean Mbytes?
> not the remaining memory handled by the page table.
>
> In the first case, pages are allocated, but since if came from the
> BAT region, will not have a page table mapping.
>
> In the second case, if dma_alloc_init gets memory from the BAT
> region, then we have the BAT and page management mechanisms
> both trying to control the memory.
>
> Does this sound like a good theory? Has anybody encountered
> this problem before?
The kernel should create pte tables for all RAM, even if parts of
memory are not accessed through pagetable mappings.
^ permalink raw reply
* mpc8272ads support in linux-2.4
From: Alex Zeffertt @ 2005-10-06 16:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
I have read that the MPC8272ADS board is supported in linux-2.6. Has
anybody backported this support to linux-2.4. I am using linux-2.4.25
from ELDK. If anyone has a patch I would be very grateful if they
sent it to me.
Regards,
Alex Zeffertt
PS Does anyone know where the master PPC patches are kept? I.e. the
ones you apply to kernels from kernel.org to get all the stuff that
hasn't yet been upstreamed.
^ permalink raw reply
* TKO Notice: ***Urgent Safeharbor Department Notice***
From: aw-confirm @ 2005-10-06 20:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 4482 bytes --]
^ permalink raw reply
* TKO Notice: ***Urgent Safeharbor Department Notice***
From: aw-confirm @ 2005-10-06 20:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 4482 bytes --]
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Paul Mackerras @ 2005-10-06 23:24 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <XFMail.20050929092052.pochini@shiny.it>
Giuliano Pochini writes:
> Out of curiosity, is there any advantage in using a 32 bits
> kernel on ppc64 over a 64 bits kernel ? Speed ? Complexity ?
> Compatibility ? Memory ?
Not really. The main thing in the past has been that DRI with 32-bit
X server and clients would work with a 32-bit kernel but not a 64-bit
kernel, but that's fixed now. A 64-bit kernel is faster on most
lmbench tests. I guess a 32-bit kernel might end up a little smaller,
but that's the only possible advantage I can think of.
Paul.
^ permalink raw reply
* Two bugs in handling of highmem on PPC
From: Paolo Galtieri @ 2005-10-06 23:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]
Folks,
in looking at the PPC code for handling highmem and it appears to me
that there are two bugs in how the data is written out by
__dma_sync_page_highmem().
The first is how the size of the first segment is calculated, and the
second is in the calculation of the number of segments to write out.
In the case of the first bug here is the code:
size_t seg_size = min((size_t)PAGE_SIZE, size) - offset;
The intent here is to determine the number of bytes you can write in the
current page given that kmap_atomic() maps pages in one at a time. The
problem with this code is depending on the values of size and offset the
result can be negative, e.g. if size is 200 and offset is 800 then:
seg_size = min(4096, 200) - 800
seg_size = 200 - 800
seg_size = -600;
At best this will cause an OOPs, but more likely a panic, when you call
__dma_sync() because your end address will be lower than the start
address. I believe the correct calculation should be:
size_t seg_size = min((size_t)(PAGE_SIZE - offset), size);
Here (PAGE_SIZE - offset) gives you the amount of space left in the page
which is really what you want to use when determining the number of
bytes you can write.
In the case of the second bug here is the code:
int nr_segs = PAGE_ALIGN(size + (PAGE_SIZE - offset))/PAGE_SIZE;
The first thing that sticks out is why is the macro PAGE_ALIGN(), which
is supposed to take an address as a parameter, being called with a size?
The problem with this code is that it returns the wrong number of
segments. For example, if size is 200 and the offset is 4095 this will
return 1 as the number of segments. This is wrong, there are in fact 2
segments to write, 1 byte in the current page and 199 bytes in the next
page. I believe the correct calculation should be:
1 + ((size - seg_size) + PAGE_SIZE - 1)/PAGE_SIZE;
The 1 represents the first segment which will always get written, the
rest represents the number of full and partial pages that need to be
written out. For example, if we have a size of 200 and an offset of
4095 then seg_size is 1 (min(4096 - 4095, 200)) so the number of
segments comes out to:
nr_segs = 1 + (200 - 1 + 4096 - 1)/4096
nr_segs = 1 + 4294/4096
nr_segs = 1 + 1
nr_segs = 2
Which is correct.
I would very much appreciate it if those of you who are more familiar
with this part of the kernel could review and comment on my
interpretation of what is going on and provide feedback.
Thank you,
Paolo Galtieri
I have attached a patch that is made against 2.6.14-rc3-git6
[-- Attachment #2: PPC-highmempatch --]
[-- Type: text/plain, Size: 678 bytes --]
--- linux-2.6.14/arch/ppc/kernel/dma-mapping.c.orig 2005-10-06 15:50:46.000000000 -0700
+++ linux-2.6.14/arch/ppc/kernel/dma-mapping.c 2005-10-06 15:51:40.000000000 -0700
@@ -401,10 +401,10 @@
static inline void __dma_sync_page_highmem(struct page *page,
unsigned long offset, size_t size, int direction)
{
- size_t seg_size = min((size_t)PAGE_SIZE, size) - offset;
+ size_t seg_size = min((size_t)(PAGE_SIZE - offset), size);
size_t cur_size = seg_size;
unsigned long flags, start, seg_offset = offset;
- int nr_segs = PAGE_ALIGN(size + (PAGE_SIZE - offset))/PAGE_SIZE;
+ 1 + ((size - seg_size) + PAGE_SIZE - 1)/PAGE_SIZE;
int seg_nr = 0;
local_irq_save(flags);
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Benjamin Herrenschmidt @ 2005-10-07 0:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AFEB186E-99B9-4BE8-9AE3-315C74277483@freescale.com>
> Dope, you're right. I notice that we apparent do this for BTIC and
> DPM in this function though?
Yes, those bits are buggy. Good catch
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Benjamin Herrenschmidt @ 2005-10-07 0:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1128644808.17365.2.camel@gaston>
On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
> > Dope, you're right. I notice that we apparent do this for BTIC and
> > DPM in this function though?
>
> Yes, those bits are buggy. Good catch
And no, in fact, my brain is buggy... On ppc32 we identify first, then
fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
actually goes test the feature bit.
I think ppc64 does it the other way around. ppc64 certainly _requires_
taht the fixup has not yet been applied while running early_setup() as
it may change some CPU features according to firmware properties.
So in the merged kernel, we need to be extra careful here. I think we
should go the ppc64 way actually and apply the fixups later. But that
means fixing the code in cpu_setup_6xx.S indeed.
Ben.
^ permalink raw reply
* Re: Two bugs in handling of highmem on PPC
From: Benjamin Herrenschmidt @ 2005-10-07 0:54 UTC (permalink / raw)
To: Paolo Galtieri; +Cc: linuxppc-dev
In-Reply-To: <1128639689.4809.19.camel@playin.mvista.com>
>
> I would very much appreciate it if those of you who are more familiar
> with this part of the kernel could review and comment on my
> interpretation of what is going on and provide feedback.
While the first bit of your patch makes some sense, the second one
doesn't at all to me, you must be missing something there...
Ben
^ permalink raw reply
* Problem Regarding Ping in Linux kernel version 2.4.24
From: apoorv sangal @ 2005-10-07 5:05 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: sibi_mathew, vikrant_basotra, apoorv sangal
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Hi All,
I have ported Linux kernel version 2.4.24 on MPC8266 based customized
Board, having LXT971 ethernet chip.
The root file system is JFFS2 which i have made using mkfs.jffs2 utility
which comes along with the ELDK 3.0
In the kernel code i checked that there is support for the LXT971 chip, but
even after enabling all the network related funcuntionalities in the linux
kernel configuration, I am either not able to ping from the board to any
machine on the network, nor from the any other machine to the board.
The board is able to ping itself.
Can some one please throw some light why the board is not able to ping any
other machine.
Regards
Apoorv Sangal
[-- Attachment #2: Type: text/html, Size: 845 bytes --]
^ permalink raw reply
* Re: 8260 PQ2FADS
From: vanamali gouripeddi @ 2005-10-07 7:17 UTC (permalink / raw)
To: linuxppc-embedded
hi
after the configuration and installation of binutils-2.16.1 i hav
added headers in the same tools directory now as iam trying to
configure gcc-2.95.3 the following error is displayed after the make
command
-mppc not identified
libcc2.a as one error and
stmp-multilib-sub
as the other plz provide the solution as we running out of time
On 10/7/05, linuxppc-embedded-request@ozlabs.org
<linuxppc-embedded-request@ozlabs.org> wrote:
> Send Linuxppc-embedded mailing list submissions to
> =09linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =09https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> =09linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> =09linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
> 1. mpc8272ads support in linux-2.4 (Alex Zeffertt)
> 2. TKO Notice: ***Urgent Safeharbor Department Notice***
> (aw-confirm@eBay.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Oct 2005 17:36:27 +0100
> From: Alex Zeffertt <ajz@cambridgebroadband.com>
> Subject: mpc8272ads support in linux-2.4
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <20051006173628.53f25862.ajz@cambridgebroadband.com>
> Content-Type: text/plain; charset=3DUS-ASCII
>
> Hi list,
>
> I have read that the MPC8272ADS board is supported in linux-2.6. Has
> anybody backported this support to linux-2.4. I am using linux-2.4.25
> from ELDK. If anyone has a patch I would be very grateful if they
> sent it to me.
>
> Regards,
>
> Alex Zeffertt
>
> PS Does anyone know where the master PPC patches are kept? I.e. the
> ones you apply to kernels from kernel.org to get all the stuff that
> hasn't yet been upstreamed.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 6 Oct 2005 16:57:36 -0400 (EDT)
> From: aw-confirm@eBay.com <aw-confirm@eBay.com>
> Subject: TKO Notice: ***Urgent Safeharbor Department Notice***
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <20051006205736.38DA586FEE6@athens.9degrees.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051006/af0ff7=
7a/attachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 14, Issue 10
> *************************************************
>
^ permalink raw reply
* mpc8248 and FCC ethernet
From: Wojciech Kromer @ 2005-10-07 9:14 UTC (permalink / raw)
To: linuxppc-embedded
What are differences between using FCC in u-boot and kernel?
I have fine working u-boot on my new mpc8248 board,
I can sucessfully download kernel via ethernet on FCC1.
But inside kernel all RX frames are filled with 0xff data,
also send frames I can see on the other side, are full of 0xff.
Clocks and other FCC aware registers seems to be correct.
The same version on linux (2_4_devel from denx.de) works fine
on another mpc8260 board.
Any hints? Where to find differences?
What should be important to check?
^ permalink raw reply
* about pci net controller without EPROM onboard
From: ÏÄÓê @ 2005-10-07 10:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: deboralh
Thanks for the help , i found out that the kernel was not configued well for pci net card .
Now i am boarding U-BOOT and kernel(linuxppc) to my own board (based on MPC5200,have a i82551 on board without
EPROM).After i set the eth1addr ,U-boot could tftp files through the i82551 chip :
PCI: Bus Dev VenId DevId Class Int
00 18 8086 1209 0200 00
00 1a 1057 5803 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, i82559#0
But after the kernel bootup ,i could not find eth1 ,message during bootup as follow :
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 00:1a.0
Intel(R) PRO/100 Network Driver - version 2.3.38-k1
Copyright (c) 2004 Intel Corporation
PCI: Enabling device 00:18.0 (0006 -> 0007)
e100: Invalid Ethernet address
e100: Failed to initialize, instance #0
How can i make the chip active ?
^ permalink raw reply
* RE: mpc8248 and FCC ethernet
From: Fillod Stephane @ 2005-10-07 11:21 UTC (permalink / raw)
To: Wojciech Kromer, linuxppc-embedded
Wojciech Kromer wrote:
[..]
>But inside kernel all RX frames are filled with 0xff data,
>also send frames I can see on the other side, are full of 0xff.
>Clocks and other FCC aware registers seems to be correct.
>The same version on linux (2_4_devel from denx.de) works fine
>on another mpc8260 board.
Most likely, you're using a wrong DPRAM range.
This reminds me this problem "All-ones problem with FCC1 on MPC8541"
=20
http://ozlabs.org/pipermail/linuxppc-embedded/2004-November/016050.html
so double check your manual. The MPC8555E manual is still wrong in
this regard, and no errata has been issued yet.
--=20
Stephane
^ permalink raw reply
* Re: mpc8272ads support in linux-2.4
From: Vitaly Bordug @ 2005-10-07 11:57 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20051006173628.53f25862.ajz@cambridgebroadband.com>
Alex Zeffertt wrote:
> Hi list,
>
> I have read that the MPC8272ADS board is supported in linux-2.6. Has
> anybody backported this support to linux-2.4. I am using linux-2.4.25
> from ELDK. If anyone has a patch I would be very grateful if they
> sent it to me.
>
Yes, it has been supported within 2.4 tree in bitkeeper days.
The source you can rsync from source.mvista.com (take a look at
http://penguinppc.org/kernel/.
> Regards,
>
> Alex Zeffertt
>
> PS Does anyone know where the master PPC patches are kept? I.e. the
> ones you apply to kernels from kernel.org to get all the stuff that
> hasn't yet been upstreamed.
Actually answer is nowhere AFAIK. Now with git, we are working with
maintainers, and often with Andrew Morton directly, so ppc patches
usually are pushed without inbetween place unlike they used to.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Problem Regarding Ping in Linux kernel version 2.4.24
From: Aristeu Sergio Rozanski Filho @ 2005-10-07 12:31 UTC (permalink / raw)
To: apoorv sangal
Cc: apoorv sangal, vikrant_basotra, sibi_mathew, Linuxppc-embedded
In-Reply-To: <a79669360510062205v629affb9ga687078f018afae@mail.gmail.com>
Hi,
> I have ported Linux kernel version 2.4.24 on MPC8266 based customized
> Board, having LXT971 ethernet chip.
> The root file system is JFFS2 which i have made using mkfs.jffs2 utility which
> comes along with the ELDK 3.0
> In the kernel code i checked that there is support for the LXT971 chip, but
> even after enabling all the network related funcuntionalities in the linux
> kernel configuration, I am either not able to ping from the board to any
> machine on the network, nor from the any other machine to the board.
> The board is able to ping itself.
> Can some one please throw some light why the board is not able to ping any
> other machine.
try to comment this line in LXT971 section of driver:
{ mk_mii_write(MII_REG_CR, 0x1200), NULL }, /* autonegotiate */
and check if it works
--
Aristeu
^ permalink raw reply
* Your Account is Suspended For Security Reasons
From: service @ 2005-10-07 13:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 625 bytes --]
[-- Attachment #2: important-details.zip --]
[-- Type: application/octet-stream, Size: 53536 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Kumar Gala @ 2005-10-07 14:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1128645230.17365.5.camel@gaston>
On Oct 6, 2005, at 7:33 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
>
>>> Dope, you're right. I notice that we apparent do this for BTIC and
>>>
>
>
>>> DPM in this function though?
>>>
>>
>> Yes, those bits are buggy. Good catch
>>
>
> And no, in fact, my brain is buggy... On ppc32 we identify first, then
> fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
> actually goes test the feature bit.
>
> I think ppc64 does it the other way around. ppc64 certainly _requires_
> taht the fixup has not yet been applied while running early_setup() as
> it may change some CPU features according to firmware properties.
>
> So in the merged kernel, we need to be extra careful here. I think we
> should go the ppc64 way actually and apply the fixups later. But that
> means fixing the code in cpu_setup_6xx.S indeed.
Well, since we do this early on ppc32, my patch should be ok than.
(And is need on 7448, do to some crazyness in how L3CR works on
various versions of 7448).
I'd like to see we push this now and worry about "fixing" all of
cpu_setup_6xx.S when we move it over to arch/powerpc
- kumar
^ permalink raw reply
* TQM8260 and linux-2.6.14-rc3
From: Studencki Pawel @ 2005-10-07 14:55 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
hello,
Trying to boot linux-2.6.14-rc3 on TQM8260 I found,
that following line is missing in file arch/ppc/syslib/m8260_setup.c:
-----------------------------------------------------------------------
--- m8260_setup.c.org 2005-10-07 16:42:41.420238000 +0200
+++ m8260_setup.c 2005-10-07 16:41:58.811408400 +0200
@@ -249,6 +249,8 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ identify_ppc_sys_by_id(mfspr(SPRN_SVR));
+
ppc_md.setup_arch = m8260_setup_arch;
ppc_md.show_cpuinfo = m8260_show_cpuinfo;
ppc_md.init_IRQ = m8260_init_IRQ;
---------------------------------------------------------------------
if not set, we get problem here:
static int __init ppc_sys_init(void)
{
unsigned int i, dev_id, ret = 0;
BUG_ON(cur_ppc_sys_spec == NULL); <--------------------------
Moreover the default configuration found in
arch/ppc/configs/TQM8260_defconfig
doesn't work or I do something wrong.
for example configuration of serial port:
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=32
inspite of this I use following(SMC1):
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
# CONFIG_SERIAL_CPM_SCC1 is not set
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
CONFIG_SERIAL_CPM_SMC1=y
# CONFIG_SERIAL_CPM_SMC2 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
best regards
Pawel
^ permalink raw reply
* Re: TQM8260 and linux-2.6.14-rc3
From: Vitaly Bordug @ 2005-10-07 15:12 UTC (permalink / raw)
To: Studencki Pawel; +Cc: linuxppc-embedded list
In-Reply-To: <253377027D27DA11B7010002A5AE5CFE0B72B6@nbgh103a.nbg6.siemens.de>
Studencki Pawel wrote:
> hello,
>
> Trying to boot linux-2.6.14-rc3 on TQM8260 I found,
> that following line is missing in file arch/ppc/syslib/m8260_setup.c:
>
> -----------------------------------------------------------------------
> --- m8260_setup.c.org 2005-10-07 16:42:41.420238000 +0200
> +++ m8260_setup.c 2005-10-07 16:41:58.811408400 +0200
> @@ -249,6 +249,8 @@
> strcpy(cmd_line, (char *)(r6+KERNELBASE));
> }
>
> + identify_ppc_sys_by_id(mfspr(SPRN_SVR));
> +
This is not quite right. For these types of boards (at least, most of),
the soc id is stored in the immr register. But yes, that's definitely a
problem, I'll take a look at this asap.
> ppc_md.setup_arch = m8260_setup_arch;
> ppc_md.show_cpuinfo = m8260_show_cpuinfo;
> ppc_md.init_IRQ = m8260_init_IRQ;
> ---------------------------------------------------------------------
>
>
> if not set, we get problem here:
>
> static int __init ppc_sys_init(void)
> {
> unsigned int i, dev_id, ret = 0;
>
> BUG_ON(cur_ppc_sys_spec == NULL); <--------------------------
>
>
> Moreover the default configuration found in
> arch/ppc/configs/TQM8260_defconfig
> doesn't work or I do something wrong.
> for example configuration of serial port:
>
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> # CONFIG_SERIAL_8250_EXTENDED is not set
>
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_UNIX98_PTY_COUNT=32
>
> inspite of this I use following(SMC1):
>
> #
> # Serial drivers
> #
> # CONFIG_SERIAL_8250 is not set
>
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_SERIAL_CPM=y
> CONFIG_SERIAL_CPM_CONSOLE=y
> # CONFIG_SERIAL_CPM_SCC1 is not set
> # CONFIG_SERIAL_CPM_SCC2 is not set
> # CONFIG_SERIAL_CPM_SCC3 is not set
> # CONFIG_SERIAL_CPM_SCC4 is not set
> CONFIG_SERIAL_CPM_SMC1=y
> # CONFIG_SERIAL_CPM_SMC2 is not set
> CONFIG_UNIX98_PTYS=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=256
>
>
> best regards
> Pawel
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Important Notification
From: webmaster @ 2005-10-07 14:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 721 bytes --]
[-- Attachment #2: email-details.zip --]
[-- Type: application/octet-stream, Size: 53528 bytes --]
^ permalink raw reply
* ALERT - GroupShield ticket number OA523_1128698597_BATISTUTA_1 w as generated
From: GroupShield for Exchange (BATISTUTA) @ 2005-10-07 15:23 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.
To:
linuxppc-embedded@ozlabs.org <linuxppc-embedded@ozlabs.org>
From:
webmaster@ozlabs.org <webmaster@ozlabs.org>
Sent:
-1198011008,29739847
Subject:
Important Notification
Attachment Details:-
Attachment Name: email-details.zip
File: email-details.zip
Infected? Yes
Repaired? No
Blocked? No
Deleted? No
Virus Name: Generic Malware.a!zip
[-- Attachment #2: Type: application/ms-tnef, Size: 1935 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox