* Framebuffer driver using SM501 hardware.
From: Surendra Yadav @ 2005-08-16 13:34 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am writing framebuffer driver using SM501. This graphics driver chip can
drive CRT and TFT panel. I have written two seperate framebuffer driver, one
for CRT and one for TFT Panel.
But I am not able to test both the devices. Any one of them work at a time.
I have created two files /dev/fb0 and /dev/fb1. These two can be open
successfully and mmap is also successful from userspace. If I am trying to
write on fb0 and fb1 with different data, they displayed on either CRT or
TFT panel.
Can any one help me How to test two different framebuffer devices?
Thanks.
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-16 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <725685C1-2B6B-4B19-A1E9-D68AB21AFEAF@freescale.com>
Kumar Gala wrote:
> On Aug 12, 2005, at 11:30 AM, Vitaly Bordug wrote:
>
>> Kumar Gala wrote:
>>
>>> Can you do a sizeof instead?
>>>
>>> #define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)
>>>
>>> Something like matchted[num_ele] ??
>>>
>>>
>>
>> That's what the first I tried actually :)
>> gcc is not happy with it:
>>
>> arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
>> arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token
>>
>> and if I remove [] from the ppc_sys_specs, it outputs:
>>
>> arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
>> arch/ppc/syslib/ppc_sys.c:54: error: invalid application of `sizeof' to
>> incomplete type `({anonymous})'
>>
>> So I cannot use sizeof this case, I think...
>
>
> Realized the same thing. I'm thinking that your original method is the
> best solution to just do this on the stack. In general the number or
> processors (array size) is going to be less than 100. So at most this
> array is going to end up being 100 bytes on the stack. I dont think
> that's a big deal at the point we are calling this
>
Thus, are there any modifications needed for the original approach?
Or maybe it's simpler to add say MAX_PPC_SPECS to ppc_sys.h since this
list will be limited anyway? We could have the simple array with static
size then, and additional ppc_sys_specs sanity check (whether it has
"default" element with both 0 id and "" name) could be easily
implemented as well.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Tom Rini @ 2005-08-16 14:49 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev
In-Reply-To: <20050815225224.F28706@cox.net>
On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
> >
> > > This restores behavior from 2.4 where PReP platforms identified
> > > as Motorola would calibrate the decrementer using the RTC. On
> > > real Motorola PReP hardware this isn't needed. However, in order
> > > to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> > > PReP system) it is necessary to allow it to calibrate the decrementer
> > > using an emulated RTC. If the decrementer rate is read from
> > > residual data then timing is screwed since a qemu PReP system typically
> > > runs much faster than the original hardware.
> > >
> > > If anybody has objections to this as the default, let me know. It
> > > still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> > > affect the IBM PReP paths. My goal with this is to be able to run
> > > a stock 2.6 defconfig PReP build on qemu.
> >
> > So, I like this, and not just because I'm playing with qemu as well.
>
> Why? It has no other redeeming quality except that it makes qemu work.
And it gets us away from residual data which can be crap or non
existant. FWIW, I've move past using qemu, and I still like the change.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] Support 440EP On-Chip OHCI USB Host Controller (v3)
From: John Otken @ 2005-08-16 15:25 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-usb-devel
This updated patch adds support for the AMCC 440EP on-chip
OHCI USB host controller. I tested it on the Bamboo board
using the 2.6.13-rc6 kernel.
I'm cross posting this to linux-usb-devel. Let me know if
that's a mistake.
This patch depends on my "fix invalid function name
usb_hcd_put in ohci-ppc-soc.c" patch from 2005-07-20:
http://patchwork.ozlabs.org/linuxppc/patch?id=1803
It also depends on Dale Farnsworth's "2.6.12-3 header
<asm/usb.h> missing" patch on 2005-08-10 to remove usb.h:
http://patchwork.ozlabs.org/linuxppc/patch?id=1969
Thanks to Wade Farnsworth for a bug fix.
This patch supersedes my previous versions released on
2005-07-25, 2005-07-27, and 2005-08-09:
http://patchwork.ozlabs.org/linuxppc/patch?id=1841
http://patchwork.ozlabs.org/linuxppc/patch?id=1855
http://patchwork.ozlabs.org/linuxppc/patch?id=1965
Comments are welcome.
Signed-off-by: John Otken <jotken@softadvances.com>
diff -uprN b/arch/ppc/platforms/4xx/ibm440ep.c c/arch/ppc/platforms/4xx/ibm440ep.c
--- b/arch/ppc/platforms/4xx/ibm440ep.c 2005-08-09 05:45:59.000000000 -0500
+++ c/arch/ppc/platforms/4xx/ibm440ep.c 2005-08-15 16:22:02.031794568 -0500
@@ -194,8 +194,32 @@ static struct resource usb_gadget_resour
},
};
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = 0x0EF601000,
+ .end = 0x0EF60107F,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 40,
+ .end = 40,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static u64 dma_mask = 0xffffffffULL;
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
static struct platform_device usb_gadget_device = {
.name = "musbhsfc",
.id = 0,
@@ -208,6 +232,7 @@ static struct platform_device usb_gadget
};
static struct platform_device *ibm440ep_devs[] __initdata = {
+ &ohci_usb_device,
&usb_gadget_device,
};
diff -uprN b/drivers/usb/host/Kconfig c/drivers/usb/host/Kconfig
--- b/drivers/usb/host/Kconfig 2005-08-09 05:46:03.000000000 -0500
+++ c/drivers/usb/host/Kconfig 2005-08-15 16:20:41.177288635 -0500
@@ -81,12 +81,12 @@ config USB_OHCI_HCD
config USB_OHCI_HCD_PPC_SOC
bool "OHCI support for on-chip PPC USB controller"
- depends on USB_OHCI_HCD && (STB03xxx || PPC_MPC52xx)
+ depends on USB_OHCI_HCD && (STB03xxx || PPC_MPC52xx || 440EP)
default y
select USB_OHCI_BIG_ENDIAN
---help---
- Enables support for the USB controller on the MPC52xx or
- STB03xxx processor chip. If unsure, say Y.
+ Enables support for the USB controller on the MPC52xx,
+ STB03xxx, or 440EP processor chip. If unsure, say Y.
config USB_OHCI_HCD_PCI
bool "OHCI support for PCI-bus USB controllers"
@@ -105,7 +105,7 @@ config USB_OHCI_BIG_ENDIAN
config USB_OHCI_LITTLE_ENDIAN
bool
depends on USB_OHCI_HCD
- default n if STB03xxx || PPC_MPC52xx
+ default n if STB03xxx || PPC_MPC52xx || 440EP
default y
config USB_UHCI_HCD
diff -uprN b/drivers/usb/host/ohci.h c/drivers/usb/host/ohci.h
--- b/drivers/usb/host/ohci.h 2005-08-09 05:46:03.000000000 -0500
+++ c/drivers/usb/host/ohci.h 2005-08-15 16:20:41.183288079 -0500
@@ -560,7 +560,7 @@ static inline u32 hc32_to_cpup (const st
* some big-endian SOC implementations. Same thing happens with PSW access.
*/
-#ifdef CONFIG_STB03xxx
+#if defined(CONFIG_STB03xxx) || defined(CONFIG_440EP)
#define OHCI_BE_FRAME_NO_SHIFT 16
#else
#define OHCI_BE_FRAME_NO_SHIFT 0
diff -uprN b/drivers/usb/Kconfig c/drivers/usb/Kconfig
--- b/drivers/usb/Kconfig 2005-08-09 05:46:02.000000000 -0500
+++ c/drivers/usb/Kconfig 2005-08-15 16:20:41.184287986 -0500
@@ -25,6 +25,7 @@ config USB_ARCH_HAS_OHCI
# PPC:
default y if STB03xxx
default y if PPC_MPC52xx
+ default y if 440EP
# MIPS:
default y if SOC_AU1X00
# more:
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Keith J Outwater @ 2005-08-16 15:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4301C22F.2070006@ru.mvista.com>
Hi Andrei -
Just to be clear: we are talking about linuxppc-2.4 NOT
linuxppc_2_4_devel, right?
Keith
Andrei Konovalov <akonovalov@ru.mvista.com> wrote on 08/16/2005 03:38:39
AM:
> Keith J Outwater wrote:
> > Hello all -
> > I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
> > Can anyone point me to the "best" kernel source tree to use ?
> > "Best" in this case means:
> > 1. A 2.4 series kernel with good support for Xilinx peripheral devices
> > (existing Xilinx ML300 support is fine).
> > 2. Good stability
> >
> > By default I'll use the Montavista linuxppc_2.4 tree unless there is a
> > better choice out there.
>
> If you mean the rsync access to source.mvista.com::linuxppc-2.4
> then yes, this is the most recent (as regards to Virtex II Pro support)
> community 2.4 tree.
>
> Thanks,
> Andrei
>
> > Thanks!
> >
> > Keith
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Andrei Konovalov @ 2005-08-16 16:15 UTC (permalink / raw)
To: Keith J Outwater; +Cc: linuxppc-embedded
In-Reply-To: <OF1B6DBB03.E543CEAD-ON0725705F.0056B53A-0725705F.0056E021@mck.us.ray.com>
Keith J Outwater wrote:
> Hi Andrei -
> Just to be clear: we are talking about linuxppc-2.4 NOT
> linuxppc_2_4_devel, right?
Correct.
Thanks,
Andrei
> Keith
>
> Andrei Konovalov <akonovalov@ru.mvista.com> wrote on 08/16/2005 03:38:39
> AM:
>
>
>>Keith J Outwater wrote:
>>
>>>Hello all -
>>>I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
>>>Can anyone point me to the "best" kernel source tree to use ?
>>>"Best" in this case means:
>>>1. A 2.4 series kernel with good support for Xilinx peripheral devices
>
>
>>>(existing Xilinx ML300 support is fine).
>>>2. Good stability
>>>
>>>By default I'll use the Montavista linuxppc_2.4 tree unless there is a
>
>
>>>better choice out there.
>>
>>If you mean the rsync access to source.mvista.com::linuxppc-2.4
>>then yes, this is the most recent (as regards to Virtex II Pro support)
>>community 2.4 tree.
>>
>>Thanks,
>>Andrei
>>
>>
>>>Thanks!
>>>
>>>Keith
>>>_______________________________________________
>>>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
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Keith J Outwater @ 2005-08-16 16:17 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <43021108.9070200@ru.mvista.com>
Thanks Andrei.
Last question: do you know of any non bitkeeper repositories? I'm stuck
behind a firewall here.
Thanks,
Keith
Andrei Konovalov <akonovalov@ru.mvista.com> wrote on 08/16/2005 09:15:04
AM:
> Keith J Outwater wrote:
> > Hi Andrei -
> > Just to be clear: we are talking about linuxppc-2.4 NOT
> > linuxppc_2_4_devel, right?
>
> Correct.
>
> Thanks,
> Andrei
>
> > Keith
> >
> > Andrei Konovalov <akonovalov@ru.mvista.com> wrote on 08/16/2005
03:38:39
> > AM:
> >
> >
> >>Keith J Outwater wrote:
> >>
> >>>Hello all -
> >>>I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
> >>>Can anyone point me to the "best" kernel source tree to use ?
> >>>"Best" in this case means:
> >>>1. A 2.4 series kernel with good support for Xilinx peripheral
devices
> >
> >
> >>>(existing Xilinx ML300 support is fine).
> >>>2. Good stability
> >>>
> >>>By default I'll use the Montavista linuxppc_2.4 tree unless there is
a
> >
> >
> >>>better choice out there.
> >>
> >>If you mean the rsync access to source.mvista.com::linuxppc-2.4
> >>then yes, this is the most recent (as regards to Virtex II Pro
support)
> >>community 2.4 tree.
> >>
> >>Thanks,
> >>Andrei
> >>
> >>
> >>>Thanks!
> >>>
> >>>Keith
> >>>_______________________________________________
> >>>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
>
>
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Keith J Outwater @ 2005-08-16 15:53 UTC (permalink / raw)
To: Peter Ryser; +Cc: linuxppc-embedded
In-Reply-To: <4301686E.6020904@xilinx.com>
Hi Peter -
Yes, I have looked at both xapp765 and xapp542. In order to get the
kernel source mentioned in the app note, I have to get the Monta Vista
preview kit and get it installed. The preview kit will not install under
Fedora Core 4 - the encryption stuff is broken (and the fix in the Monta
Vista FAQ does not work).
I am running all of my development tools (EDK, ISE, ELDK, etc...) under
Fedora Core 4, so I am looking for a publicly accessible kernel source
tree that best supports the PPC405 in the Virtex II Pro.
Keith
Peter Ryser <peter.ryser@xilinx.com> wrote on 08/15/2005 09:15:42 PM:
> You might want to look at Xilinx Application Note 765 (XAPP765,
> http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf) for some instructions
> on how to get started with EDK and Linux. All source is published in
> linuxppc-2.4.
>
> - Peter
>
>
> Keith J Outwater wrote:
>
> >Hello all -
> >I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
> >Can anyone point me to the "best" kernel source tree to use ?
> >"Best" in this case means:
> >1. A 2.4 series kernel with good support for Xilinx peripheral devices
> >(existing Xilinx ML300 support is fine).
> >2. Good stability
> >
> >By default I'll use the Montavista linuxppc_2.4 tree unless there is a
> >better choice out there.
> >
> >Thanks!
> >
> >Keith
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >
>
>
>
^ permalink raw reply
* [PATCH] Use platform device for 8250 registration
From: David Woodhouse @ 2005-08-16 16:21 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
My dual G4 PowerMac crashes sometimes when it probes for the (absent)
serial ports. Theoretically it's supposed to take a machine check and
recover -- but it doesn't always work like that.
This patch removes the defaults from asm/pc_serial.h and uses the code
which already existed for ppc64 to register any ports which are found in
the device tree. It's slightly updated to work in 32-bit and also on the
Pegasos which claims the input frequency is 0Hz.
We could probably remove all the rest of the crap from asm/serial.h and
let platforms register their own serial8250 platform devices. And this
probably breaks serial ports on PReP, which needs to do likewise.
--- linux-2.6.12/drivers/serial/Makefile~ 2005-08-11 13:51:50.000000000 +0100
+++ linux-2.6.12/drivers/serial/Makefile 2005-08-15 21:08:49.000000000 +0100
@@ -22,6 +22,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250
obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
+obj-$(CONFIG_SERIAL_8250_OF) += 8250_of.o
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
--- linux-2.6.12/drivers/serial/8250_of.c~ 2005-08-15 21:14:27.000000000 +0100
+++ linux-2.6.12/drivers/serial/8250_of.c 2005-08-15 21:20:59.000000000 +0100
@@ -0,0 +1,199 @@
+#include <linux/kernel.h>
+#include <linux/serial.h>
+#include <linux/serial_8250.h>
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <asm/serial.h>
+#include <asm/prom.h>
+
+#if 0
+#define DBG(fmt...) printk(KERN_DEBUG fmt)
+#else
+#define DBG(fmt...) do { } while (0)
+#endif
+
+/*
+ * This function can be used by platforms to "find" legacy serial ports.
+ * It works for "serial" nodes under an "isa" node, and will try to
+ * respect the "ibm,aix-loc" property if any. It works with up to 8
+ * ports.
+ */
+
+#define MAX_LEGACY_SERIAL_PORTS 8
+static int ports_probed = 0;
+
+static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
+static unsigned int old_serial_count;
+
+void __init generic_find_legacy_serial_ports(u64 *physport,
+ unsigned int *default_speed)
+{
+ struct device_node *np;
+ u32 *sizeprop;
+
+ struct isa_reg_property {
+ u32 space;
+ u32 address;
+ u32 size;
+ };
+
+ DBG(" -> generic_find_legacy_serial_port()\n");
+ ports_probed = 1;
+
+ *physport = 0;
+ if (default_speed)
+ *default_speed = 0;
+
+ np = of_find_node_by_path("/");
+ if (!np)
+ return;
+
+ /* First fill our array */
+ for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
+ struct device_node *isa, *pci;
+ struct isa_reg_property *reg;
+ unsigned long phys_size, addr_size;
+ u64 io_base;
+ u32 *rangesp;
+ u32 *interrupts, *clk, *spd;
+ char *typep;
+ int index, rlen, rentsize;
+
+ /* Ok, first check if it's under an "isa" parent */
+ isa = of_get_parent(np);
+ if (!isa || strcmp(isa->name, "isa")) {
+ DBG("%s: no isa parent found\n", np->full_name);
+ continue;
+ }
+
+ /* Now look for an "ibm,aix-loc" property that gives us ordering
+ * if any...
+ */
+ typep = (char *)get_property(np, "ibm,aix-loc", NULL);
+
+ /* Get the ISA port number */
+ reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
+ if (reg == NULL)
+ goto next_port;
+ /* We assume the interrupt number isn't translated ... */
+ interrupts = (u32 *)get_property(np, "interrupts", NULL);
+ /* get clock freq. if present */
+ clk = (u32 *)get_property(np, "clock-frequency", NULL);
+ /* get default speed if present */
+ spd = (u32 *)get_property(np, "current-speed", NULL);
+ /* Default to locate at end of array */
+ index = old_serial_count; /* end of the array by default */
+
+ /* If we have a location index, then use it */
+ if (typep && *typep == 'S') {
+ index = simple_strtol(typep+1, NULL, 0) - 1;
+ /* if index is out of range, use end of array instead */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ index = old_serial_count;
+ /* if our index is still out of range, that mean that
+ * array is full, we could scan for a free slot but that
+ * make little sense to bother, just skip the port
+ */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+ /* Check if there is a port who already claimed our slot */
+ if (serial_ports[index].iobase != 0) {
+ /* if we still have some room, move it, else override */
+ if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
+ DBG("Moved legacy port %d -> %d\n", index,
+ old_serial_count);
+ serial_ports[old_serial_count++] =
+ serial_ports[index];
+ } else {
+ DBG("Replacing legacy port %d\n", index);
+ }
+ }
+ }
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+
+ /* Now fill the entry */
+ memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
+ serial_ports[index].uartclk = (clk && *clk) ? *clk : BASE_BAUD * 16;
+ serial_ports[index].iobase = reg->address;
+ serial_ports[index].irq = interrupts ? interrupts[0] : 0;
+ serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
+
+ DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
+ index,
+ serial_ports[index].iobase,
+ serial_ports[index].irq,
+ serial_ports[index].uartclk);
+
+ /* Get phys address of IO reg for port 1 */
+ if (index != 0)
+ goto next_port;
+
+ pci = of_get_parent(isa);
+ if (!pci) {
+ DBG("%s: no pci parent found\n", np->full_name);
+ goto next_port;
+ }
+
+ rangesp = (u32 *)get_property(pci, "ranges", &rlen);
+ if (rangesp == NULL) {
+ of_node_put(pci);
+ goto next_port;
+ }
+ rlen /= 4;
+
+ /* we need the #size-cells of the PCI bridge node itself */
+ phys_size = 1;
+ sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
+ if (sizeprop != NULL)
+ phys_size = *sizeprop;
+ /* we need the parent #addr-cells */
+ addr_size = prom_n_addr_cells(pci);
+ rentsize = 3 + addr_size + phys_size;
+ io_base = 0;
+ for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
+ if (((rangesp[0] >> 24) & 0x3) != 1)
+ continue; /* not IO space */
+ io_base = rangesp[3];
+ if (addr_size == 2)
+ io_base = (io_base << 32) | rangesp[4];
+ }
+ if (io_base != 0) {
+ *physport = io_base + reg->address;
+ if (default_speed && spd)
+ *default_speed = *spd;
+ }
+ of_node_put(pci);
+ next_port:
+ of_node_put(isa);
+ }
+
+ DBG(" <- generic_find_legacy_serial_port()\n");
+}
+
+static struct platform_device serial_device = {
+ .name = "serial8250",
+ .id = 0,
+ .dev = {
+ .platform_data = serial_ports,
+ },
+};
+
+static int __init serial_dev_init(void)
+{
+ u64 phys;
+ unsigned int spd;
+
+ if (!ports_probed)
+ generic_find_legacy_serial_ports(&phys, &spd);
+ return platform_device_register(&serial_device);
+}
+arch_initcall(serial_dev_init);
+
+
--- linux-2.6.12/drivers/serial/Kconfig~ 2005-08-11 13:51:50.000000000 +0100
+++ linux-2.6.12/drivers/serial/Kconfig 2005-08-15 21:13:41.000000000 +0100
@@ -77,6 +77,11 @@ config SERIAL_8250_CS
If unsure, say N.
+config SERIAL_8250_OF
+ bool
+ default y
+ depends on PPC_OF && SERIAL_8250 != n
+
config SERIAL_8250_ACPI
bool "8250/16550 device discovery via ACPI namespace"
default y if IA64
--- linux-2.6.12/arch/ppc64/kernel/setup.c~ 2005-08-11 13:52:04.000000000 +0100
+++ linux-2.6.12/arch/ppc64/kernel/setup.c 2005-08-15 20:27:25.000000000 +0100
@@ -1147,186 +1147,6 @@ void __init setup_default_decr(void)
lpaca->next_jiffy_update_tb = get_tb() + tb_ticks_per_jiffy;
}
-#ifndef CONFIG_PPC_ISERIES
-/*
- * This function can be used by platforms to "find" legacy serial ports.
- * It works for "serial" nodes under an "isa" node, and will try to
- * respect the "ibm,aix-loc" property if any. It works with up to 8
- * ports.
- */
-
-#define MAX_LEGACY_SERIAL_PORTS 8
-static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
-static unsigned int old_serial_count;
-
-void __init generic_find_legacy_serial_ports(u64 *physport,
- unsigned int *default_speed)
-{
- struct device_node *np;
- u32 *sizeprop;
-
- struct isa_reg_property {
- u32 space;
- u32 address;
- u32 size;
- };
- struct pci_reg_property {
- struct pci_address addr;
- u32 size_hi;
- u32 size_lo;
- };
-
- DBG(" -> generic_find_legacy_serial_port()\n");
-
- *physport = 0;
- if (default_speed)
- *default_speed = 0;
-
- np = of_find_node_by_path("/");
- if (!np)
- return;
-
- /* First fill our array */
- for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
- struct device_node *isa, *pci;
- struct isa_reg_property *reg;
- unsigned long phys_size, addr_size, io_base;
- u32 *rangesp;
- u32 *interrupts, *clk, *spd;
- char *typep;
- int index, rlen, rentsize;
-
- /* Ok, first check if it's under an "isa" parent */
- isa = of_get_parent(np);
- if (!isa || strcmp(isa->name, "isa")) {
- DBG("%s: no isa parent found\n", np->full_name);
- continue;
- }
-
- /* Now look for an "ibm,aix-loc" property that gives us ordering
- * if any...
- */
- typep = (char *)get_property(np, "ibm,aix-loc", NULL);
-
- /* Get the ISA port number */
- reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
- if (reg == NULL)
- goto next_port;
- /* We assume the interrupt number isn't translated ... */
- interrupts = (u32 *)get_property(np, "interrupts", NULL);
- /* get clock freq. if present */
- clk = (u32 *)get_property(np, "clock-frequency", NULL);
- /* get default speed if present */
- spd = (u32 *)get_property(np, "current-speed", NULL);
- /* Default to locate at end of array */
- index = old_serial_count; /* end of the array by default */
-
- /* If we have a location index, then use it */
- if (typep && *typep == 'S') {
- index = simple_strtol(typep+1, NULL, 0) - 1;
- /* if index is out of range, use end of array instead */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- index = old_serial_count;
- /* if our index is still out of range, that mean that
- * array is full, we could scan for a free slot but that
- * make little sense to bother, just skip the port
- */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
- /* Check if there is a port who already claimed our slot */
- if (serial_ports[index].iobase != 0) {
- /* if we still have some room, move it, else override */
- if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
- DBG("Moved legacy port %d -> %d\n", index,
- old_serial_count);
- serial_ports[old_serial_count++] =
- serial_ports[index];
- } else {
- DBG("Replacing legacy port %d\n", index);
- }
- }
- }
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
-
- /* Now fill the entry */
- memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
- serial_ports[index].uartclk = clk ? *clk : BASE_BAUD * 16;
- serial_ports[index].iobase = reg->address;
- serial_ports[index].irq = interrupts ? interrupts[0] : 0;
- serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
-
- DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
- index,
- serial_ports[index].iobase,
- serial_ports[index].irq,
- serial_ports[index].uartclk);
-
- /* Get phys address of IO reg for port 1 */
- if (index != 0)
- goto next_port;
-
- pci = of_get_parent(isa);
- if (!pci) {
- DBG("%s: no pci parent found\n", np->full_name);
- goto next_port;
- }
-
- rangesp = (u32 *)get_property(pci, "ranges", &rlen);
- if (rangesp == NULL) {
- of_node_put(pci);
- goto next_port;
- }
- rlen /= 4;
-
- /* we need the #size-cells of the PCI bridge node itself */
- phys_size = 1;
- sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
- if (sizeprop != NULL)
- phys_size = *sizeprop;
- /* we need the parent #addr-cells */
- addr_size = prom_n_addr_cells(pci);
- rentsize = 3 + addr_size + phys_size;
- io_base = 0;
- for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
- if (((rangesp[0] >> 24) & 0x3) != 1)
- continue; /* not IO space */
- io_base = rangesp[3];
- if (addr_size == 2)
- io_base = (io_base << 32) | rangesp[4];
- }
- if (io_base != 0) {
- *physport = io_base + reg->address;
- if (default_speed && spd)
- *default_speed = *spd;
- }
- of_node_put(pci);
- next_port:
- of_node_put(isa);
- }
-
- DBG(" <- generic_find_legacy_serial_port()\n");
-}
-
-static struct platform_device serial_device = {
- .name = "serial8250",
- .id = 0,
- .dev = {
- .platform_data = serial_ports,
- },
-};
-
-static int __init serial_dev_init(void)
-{
- return platform_device_register(&serial_device);
-}
-arch_initcall(serial_dev_init);
-
-#endif /* CONFIG_PPC_ISERIES */
int check_legacy_ioport(unsigned long base_port)
{
--- linux-2.6.12/include/asm-ppc/pc_serial.h~ 2005-08-15 21:19:32.000000000 +0100
+++ linux-2.6.12/include/asm-ppc/pc_serial.h 2005-08-15 21:20:24.000000000 +0100
@@ -26,18 +26,3 @@
#define RS_TABLE_SIZE 4
#endif
-/* Standard COM flags (except for COM4, because of the 8514 problem) */
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
-#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
-#else
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
-#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
-#endif
-
-#define SERIAL_PORT_DFNS \
- /* UART CLK PORT IRQ FLAGS */ \
- { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, /* ttyS0 */ \
- { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS }, /* ttyS1 */ \
- { 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS }, /* ttyS2 */ \
- { 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS }, /* ttyS3 */
--
dwmw2
^ permalink raw reply
* Re: Framebuffer driver using SM501 hardware.
From: Dan Malek @ 2005-08-16 16:38 UTC (permalink / raw)
To: surendra.yadav; +Cc: linuxppc-dev
In-Reply-To: <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com>
On Aug 16, 2005, at 9:34 AM, Surendra Yadav wrote:
> I am writing framebuffer driver using SM501. This graphics driver chip
> can
> drive CRT and TFT panel. I have written two seperate framebuffer
> driver, one
> for CRT and one for TFT Panel.
I hope you didn't start from scratch. There is already an SM501
framebuffer driver that works for both CRT and TFT panel.
> But I am not able to test both the devices. Any one of them work at a
> time.
> I have created two files /dev/fb0 and /dev/fb1.
I don't think you want to do that unless you want two completely
separate
images on the different outputs. Normally, both the CRT and TFT display
the same images from the single framebuffer, and you use the capability
of the graphics engine to resize as necessary.
> .... These two can be open
> successfully and mmap is also successful from userspace. If I am
> trying to
> write on fb0 and fb1 with different data, they displayed on either
> CRT or
> TFT panel.
If that's what you really want to do, I suspect you will have to
register the driver
twice as two separate frame buffers and then manage that within the
single driver. I would also consider allocating different areas of the
single
frame buffer and then configure the planes to use the different areas
within
the single buffer.
Good luck.
-- Dan
^ permalink raw reply
* [PATCH] ppc32: add 440GX rev.F cputable entry
From: Eugene Surovegin @ 2005-08-16 17:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Add PowerPC 440GX rev.F cputable entry.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -922,6 +922,16 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* 440GX Rev. F */
+ .pvr_mask = 0xf0000fff,
+ .pvr_value = 0x50000894,
+ .cpu_name = "440GX Rev. F",
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
#endif /* CONFIG_44x */
#ifdef CONFIG_FSL_BOOKE
{ /* e200z5 */
^ permalink raw reply
* Re: Framebuffer driver using SM501 hardware.
From: Clemens Koller @ 2005-08-16 18:23 UTC (permalink / raw)
To: surendra.yadav; +Cc: linuxppc-dev
In-Reply-To: <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com>
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
Hi!
I was working with the SM501 framebuffer for a while on
linux-2.6.
It is heavily based on old silicon motion code and
not in good shape, so I didn't dare to publish it ;-)
But it's working on ppc, linux-2.6 and X was running on it.
There is a color-mapping issue left (RGB is swapped on powerpc)
and it needs lots of code cleanup or a complete rewrite.
Due to my project schedule, it will take me some month
until I can focus on the voyagerfb again.
But take what you want...
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Surendra Yadav wrote:
> Hi all,
>
> I am writing framebuffer driver using SM501. This graphics driver chip can
> drive CRT and TFT panel. I have written two seperate framebuffer driver, one
> for CRT and one for TFT Panel.
>
> But I am not able to test both the devices. Any one of them work at a time.
> I have created two files /dev/fb0 and /dev/fb1. These two can be open
> successfully and mmap is also successful from userspace. If I am trying to
> write on fb0 and fb1 with different data, they displayed on either CRT or
> TFT panel.
>
> Can any one help me How to test two different framebuffer devices?
>
> Thanks.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: voyager-0.2.tar.gz --]
[-- Type: application/octet-stream, Size: 25402 bytes --]
^ permalink raw reply
* Re: Framebuffer driver using SM501 hardware.
From: Wolfgang Denk @ 2005-08-16 19:48 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-dev, surendra.yadav
In-Reply-To: <43022F05.3050409@anagramm.de>
In message <43022F05.3050409@anagramm.de> you wrote:
>
> I was working with the SM501 framebuffer for a while on
> linux-2.6.
...and we did in the context of our 2.4 kernel.
> There is a color-mapping issue left (RGB is swapped on powerpc)
> and it needs lots of code cleanup or a complete rewrite.
I think we fixed some of these problems, and I have a couple of other
patches sitting in my queue. Anybody interested can (1) have a look
at our tree and (2) mail me.
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
"A little knowledge is a dangerous thing." - Doug Gwyn
^ permalink raw reply
* Re: Framebuffer driver using SM501 hardware.
From: Wolfgang Denk @ 2005-08-16 19:42 UTC (permalink / raw)
To: surendra.yadav; +Cc: linuxppc-dev
In-Reply-To: <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com>
In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote:
>
> I am writing framebuffer driver using SM501. This graphics driver chip can
Why are you re-inventing the wheel?
> drive CRT and TFT panel. I have written two seperate framebuffer driver, one
> for CRT and one for TFT Panel.
Why didn't you use the existing framebuffer driver?
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
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
^ permalink raw reply
* [PATCH] PPC: Don't sleep in flush_dcache_icache_page()
From: Roland Dreier @ 2005-08-16 20:56 UTC (permalink / raw)
To: mporter, linuxppc-embedded
flush_dcache_icache_page() will be called on an instruction page
fault. We can't sleep in the fault handler, so use kmap_atomic()
instead of just kmap() for the Book-E case.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -560,8 +560,16 @@ void flush_dcache_page(struct page *page
void flush_dcache_icache_page(struct page *page)
{
#ifdef CONFIG_BOOKE
- __flush_dcache_icache(kmap(page));
- kunmap(page);
+ unsigned long flags;
+ void *start;
+
+ local_irq_save(flags);
+
+ start = kmap_atomic(page, KM_PPC_SYNC_PAGE);
+ __flush_dcache_icache(start);
+ kunmap_atomic(start, KM_PPC_SYNC_PAGE);
+
+ local_irq_restore(flags);
#elif CONFIG_8xx
/* On 8xx there is no need to kmap since highmem is not supported */
__flush_dcache_icache(page_address(page));
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Otto Solares @ 2005-08-16 21:12 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050815222510.C28706@cox.net>
On Mon, Aug 15, 2005 at 10:25:10PM -0700, Matt Porter wrote:
> On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote:
> > Hi!
> >
> > Redwood-6 support in 2.6 is broken. I subscribed to this
> > list just to know if somebody is working on it? 2.4.30
> > works ok.
>
> I went ahead and fixed this compile issue in the following patch:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html
Excellent!, it compiles now.
Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
same thing as zImage.treebot that appears now in 2.6?
Thank you.
-otto
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Matt Porter @ 2005-08-16 21:19 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
In-Reply-To: <20050816211259.GB28419@guug.org>
On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> On Mon, Aug 15, 2005 at 10:25:10PM -0700, Matt Porter wrote:
> > On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote:
> > > Hi!
> > >
> > > Redwood-6 support in 2.6 is broken. I subscribed to this
> > > list just to know if somebody is working on it? 2.4.30
> > > works ok.
> >
> > I went ahead and fixed this compile issue in the following patch:
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html
>
> Excellent!, it compiles now.
>
> Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> same thing as zImage.treebot that appears now in 2.6?
Yes, this is the image that boots on the stock OpenBIOS firmware.
It has the standard "tree" header on it.
-Matt
^ permalink raw reply
* [PATCH] ppc32: Fix PPC440SP SRAM controller DCRs
From: Matt Porter @ 2005-08-16 21:41 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Fixes the incorrect DCR base value for the 440SP SRAM controller.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
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
@@ -423,11 +423,7 @@
#define MQ0_CONFIG_SIZE_2G 0x0000c000
/* Internal SRAM Controller 440GX/440SP */
-#ifdef CONFIG_440SP
-#define DCRN_SRAM0_BASE 0x100
-#else /* 440GX */
#define DCRN_SRAM0_BASE 0x000
-#endif
#define DCRN_SRAM0_SB0CR (DCRN_SRAM0_BASE + 0x020)
#define DCRN_SRAM0_SB1CR (DCRN_SRAM0_BASE + 0x021)
^ permalink raw reply
* [PATCH] ppc32: removed usage of <asm/segment.h>
From: Kumar Gala @ 2005-08-16 22:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
Made <asm/segment.h> a dummy include like it is in ppc64 and removed any
users if it in arch/ppc.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit f63ab7e926d6c5e96de501ec9eac7f28af188a65
tree adcc67a572ec8e4d1520a7a5493ea909028e76f9
parent d88b795bc4c4b59c29a98e2a551c2ad4d65901c5
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 16:59:22 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 16:59:22 -0500
arch/ppc/kernel/temp.c | 1 -
arch/ppc/kernel/time.c | 1 -
arch/ppc/platforms/chrp_time.c | 1 -
include/asm-ppc/segment.h | 7 ++++++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/kernel/temp.c b/arch/ppc/kernel/temp.c
--- a/arch/ppc/kernel/temp.c
+++ b/arch/ppc/kernel/temp.c
@@ -21,7 +21,6 @@
#include <linux/interrupt.h>
#include <linux/init.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/reg.h>
#include <asm/nvram.h>
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -58,7 +58,6 @@
#include <linux/init.h>
#include <linux/profile.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/cache.h>
diff --git a/arch/ppc/platforms/chrp_time.c b/arch/ppc/platforms/chrp_time.c
--- a/arch/ppc/platforms/chrp_time.c
+++ b/arch/ppc/platforms/chrp_time.c
@@ -22,7 +22,6 @@
#include <linux/init.h>
#include <linux/bcd.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/prom.h>
diff --git a/include/asm-ppc/segment.h b/include/asm-ppc/segment.h
--- a/include/asm-ppc/segment.h
+++ b/include/asm-ppc/segment.h
@@ -1 +1,6 @@
-#include <asm/uaccess.h>
+#ifndef __PPC_SEGMENT_H
+#define __PPC_SEGMENT_H
+
+/* Only here because we have some old header files that expect it.. */
+
+#endif /* __PPC_SEGMENT_H */
^ permalink raw reply
* [PATCH] ppc32: add cputable entry for 440SP Rev. A
From: Matt Porter @ 2005-08-16 22:17 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Adds the appropriate cputable entry for PPC440SP so cache line
sizes are configured correctly.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -922,6 +922,16 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* 440SP Rev. A */
+ .pvr_mask = 0xff000fff,
+ .pvr_value = 0x53000891,
+ .cpu_name = "440SP Rev. A",
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
#endif /* CONFIG_44x */
#ifdef CONFIG_FSL_BOOKE
{ /* e200z5 */
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Paul Mackerras @ 2005-08-17 1:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0508161700050.5751@nylon.am.freescale.net>
Kumar Gala writes:
> Made <asm/segment.h> a dummy include like it is in ppc64 and removed any
> users if it in arch/ppc.
Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
too, for that matter) entirely?
Paul.
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Shawn Jin @ 2005-08-17 1:53 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <c3d0340b050811154148164691@mail.gmail.com>
> When the kernel is booting, it gets to the point where console_init()
> is called, which calls individual early console initialization
> functions. In my case it's serial8250_console_init(). Before
> register_console() is called in serial8250_console_init(), everything
> seems fine because the debugging logs are printed on the serial port.
> But once register_console() is called, the serial port continues
> spitting out =E0. See the following message. What's wrong?
FYI. The problem was caused by the endianess of io mem access. My
16550-compatible uart port is on a 32-bit bus. The io mem is big
endian. The current serial8250 driver always call read*/write*() to
access uart control registers. These functions are implemented for
little endian access only. So I have to add some awful #ifdef in the
driver to call big endian access functions.
Regards,
-Shawn.
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Otto Solares @ 2005-08-17 2:47 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050816141908.A1053@cox.net>
On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > same thing as zImage.treebot that appears now in 2.6?
>
> Yes, this is the image that boots on the stock OpenBIOS firmware.
> It has the standard "tree" header on it.
Thank you, just one more thing, do you know if the smc91x driver
works for PPC? In 2.4 I had to set:
CONFIG_SMC91111=y
CONFIG_SMC91111_ADVANCED=y
CONFIG_SMC91111_BYTE_SWAP=y
Looking in the driver itself I think it was developed for ARM.
I am unable to netboot, I don't have serial console so my only access
to this little box (MediaMVP) is the net. Thank you.
-otto
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Dale Farnsworth @ 2005-08-17 3:13 UTC (permalink / raw)
To: Otto Solares, linuxppc-embedded
In-Reply-To: <20050817024745.GA30824@guug.org>
On Wed, Aug 17, 2005 at 02:47:45AM +0000, Otto Solares wrote:
> On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> > On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > > same thing as zImage.treebot that appears now in 2.6?
> >
> > Yes, this is the image that boots on the stock OpenBIOS firmware.
> > It has the standard "tree" header on it.
>
> Thank you, just one more thing, do you know if the smc91x driver
> works for PPC?
I added smc91111 support for redwood5 and redwood6 many months
ago. See the reference to CONFIG_REDWOOD_5 in smc91x.h. I haven't
tested it recently though. I'll give it a try tomorrow.
If your machine is not a redwood5 or redwood6, you'll also have to
add platform device initialization in your platform code. See
arch/ppc/platforms/4xx/redwood6.c.
-Dale
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Matt Porter @ 2005-08-17 3:17 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
In-Reply-To: <20050817024745.GA30824@guug.org>
On Tue, Aug 16, 2005 at 08:47:45PM -0600, Otto Solares wrote:
> On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> > On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > > same thing as zImage.treebot that appears now in 2.6?
> >
> > Yes, this is the image that boots on the stock OpenBIOS firmware.
> > It has the standard "tree" header on it.
>
> Thank you, just one more thing, do you know if the smc91x driver
> works for PPC? In 2.4 I had to set:
It should work.
> CONFIG_SMC91111=y
> CONFIG_SMC91111_ADVANCED=y
> CONFIG_SMC91111_BYTE_SWAP=y
>
> Looking in the driver itself I think it was developed for ARM.
Well, the ARM folks were the earliest users of smc9xxxx glued
onto their parts. There have been multiple drivers over the years
and then Nico recently unified them into smc91x. PPC has always
had PCI Ethernets or on-chips Ethernet (like the other 4xx parts)
so having a nasty little smc part glued onto a bus isn't that
popular. :)
It should still work. Dale Farnsworth took the time to add the
proper redwood specific bits to smc91x.h for accessing the regs
and add the bits to instantiate an smc91x platform device in the
redwood kernel ports.
> I am unable to netboot, I don't have serial console so my only access
> to this little box (MediaMVP) is the net. Thank you.
What kernel port are you using? You're trying boot a Redwood 6
kernel on the MediaMVP?
-Matt
^ 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