* RE: Generated xilinx linux 2.6 image sections
From: greenlean @ 2008-01-22 9:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080121184553.569BF179805C@mail212-sin.bigfish.com>
I've got two DDR memories declared on my EDK xparameters_ml300.h file
/* Definitions for driver DDR */
#define XPAR_XDDR_NUM_INSTANCES 1
/* Definitions for peripheral DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5 */
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_ECC_BASEADDR
0xFFFFFFFF
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_ECC_HIGHADDR
0x00000000
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_DEVICE_ID 0
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_INCLUDE_ECC_INTR 0
/******************************************************************/
/* Definitions for peripheral DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5 */
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM0_BASEADDR
0x00000000
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM0_HIGHADDR
0x0FFFFFFF
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM1_BASEADDR
0x10000000
#define XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM1_HIGHADDR
0x1FFFFFFF
/******************************************************************/
/* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xfffe0000
#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
/******************************************************************/
And my .config file is using this configuration for the memory:
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00400000
Should I change this options to make the kernel CONFIG_BOOT_LOAD start in
the seccond MEM1?, or is the problem caused by CONFIG_CONSISTENT_START?? How
are used this variables?? Is the kernel start address out of the memory ((
0xC0000000 > 0x1FFFFFFF??
I'm using a DDR 256 from Kingston KVR266X64C25/256 and when I run the
TestApp_Memory it fails at
-- Entering main() --
Starting MemoryTest for DDR_512MB_64Mx64_rank2_row13_col10_cl2_5:
Running 32-bit test...FAILED!
Running 16-bit test...FAILED!
Running 8-bit test...FAILED!
Starting MemoryTest for DDR_512MB_64Mx64_rank2_row13_col10_cl2_5:
Running 32-bit test...PASSED!
Running 16-bit test...PASSED!
Running 8-bit test...PASSED!
-- Exiting main() --
I thought that this didn't mind but the first test is form Mem0
(XUtil_MemoryTest32((Xuint32*)XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM0_BASEADDR)
and the second one is for mem1 (
XUtil_MemoryTest32((Xuint32*)XPAR_DDR_512MB_64MX64_RANK2_ROW13_COL10_CL2_5_MEM1_BASEADDR,
1024, 0xAAAA5555, XUT_ALLMEMTESTS);)
and the first one is failing so if the kernel is trying to boot from mem0
(CONFIG_BOOT_LOAD=0x00400000) i shouldn't boot, or should it?
Please, can someone confirm me this, while I try myself... I'm not sure how
this addresses works!!!
Stephen Neuendorffer wrote:
>
> The testapps are generated using a different linker script.
>
> Based on what you sent out, it looks like your EDK design has a memory
> at 0x10000000, but this is
> not reflected in the linux image you've generated. This makes me
> suspect that you haven't generated the BSP and copied the appropriate
> xparameters file over xparameters_xup.h (assuming you are using
> CONFIG_XILINX_XUPV2P).
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of greenlean
>> Sent: Monday, January 21, 2008 5:06 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Generated xilinx linux 2.6 image sections
>>
>>
>> Hi all,
>>
>> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
> server in
>> the XUPV2P board I'm really having troubles (I can't see anything in
> the
>> minicom console terminal). I'm not seeing anything, neither the
> ucompressing
>> kernel string nor the prompt with the memory addresses that kernel
> prompt at
>> first time, so I have started to distrust of anything.
>>
>> When I download the kernel using xmd, I see:
>>
>> XMD% dow imagen_UART16550_ml300.elf
>> section, .text: 0x00400000-0x0040387b
>> section, .data: 0x00404000-0x004e6fff
>> section, .bss: 0x004e7000-0x004e919f
>> Downloaded Program imagen_UART16550_ml300.elf
>> Setting PC with Program Start Address 0x00400000
>>
>> and when I download some of the TestApp generated by EDK I see:
>>
>> XMD% dow perif.elf
>> section, .vectors: 0xfffe0000-0xfffe20c3
>> section, .text: 0x10000000-0x10003b7b
>> section, .init: 0x10003b7c-0x10003b9f
>> section, .fini: 0x10003ba0-0x10003bbf
>> section, .boot0: 0xfffe20c4-0xfffe20d3
>> section, .boot: 0xfffffffc-0xffffffff
>> section, .rodata: 0x10003bc0-0x10004111
>> section, .sdata2: 0x10004114-0x10004113
>> section, .sbss2: 0x10004114-0x10004113
>> section, .data: 0x10004114-0x10004243
>> section, .got: 0x10004244-0x10004243
>> section, .got1: 0x10004244-0x10004243
>> section, .got2: 0x10004244-0x1000425f
>> section, .ctors: 0x10004260-0x10004267
>> section, .dtors: 0x10004268-0x1000426f
>> section, .fixup: 0x10004270-0x1000426f
>> section, .eh_frame: 0x10004270-0x10004277
>> section, .jcr: 0x10004278-0x1000427b
>> section, .gcc_except_table: 0x1000427c-0x100042
>> section, .sdata: 0x1000427c-0x10004293
>> section, .sbss: 0x10004294-0x100042a3
>> section, .bss: 0x100042a4-0x10004473
>> section, .stack: 0x10004474-0x1000647f
>> section, .heap: 0x10006480-0x1000847f
>> Downloaded Program perif.elf
>> Setting PC with Program Start Address 0xfffffffc
>>
>> Does anybody know why the kernel elf don't have a boot section like
> the
>> TestApp generated by EDK?
>>
>> I suppossed this is because the image kernel is compressed, but
> despite
>> beeing compressed it should have a boot section or something similar
> ???
>> It's right that the kernel start address is set to the 0x00400000??
>>
>> Or does the section .text contains all the kernel code to uncompresse
> the
>> code of the kernel??
>>
>>
>>
>> --
>> View this message in context:
> http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
>> tp14997109p14997109.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-tp14997109p15015244.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2] 8xx: Analogue & Micro Adder875 board support.
From: Stephen Rothwell @ 2008-01-22 9:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223140.GA17300@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Hi Scott,
Just one small thing.
On Thu, 17 Jan 2008 16:31:40 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static __initdata struct of_device_id __initdata of_bus_ids[] = {
You don't need to mark it __initdata twice ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: Jean Delvare @ 2008-01-22 10:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: David Brownell, linuxppc-dev, Linux I2C
In-Reply-To: <9e4733910801210850j39b9d51fy706b58ca15805f35@mail.gmail.com>
Hi Jon,
On Mon, 21 Jan 2008 11:50:13 -0500, Jon Smirl wrote:
> In my version of these patches new style drivers could be loaded with
> both the driver_name/name scheme and the modalias. In these patches
> new style drivers can only be loaded via modalias. Is that what you
> intended? I'm all for making new style driver only use the modalias
> scheme.
Yes, this is what I intended. I see no point in having two ways to
achieve the same result, it makes things more complex, more costly and
possibly confusing.
I would reconsider if someone points out a very good reason to keep both
schemes in parallel.
--
Jean Delvare
^ permalink raw reply
* [PATCH 1/4] Search for and publish cell OF platform devices earlier
From: Michael Ellerman @ 2008-01-22 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
Currently cell publishes OF devices at device_initcall() time, which
means the earliest a driver can bind to a device is also device_initcall()
time. We have a driver we want to register before other devices, so
publish the devices at subsys_initcall() time.
This should not cause any behaviour change for existing drivers, as they
are still bound at device_initcall() time.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index e6534b5..a7f609b 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -98,7 +98,7 @@ static int __init cell_publish_devices(void)
}
return 0;
}
-machine_device_initcall(cell, cell_publish_devices);
+machine_subsys_initcall(cell, cell_publish_devices);
static void cell_mpic_cascade(unsigned int irq, struct irq_desc *desc)
{
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/4] Create and hook up of_platform_device_shutdown
From: Michael Ellerman @ 2008-01-22 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3ce7be4c77581ce103a8da9f33a734270c9dc6e8.1200999872.git.michael@ellerman.id.au>
Although of_platform_device's can have a shutdown routine, at the moment
the bus code doesn't actually call it. So add the required glue to
hook the shutdown routine.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/of/platform.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b47bb2d..9152479 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -85,6 +85,15 @@ static int of_platform_device_resume(struct device * dev)
return error;
}
+static void of_platform_device_shutdown(struct device * dev)
+{
+ struct of_device *of_dev = to_of_device(dev);
+ struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+
+ if (dev->driver && drv->shutdown)
+ drv->shutdown(of_dev);
+}
+
int of_bus_type_init(struct bus_type *bus, const char *name)
{
bus->name = name;
@@ -93,6 +102,7 @@ int of_bus_type_init(struct bus_type *bus, const char *name)
bus->remove = of_platform_device_remove;
bus->suspend = of_platform_device_suspend;
bus->resume = of_platform_device_resume;
+ bus->shutdown = of_platform_device_shutdown;
return bus_register(bus);
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 3/4] Convert axon_msi to an of_platform driver
From: Michael Ellerman @ 2008-01-22 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3ce7be4c77581ce103a8da9f33a734270c9dc6e8.1200999872.git.michael@ellerman.id.au>
Now that we create of_platform devices earlier on cell, we can make the
axon_msi driver an of_platform driver. This makes the code cleaner in
several ways, and most importantly means we have a struct device.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/axon_msi.c | 76 ++++++++++++++-----------------
1 files changed, 34 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 095988f..8de3d23 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -13,8 +13,8 @@
#include <linux/kernel.h>
#include <linux/pci.h>
#include <linux/msi.h>
-#include <linux/reboot.h>
+#include <asm/of_platform.h>
#include <asm/dcr.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -67,12 +67,9 @@ struct axon_msic {
struct irq_host *irq_host;
__le32 *fifo;
dcr_host_t dcr_host;
- struct list_head list;
u32 read_offset;
};
-static LIST_HEAD(axon_msic_list);
-
static void msic_dcr_write(struct axon_msic *msic, unsigned int dcr_n, u32 val)
{
pr_debug("axon_msi: dcr_write(0x%x, 0x%x)\n", val, dcr_n);
@@ -292,30 +289,25 @@ static struct irq_host_ops msic_host_ops = {
.map = msic_host_map,
};
-static int axon_msi_notify_reboot(struct notifier_block *nb,
- unsigned long code, void *data)
+static int axon_msi_shutdown(struct of_device *device)
{
- struct axon_msic *msic;
+ struct axon_msic *msic = device->dev.platform_data;
u32 tmp;
- list_for_each_entry(msic, &axon_msic_list, list) {
- pr_debug("axon_msi: disabling %s\n",
- msic->irq_host->of_node->full_name);
- tmp = dcr_read(msic->dcr_host, MSIC_CTRL_REG);
- tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE;
- msic_dcr_write(msic, MSIC_CTRL_REG, tmp);
- }
+ pr_debug("axon_msi: disabling %s\n",
+ msic->irq_host->of_node->full_name);
+ tmp = dcr_read(msic->dcr_host, MSIC_CTRL_REG);
+ tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE;
+ msic_dcr_write(msic, MSIC_CTRL_REG, tmp);
return 0;
}
-static struct notifier_block axon_msi_reboot_notifier = {
- .notifier_call = axon_msi_notify_reboot
-};
-
-static int axon_msi_setup_one(struct device_node *dn)
+static int axon_msi_probe(struct of_device *device,
+ const struct of_device_id *device_id)
{
struct page *page;
+ struct device_node *dn = device->node;
struct axon_msic *msic;
unsigned int virq;
int dcr_base, dcr_len;
@@ -385,7 +377,11 @@ static int axon_msi_setup_one(struct device_node *dn)
MSIC_CTRL_IRQ_ENABLE | MSIC_CTRL_ENABLE |
MSIC_CTRL_FIFO_SIZE);
- list_add(&msic->list, &axon_msic_list);
+ device->dev.platform_data = msic;
+
+ ppc_md.setup_msi_irqs = axon_msi_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = axon_msi_teardown_msi_irqs;
+ ppc_md.msi_check_device = axon_msi_check_device;
printk(KERN_DEBUG "axon_msi: setup MSIC on %s\n", dn->full_name);
@@ -402,28 +398,24 @@ out:
return -1;
}
-static int axon_msi_init(void)
-{
- struct device_node *dn;
- int found = 0;
-
- pr_debug("axon_msi: initialising ...\n");
-
- for_each_compatible_node(dn, NULL, "ibm,axon-msic") {
- if (axon_msi_setup_one(dn) == 0)
- found++;
- }
-
- if (found) {
- ppc_md.setup_msi_irqs = axon_msi_setup_msi_irqs;
- ppc_md.teardown_msi_irqs = axon_msi_teardown_msi_irqs;
- ppc_md.msi_check_device = axon_msi_check_device;
-
- register_reboot_notifier(&axon_msi_reboot_notifier);
+static struct of_device_id axon_msi_device_id[] = {
+ {
+ .compatible = "ibm,axon-msic"
+ },
+ {}
+};
- pr_debug("axon_msi: registered callbacks!\n");
- }
+static struct of_platform_driver axon_msi_driver = {
+ .match_table = axon_msi_device_id,
+ .probe = axon_msi_probe,
+ .shutdown = axon_msi_shutdown,
+ .driver = {
+ .name = "axon-msi"
+ },
+};
- return 0;
+static int __init axon_msi_init(void)
+{
+ return of_register_platform_driver(&axon_msi_driver);
}
-arch_initcall(axon_msi_init);
+subsys_initcall(axon_msi_init);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 4/4] Avoid DMA exception when using axon_msi with IOMMU
From: Michael Ellerman @ 2008-01-22 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3ce7be4c77581ce103a8da9f33a734270c9dc6e8.1200999872.git.michael@ellerman.id.au>
There's a brown-paper-bag bug in axon_msi, we pass the address of our
FIFO directly to the hardware, without DMA mapping it. This leads to
DMA exceptions if you enable MSI & the IOMMU.
The fix is to correctly DMA map the fifo, dma_alloc_coherent() does
what we want - and we need to track the virt & phys addresses.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/axon_msi.c | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 8de3d23..c546879 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -65,7 +65,8 @@
struct axon_msic {
struct irq_host *irq_host;
- __le32 *fifo;
+ __le32 *fifo_virt;
+ dma_addr_t fifo_phys;
dcr_host_t dcr_host;
u32 read_offset;
};
@@ -91,7 +92,7 @@ static void axon_msi_cascade(unsigned int irq, struct irq_desc *desc)
while (msic->read_offset != write_offset) {
idx = msic->read_offset / sizeof(__le32);
- msi = le32_to_cpu(msic->fifo[idx]);
+ msi = le32_to_cpu(msic->fifo_virt[idx]);
msi &= 0xFFFF;
pr_debug("axon_msi: woff %x roff %x msi %x\n",
@@ -306,7 +307,6 @@ static int axon_msi_shutdown(struct of_device *device)
static int axon_msi_probe(struct of_device *device,
const struct of_device_id *device_id)
{
- struct page *page;
struct device_node *dn = device->node;
struct axon_msic *msic;
unsigned int virq;
@@ -338,16 +338,14 @@ static int axon_msi_probe(struct of_device *device,
goto out_free_msic;
}
- page = alloc_pages_node(of_node_to_nid(dn), GFP_KERNEL,
- get_order(MSIC_FIFO_SIZE_BYTES));
- if (!page) {
+ msic->fifo_virt = dma_alloc_coherent(&device->dev, MSIC_FIFO_SIZE_BYTES,
+ &msic->fifo_phys, GFP_KERNEL);
+ if (!msic->fifo_virt) {
printk(KERN_ERR "axon_msi: couldn't allocate fifo for %s\n",
dn->full_name);
goto out_free_msic;
}
- msic->fifo = page_address(page);
-
msic->irq_host = irq_alloc_host(of_node_get(dn), IRQ_HOST_MAP_NOMAP,
NR_IRQS, &msic_host_ops, 0);
if (!msic->irq_host) {
@@ -370,9 +368,9 @@ static int axon_msi_probe(struct of_device *device,
pr_debug("axon_msi: irq 0x%x setup for axon_msi\n", virq);
/* Enable the MSIC hardware */
- msic_dcr_write(msic, MSIC_BASE_ADDR_HI_REG, (u64)msic->fifo >> 32);
+ msic_dcr_write(msic, MSIC_BASE_ADDR_HI_REG, msic->fifo_phys >> 32);
msic_dcr_write(msic, MSIC_BASE_ADDR_LO_REG,
- (u64)msic->fifo & 0xFFFFFFFF);
+ msic->fifo_phys & 0xFFFFFFFF);
msic_dcr_write(msic, MSIC_CTRL_REG,
MSIC_CTRL_IRQ_ENABLE | MSIC_CTRL_ENABLE |
MSIC_CTRL_FIFO_SIZE);
@@ -390,7 +388,8 @@ static int axon_msi_probe(struct of_device *device,
out_free_host:
kfree(msic->irq_host);
out_free_fifo:
- __free_pages(virt_to_page(msic->fifo), get_order(MSIC_FIFO_SIZE_BYTES));
+ dma_free_coherent(&device->dev, MSIC_FIFO_SIZE_BYTES, msic->fifo_virt,
+ msic->fifo_phys);
out_free_msic:
kfree(msic);
out:
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* RE: Generated xilinx linux 2.6 image sections
From: greenlean @ 2008-01-22 13:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <15015244.post@talk.nabble.com>
Now It's running the problem was the DDR controller I was including the 512
one but I'm working with a 256 DDR module .......
Thanks for the orientation, really usefull.
Bye.
Stephen Neuendorffer wrote:
>
> The testapps are generated using a different linker script.
>
> Based on what you sent out, it looks like your EDK design has a memory
> at 0x10000000, but this is
> not reflected in the linux image you've generated. This makes me
> suspect that you haven't generated the BSP and copied the appropriate
> xparameters file over xparameters_xup.h (assuming you are using
> CONFIG_XILINX_XUPV2P).
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of greenlean
>> Sent: Monday, January 21, 2008 5:06 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Generated xilinx linux 2.6 image sections
>>
>>
>> Hi all,
>>
>> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
> server in
>> the XUPV2P board I'm really having troubles (I can't see anything in
> the
>> minicom console terminal). I'm not seeing anything, neither the
> ucompressing
>> kernel string nor the prompt with the memory addresses that kernel
> prompt at
>> first time, so I have started to distrust of anything.
>>
>>
>> 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
>
>
--
View this message in context: http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-tp14997109p15018508.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] create modalias file in sysfs for bus vio
From: Stephen Rothwell @ 2008-01-22 14:05 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080122083328.GA11928@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi Olaf,
Thanks for this. Just a couple of nits ...
On Tue, 22 Jan 2008 09:33:28 +0100 Olaf Hering <olaf@aepfle.de> wrote:
>
> +static ssize_t modalias_show (struct device *dev, struct device_attribute *attr,
^
No space here, please.
> + char *buf)
> +{
> + struct device_node *of_node = dev->archdata.of_node;
> + const char *compat;
> + int i = 0;
> +
> + if (of_node) {
> + compat = of_get_property(of_node, "compatible", &i);
> + i = sprintf (buf, "vio:T%sS%s\n", of_node->type, compat ? compat : "");
^
Or here.
It would be nice if we could factor out the "vio:T%sS%s" string as it is
also used in vio_hotplug().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-01-22 14:21 UTC (permalink / raw)
To: linuxppc-dev
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/of/device.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -86,7 +86,19 @@ static ssize_t dev_show_devspec(struct d
return sprintf(buf, "%s", ofdev->node->full_name);
}
+static ssize_t dev_show_modalias(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev = to_of_device(dev);
+ ssize_t len = 0;
+
+ if (ofdev)
+ len = of_device_get_modalias(ofdev, buf, PAGE_SIZE);
+ return len;
+}
+
static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static DEVICE_ATTR(modalias, S_IRUGO, dev_show_modalias, NULL);
/**
* of_release_dev - free an of device structure when all users of it are finished.
@@ -116,6 +128,11 @@ int of_device_register(struct of_device
return rc;
rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
+ if (rc) {
+ device_unregister(&ofdev->dev);
+ return rc;
+ }
+ rc = device_create_file(&ofdev->dev, &dev_attr_modalias);
if (rc)
device_unregister(&ofdev->dev);
@@ -126,6 +143,7 @@ EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
device_remove_file(&ofdev->dev, &dev_attr_devspec);
+ device_remove_file(&ofdev->dev, &dev_attr_modalias);
device_unregister(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_unregister);
^ permalink raw reply
* Re: [PATCH 2/4] Create and hook up of_platform_device_shutdown
From: Stephen Rothwell @ 2008-01-22 14:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <bb8d7cc1a060af291ef6efb0f4222f81fa91f417.1200999872.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
Hi Michael,
Just a couple of things.
On Tue, 22 Jan 2008 22:04:40 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> +static void of_platform_device_shutdown(struct device * dev)
^
No space, please.
Also, I wonder if we should check that the drivers that already have
specified a shutdown routine (drivers/input/misc/sparcspkr.c,
drivers/usb/host/ohci-ppc-of.c and drivers/watchdog/mpc5200_wdt.c) are
actually ok if it actually gets called. :-)
Also, patches like this should be cc'd to (at least) the sparc guys
(sparclinux@vger.kernel.org) since they share this stuff with us, now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] Convert axon_msi to an of_platform driver
From: Stephen Rothwell @ 2008-01-22 14:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <c04b1ca531fcd78c42c5a13802c1c331f9b4c8a7.1200999872.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
Hi Michael,
On Tue, 22 Jan 2008 22:04:40 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> +#include <asm/of_platform.h>
You must have missed the lectures :-) Please use linux/of_platform.h
> +static struct of_device_id axon_msi_device_id[] = {
const, please.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-01-22 14:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080122142109.GA12967@aepfle.de>
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/of/device.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -86,7 +86,20 @@ static ssize_t dev_show_devspec(struct d
return sprintf(buf, "%s", ofdev->node->full_name);
}
+static ssize_t dev_show_modalias(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev = to_of_device(dev);
+ ssize_t len = 0;
+
+ len = of_device_get_modalias(ofdev, buf, PAGE_SIZE);
+ buf[len] = '\n';
+ buf[len+1] = 0;
+ return len+1;
+}
+
static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static DEVICE_ATTR(modalias, S_IRUGO, dev_show_modalias, NULL);
/**
* of_release_dev - free an of device structure when all users of it are finished.
@@ -116,6 +129,11 @@ int of_device_register(struct of_device
return rc;
rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
+ if (rc) {
+ device_unregister(&ofdev->dev);
+ return rc;
+ }
+ rc = device_create_file(&ofdev->dev, &dev_attr_modalias);
if (rc)
device_unregister(&ofdev->dev);
@@ -126,6 +144,7 @@ EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
device_remove_file(&ofdev->dev, &dev_attr_devspec);
+ device_remove_file(&ofdev->dev, &dev_attr_modalias);
device_unregister(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_unregister);
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-22 14:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ingo Molnar
In-Reply-To: <1200659696.23161.81.camel@thor.sulgenrain.local>
On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
> This is on a PowerBook5,8.
>
> In a nutshell, things seem more sluggish in general than with 2.6.23.
> But in particular, processes running at nice levels >0 can get most of
> the CPU cycles available, slowing down processes running at nice level
> 0.
The canonical test case I've come up with is to run an infinite loop
with
sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
This makes my X session (X server running at nice level -1, clients at
0) unusably sluggish (it can even take several seconds to process ctrl-c
to interrupt the infinite loop) with 2.6.24-rc but works as expected
with 2.6.23.
Anybody else seeing this?
> I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
> there with -rc8. I'd be surprised if this kind of behaviour remained
> unfixed for that long if it affected x86, so I presume it's powerpc
> specific.
Or maybe not... I've bisected this down to the scheduler changes between
df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb . I'll try and bisect it further, but this is my main work machine, so I can't reboot it too often. I'm CC'ing Ingo in case he has any ideas offhand.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH v2] create modalias file in sysfs for bus of_platform
From: Stephen Rothwell @ 2008-01-22 14:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20080122144053.GA13019@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
Hi Olaf,
Thanks for doing this. Patches to drivers/of should also be cc'd to the
Sparc guys as they share this stuff with is, now.
Also, drivers/macintosh/macio_sysfs.c does this for itself, so that
should probably be removed.
On Tue, 22 Jan 2008 15:40:53 +0100 Olaf Hering <olaf@aepfle.de> wrote:
>
> Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
> of modules. modalias files are already present for many other bus types.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> drivers/of/device.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -86,7 +86,20 @@ static ssize_t dev_show_devspec(struct d
> return sprintf(buf, "%s", ofdev->node->full_name);
> }
>
> +static ssize_t dev_show_modalias(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct of_device *ofdev = to_of_device(dev);
> + ssize_t len = 0;
> +
> + len = of_device_get_modalias(ofdev, buf, PAGE_SIZE);
Should you pass (PAGE_SIZE - 1 (or 2)) here?
> + buf[len] = '\n';
> + buf[len+1] = 0;
> + return len+1;
> +}
> +
> static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
> +static DEVICE_ATTR(modalias, S_IRUGO, dev_show_modalias, NULL);
>
> /**
> * of_release_dev - free an of device structure when all users of it are finished.
> @@ -116,6 +129,11 @@ int of_device_register(struct of_device
> return rc;
>
> rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
> + if (rc) {
> + device_unregister(&ofdev->dev);
> + return rc;
> + }
> + rc = device_create_file(&ofdev->dev, &dev_attr_modalias);
> if (rc)
> device_unregister(&ofdev->dev);
>
> @@ -126,6 +144,7 @@ EXPORT_SYMBOL(of_device_register);
> void of_device_unregister(struct of_device *ofdev)
> {
> device_remove_file(&ofdev->dev, &dev_attr_devspec);
> + device_remove_file(&ofdev->dev, &dev_attr_modalias);
> device_unregister(&ofdev->dev);
> }
> EXPORT_SYMBOL(of_device_unregister);
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* framebuffer swap endianess
From: Angelo @ 2008-01-22 15:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
Hi, i'm angelo.
I have just create a framebuffer for an embedded system:
- powerpc (little endian) with a GPU (big endian).
I'm working on linux 2.6.22
When i try to execute Xfbdev, it starts but with wrong colors.
I need to swap the RGB format (RRRRRGGGGGGBBBBB) to BGR, respecting the endianess (GGGRRRRRBBBBBGGG).
I know that X loads with some ioctl, the principal settings through framebuffer.
But i'm not sure if framebuffer can inform it on the RGB format.
I also tried to change something on cmap, but nothing changes on display;
So, i hope you can help me.
Many thanks.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 952 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Add flash node to mpc8641_hpcn.dts
From: Kumar Gala @ 2008-01-22 16:44 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201019917.5716.154.camel@rhino>
On Jan 22, 2008, at 10:38 AM, Wade Farnsworth wrote:
> Add flash and partition information to mpc8641_hpcn.dts
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 27 +++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
> boot/dts/mpc8641_hpcn.dts
> index a719179..679e857 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -457,4 +457,31 @@
> 0 00100000>;
> };
> };
This really should be under a localbus node.
- k
>
> +
> + flash@ff800000 {
> + compatible = "cfi-flash";
> + reg = <ff800000 00800000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "kernel";
> + reg = <00000000 00300000>;
> + };
> + partition@300000 {
> + label = "firmware b";
> + reg = <00300000 00100000>;
> + read-only;
> + };
> + partition@400000 {
> + label = "fs";
> + reg = <00400000 00300000>;
> + };
> + partition@700000 {
> + label = "firmware a";
> + reg = <00700000 00100000>;
> + read-only;
> + };
> + };
> };
>
^ permalink raw reply
* Re: framebuffer swap endianess
From: Josh Boyer @ 2008-01-22 16:45 UTC (permalink / raw)
To: Angelo; +Cc: linuxppc-embedded
In-Reply-To: <323144.65236.qm@web23105.mail.ird.yahoo.com>
On Tue, 22 Jan 2008 16:46:47 +0100 (CET)
Angelo <s104259@yahoo.it> wrote:
> Hi, i'm angelo.
>
> I have just create a framebuffer for an embedded system:
> - powerpc (little endian) with a GPU (big endian).
I think you have those backwards? PowerPC is big-endian...
josh
^ permalink raw reply
* [PATCH 2/2] MPC8641 HPCN: publish all soc and flash devices
From: Wade Farnsworth @ 2008-01-22 16:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1201019917.5716.154.camel@rhino>
Publish all soc and flash devices from the device tree, similar to what
is done for other boards.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 14f4e52..f266264 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -18,6 +18,7 @@
#include <linux/kdev_t.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
+#include <linux/of_platform.h>
#include <asm/system.h>
#include <asm/time.h>
@@ -212,6 +213,21 @@ mpc86xx_time_init(void)
return 0;
}
+static struct of_device_id mpc86xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ { .compatible = "cfi-flash", },
+ {},
+};
+
+static int __init mpc86xx_publish_devices(void)
+{
+ of_platform_bus_probe(NULL, mpc86xx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc86xx_publish_devices);
+
define_machine(mpc86xx_hpcn) {
.name = "MPC86xx HPCN",
.probe = mpc86xx_hpcn_probe,
^ permalink raw reply related
* Re: [PATCH 1/2] Add flash node to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2008-01-22 16:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <06AA1424-0697-4AF8-B843-945211A5B54A@kernel.crashing.org>
On Tue, 2008-01-22 at 10:44 -0600, Kumar Gala wrote:
> On Jan 22, 2008, at 10:38 AM, Wade Farnsworth wrote:
>
> > Add flash and partition information to mpc8641_hpcn.dts
> >
> > Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
> >
> > ---
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts | 27 +++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
> > boot/dts/mpc8641_hpcn.dts
> > index a719179..679e857 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -457,4 +457,31 @@
> > 0 00100000>;
> > };
> > };
>
> This really should be under a localbus node.
>
> - k
>
Ok. I'll fix it up and resend.
--Wade
^ permalink raw reply
* Re: [PATCH 2/2] MPC8641 HPCN: publish all soc and flash devices
From: Kumar Gala @ 2008-01-22 16:50 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201020432.5716.159.camel@rhino>
On Jan 22, 2008, at 10:47 AM, Wade Farnsworth wrote:
> Publish all soc and flash devices from the device tree, similar to
> what
> is done for other boards.
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> ---
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index 14f4e52..f266264 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -18,6 +18,7 @@
> #include <linux/kdev_t.h>
> #include <linux/delay.h>
> #include <linux/seq_file.h>
> +#include <linux/of_platform.h>
>
> #include <asm/system.h>
> #include <asm/time.h>
> @@ -212,6 +213,21 @@ mpc86xx_time_init(void)
> return 0;
> }
>
> +static struct of_device_id mpc86xx_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + { .compatible = "cfi-flash", },
> + {},
> +};
> +
> +static int __init mpc86xx_publish_devices(void)
> +{
> + of_platform_bus_probe(NULL, mpc86xx_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc86xx_publish_devices);
> +
this should look more like:
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .compatible = "simple-bus" },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ return 0;
+}
+machine_device_initcall(mpc86xx_hpcn, mpc86xx_publish_devices);
+
>
> define_machine(mpc86xx_hpcn) {
> .name = "MPC86xx HPCN",
> .probe = mpc86xx_hpcn_probe,
>
^ permalink raw reply
* Re: [PATCH 1/2] Add flash node to mpc8641_hpcn.dts
From: Kumar Gala @ 2008-01-22 16:49 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201020463.5716.161.camel@rhino>
On Jan 22, 2008, at 10:47 AM, Wade Farnsworth wrote:
> On Tue, 2008-01-22 at 10:44 -0600, Kumar Gala wrote:
>> On Jan 22, 2008, at 10:38 AM, Wade Farnsworth wrote:
>>
>>> Add flash and partition information to mpc8641_hpcn.dts
>>>
>>> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>>>
>>> ---
>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 27 +++++++++++++++++++++
>>> ++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
>>> boot/dts/mpc8641_hpcn.dts
>>> index a719179..679e857 100644
>>> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> @@ -457,4 +457,31 @@
>>> 0 00100000>;
>>> };
>>> };
>>
>> This really should be under a localbus node.
>>
>> - k
>>
>
> Ok. I'll fix it up and resend.
look at the mpc8313erdb.dts (in my tree, as an example).
- k
^ permalink raw reply
* [PATCH 1/2] Add flash node to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2008-01-22 16:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Add flash and partition information to mpc8641_hpcn.dts
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 27 +++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index a719179..679e857 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -457,4 +457,31 @@
0 00100000>;
};
};
+
+ flash@ff800000 {
+ compatible = "cfi-flash";
+ reg = <ff800000 00800000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <00000000 00300000>;
+ };
+ partition@300000 {
+ label = "firmware b";
+ reg = <00300000 00100000>;
+ read-only;
+ };
+ partition@400000 {
+ label = "fs";
+ reg = <00400000 00300000>;
+ };
+ partition@700000 {
+ label = "firmware a";
+ reg = <00700000 00100000>;
+ read-only;
+ };
+ };
};
^ permalink raw reply related
* Re: [PATCH] Various new ibm405 DCRN #defines
From: Joshua Williams @ 2008-01-22 17:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1200956274.6807.12.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-01-21 at 16:43 -0600, Joshua Williams wrote:
>> Various new ibm405 DCRN #defines.
>>
>> Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
>
> May I ask what for ? :-) Also, it's all arch/ppc, not arch/powerpc...
> nothing we want to improve to much on at this stage unless there's a
> really good reason.
The 405x #defines were incomplete and this was meant to
make them a bit tighter. Since arch/ppc is in life support
mode this can wait until the 405x stuff gets moved over to
arch/powerpc.
Thanks!
- Josh
>> ---
>> arch/ppc/platforms/4xx/ibm405ep.h | 3 +++
>> arch/ppc/platforms/4xx/ibm405gp.h | 9 +++++++++
>> arch/ppc/platforms/4xx/ibm405gpr.h | 9 +++++++++
>> include/asm-ppc/ibm405.h | 27 +++++++++++++++++++++++++++
>> 4 files changed, 48 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/ppc/platforms/4xx/ibm405ep.h
>> b/arch/ppc/platforms/4xx/ibm405ep.h
>> index 3ef20a5..d82a4c7 100644
>> --- a/arch/ppc/platforms/4xx/ibm405ep.h
>> +++ b/arch/ppc/platforms/4xx/ibm405ep.h
>> @@ -139,6 +139,9 @@
>> #define DCRN_UIC0_BASE 0x0C0
>> #define UIC0 DCRN_UIC0_BASE
>>
>> +/* DCRN_SDRAM0_BASE offsets - general 405 offsets in asm/ibm405.h */
>> +#define DCRN_SDRAM0_STATUS 0x24 /* SDRAM Controller Status */
>> +
>> #include <asm/ibm405.h>
>>
>> #endif /* __ASM_IBM405EP_H__ */
>> diff --git a/arch/ppc/platforms/4xx/ibm405gp.h
>> b/arch/ppc/platforms/4xx/ibm405gp.h
>> index 9f15e55..9f7e850 100644
>> --- a/arch/ppc/platforms/4xx/ibm405gp.h
>> +++ b/arch/ppc/platforms/4xx/ibm405gp.h
>> @@ -142,6 +142,15 @@
>> #define DCRN_UIC0_BASE 0x0C0
>> #define UIC0 DCRN_UIC0_BASE
>>
>> +/* DCRN_SDRAM0_BASE offsets - general 405 offsets in asm/ibm405.h */
>> +#define DCRN_SDRAM0_BESR0 0x00 /* Bus Error Syndrome Reg 0 */
>> +#define DCRN_SDRAM0_BESR1 0x08 /* Bus Error Syndrome Reg 1 */
>> +#define DCRN_SDRAM0_BEAR 0x10 /* Bus Error Address Reg */
>> +#define DCRN_SDRAM0_B2CR 0x48 /* Memory Bank 2 Configuration Reg */
>> +#define DCRN_SDRAM0_B3CR 0x4c /* Memory Bank 3 Configuration Reg */
>> +#define DCRN_SDRAM0_ECCCFG 0x94 /* ECC Configuration */
>> +#define DCRN_SDRAM0_ECCESR 0x98 /* ECC Error Status */
>> +
>> #include <asm/ibm405.h>
>>
>> #endif /* __ASM_IBM405GP_H__ */
>> diff --git a/arch/ppc/platforms/4xx/ibm405gpr.h
>> b/arch/ppc/platforms/4xx/ibm405gpr.h
>> index 9e01f15..6f39042 100644
>> --- a/arch/ppc/platforms/4xx/ibm405gpr.h
>> +++ b/arch/ppc/platforms/4xx/ibm405gpr.h
>> @@ -142,6 +142,15 @@
>> #define DCRN_UIC0_BASE 0x0C0
>> #define UIC0 DCRN_UIC0_BASE
>>
>> +/* DCRN_SDRAM0_BASE offsets - general 405 offsets in asm/ibm405.h */
>> +#define DCRN_SDRAM0_BESR0 0x00 /* Bus Error Syndrome Reg 0 */
>> +#define DCRN_SDRAM0_BESR1 0x08 /* Bus Error Syndrome Reg 1 */
>> +#define DCRN_SDRAM0_BEAR 0x10 /* Bus Error Address Reg */
>> +#define DCRN_SDRAM0_B2CR 0x48 /* Memory Bank 2 Configuration Reg */
>> +#define DCRN_SDRAM0_B3CR 0x4c /* Memory Bank 3 Configuration Reg */
>> +#define DCRN_SDRAM0_ECCCFG 0x94 /* ECC Configuration */
>> +#define DCRN_SDRAM0_ECCESR 0x98 /* ECC Error Status */
>> +
>> #include <asm/ibm405.h>
>>
>> #endif /* __ASM_IBM405GPR_H__ */
>> diff --git a/include/asm-ppc/ibm405.h b/include/asm-ppc/ibm405.h
>> index 4e5be9e..04aaae6 100644
>> --- a/include/asm-ppc/ibm405.h
>> +++ b/include/asm-ppc/ibm405.h
>> @@ -135,6 +135,26 @@
>> #ifdef DCRN_EBC_BASE
>> #define DCRN_EBCCFGADR (DCRN_EBC_BASE + 0x0) /* Peripheral Controller
>> Address */
>> #define DCRN_EBCCFGDATA (DCRN_EBC_BASE + 0x1) /* Peripheral Controller
>> Data */
>> +#define DCRN_EBC_PB0CR 0x00 /* Peripheral Bank 0 Config Reg */
>> +#define DCRN_EBC_PB1CR 0x01 /* Peripheral Bank 1 Config Reg */
>> +#define DCRN_EBC_PB2CR 0x02 /* Peripheral Bank 2 Config Reg */
>> +#define DCRN_EBC_PB3CR 0x03 /* Peripheral Bank 3 Config Reg */
>> +#define DCRN_EBC_PB4CR 0x04 /* Peripheral Bank 4 Config Reg */
>> +#define DCRN_EBC_PB5CR 0x05 /* Peripheral Bank 5 Config Reg */
>> +#define DCRN_EBC_PB6CR 0x06 /* Peripheral Bank 6 Config Reg */
>> +#define DCRN_EBC_PB7CR 0x07 /* Peripheral Bank 7 Config Reg */
>> +#define DCRN_EBC_PB0AP 0x10 /* Peripheral Bank 0 Access Parameters */
>> +#define DCRN_EBC_PB1AP 0x11 /* Peripheral Bank 1 Access parameters */
>> +#define DCRN_EBC_PB2AP 0x12 /* Peripheral Bank 2 Access Parameters */
>> +#define DCRN_EBC_PB3AP 0x13 /* Peripheral Bank 3 Access Parameters */
>> +#define DCRN_EBC_PB4AP 0x14 /* Peripheral Bank 4 Access Parameters */
>> +#define DCRN_EBC_PB5AP 0x15 /* Peripheral Bank 5 Access Parameters */
>> +#define DCRN_EBC_PB6AP 0x16 /* Peripheral Bank 6 Access Parameters */
>> +#define DCRN_EBC_PB7AP 0x17 /* Peripheral Bank 7 Access Parameters */
>> +#define DCRN_EBC_PBEAR 0x20 /* Peripheral Bus Error Address Reg */
>> +#define DCRN_EBC_PBESR0 0x21 /* Peripheral Bus Error Status Reg 0 */
>> +#define DCRN_EBC_PBESR1 0x22 /* Peripheral Bus Error Status Reg 1 */
>> +#define DCRN_EBC_EPCR 0x23 /* External Peripheral Control Reg */
>> #endif
>>
>> #ifdef DCRN_EXIER_BASE
>> @@ -286,6 +306,13 @@
>> #ifdef DCRN_SDRAM0_BASE
>> #define DCRN_SDRAM0_CFGADDR (DCRN_SDRAM0_BASE + 0x0) /* Memory
>> Controller Address */
>> #define DCRN_SDRAM0_CFGDATA (DCRN_SDRAM0_BASE + 0x1) /* Memory
>> Controller Data */
>> +#define DCRN_SDRAM0_CFG 0x20 /* SDRAM Configuration */
>> +#define DCRN_SDRAM0_STATUS 0x24 /* SDRAM Controller Status */
>> +#define DCRN_SDRAM0_RTR 0x30 /* Refresh Timer Reg */
>> +#define DCRN_SDRAM0_PMIT 0x34 /* Power Management Idle Timer */
>> +#define DCRN_SDRAM0_B0CR 0x40 /* Memory Bank 0 Configuration Reg */
>> +#define DCRN_SDRAM0_B1CR 0x44 /* Memory Bank 1 Configuration Reg */
>> +#define DCRN_SDRAM0_TR 0x80 /* SDRAM Timing Reg */
>> #endif
>>
>> #ifdef DCRN_OCM0_BASE
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH] Various new ibm405 DCRN #defines
From: Josh Boyer @ 2008-01-22 17:10 UTC (permalink / raw)
To: Joshua Williams; +Cc: linuxppc-dev
In-Reply-To: <47962316.8040709@qlogic.com>
On Tue, 22 Jan 2008 11:08:38 -0600
Joshua Williams <joshua.williams@qlogic.com> wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2008-01-21 at 16:43 -0600, Joshua Williams wrote:
> >> Various new ibm405 DCRN #defines.
> >>
> >> Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
> >
> > May I ask what for ? :-) Also, it's all arch/ppc, not arch/powerpc...
> > nothing we want to improve to much on at this stage unless there's a
> > really good reason.
>
> The 405x #defines were incomplete and this was meant to
> make them a bit tighter. Since arch/ppc is in life support
> mode this can wait until the 405x stuff gets moved over to
> arch/powerpc.
Which 405x stuff? Walnut is moved over already. Other boards will
need to be ported by people that have those boards.
josh
^ 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