* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 12:37 UTC (permalink / raw)
To: Matej Kupljen; +Cc: linuxppc-dev
In-Reply-To: <1124279443.16175.40.camel@localhost.localdomain>
Matej Kupljen wrotq:
> Hi Clemens
>
>
>>It would be great to have our code collected somewhere in a public
>>cvs/git archive.
>>There are also some patches to add (accelerated) SM501 support to
>>the latest X somewhere in atmosphere:
>>
>>https://bugs.freedesktop.org/attachment.cgi?id=1775
>
>
> I also did some testing with X and SM501 using SM501 and MPC5200
> on local bus, but I am not working on that board at the moment.
>
> See:
> https://bugs.freedesktop.org/show_bug.cgi?id=312
>
> If I find some time, I'll probably be able to help you
> with some testing.
>
> BR,
> Matej
>
Thanks all for (keen) interest, I'll create cvs/git during nearest days.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Geert Uytterhoeven @ 2005-08-17 12:42 UTC (permalink / raw)
To: Andrey Volkov
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <43032A76.6080104@varma-el.com>
On Wed, 17 Aug 2005, Andrey Volkov wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 17 Aug 2005, Andrey Volkov wrote:
> >
> >>Todo:
> >>- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
> >
> >
> > Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
> > there are).
>
> Sorry for inexactitude, problem (as usually :)) in next (for case of
> MPC5200 connected through PCI to SM501): PCI on PPC (and hence SM501) is
> a little endian, PPC - big endian.
> Currently (up to 2.6.13-rc6) frame buffer routines use
> __raw_writeXX for write to fb memory. Result - garbage with colors in
> RGB565/RGB888 modes (but pixels, meanwhile, are in place). If using
> write[lw] - colors are diplayed correctly, but all image pixels are
> shifted for (RGB565). This is not bug of frame buffer, this is lack of
> some define in .config which tell fb/device driver how palette must be
> generated (more precisely it is unknown when must be RGB565, but when
> must be BGR565).
Sorry, I cannot follow.
1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
the pseudo palette,
2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
in the color bitfields in fb_var_screeninfo,
3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
And then there's no much we can do...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 13:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-embedded list, linuxppc-dev list
In-Reply-To: <1124263872.3869.48.camel@localhost.localdomain>
> Yes, that's precisely what I meant. Just remove it from the list in
> serial.h and as Ben says, instantiating a platform device is easy.
>
> static struct plat_serial8250_port my_serial_ports[] = {
> {
> .uartclk = 115200*16,
> .iobase = 0x2f8,
> .irq = 3,
> .flags = ASYNC_BOOT_AUTOCONF;
> },
> };
>
> static struct platform_device my_serial_device = {
> .name = "serial8250",
> .dev.platform_data = my_serial_ports,
> };
>
> ... platform_device_register(&my_serial_device);
If we are going forward with this change for OF, can we kill
pc_serial.h and just move the default BASE_BAUD and RS_TABLE size
into serial.h.
- kumar
^ permalink raw reply
* When are machine checks suppose to be recoverable?
From: Kumar Gala @ 2005-08-17 14:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev list; +Cc: David Woodhouse
In-Reply-To: <1124209292.3869.5.camel@localhost.localdomain>
David's 8250 cleanup patch made me wondering when are machine checks
suppose to recoverable? General class of conditions is what I'm
looking for here.
Is David's case due to some PCI master abort or something else?
- kumar
On Aug 16, 2005, at 11:21 AM, David Woodhouse wrote:
> 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.
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 14:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <Pine.LNX.4.62.0508171439060.6073@numbat.sonytel.be>
Geert Uytterhoeven wrote:
> On Wed, 17 Aug 2005, Andrey Volkov wrote:
>
>>Geert Uytterhoeven wrote:
>>
>>>On Wed, 17 Aug 2005, Andrey Volkov wrote:
>>>
>>>
>>>>Todo:
>>>>- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
>>>
>>>
>>>Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
>>>there are).
>>
>>Sorry for inexactitude, problem (as usually :)) in next (for case of
>>MPC5200 connected through PCI to SM501): PCI on PPC (and hence SM501) is
>>a little endian, PPC - big endian.
>>Currently (up to 2.6.13-rc6) frame buffer routines use
>>__raw_writeXX for write to fb memory. Result - garbage with colors in
>>RGB565/RGB888 modes (but pixels, meanwhile, are in place). If using
>>write[lw] - colors are diplayed correctly, but all image pixels are
>>shifted for (RGB565). This is not bug of frame buffer, this is lack of
>>some define in .config which tell fb/device driver how palette must be
>>generated (more precisely it is unknown when must be RGB565, but when
>>must be BGR565).
>
>
> Sorry, I cannot follow.
Ok, I'll try more clearly:
>
> 1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
> the pseudo palette,
> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
> in the color bitfields in fb_var_screeninfo,
Yes, due to duality of SM501: in memory mapped mode, its endian same as
on the host, BUT in PCI mode it work only as little endian
(theoretically it could be switched to big endian too, but for PPC it
have not meaning).
Both above problems could be solved by #ifdef/#else in SM5xx driver (as
I said before, my driver in prerelease stage :) ).
But it will be more useful, IMHO, if somewhere in Kconfig will be
defined something like CONFIG_PCI_LITTLE_ENDIAN/
CONFIG_FB_TARGET_LITTLE_ENDIAN.
> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
Right. As I wrote before, when SM501 blitter work as PCI bus master, it
read/write from/to host memory in little endian mode. But situation
changed when HOST (MPC), read/write from/to framebuffer - PCI subsystem
of MPC convert endian on the fly :(.
Currently I've two workarounds:
1) Don't use SM501 as bus master (more preferably, since SM501 anyway
have some silicon bugs when work as bus master)
2) Try use different functions for accelerated/unaccelerated bitblit.
> And then there's no much we can do...
>
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Clemens Koller @ 2005-08-17 14:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <Pine.LNX.4.62.0508171439060.6073@numbat.sonytel.be>
Hi Geert, Andrey and friends...
I am working on ppc, MPC8540, SM501 on PCI,
drivers=voyagerfb-0.2.tar.gz from last post.
on linux-2.6
Geert wrote:
> Sorry, I cannot follow.
>
> 1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
> the pseudo palette,
> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
> in the color bitfields in fb_var_screeninfo,
> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
> And then there's no much we can do...
It looks for me like 3. = bytes are flipped = an endian issue:
In 32 (RGBAlpha) mode (the one we want to use) the colors appear
wrong. I get my /dev/fb0 appear as
BB GG RR aa BB GG RR aa BB GG RR aa ...
In the great SM501 Databook Version 1.02, Page 2-39, it says:
Configuration 2, Endian Control at MMIO_base+0x00005c:
write 0x00000000 for little endian or
write 0xffffffff for big endian
into this register before touching any other register of the sm501.
I've tried that, but it didn't change anything on my system. :-(
(Well, we can flip the DAC outputs in our hw design ;-)
Best greets,
Clemens
_______________________________
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
------------------------------------------------
details:
$ cp red /dev/fb0
gives me a some red color...
$ bvi red
00000000 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000010 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000020 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
...
$ cp green /dev/fb0
gives me a some green color...
00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
...
$ cp blue /dev/fb0
well... blue
FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 14:52 UTC (permalink / raw)
To: Clemens Koller
Cc: Linux/PPC Development, Geert Uytterhoeven,
Linux Frame Buffer Device Development, surendra.yadav
In-Reply-To: <43034A59.6000008@anagramm.de>
Clemens Koller wrote:
> Hi Geert, Andrey and friends...
>
> I am working on ppc, MPC8540, SM501 on PCI,
> drivers=voyagerfb-0.2.tar.gz from last post.
> on linux-2.6
>
> Geert wrote:
>
>> Sorry, I cannot follow.
>>
>> 1. If it's a palette issue, your setcolreg() routine doesn't fill in
>> correctly
>> the pseudo palette,
>> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the
>> offsets
>> in the color bitfields in fb_var_screeninfo,
>> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG,
>> right?
>> And then there's no much we can do...
>
>
> It looks for me like 3. = bytes are flipped = an endian issue:
> In 32 (RGBAlpha) mode (the one we want to use) the colors appear
> wrong. I get my /dev/fb0 appear as
> BB GG RR aa BB GG RR aa BB GG RR aa ...
>
> In the
> great
You're forget qutation here :)
SM501 Databook Version 1.02, Page 2-39, it says:
> Configuration 2, Endian Control at MMIO_base+0x00005c:
> write 0x00000000 for little endian or
> write 0xffffffff for big endian
> into this register before touching any other register of the sm501.
> I've tried that, but it didn't change anything on my system. :-(
> (Well, we can flip the DAC outputs in our hw design ;-)
As I understand, but I'm not sure, LE/BE controlled only by some GPIO
pin (GPIO4 was on rev A/B). I try write to this reg too, with same result.
>
> Best greets,
>
> Clemens
> _______________________________
> 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
>
> ------------------------------------------------
> details:
>
> $ cp red /dev/fb0 gives me a some red color...
> $ bvi red
> 00000000 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000010 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000020 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> ...
> $ cp green /dev/fb0 gives me a some green color...
> 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
> ...
> $ cp blue /dev/fb0
> well... blue
> FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00
>
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 15:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list, linuxppc-embedded list
In-Reply-To: <1124263872.3869.48.camel@localhost.localdomain>
On Wed, Aug 17, 2005 at 08:31:11AM +0100, David Woodhouse wrote:
> On Wed, 2005-08-17 at 01:30 -0500, Kumar Gala wrote:
> > > We could probably remove all the rest of the crap from asm/serial.h and
> > > let platforms register their own serial8250 platform devices...
>
> > Hmm, I wondering if we can provide some standard way of handling this
> > for the embedded platforms as well. It would be nice to drop the old
> > style of initialization completely and move to using a platform
> > device always.
>
> Yes, that's precisely what I meant. Just remove it from the list in
> serial.h and as Ben says, instantiating a platform device is easy.
>
> static struct plat_serial8250_port my_serial_ports[] = {
> {
> .uartclk = 115200*16,
> .iobase = 0x2f8,
> .irq = 3,
> .flags = ASYNC_BOOT_AUTOCONF;
> },
> };
So long as you convert arch/ppc/boot/ to this as well, why not (or at
least being able to grab the infos from these structs somehow).
Once everyone is on a flat tree, I don't object to killing all of the
old-style uart definitions steaming out of <asm-ppc/serial.h>.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 15:22 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817150536.GN8214@smtp.west.cox.net>
> So long as you convert arch/ppc/boot/ to this as well, why not (or at
> least being able to grab the infos from these structs somehow).
>
> Once everyone is on a flat tree, I don't object to killing all of the
> old-style uart definitions steaming out of <asm-ppc/serial.h>.
Tom, do have a test system that I can look at converting that you
would be willing to test the changes to arch/ppc/boot for me.
(everything I boot doesn't use it)
- kumar
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 15:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <DCB7B3B3-635C-400A-BBAC-DF092AD5B143@freescale.com>
On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >So long as you convert arch/ppc/boot/ to this as well, why not (or at
> >least being able to grab the infos from these structs somehow).
> >
> >Once everyone is on a flat tree, I don't object to killing all of the
> >old-style uart definitions steaming out of <asm-ppc/serial.h>.
>
> Tom, do have a test system that I can look at converting that you
> would be willing to test the changes to arch/ppc/boot for me.
With Matt's patch, you could boot a PReP kernel (no VGA con) :)
But if you convert LoPEC, I'll throw the kernel at it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 16:16 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817153013.GO8214@smtp.west.cox.net>
On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
> On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
>
>
>>> So long as you convert arch/ppc/boot/ to this as well, why not
>>> (or at
>>> least being able to grab the infos from these structs somehow).
>>>
>>> Once everyone is on a flat tree, I don't object to killing all of
>>> the
>>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
>>>
>>
>> Tom, do have a test system that I can look at converting that you
>> would be willing to test the changes to arch/ppc/boot for me.
>>
>
> With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> But if you convert LoPEC, I'll throw the kernel at it.
Does PReP use bootcode? I thought it was OF based, but what do I know.
- kumar
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Matt Porter @ 2005-08-17 16:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Tom Rini, linuxppc-embedded list, David Woodhouse,
linuxppc-dev list
In-Reply-To: <184D9473-D0E7-4424-A25F-60381472C10A@freescale.com>
On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
>
> On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
>
> > On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >
> >
> >>> So long as you convert arch/ppc/boot/ to this as well, why not
> >>> (or at
> >>> least being able to grab the infos from these structs somehow).
> >>>
> >>> Once everyone is on a flat tree, I don't object to killing all of
> >>> the
> >>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
> >>>
> >>
> >> Tom, do have a test system that I can look at converting that you
> >> would be willing to test the changes to arch/ppc/boot for me.
> >>
> >
> > With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> > But if you convert LoPEC, I'll throw the kernel at it.
>
> Does PReP use bootcode? I thought it was OF based, but what do I know.
Are you asking on a real machine or on qemu? On real PReP hardwrae
you can find both OF and other firmware like PPCBUG...in both cases
they dump residual data. On qemu, jmayer wrote the openhackware bios
with is supposed to be some minimal OF-like thing...it dumps
residual data too.
-Matt
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 16:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <184D9473-D0E7-4424-A25F-60381472C10A@freescale.com>
On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
>
> On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
>
> >On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >
> >
> >>>So long as you convert arch/ppc/boot/ to this as well, why not
> >>>(or at
> >>>least being able to grab the infos from these structs somehow).
> >>>
> >>>Once everyone is on a flat tree, I don't object to killing all of
> >>>the
> >>>old-style uart definitions steaming out of <asm-ppc/serial.h>.
> >>>
> >>
> >>Tom, do have a test system that I can look at converting that you
> >>would be willing to test the changes to arch/ppc/boot for me.
> >>
> >
> >With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> >But if you convert LoPEC, I'll throw the kernel at it.
>
> Does PReP use bootcode? I thought it was OF based, but what do I know.
In qemu? Yes, it does.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 16:35 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817092703.B6355@cox.net>
On Wed, Aug 17, 2005 at 09:27:03AM -0700, Matt Porter wrote:
> On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
> >
> > On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
> >
> > > On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> > >
> > >
> > >>> So long as you convert arch/ppc/boot/ to this as well, why not
> > >>> (or at
> > >>> least being able to grab the infos from these structs somehow).
> > >>>
> > >>> Once everyone is on a flat tree, I don't object to killing all of
> > >>> the
> > >>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
> > >>>
> > >>
> > >> Tom, do have a test system that I can look at converting that you
> > >> would be willing to test the changes to arch/ppc/boot for me.
> > >>
> > >
> > > With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> > > But if you convert LoPEC, I'll throw the kernel at it.
> >
> > Does PReP use bootcode? I thought it was OF based, but what do I know.
>
> Are you asking on a real machine or on qemu? On real PReP hardwrae
> you can find both OF and other firmware like PPCBUG...in both cases
> they dump residual data. On qemu, jmayer wrote the openhackware bios
> with is supposed to be some minimal OF-like thing...it dumps
> residual data too.
But either way, the kernel boots using the code in arch/ppc/boot/simple/
which uses serial values from <asm-ppc/pc_serial.h>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: David Woodhouse @ 2005-08-17 16:39 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev
In-Reply-To: <20050817121128.A19990@flint.arm.linux.org.uk>
On Wed, 2005-08-17 at 12:11 +0100, Russell King wrote:
> Doesn't PPC64 have NO_IRQ ?
PPC64 does but I find no definition of is_real_interrupt() other than
the bogus one in 8250.c which checks for zero. PPC32 does not -- let's
clean that one up separately.
--- 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,197 @@
+#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,4 @@
#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 /* */
-#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: [PATCH] Use platform device for 8250 registration
From: Russell King @ 2005-08-17 16:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1124296771.3869.74.camel@localhost.localdomain>
On Wed, Aug 17, 2005 at 05:39:30PM +0100, David Woodhouse wrote:
> On Wed, 2005-08-17 at 12:11 +0100, Russell King wrote:
> > Doesn't PPC64 have NO_IRQ ?
>
> PPC64 does but I find no definition of is_real_interrupt() other than
> the bogus one in 8250.c which checks for zero. PPC32 does not -- let's
> clean that one up separately.
Ok. I'll give you this line now for this patch:
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
so you're free to push it upstream whenever you deem is the right time.
Thanks.
--
Russell King
^ permalink raw reply
* [PATCH] ppc32: ppc_sys SOC identification additions
From: Vitaly Bordug @ 2005-08-17 17:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Kumar,
this is proposed extension of ppc_sys identify functions.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_add.patch --]
[-- Type: text/x-patch, Size: 2509 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -35,10 +36,58 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
- /* TODO */
+ unsigned int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ break;
+ i++;
+ }
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
return;
}
+static int __init count_sys_specs(void)
+{
+ int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, ""))
+ i++;
+ return i;
+}
+
+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+ int ret = -1;
+ unsigned int i = 0;
+ unsigned int j = 0;
+ unsigned int dups = 0;
+
+ unsigned char matched[count_sys_specs()];
+
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ matched[j++] = i;
+ i++;
+ }
+ if (j != 0) {
+ for (i = 0; i < j; i++) {
+ if ((ppc_sys_specs[matched[i]].mask & id) ==
+ ppc_sys_specs[matched[i]].value) {
+ ret = matched[i];
+ dups++;
+ }
+ }
+ ret = (dups == 1) ? ret : (-1 * dups);
+ }
+ return ret;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name, id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
+}
+
/* Update all memory resources by paddr, call before platform_device_register */
void __init
ppc_sys_fixup_mem_resource(struct platform_device *pdev, phys_addr_t paddr)
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -51,7 +51,8 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
-extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name(char* name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Dale Farnsworth @ 2005-08-17 19:18 UTC (permalink / raw)
To: Otto Solares, linuxppc-embedded
In-Reply-To: <20050817031336.GA20712@xyzzy.farnsworth.org>
On Wed, Aug 17, 2005 at 03:13:36AM +0000, Dale Farnsworth wrote:
> 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.
Just following up. I verified that current linux-2.6.git netboots
fine on redwood5 using the SMC91111.
-Dale
^ permalink raw reply
* [PATCH] Fix for TLB errata on early Xilinx Virtex-II Pro silicon
From: Grant Likely @ 2005-08-17 20:05 UTC (permalink / raw)
To: linuxppc-embedded
Early versions of the Xilinx Virtex-II Pro have a TLB errata where
only even numbered TLB entries work correctly. Occurs on chips where
PVR == 0x20010820 || 0x20010860
See Record #14052, solution #12 in the Xilinx answers database
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14052
This patch adds a config option to use only even TLB entries on the V2Pro
It also makes a trivial change to the Kconfig so that Xilinx options depend
on VIRTEX_II_PRO instead of XILINX_ML300
Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
---
arch/ppc/kernel/head_4xx.S | 11 +++++++++++
arch/ppc/platforms/4xx/Kconfig | 28 ++++++++++++++++++++++------
2 files changed, 33 insertions(+), 6 deletions(-)
322a82cd190a777e4ebe728cad2a2a3759039260
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -769,7 +769,11 @@ finish_tlb_load:
/* load the next available TLB index.
*/
lwz r9, tlb_4xx_index@l(0)
+#if defined(CONFIG_VIRTEX_II_PRO_TLB_FIX)
+ addi r9, r9, 2
+#else
addi r9, r9, 1
+#endif
andi. r9, r9, (PPC4XX_TLB_SIZE-1)
stw r9, tlb_4xx_index@l(0)
@@ -926,7 +930,14 @@ initial_mmu:
clrrwi r3,r3,10 /* Mask off the effective page number */ ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
+#if defined(CONFIG_VIRTEX_II_PRO_TLB_FIX)
+ /* Odd numbered TLB slots are broken on Xilinx V2Pro processors
+ * where PVR = 20010820 | 20010860
+ */
+ li r0,62 /* TLB slot 62 */
+#else
li r0,63 /* TLB slot 63 */
+#endif
tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -161,11 +161,6 @@ config IBM_OCP
depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || EP405 || LUAN || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
default y
-config XILINX_OCP
- bool
- depends on XILINX_ML300
- default y
-
config IBM_EMAC4
bool
depends on 440GX || 440SP
@@ -201,6 +196,27 @@ config VIRTEX_II_PRO
depends on XILINX_ML300
default y
+config VIRTEX_II_PRO_TLB_FIX
+ bool "Virtex-II Pro TLB bugfix"
+ depends on VIRTEX_II_PRO
+ default n
+ help
+ Early versions of the Xilinx Virtex-II Pro have a TLB errata where
+ only even numbered TLB entries work correctly. Say Y here if
+ PVR == 0x20010820 || 0x20010860, or if your board crashes early
+ after enabling the MMU
+
+ See Record #14052, solution #12 in the Xilinx answers database
+ http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14052
+
+ It is safe to say Y here, but there is a performance impact.
+ Say N if unsure.
+
+config XILINX_OCP
+ bool
+ depends on VIRTEX_II_PRO
+ default y
+
config STB03xxx
bool
depends on REDWOOD_5 || REDWOOD_6
@@ -208,7 +224,7 @@ config STB03xxx
config EMBEDDEDBOOT
bool
- depends on EP405 || XILINX_ML300
+ depends on EP405 || VIRTEX_II_PRO
default y
config IBM_OPENBIOS
^ permalink raw reply
* Cartões UOL
From: cartoes @ 2005-08-17 6:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 6217 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys SOC identification additions
From: Wolfgang Denk @ 2005-08-17 20:49 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <430372E9.7040700@ru.mvista.com>
In message <430372E9.7040700@ru.mvista.com> you wrote:
>
> + while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
...
> + while (strcmp(ppc_sys_specs[i].ppc_sys_name, ""))
...
> + while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
What about:
while (ppc_sys_specs[i].ppc_sys_name[0]) ... ???
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
What we anticipate seldom occurs; what we least expect generally
happens. - Bengamin Disraeli
^ permalink raw reply
* Re: When are machine checks suppose to be recoverable?
From: Benjamin Herrenschmidt @ 2005-08-17 21:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse
In-Reply-To: <76E28B16-5706-48C8-B92A-349C4F40FA76@freescale.com>
On Wed, 2005-08-17 at 09:00 -0500, Kumar Gala wrote:
> David's 8250 cleanup patch made me wondering when are machine checks
> suppose to recoverable? General class of conditions is what I'm
> looking for here.
>
> Is David's case due to some PCI master abort or something else?
Might be some issue on SMP machines...
Ben.
^ permalink raw reply
* Re: When are machine checks suppose to be recoverable?
From: David Woodhouse @ 2005-08-17 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1124315089.8857.41.camel@gaston>
On Thu, 2005-08-18 at 07:44 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2005-08-17 at 09:00 -0500, Kumar Gala wrote:
> > David's 8250 cleanup patch made me wondering when are machine checks
> > suppose to recoverable? General class of conditions is what I'm
> > looking for here.
> >
> > Is David's case due to some PCI master abort or something else?
>
> Might be some issue on SMP machines...
Yeah, that'll probably be the reason it turns out _not_ to be
recoverable despite our expectations. But that wasn't Kumar's question.
--
dwmw2
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Otto Solares @ 2005-08-18 0:08 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050817191815.GA331@xyzzy.farnsworth.org>
On Wed, Aug 17, 2005 at 12:18:15PM -0700, Dale Farnsworth wrote:
> On Wed, Aug 17, 2005 at 03:13:36AM +0000, Dale Farnsworth wrote:
> > 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.
>
> Just following up. I verified that current linux-2.6.git netboots
> fine on redwood5 using the SMC91111.
Excellent for your code! the box I'm talking about is redwood6
based, just a question, the supplied smc91xxx.c for 2.4 needs
byte swapping, that works ok with your code and this unified
smc91x driver?
Thank you.
-otto
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Otto Solares @ 2005-08-18 0:02 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050816201745.C2246@cox.net>
On Tue, Aug 16, 2005 at 08:17:45PM -0700, Matt Porter wrote:
> What kernel port are you using? You're trying boot a Redwood 6
> kernel on the MediaMVP?
I'm using kernel.org's 2.6.12.4 + your dma patch.
Yes I'm trying to boot this redwood6 kernel on the MediaMVP,
Hauppauge provides source for 2.4.18 which is plain old, my
University project is boot a 2.6 kernel on this little box.
I setup netconsole to see what's going on in the boot but
it doesn't work that's why I think the smc91x driver does not
support PPC or probably it does not support netpoll which is
the base for netconsole, I'll continue figuring out what is
going on.
I really apreciate all your help. Thank you.
-otto
^ 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