* [PATCH] UPIO_TSI cleanup
From: Al Viro @ 2006-09-23 0:39 UTC (permalink / raw)
To: linuxppc-dev
(le32_to_cpu(x) >> 8) & 0xff is a very odd way to spell (x >> 16) & 0xff,
even if that code is hit only on ppc. The value is host-endian - we've
got it from readl(), after all...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/serial/8250.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 0ae9ced..10c2daa 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -320,8 +320,8 @@ #endif
case UPIO_TSI:
if (offset == UART_IIR) {
- tmp = readl((u32 *)(up->port.membase + UART_RX));
- return (cpu_to_le32(tmp) >> 8) & 0xff;
+ tmp = readl(up->port.membase + (UART_IIR & ~3));
+ return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
} else
return readb(up->port.membase + offset);
--
1.4.2.GIT
^ permalink raw reply related
* Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver
From: Randy.Dunlap @ 2006-09-23 0:57 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, Luca, linux-kernel, linux-scsi
In-Reply-To: <20060922235017.GD14213@austin.ibm.com>
On Fri, 22 Sep 2006 18:50:17 -0500 Linas Vepstas wrote:
> On Fri, Sep 22, 2006 at 04:39:29PM -0700, Randy.Dunlap wrote:
> > On Fri, 22 Sep 2006 18:32:35 -0500 Linas Vepstas wrote:
> >
> > > On Sat, Sep 23, 2006 at 12:06:29AM +0200, Luca wrote:
> > > >
> > > > Space after function name? You put in other places too, it's not
> > > > consistent with the rest of the patch.
> > >
> > > Oops. I was also coding on a different project recently, with a
> > > different style. I'll send a revised patch in a moment.
> >
> > Please change if()'s to use
> >
> > if (var == constant)
> > instead of
> > if (constant == var)
>
> Yuck! Horrid coding style! No rational excuse for coding like that.
> Advice taken under protest; new patch shortly.
Just after my email, I saw this :)
http://marc.theaimsgroup.com/?l=linux-mm-commits&m=115896769322020&w=2
---
~Randy
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-23 0:57 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Matt Porter, Paul Mackerras, linuxppc-dev
In-Reply-To: <45143B2B.7060501@ru.mvista.com>
> Well, is there need for duplication of size if "reg" prop must
> be present anyway?
No, not really. But this way, "reg" can be absent, actually.
Segher
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehca firmware interface based on Anton Blanchard's new hvcall interface
From: Roland Dreier @ 2006-09-23 1:21 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: pmac, linux-kernel, openib-general, openfabrics-ewg, linuxppc-dev,
Christoph.Raisch/Germany/IBM
In-Reply-To: <200609222200.12722.hnguyen@de.ibm.com>
Thanks, I rolled this up in the ehca patch in my tree.
Anyway both Paul and I merged with Linus today, so the hcall cleanup
and ehca are both upstream. It would be great if you could do a quick
check to make sure that ehca works in Linus's current git tree.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-23 0:54 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <20060922185923.GB25738@mag.az.mvista.com>
> Oh, okay. I didn't realize there was an actual "64-bit" property.
> I thought you just meant "/cpus/#address-cells = <2>".
> I should've googled first.
No, cpus/"#address-cells" is required to be 1, as that's the number
of address cells required to identify a CPU itself.
> So, yes, that probably does give us the info we need.
> Here is where I think we are for getting the effective base addr
> of the regs for the console uart in the bootwrapper:
>
> 1) We add the "fw,address" property to the uart's dt node. That
> property provides the effective base address of the uart's registers
> left over by the firmware. The format is similar to that of the
> "reg" property in that it contains an "address size" tuple.
I completely lost you here, sorry. Maybe it's me. Care to
repeat this in a (perhaps more verbose) way that I might
understand?
> 2) The effective address width (32 or 64 bits) (i.e., the # cells in
> the "address" portion of the tuple) is indicated by the presence of
> the
> "/cpus/64-bit" property. If it exists, the effective addr space is
> 64-bits wide (2 cells); if not, its 32-bits wide (1 cell).
Yes. Except a "cell" is not what you think it is. A "cell" is the
size of numbers OF deals with internally; just deal with it. Of
course, there's things like "#address-cells", which really mean
"#-32bit-things-per-address".
> 3) The number of cells in the "size" portion of the tuple is indicated
> by the nearest #size-cells as you go up the tree. Just like the "reg"
> property.
Yes, sounds fine.
Segher
^ permalink raw reply
* Re: bsp for Linux kernel 2.6
From: shenbagaraj @ 2006-09-23 17:15 UTC (permalink / raw)
To: Yang, Steve; +Cc: linuxppc-embedded
In-Reply-To: <D9055C0A0A86BD4E89AD96A89EA767DB8D34CD@ALA-MAIL03.corp.ad.wrs.com>
Hi Steve,
Thank you for information,I need the older version of windriver which
support 2.6.11.11 kernel with some patch to build in open source
kernel.Where do i get those patch.
regards,
shenbagaraj.
----- Original Message -----
From: "Yang, Steve" <steve.yang@windriver.com>
To: "shenbagaraj" <shenbagaraj@esds.in>
Cc: <linuxppc-embedded@ozlabs.org>
Sent: Friday, September 22, 2006 5:57 AM
Subject: RE: bsp for Linux kernel 2.6
Shen,
Wind River Linux 1.3 has BSP support for this board. The kernel version
is 2.6.14.
Regards,
Steve Yang
-----Original Message-----
From: linuxppc-embedded-bounces+syang=windriver.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+syang=windriver.com@ozlabs.org] On
Behalf Of shenbagaraj
Sent: Thursday, September 21, 2006 5:07 PM
To: linuxppc-embedded@ozlabs.org
Subject: bsp for Linux kernel 2.6
Hi,
I ma working on Windriver powerquicc board 8260.where do i get the
required patches for linux 2.6.11.11.
regards,
shen
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Mark A. Greer @ 2006-09-23 8:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <74E4B2E4-B59C-4998-B9FC-A77245C6AF6B@kernel.crashing.org>
On Sat, Sep 23, 2006 at 02:54:12AM +0200, Segher Boessenkool wrote:
> >Here is where I think we are for getting the effective base addr
> >of the regs for the console uart in the bootwrapper:
> >
> >1) We add the "fw,address" property to the uart's dt node. That
> >property provides the effective base address of the uart's registers
> >left over by the firmware. The format is similar to that of the
> >"reg" property in that it contains an "address size" tuple.
>
> I completely lost you here, sorry. Maybe it's me. Care to
> repeat this in a (perhaps more verbose) way that I might
> understand?
Well, I'm still new to the dt stuff and probably use the wrong
terminology all the time. I tried to use the same type of description
that is used in ./Documentation/powerpc/booting-without-of.txt.
For example:
'"reg" properties are always a tuple of the type "address size"
where the number of cells of address and size is specified by
the bus #address-cells and #size-cells.'
All I'm try to say is that "fw,address" is just like the "reg" property
except that it holds the effective addr not the physical addr and the
size of the address is determined by the existence of "/cpus/64-bit"
not #address-cells. That's all.
> >2) The effective address width (32 or 64 bits) (i.e., the # cells in
> >the "address" portion of the tuple) is indicated by the presence of
> >the
> >"/cpus/64-bit" property. If it exists, the effective addr space is
> >64-bits wide (2 cells); if not, its 32-bits wide (1 cell).
>
> Yes. Except a "cell" is not what you think it is. A "cell" is the
> size of numbers OF deals with internally; just deal with it. Of
> course, there's things like "#address-cells", which really mean
> "#-32bit-things-per-address".
Okay, well, when I talked about cells I meant "#-32bit-things-per-address".
Obviously it was silly of me to think that "#address-cells" meant the # of
address cells...
Mark
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-23 10:15 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <20060923081836.GA25298@mag.az.mvista.com>
> All I'm try to say is that "fw,address" is just like the "reg"
> property
> except that it holds the effective addr not the physical addr and the
> size of the address is determined by the existence of "/cpus/64-bit"
> not #address-cells. That's all.
Sounds good.
>> Yes. Except a "cell" is not what you think it is. A "cell" is the
>> size of numbers OF deals with internally; just deal with it. Of
>> course, there's things like "#address-cells", which really mean
>> "#-32bit-things-per-address".
>
> Okay, well, when I talked about cells I meant "#-32bit-things-per-
> address".
> Obviously it was silly of me to think that "#address-cells" meant
> the # of
> address cells...
Some background might clear things up (or not)... A "cell" is the
unit of data in a Forth system. When OF was young (and not yet
called OF), all systems were 32-bit, and the 32-bit-thingies in
the properties (which weren't yet called properties) in the device
tree were called cells as well. When 64-bit came into the picture,
everything fell apart. The "correct" name for the property thingies
now is "integers as encoded with encode-int". Maybe we can compromise
on calling it "property cells" or something.
The situation is even worse with "package", let's not go there :-)
Segher
^ permalink raw reply
* [PATCH] #elif that should've been #elif defined
From: Al Viro @ 2006-09-23 15:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
#elif CONFIG_44x
in ibm4xx.h should've been
#elif defined(CONFIG_44x)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
include/asm-ppc/ibm4xx.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/ibm4xx.h b/include/asm-ppc/ibm4xx.h
index cf62b69..499c146 100644
--- a/include/asm-ppc/ibm4xx.h
+++ b/include/asm-ppc/ibm4xx.h
@@ -86,7 +86,7 @@ #define _ISA_MEM_BASE 0
#define PCI_DRAM_OFFSET 0
#endif
-#elif CONFIG_44x
+#elif defined(CONFIG_44x)
#if defined(CONFIG_BAMBOO)
#include <platforms/4xx/bamboo.h>
--
1.4.2.GIT
^ permalink raw reply related
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Sergei Shtylyov @ 2006-09-23 15:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Matt Porter, Paul Mackerras, linuxppc-dev
In-Reply-To: <91D1965E-2377-4ADB-B6F9-2B5A1549D75B@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>> Well, is there need for duplication of size if "reg" prop must be
>> present anyway?
> No, not really. But this way, "reg" can be absent, actually.
Is this a joke? :-)
Or you're supposing that UART is only usable to the bootwrapper? Or you're
going to add support for this new prop to the main kernel as well?
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehca firmware interface based on Anton Blanchard's new hvcall interface
From: Hoang-Nam Nguyen @ 2006-09-23 20:45 UTC (permalink / raw)
To: Roland Dreier
Cc: pmac, linux-kernel, openib-general, openfabrics-ewg, linuxppc-dev,
Christoph.Raisch/Germany/IBM
In-Reply-To: <adahcyzfkd0.fsf@cisco.com>
Hi Roland,
> Anyway both Paul and I merged with Linus today, so the hcall cleanup
> and ehca are both upstream. It would be great if you could do a quick
> check to make sure that ehca works in Linus's current git tree.
I compiled Linus's git tree and did some basic tests successfully
with ehca (ipoib, userspace, netpipe tcp/ib).
Thanks!
Nam Nguyen
^ permalink raw reply
* RE: MPC5200b kernel module memory mapping
From: Steven Kaiser @ 2006-09-23 20:46 UTC (permalink / raw)
To: 'Markus Klotzbücher'; +Cc: linuxppc-embedded
In-Reply-To: <87slilxf92.fsf@creamnet.de>
Markus:
> > sure I am setting up the LocalBus chip select registers ok.
>
> I would guess this is not the case. What kind of device is this?
It is a Freescale MPC5200b:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B
You are correct. I was so concerned about the linux driver stuff (
request_region(), ioremap(), etc ), that I was locked into endless studies
on that and see now I clearly overlooked some simple chip setting up. Doh!
Thanks for reorienting my focus--
int init_module(void) { ...
// reserve a page of memory for our hardware /proc/iomem
if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
printk (KERN_ALERT "LED init_module: memory already in
use\n");
return -EBUSY;
}
request_region(MALab_MM_START,MALab_MM_SIZE,LED_DEVICE_NAME);
// enable LocalBus chip select CS2 to hit on our address range
*(volatile u32 *)MPC5xxx_MM_IPBI &= ~0x00040000;
*(volatile u16 *)(MPC5xxx_MM_CS2_START + 2) = MALab_MM_START >> 16;
*(volatile u16 *)(MPC5xxx_MM_CS2_STOP + 2) = MALab_MM_END >> 16;
*(volatile u32 *)MPC5xxx_MM_IPBI |= 0x00040000;
// LocalBus Chip Select 2,3 Configuration Register
*(volatile u32 *)(MPC5xxx_MBAR + 0x0308) = 0x03031110;
*(volatile u32 *)(MPC5xxx_MBAR + 0x030c) = 0x03031110;
// LocalBus Chip Select Control Register
*(volatile u32 *)(MPC5xxx_MBAR + 0x0318) |= 0x01000000;
// map our physical address into kernal virtual address space
ioaddr = ioremap(MALab_MM_START,MALab_MM_SIZE);
printk(KERN_ALERT "ioaddr: 0x%08x\n", (u32)ioaddr);
and later, any of these calls work:
^ permalink raw reply
* RE: MPC5200b kernel module memory mapping
From: Steven Kaiser @ 2006-09-23 20:55 UTC (permalink / raw)
To: 'Markus Klotzbücher'; +Cc: linuxppc-embedded
In-Reply-To: <87slilxf92.fsf@creamnet.de>
Markus:
> > sure I am setting up the LocalBus chip select registers ok.
>
> I would guess this is not the case. What kind of device is this?
You are correct. I was so concerned about the linux driver stuff (
request_region(), ioremap(), etc ), that I was locked into endless studies
on that and see now I clearly overlooked some simple chip setting up. Doh!
Thanks for reorienting my focus--
My chip is a Freescale MPC5200b:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B
So here's what I've doing that seems to work, as verified by an
oscilloscope:
// 64k I/O Port Space: 0x60000000 - 0x60001000 -> 0x60000000 - 0x60001000
#define MPC5xxx_MM_CS2_START (MPC5xxx_MBAR + 0x0014)
#define MPC5xxx_MM_CS2_STOP (MPC5xxx_MBAR + 0x0018)
#define MPC5xxx_MM_IPBI (MPC5xxx_MBAR + 0x0054)
#define MALab_MM_START 0x60000000U
#define MALab_MM_END 0x6000ffffU
#define MALab_MM_SIZE 0x00010000U
void *ioaddr = NULL;
int init_module(void) { ...
// reserve a page of memory for our hardware /proc/iomem
if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
printk (KERN_ALERT "LED init_module: memory already in
use\n");
return -EBUSY;
}
request_region(MALab_MM_START,MALab_MM_SIZE,LED_DEVICE_NAME);
// enable LocalBus chip select CS2 to hit on our address range
*(volatile u32 *)MPC5xxx_MM_IPBI &= ~0x00040000;
*(volatile u16 *)(MPC5xxx_MM_CS2_START + 2) = MALab_MM_START >> 16;
*(volatile u16 *)(MPC5xxx_MM_CS2_STOP + 2) = MALab_MM_END >> 16;
*(volatile u32 *)MPC5xxx_MM_IPBI |= 0x00040000;
// LocalBus Chip Select 2 Configuration Register
*(volatile u32 *)(MPC5xxx_MBAR + 0x0308) = 0x03031110;
// LocalBus Chip Select Control Register
*(volatile u32 *)(MPC5xxx_MBAR + 0x0318) |= 0x01000000;
// map our physical address into kernal virtual address space
ioaddr = ioremap(MALab_MM_START,MALab_MM_SIZE);
printk(KERN_ALERT "ioaddr: 0x%08x\n", (u32)ioaddr);
then later, any of these calls work (even in interrupt routines it appears):
u32 buf[10];
*(volatile u16 *)ioaddr = 0x5555;
outw(0x5555,ioaddr);
outsw(ioaddr,buf,10);
I guess this is simple stuff for most everybody here.
Steve
^ permalink raw reply
* Booting problems
From: David H. Lynch Jr. @ 2006-09-24 4:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
I am booting a compressed initramfs kernel.
I have hit what appears to be a size issue. simply adding more data
to the initramfs source directory,
or adding even a small amount of unused code to my kernel causes it
to hang after relocation during boot.
The point of failure varies with the size of the kernel image.
I have tried blindly jiggering with the CONFIG_ADVANCED_OPTIONS
setting with no noticable effect.
The total zImage.elf size is just shy of 3Mb.
Does anyone have an idea what I need to do to be able to load a
larger image ?
[-- Attachment #2: Type: text/html, Size: 994 bytes --]
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: David H. Lynch Jr. @ 2006-09-24 5:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609191427o11146c54q650738bcb10f8d98@mail.gmail.com>
Grant Likely wrote:
>
> Step 1: run away
> Step 2: don't look back.
There are days.
>
> Just kidding. Unless you want to help move Virtex support from
> arch/ppc to arch/powerpc, you don't really need to worry about device
> trees for a while.
>
> If you are interested, look at
> Documentation/powerpc/booting-without-of.txt. Then start poking Matt
> Porter about when he's going to get 4xx ported to arch/powerpc.
That depends. I am a consultant. My works is primarily paid for by
my clients, clients.
I tinker when I am not otherwise busy. But I am very busy, despite
being short on work !?
>
> I've been half heartedly looking at what needs to be done to generate
> a device tree based on either system.mhs or xparameters.h. I'm
> probably going to write a tiny C program that is compiled against
> xparameters.h and spits out a valid dts file. The dts file can then
> be run through the device tree compiler to produce the flattened
> device tree structure.
That sounds somewhat interesting.
But as was somewhat raised elsewhere - what about partial
reprogramming the FPGA on the fly ?
One of the fundimental issues I am facing, is that I have to deal
with a system where nothing is certain except that there is a
ppc405 present. There will always be more than that - but there is
not another component that MUST be present.
As things go forward, more optional components get added.
Pico is not yet doing partial FPGA reprogramming on the fly - but I
am certain it is coming. It fits perfectly with the goals and objectives
of the company and its clients.
For the moment the problem is fairly small. But it is only going to
get worse with time. The decisions I make now, will either make my life
pleasant or horrible later.
Better to work towards where we are going now.
I guess I need to digest
Documentation/powerpc/booting-without-of.txt. now. At the moment things
are busy
>
>>
>> The vague Picture I have is the have something to do with some
>> datastructure that Mac's typically create at or prior to boot. And
>> that for
>> embedded systems we are building them
>> externally compiling them and then attaching the compiled device
>> tree
>> to our project.
>
> That right. You don't compile device base addresses, irqs, etc into
> the kernel. You pass them in at boot time with a data structure.
>
>>
>> I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC,
>> Flash
>> and Keyhole (pseuodo serial host interface). Of those it is only certain
>> that the flash will always be there.
>> We have bit images with Keyhole only, Uartlite only TEMAC only,
>> Sometimes we have a Pic sometimes not. I was trying to get to the
>> point were
>> I could dynamically add what was there
>> to Platform devices during initialization.
>>
>> If Device trees are static, then do they even apply to what I
>> have to
>> deal with ?
>
> Device trees don't have to be static. They can be generated/modified
> on the fly if the bootloader supports it. Or you can pass a different
> tree depending on what IP you have on the board.
Can you populate the tree dynamically inside the Linux setup code ?
>
> Cheers,
> g.
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* AC power not detected if no battery present
From: Olaf Hering @ 2006-09-24 6:40 UTC (permalink / raw)
To: linuxppc-dev
PMU_PWR_AC_PRESENT in pmu_power_flags is never set if booted without
battery. This leads to 'AC Power' == 0 in /proc/pmu/info.
How can this be fixed properly?
^ permalink raw reply
* Re: AC power not detected if no battery present
From: Benjamin Herrenschmidt @ 2006-09-24 7:11 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060924064008.GA7925@aepfle.de>
On Sun, 2006-09-24 at 08:40 +0200, Olaf Hering wrote:
> PMU_PWR_AC_PRESENT in pmu_power_flags is never set if booted without
> battery. This leads to 'AC Power' == 0 in /proc/pmu/info.
> How can this be fixed properly?
Maybe simply buy forcing it when there is no battery ? I fail to see how
the machine could be up without battery _and_ without AC :)
Ben.
^ permalink raw reply
* [PATCH] enable sysrq in pmac32_defconfig
From: Olaf Hering @ 2006-09-24 8:38 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Enable sysrq also for pmac32
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Index: linux-2.6/arch/powerpc/configs/pmac32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pmac32_defconfig
+++ linux-2.6/arch/powerpc/configs/pmac32_defconfig
@@ -1826,7 +1826,7 @@ CONFIG_OPROFILE=y
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
-# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
^ permalink raw reply
* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-24 14:35 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <45161ADB.4020106@dlasys.net>
On 9/23/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > I've been half heartedly looking at what needs to be done to generate
> > a device tree based on either system.mhs or xparameters.h. I'm
> > probably going to write a tiny C program that is compiled against
> > xparameters.h and spits out a valid dts file. The dts file can then
> > be run through the device tree compiler to produce the flattened
> > device tree structure.
> That sounds somewhat interesting.
>
> But as was somewhat raised elsewhere - what about partial
> reprogramming the FPGA on the fly ?
Then you'll need to register/unregister devices from the platform bus
on the fly (assuming the FPGA is reprogrammed after control is passed
to Linux). The device tree is primarily for passing information from
the boot loader to linux. Once linux is booted and the fdt is used to
populate the platform buss, you can safely ignore it.
> > Device trees don't have to be static. They can be generated/modified
> > on the fly if the bootloader supports it. Or you can pass a different
> > tree depending on what IP you have on the board.
> Can you populate the tree dynamically inside the Linux setup code ?
Yes; there is a common library that is being developed to
generate/modify the device tree from anywhere; boot loader, inside the
kernel (like for kexec), etc. Search the mailing list.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] UPIO_TSI cleanup
From: Sergei Shtylyov @ 2006-09-24 15:00 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, rmk+serial
In-Reply-To: <E1GQvYX-0002iX-IN@ZenIV.linux.org.uk>
Hello.
Al Viro wrote:
> (le32_to_cpu(x) >> 8) & 0xff is a very odd way to spell (x >> 16) & 0xff,
> even if that code is hit only on ppc. The value is host-endian - we've
> got it from readl(), after all...
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> drivers/serial/8250.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 0ae9ced..10c2daa 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
Shouldn't this go to rmk+serial@arm.linux.org.uk instead?
> @@ -320,8 +320,8 @@ #endif
>
> case UPIO_TSI:
> if (offset == UART_IIR) {
> - tmp = readl((u32 *)(up->port.membase + UART_RX));
> - return (cpu_to_le32(tmp) >> 8) & 0xff;
> + tmp = readl(up->port.membase + (UART_IIR & ~3));
> + return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
> } else
> return readb(up->port.membase + offset);
>
I'd also like to suggest actually writing to IER in the serial_out() even
if the UUE bit is set, jusk mask 2 MSBs off (Xscale UART detection code which
breaks Tsi10x UART sould have been CONFIG_ARM dependent I think). The whole
UPIO_TSI thing looks much like an abuse to me, however it still seems to be a
necessary evil... :-/
WBR, Sergei
^ permalink raw reply
* [PATCH] update powerpc defconfig files after libata kconfig breakage
From: Olaf Hering @ 2006-09-24 18:53 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Update defconfig files after libata .config breakage
sed -i 's/CONFIG_SCSI_SATA_/CONFIG_SATA_/;s/CONFIG_SCSI_SATA/CONFIG_ATA/' arch/powerpc/configs/*g
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/configs/chrp32_defconfig | 2 +-
arch/powerpc/configs/g5_defconfig | 28 ++++++++++++++--------------
arch/powerpc/configs/iseries_defconfig | 2 +-
arch/powerpc/configs/mpc7448_hpc2_defconfig | 28 ++++++++++++++--------------
arch/powerpc/configs/mpc834x_itx_defconfig | 28 ++++++++++++++--------------
arch/powerpc/configs/pmac32_defconfig | 2 +-
arch/powerpc/configs/ppc64_defconfig | 28 ++++++++++++++--------------
arch/powerpc/configs/pseries_defconfig | 2 +-
8 files changed, 60 insertions(+), 60 deletions(-)
Index: linux-2.6/arch/powerpc/configs/chrp32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/chrp32_defconfig
+++ linux-2.6/arch/powerpc/configs/chrp32_defconfig
@@ -492,7 +492,7 @@ CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-# CONFIG_SCSI_SATA is not set
+# CONFIG_ATA is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/g5_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/g5_defconfig
+++ linux-2.6/arch/powerpc/configs/g5_defconfig
@@ -490,23 +490,23 @@ CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-CONFIG_SCSI_SATA_SVW=y
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+CONFIG_SATA_SVW=y
# CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/iseries_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/iseries_defconfig
+++ linux-2.6/arch/powerpc/configs/iseries_defconfig
@@ -475,7 +475,7 @@ CONFIG_SCSI_FC_ATTRS=y
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-# CONFIG_SCSI_SATA is not set
+# CONFIG_ATA is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/mpc7448_hpc2_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/mpc7448_hpc2_defconfig
+++ linux-2.6/arch/powerpc/configs/mpc7448_hpc2_defconfig
@@ -413,23 +413,23 @@ CONFIG_BLK_DEV_SD=y
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-# CONFIG_SCSI_SATA_SVW is not set
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+# CONFIG_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
-CONFIG_SCSI_SATA_MV=y
-# CONFIG_SCSI_SATA_NV is not set
+CONFIG_SATA_MV=y
+# CONFIG_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/mpc834x_itx_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/mpc834x_itx_defconfig
+++ linux-2.6/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -464,23 +464,23 @@ CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-# CONFIG_SCSI_SATA_SVW is not set
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+# CONFIG_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-CONFIG_SCSI_SATA_SIL=y
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+CONFIG_SATA_SIL=y
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/pmac32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pmac32_defconfig
+++ linux-2.6/arch/powerpc/configs/pmac32_defconfig
@@ -682,7 +682,7 @@ CONFIG_SCSI_AIC7XXX_OLD=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-# CONFIG_SCSI_SATA is not set
+# CONFIG_ATA is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/ppc64_defconfig
+++ linux-2.6/arch/powerpc/configs/ppc64_defconfig
@@ -520,23 +520,23 @@ CONFIG_SCSI_ISCSI_ATTRS=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-CONFIG_SCSI_SATA_SVW=y
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+CONFIG_SATA_SVW=y
# CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pseries_defconfig
+++ linux-2.6/arch/powerpc/configs/pseries_defconfig
@@ -506,7 +506,7 @@ CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-# CONFIG_SCSI_SATA is not set
+# CONFIG_ATA is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
^ permalink raw reply
* Re: AC power not detected if no battery present
From: Jeremy Kerr @ 2006-09-25 0:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1159081888.5924.20.camel@localhost.localdomain>
Ben,
> Maybe simply buy forcing it when there is no battery ? I fail to see
> how the machine could be up without battery _and_ without AC :)
"It should be noted that, unlike PC's, computers running Mac OS do not
use conventional power supplies, and instead use power crystals."
-- http://uncyclopedia.org/wiki/Mac_OS_X
Jeremy
^ permalink raw reply
* RE: kernel opps during PCI read
From: Liu Dave-r63238 @ 2006-09-25 3:54 UTC (permalink / raw)
To: Tony Hardie, linuxppc-embedded
In-Reply-To: <CE711B0E5D7A1A4096A808997E00832901B32FEE@fmt-ex01.net.com>
[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]
The machine checking is happening when you configuration read from PCI
bus.
please check the register settings for PCI.
-DAve
Hiya, I'm running into the following issue running on our custom
PPC8270 (PQ2FADS style) system.
It only seems to happen when we load the system just a little
(more PCI interrupts and transactions).
Any ideas?
/ # [ 456.440195] Machine check in kernel mode.
[ 456.442646] Caused by (from SRR1=41030): Transfer error ack
signal
[ 456.448828] Oops: machine check, sig: 7 [#1]
[ 456.453088] PREEMPT
[ 456.455269] NIP: C00119CC LR: C0011914 CTR: C0011334
[ 456.460233] REGS: c01fbd40 TRAP: 0200 Tainted: P
(2.6.17.3)
[ 456.466493] MSR: 00041030 <ME,IR,DR> CR: 22002082 XER:
20000000
[ 456.472589] TASK = c01b5f20[0] 'swapper' THREAD: c01fa000
[ 456.477809] GPR00: 00000000 C01FBDF0 C01B5F20 00000000
FFFFFF7F 00000003 00000001 C01FBE18
[ 456.486164] GPR08: 00000000 F0010904 00000000 F0010907
00000000 100934F0 07FFF000 00000001
[ 456.494520] GPR16: 00800000 07FFE964 FFFFFFFF 00000000
07FFC6BC 007FFF00 FF800040 07FA7770
[ 456.502876] GPR24: C0210000 C01FBE58 00000001 000000CF
C01FBE18 000000A0 C024A000 C03AAA00
[ 456.511406] NIP [C00119CC] indirect_read_config+0x100/0x14c
[ 456.516977] LR [C0011914] indirect_read_config+0x48/0x14c
[ 456.522373] Call Trace:
[ 456.524812] [C01FBDF0] [C01FA028]
init_thread_union+0x28/0x2000 (unreliable)
[ 456.531862] [C01FBE10] [C00E2FB0]
pci_bus_read_config_byte+0x60/0xa8
[ 456.538216] [C01FBE50] [C909373C] OnInterrupt+0x40/0x178
[bridge]
[ 456.544309] [C01FBE70] [C003EA54] handle_IRQ_event+0x64/0xb8
[ 456.549966] [C01FBE90] [C003EBE0] __do_IRQ+0x138/0x1c0
[ 456.555102] [C01FBEC0] [C0009D04] do_IRQ+0x44/0x88
[ 456.559889] [C01FBEE0] [C0004914] ret_from_except+0x0/0x14
[ 456.565372] [C01FBFA0] [C000C9B8] cpu_idle+0xe0/0xf8
[ 456.570334] [C01FBFB0] [C0003A64] rest_init+0x3c/0x4c
[ 456.575382] [C01FBFC0] [C01FC6C4] start_kernel+0x1d0/0x228
[ 456.580865] [C01FBFF0] [000032C0] 0x32c0
[ 456.584781] Instruction dump:
[ 456.587741] bb410008 38210020 7c0803a6 4e800020 887f004c
813e0010 5460063e 7c004a78
[ 456.595487] 3120ffff 7d490110 4bffff70 7c0928ae <0c000000>
4c00012c 901c0000 38600000
[ 456.615184] Kernel panic - not syncing: Aiee, killing
interrupt handler!
Cheers
Tony
Tony Hardie B.Sc
VX Software Architect
Net.com
6900 Paseo Padre Parkway
Fremont
CA, 94555
Ph: 510-574-2386
Mob: 510-449-4339
[-- Attachment #2: Type: text/html, Size: 11623 bytes --]
^ permalink raw reply
* Unable to boot kernel 2.6 from u-boot 1.1.2 in MPC8540
From: revathy @ 2006-09-25 6:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am currently working on a MPC8540 based custom board to port linux-2.6.x.
iam using kernel-2.6.12 in which platform code CCSRBAR is set to 0xff70 0000 which is the
default value for 8540 found from HRM. it hangs at "Uncompressing kernel image...ok".Iam
using u-boot-1.1.2.
Should i edit anything in .config file?
or am i missing something anywhere?
Could someone help me to solve this issue.
Thanks and Regards
Revathy
^ permalink raw reply
* Trouble booting Kernel 2.6.12 on powerpc 8540
From: revathy @ 2006-09-25 5:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
First time iam porting linux kernel 2.6.12 on MPC8540(PIC) board.In
platform code i have set the CCSRBAR to 0xff70 0000 which is the
default value for 8540. it gets hanged at "Uncompressing kernel image...ok".Iam
using u-boot-1.1.2.
Should i edit anything in .config file?
Thanks and Regards
Revathy
^ 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