* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Peter Ryser @ 2006-01-17 17:06 UTC (permalink / raw)
To: Grant Likely
Cc: Andrei Konovalov, Grant Likely, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CD1021.7080205@secretlab.ca>
> I don't understand what you mean. It sounds like your suggesting I do
> exactly opposite what you're arguing; hand modify one of the
> xparameters_*.h files. Are you saying that edk can't generate Linux
> redefines for the ml403 at the moment?
Yes, it can. It looks they are not present in the xparameters_ml403.h
that you submitted as part of your patch. I'll send you the
automatically generated file in a seperate email.
> I do *not* think I should replace the edk-generated
> xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
> rather use the generated _ml403 file and change the infrastructure
> when the Linux redefines are ready.
See above. BTW, I'm not sure how familiar you are with the process in
EDK. Let me know if I can help you step through it.
>> That's not a recommended flow. It's very easy to create an EDK design
>> with the proper settings and since it is very likely that things
>> change during the design process of the FPGA the small investment
>> into making the proper settings in the tool will save a lot of time
>> in the end.
>
>
> I understand that it's not *recommended*; I'm just saying it's not
> always *reality* :p
Yeah, that's true for user projects. However, I hope that we can get the
default included in the Linux 2.6 kernel right.
> Yes; but I already said that I'll change the patch to use the Xilinx
> redefines. My argument is simply that *if* changes are required,
> there is a way for the user to do it. In the normal (recommended)
> case; nothing will need to be done. (think Larry Wall's quote: "easy
> things easy; hard things possible)
>
> When it is needed; the fixups will be in xparameters.h; not
> xparameters_*.h; and they'll be for a specific port. The fixups will
> only need to be done once per project (most likely).
I'm not sure that I follow your argument here.
> My point is that the Linux redefines are useful to more than just
> Linux ports. Don't you think standalone apps could also benefit from
> a sane-set of defines for peripherals? In other words; shouldn't the
> Linux redefines be always available (and called something more generic)?
I see what you mean and I tend to agree.
> okay, I'll change the patch to use those names.
Great. Thanks.
- Peter
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 17:30 UTC (permalink / raw)
To: Peter Ryser
Cc: Andrei Konovalov, Grant Likely, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CD240C.2050907@xilinx.com>
Peter Ryser wrote:
>
>> I don't understand what you mean. It sounds like your suggesting I do
>> exactly opposite what you're arguing; hand modify one of the
>> xparameters_*.h files. Are you saying that edk can't generate Linux
>> redefines for the ml403 at the moment?
>
>
> Yes, it can. It looks they are not present in the xparameters_ml403.h
> that you submitted as part of your patch. I'll send you the
> automatically generated file in a seperate email.
okay good; I misunderstood what you were saying. I pulled
xparameters_ml403.h out of the ref design w/ the standalone bsp. I just
haven't bothered trying to generating the Linux bsp yet.
>
>> I do *not* think I should replace the edk-generated
>> xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
>> rather use the generated _ml403 file and change the infrastructure
>> when the Linux redefines are ready.
>
>
> See above. BTW, I'm not sure how familiar you are with the process in
> EDK. Let me know if I can help you step through it.
okay, I'll ping you when I've got questions.
>> I understand that it's not *recommended*; I'm just saying it's not
>> always *reality* :p
>
>
> Yeah, that's true for user projects. However, I hope that we can get the
> default included in the Linux 2.6 kernel right.
yes, definately
>
>> Yes; but I already said that I'll change the patch to use the Xilinx
>> redefines. My argument is simply that *if* changes are required,
>> there is a way for the user to do it. In the normal (recommended)
>> case; nothing will need to be done. (think Larry Wall's quote: "easy
>> things easy; hard things possible)
>>
>> When it is needed; the fixups will be in xparameters.h; not
>> xparameters_*.h; and they'll be for a specific port. The fixups will
>> only need to be done once per project (most likely).
>
>
> I'm not sure that I follow your argument here.
I'll compose my answer in code; watch for patches. :)
btw, once Linus closes the 2.6.16 merge window, it looks like we may be
able to use the powerpc.git tree for tracking these changes.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 18:31 UTC (permalink / raw)
To: John Bonesio
Cc: Grant Likely, Andrei Konovalov, rick.moleres, linuxppc-embedded
In-Reply-To: <2FE3DBF1797A1443AAB3FA0EF6BF4EEC0123723E@XSJ-EXCHVS1.xlnx.xilinx.com>
John Bonesio wrote:
> Hello,
>
> I work in the Xilinx software group.
>
> I'm replying to this email thread because Grant suggested there be a GIT
> tree for Virtex specific changes.
I was told today that we may be able to use Paul's linuxppc tree. I'm
going to ask him later today.
>
> I am wondering if the open source community would prefer or see a
> benefit to Xilinx owning/hosting the source trees (CVS or GIT or
> whatever) for our drivers, and in particular the Linux adapter drivers.
> If we did this we would provide a web site with the information along
> with instructions on how to submit changes.
>
> We are exploring this idea and wanted to know what others thought of
> this.
Let's just keep things on the mailing list; it's the natural place to
discuss issues. If the traffic gets too high, we can do something
different.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* RE: [PATCH 00/10] Updated ML300 & ML403 patches
From: John Bonesio @ 2006-01-17 18:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Grant Likely, Andrei Konovalov, rick.moleres
Hello,
I work in the Xilinx software group.
I'm replying to this email thread because Grant suggested there be a GIT
tree for Virtex specific changes.
I am wondering if the open source community would prefer or see a
benefit to Xilinx owning/hosting the source trees (CVS or GIT or
whatever) for our drivers, and in particular the Linux adapter drivers.
If we did this we would provide a web site with the information along
with instructions on how to submit changes.
We are exploring this idea and wanted to know what others thought of
this.
- John
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Grant Likely
Sent: Tuesday, January 17, 2006 8:41 AM
To: peter.ryser
Cc: Grant Likely; Andrei Konovalov; rick.moleres; linuxppc-embedded
Subject: Re: [PATCH 00/10] Updated ML300 & ML403 patches
Peter Ryser wrote:
>=20
>> Hmm, did you use the ml403 and ml300 def configs? What date did you=20
>> pull Linus' tree? Kumar and Paul were talking today about some
serial=20
>> subsystem breakage on the linux-2.6 tree this weekend... I'll fast=20
>> forward tonight and try it on my board.=20
>=20
>=20
> Okay, please let me know how this works for you.
>=20
>> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
>> That's what I generated the latest patches against.=20
>=20
>=20
> Hmm, I only recently switched to using git. Is this number string some
> kind of a tag that I can synchronize my local git tree to? If so, how?
>=20
Yea, the number is kind of like a raw tag without a name associated with
it. The cg-seek command can be used to get you there. (But you also=20
need to have cogito installed)
>>> Anyway, there is another issue that I would like to bring up and it=20
>>> has to do with xparameters.h. The xparameters.h file, or more=20
>>> exactly, the xparameters_* file, is automatically generated by EDK=20
>>> and is then used to configure the devices in the Linux kernel at=20
>>> compile time. While I understand the desire to get away from a
static=20
>>> device definition to device enumeration at run-time, the current set
>>> of patches is a step backwards for users from a useability point of=20
>>> view. Users will now have to modify xparameters*.h by hand which is=20
>>> an error-prone process.=20
>>
>>
>>
>> Actually, users should *never* modifiy generated files. The intent
is=20
>> that board specific fixups go directly into the top level=20
>> xparameters.h so that newly generated files don't have to be touched.
>> But yes, I understand what you mean.=20
>=20
>=20
> An EDK user is free to choose arbitrary names for his peripherals.=20
> Additionally, Base System Builder uses different names for various=20
> boards (historically). With that it is impossible to make static=20
> assignments in xparameters.h. If you go back to the 2.4 kernel and
have=20
> a look at xparameters_ml300.h you can see that the assignment of
boards=20
> specific parameters to Linux specific parameters is done in there and=20
> that xparameters.h is basically used to chose the proper xparameters_*
> file for a given board.
okay
>=20
>>> Additionally, the original 'redefines' are now replaced with=20
>>> redefines in xparameters.h but differently for every board. I
suggest=20
>>> we keep the 2.4 methodology until we can come up with a better=20
>>> approach to enumerate devices at run-time.
>>
>>
>>
>> Andrei & I are already discussing this. I'm going to change the=20
>> xparameters redefines to provide a default set of mappings that can
be=20
>> used if xparameters_*.h has the linux specific mappings.=20
>=20
>=20
> Thanks. Why not just use the xparameters_ml300.h file created by the=20
> system_linux.xmp in the EDK reference design for the ML403 and rename
it=20
> to xparameters_ml403.h for inclusion into the kernel tree? We could
then=20
> make a change in EDK, add a parameter that lets the user specify the=20
> board he uses, and with that automatically create an
xparameters_ml403.h=20
> (or any other board for that matter).
I don't understand what you mean. It sounds like your suggesting I do=20
exactly opposite what you're arguing; hand modify one of the=20
xparameters_*.h files. Are you saying that edk can't generate Linux=20
redefines for the ml403 at the moment?
I do *not* think I should replace the edk-generated xparameters_ml403.h=20
with a hacked xparameters_ml300.h file. I'd rather use the generated=20
_ml403 file and change the infrastructure when the Linux redefines are=20
ready.
>=20
>> However, due to the fact that generated xparam files don't have the=20
>> Linux redefines if the FPGA engineer doesn't select a linux bsp.
>
>=20
> That's not a recommended flow. It's very easy to create an EDK design=20
> with the proper settings and since it is very likely that things
change=20
> during the design process of the FPGA the small investment into making
> the proper settings in the tool will save a lot of time in the end.
I understand that it's not *recommended*; I'm just saying it's not=20
always *reality* :p
>=20
>> I think it's important to allow user defined 'fixups' for their=20
>> board. (I've personally worked on a couple of projects where the FPGA
>> engineer would not generate the Linux BSP). Design specific fixups=20
>> can go into the top level xparameters.h without touching the
generated=20
>> file=20
>=20
>=20
> I strongly believe that this approach fixes things in the wrong place.
> The correct thing to do is to use EDK to create a proper
xparameters_*.h=20
> that matches the FPGA design. In your methodology, if the user decides
> to change the peripheral names in EDK he will have to go back and
change=20
> the defines in xparameters.h. With the 2.4 kernel methodology that is=20
> not necessary as such changes will be represented in a regenerated=20
> board-specific xparameters_*.h
???
Yes; but I already said that I'll change the patch to use the Xilinx=20
redefines. My argument is simply that *if* changes are required, there=20
is a way for the user to do it. In the normal (recommended) case;=20
nothing will need to be done. (think Larry Wall's quote: "easy things=20
easy; hard things possible)
When it is needed; the fixups will be in xparameters.h; not=20
xparameters_*.h; and they'll be for a specific port. The fixups will=20
only need to be done once per project (most likely).
>=20
>> <rant> BTW; it really bugs me that edk will generate different xparam
>> files depending on the bsp; why isn't there a single standard set of=20
>> data that is loaded into all xparam files; regardless of software=20
>> target? Some no-OS targets need the same information that a Linux=20
>> port needs. </rant>=20
>=20
>=20
> EDK creates an xparameters.h that matches the names of the parameters
in=20
> the hardware design. However, EDK is capable of assuming other=20
> personalities than 'standalone', for example Linux.
My point is that the Linux redefines are useful to more than just Linux=20
ports. Don't you think standalone apps could also benefit from a=20
sane-set of defines for peripherals? In other words; shouldn't the=20
Linux redefines be always available (and called something more generic)?
> With the Linux=20
> personality it creates the proper files AND directory structure for=20
> inclusion into the Linux kernel. Ideally, the source files that are
used=20
> to create the Linux bsp for a given FPGA design should be included in=20
> the kernel tree and be maintained in there (maybe, in the xparameters=20
> directory). I'm not so sure though how well this would be accepted in=20
> the community. Opinions?
I'll get back to you on this; I've got some thoughts; but they'll take a
while to coallate.
>=20
>> I've avoided using the same names as used by the Linux redefines=20
>> because I don't know how stable the linux bsp naming convention is,=20
>> and I want to avoid a naming conflict. If you can *guarantee* me
that=20
>> those linux redefines are stable, then I have no problem using them=20
>> instead of the new defines that are currently in the patch. If they=20
>> are not; then I'll just do a one-to-one mapping into a
non-conflicting=20
>> namespace, and users can provide custom definitions as needed.=20
>=20
>=20
> The names are stable. They have not changed since xparameters_ml300.h=20
> has been initially published to the 2.4 repository and there are no=20
> intentions on changing them. And again, we really want to move towards
a=20
> structure that allows for detecting peripherals at run-time. That will
> improve useability by a magnitude as no recompilation of the Linux=20
> kernel will be needed when the FPGA design changes.
okay, I'll change the patch to use those names.
>=20
>> This really isn't a big deal anyway; most of this discussion will=20
>> become moot in short order. Sometime in the next few releases,=20
>> linuxppc will flip over to using a flattened device tree to pass=20
>> device information from the boot loader to the kernel. xparameters=20
>> will drop out of the kernel proper entirely except for the=20
>> edk-generated device drivers (which is another issue entirely). All=20
>> the xparam stuff will be extracted into a device tree by u-boot or
the=20
>> zImage wrapper. The kernel just won't care. :)=20
>=20
>=20
> I agree. That's the way to go. Let's work towards that goal and keep=20
> xparameters_* as they have been in 2.4 for the moment.
>=20
>>> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.=20
>>> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
>>> generation and indicates how much memory is available for Linux.
This=20
>>> can be (and typically is) the same as the physically available
memory=20
>>> but can be less than that. On the other hand XPAR_MEM_* can be the=20
>>> same or a multiple of the physically available memory (aliasing for=20
>>> cached and non-cached accesses). Statically defining the memory size
>>> in xparameters_ml403.h is not desirable. This is especially true for
>>> the multi-processor FPGA devices that might want to share the=20
>>> physically available memory between themselves.
>>
>>
>>
>> As you can see in embed_config.c; I already discovered this the hard=20
>> way :(=20
>=20
>=20
> Right. Sorry, I was quoting the wrong file. The value should not be=20
> hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used=20
> which is defined in xparameters_ml403.h.
ok
>=20
>> Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I=20
>> don't have a copy of the linux xparams for ml403 in front of me at
the=20
>> moment) Is this something new?=20
>=20
>=20
> I was referring to XPAR*MEM*, i.e. the base address and high address=20
> definition for the memory in EDK.
>=20
>> Really, this isn't statically defined anyway. The bootloader (u-boot
>> or zImage) passes the memory size into the kernel; and in fact the=20
>> kernel command line; or the board setup code can restrict the amount=20
>> of mem used by the kernel. XPAR_MEM_* isn't used by the kernel
proper=20
>> at all.=20
>=20
>=20
> Agreed.
>=20
>> Thanks for the comments.=20
>=20
>=20
> Thanks for making this patch available. I know how much hard work it
is=20
> to get this done.
>=20
>>
>>
>> Another issue we need to discuss is if/how to support the xilinx=20
>> generated BSP in the kernel proper; but I'll leave that for a=20
>> different email.=20
>=20
>=20
> Okay.
>=20
>> If there's enough interest; I'll setup another git tree for the
virtex=20
>> specific patches.=20
>=20
>=20
> Hmm, interesting idea. Let's see what others think.
>=20
> - Peter
cool, thanks.
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] PPC32 8xx: support for the physmapped flash on m8xx
From: Vitaly Bordug @ 2006-01-17 19:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
Implemented more correct way to support physmapped flash on m8xx
than map in mtd.
The areas intended to contain bootloader are protected readonly.
Note that CFI and JEDEC stuff should be configured properly in order
this to work, e.g. for 885/86x CFI should support 4-chip flash interleave.
Also fixed compilation warning.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/syslib/m8xx_setup.c | 50 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
index 688616d..efe3308 100644
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -34,6 +34,13 @@
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#if defined(CONFIG_MTD) && defined(CONFIG_MTD_PHYSMAP)
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#endif
+
#include <asm/mmu.h>
#include <asm/reg.h>
#include <asm/residual.h>
@@ -49,6 +56,34 @@
#include "ppc8xx_pic.h"
+#ifdef CONFIG_MTD_PHYSMAP
+#define MPC8xxADS_BANK_WIDTH 4
+#endif
+
+#define MPC8xxADS_U_BOOT_SIZE 0x80000
+#define MPC8xxADS_FREE_AREA_OFFSET MPC8xxADS_U_BOOT_SIZE
+
+#if defined(CONFIG_MTD_PARTITIONS)
+ /*
+ NOTE: bank width and interleave relative to the installed flash
+ should have been chosen within MTD_CFI_GEOMETRY options.
+ */
+static struct mtd_partition mpc8xxads_partitions[] = {
+ {
+ .name = "bootloader",
+ .size = MPC8xxADS_U_BOOT_SIZE,
+ .offset = 0,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ }, {
+ .name = "User FS",
+ .offset = MPC8xxADS_FREE_AREA_OFFSET
+ }
+};
+
+#define mpc8xxads_part_num (sizeof (mpc8xxads_partitions) / sizeof (mpc8xxads_partitions[0]))
+
+#endif
+
static int m8xx_set_rtc_time(unsigned long time);
static unsigned long m8xx_get_rtc_time(void);
void m8xx_calibrate_decr(void);
@@ -71,6 +106,10 @@ board_init(void)
void __init
m8xx_setup_arch(void)
{
+#if defined(CONFIG_MTD) && defined(CONFIG_MTD_PHYSMAP)
+ bd_t *binfo = (bd_t *)__res;
+#endif
+
/* Reset the Communication Processor Module.
*/
m8xx_cpm_reset();
@@ -106,6 +145,17 @@ m8xx_setup_arch(void)
}
#endif
#endif
+
+#if defined (CONFIG_MPC86XADS) || defined (CONFIG_MPC885ADS)
+#if defined(CONFIG_MTD_PHYSMAP)
+ physmap_configure(binfo->bi_flashstart, binfo->bi_flashsize,
+ MPC8xxADS_BANK_WIDTH, NULL);
+#ifdef CONFIG_MTD_PARTITIONS
+ physmap_set_partitions(mpc8xxads_partitions, mpc8xxads_part_num);
+#endif /* CONFIG_MTD_PARTITIONS */
+#endif /* CONFIG_MTD_PHYSMAP */
+#endif
+
board_init();
}
^ permalink raw reply related
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 19:31 UTC (permalink / raw)
To: Peter Ryser
Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CCE89B.8050603@xilinx.com>
Peter Ryser wrote:
>
>> Hmm, did you use the ml403 and ml300 def configs? What date did you
>> pull Linus' tree? Kumar and Paul were talking today about some serial
>> subsystem breakage on the linux-2.6 tree this weekend... I'll fast
>> forward tonight and try it on my board.
>
>
> Okay, please let me know how this works for you.
Yeah, the head of Linus' tree is busted. Doing a cg-seek
67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need
to remove the following line from arch/ppc/kernel/ppc_ksyms.c
EXPORT_SYMBOL(get_wchan);
The fix will be in post -rc1
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Linux-2.4.31 porting
From: Jose França (Ext_GTBC) @ 2006-01-17 19:33 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
Hello u all!
Have you already ported a linux-2.4.31 to be used on a PPC mpc8272 (or anyone from the family) based board?
The problem that I have is that i don't have console. As far as i could debug, the kernel stucks on my_console_write (in arch/ppc/cpm2_io/uart.c), waiting for transmitter fifo to empty (line 2298 - "while (bdp->cbd_sc & BD_SC_READY)").
Any suggestions will be highly welcomed!
Thanks for reading!
Best regards,
Filipe.
[-- Attachment #2: Type: text/html, Size: 1266 bytes --]
^ permalink raw reply
* Re: Linux-2.4.31 porting
From: Vitaly Bordug @ 2006-01-17 20:08 UTC (permalink / raw)
To: Jose França; +Cc: linuxppc-embedded
In-Reply-To: <16FD2D70D281D44F9BFCF6ACF9B6117102AF6570@lisi053a.siemens.pt>
On Tue, 17 Jan 2006 19:33:21 -0000
Jose França (Ext_GTBC) <Jose.Franca.Ext@siemens.com> wrote:
> Hello u all!
>
> Have you already ported a linux-2.4.31 to be used on a PPC mpc8272 (or anyone from the family) based board?
> The problem that I have is that i don't have console. As far as i could debug, the kernel stucks on my_console_write (in arch/ppc/cpm2_io/uart.c), waiting for transmitter fifo to empty (line 2298 - "while (bdp->cbd_sc & BD_SC_READY)").
> Any suggestions will be highly welcomed!
>
>
Better use 2.6 as 8272 is definitely OK there (and it was in 2.4 but I've almost forgotten issues in 2.4)
>
> Thanks for reading!
> Best regards,
> Filipe.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: T Ziomek @ 2006-01-17 20:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tomz
In-Reply-To: <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org>
Here's another lurker poking his head up...
Grant Likely wrote:
>
> John Bonesio wrote:
> > Hello,
> >
> > I work in the Xilinx software group.
> >
> > I'm replying to this email thread because Grant suggested there be a GIT
> > tree for Virtex specific changes.
>
> I was told today that we may be able to use Paul's linuxppc tree. I'm
> going to ask him later today.
Probably a newbie question...my understanding is that kernel.org is the
preferred repository for PPC-specific code these days, correct? So the a-
bove is referring to Xilinx-specific PPC code? From what I can see on LXR
and kernel.org neither has any Xilinx-related code...
> > I am wondering if the open source community would prefer or see a
> > benefit to Xilinx owning/hosting the source trees (CVS or GIT or
> > whatever) for our drivers, and in particular the Linux adapter drivers.
> > If we did this we would provide a web site with the information along
> > with instructions on how to submit changes.
> >
> > We are exploring this idea and wanted to know what others thought of
> > this.
>
> Let's just keep things on the mailing list; it's the natural place to
> discuss issues. If the traffic gets too high, we can do something
> different.
Re keeping discussion on linuxppc-embedded, sure. Re the hosting of source
trees, I'd definitely like to see Xilinx take that on if the stuff dis-
cussed above doesn't come to pass. We need to have a relatively stable,
long-term primary source for such code.
Tom Ziomek
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 20:19 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0601171341520.2664@holyoke.labs.mot.com>
T Ziomek wrote:
> Here's another lurker poking his head up...
>
> Grant Likely wrote:
>
>>John Bonesio wrote:
>>
>>>Hello,
>>>
>>>I work in the Xilinx software group.
>>>
>>>I'm replying to this email thread because Grant suggested there be a GIT
>>>tree for Virtex specific changes.
>>
>>I was told today that we may be able to use Paul's linuxppc tree. I'm
>>going to ask him later today.
>
>
> Probably a newbie question...my understanding is that kernel.org is the
> preferred repository for PPC-specific code these days, correct? So the a-
> bove is referring to Xilinx-specific PPC code? From what I can see on LXR
> and kernel.org neither has any Xilinx-related code...
mainline linux-2.6 tree has ml300 support
ml300 platform bus support is pending for the powerpc.git tree
ml403 support is pending for the powerpc.git tree
powerpc.git is periodically pulled into linux-2.6
both are on kernel.org
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: T Ziomek @ 2006-01-17 20:23 UTC (permalink / raw)
To: Grant Likely; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <43CD5144.1070401@secretlab.ca>
On Tue, 17 Jan 2006, Grant Likely wrote:
>
> T Ziomek wrote:
>>
>> Grant Likely wrote:
>>
>>> John Bonesio wrote:
. . .
>>>> I'm replying to this email thread because Grant suggested there be a GIT
>>>> tree for Virtex specific changes.
>>>
>>> I was told today that we may be able to use Paul's linuxppc tree. I'm
>>> going to ask him later today.
>>
>> Probably a newbie question...my understanding is that kernel.org is the
>> preferred repository for PPC-specific code these days, correct? So the a-
>> bove is referring to Xilinx-specific PPC code? From what I can see on LXR
>> and kernel.org neither has any Xilinx-related code...
>
> mainline linux-2.6 tree has ml300 support
>
> ml300 platform bus support is pending for the powerpc.git tree
> ml403 support is pending for the powerpc.git tree
>
> powerpc.git is periodically pulled into linux-2.6
>
> both are on kernel.org
Meh, okay. But then what are the "Virtex specific changes" that would need
to be in Paul's linuxppc tree or anywhere but kernel.org?
Thanks, Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 20:37 UTC (permalink / raw)
To: T Ziomek; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0601171420460.2664@holyoke.labs.mot.com>
T Ziomek wrote:
> On Tue, 17 Jan 2006, Grant Likely wrote:
>> T Ziomek wrote:
>>> Grant Likely wrote:
>>>> John Bonesio wrote:
>>>>> Grant Likely wrote:
>>>>> I'm replying to this email thread because Grant suggested there be
>>>>> a GIT
>>>>> tree for Virtex specific changes.
<--- snip --->
>>
>> mainline linux-2.6 tree has ml300 support
>>
>> ml300 platform bus support is pending for the powerpc.git tree
>> ml403 support is pending for the powerpc.git tree
>>
>> powerpc.git is periodically pulled into linux-2.6
>>
>> both are on kernel.org
>
> Meh, okay. But then what are the "Virtex specific changes" that would need
> to be in Paul's linuxppc tree or anywhere but kernel.org?
Basically, I was thinking about a 'development sandbox' that feeds into
linux-2.6.git. However, if we can use Paul's powerpc tree, then I don't
need to create yet-another-git-tree
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: Linux-2.4.31 porting
From: Mark Chambers @ 2006-01-17 20:31 UTC (permalink / raw)
In-Reply-To: <16FD2D70D281D44F9BFCF6ACF9B6117102AF6570@lisi053a.siemens.pt>
Linux-2.4.31 porting
>Hello u all!
> Have you already ported a linux-2.4.31 to be used on a PPC mpc8272
(or anyone from the family) based board?
> The problem that I have is that i don't have console. As far as i
could debug, the kernel stucks on my_console_write (in
arch/ppc/cpm2_io/uart.c), waiting >for transmitter fifo to empty (line
2298 - "while (bdp->cbd_sc & BD_SC_READY)").
> Any suggestions will be highly welcomed!
I have used 2.4.24 running on an mpc8247 based board. My board uses SMC1,
SCC3 and SCC4 for tty,
(console on SCC4) so I had to edit the configuration in uart.c, but no other
changes. You probably have
a configuration mis-match, maybe your parallel port pins are not getting set
up right.
By the way, 2.4.24 put FCC ethernet tables in reserved memory, but I think
that was fixed by 2.4.31.
Check that you have CONFIG_8272 in your .config file to be sure.
Also, I worked from CONFIG_ADS8260 and I couldn't make a bit of sense of the
PCI implementation.
I think the mpc8266ads_pci.c implementation assumes some setup from the
bootloader. I'll be glad to share
what I did (though I'm not very sure of it) if you run into the same
problem.
Mark Chambers
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-17 21:24 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <2557.1137487077@www21.gmx.net>
> That's the problem: we don't have the datasheet for the ArticiaS. :-(
> But the driver initializes correctly with the Uninorth code now and with the
> DRI/DRM code changed. (The code in drm_vm.c checks for Apple's PCI vendor
> ID. Therefore I just added a check for MAI's PCI vendor ID.) But the X
> server freezes after the login screen is displayed (IIRC the mouse still
> works, but the keyboard is dead!?).
That check is only necessary because Apple bridge puts the AGP aperture
at bus address 0. This is probably not the case for you. You may not
have that right. Check what you put in agp_bridge->gart_bus_addr
> BTW: A "agp_special_page" is reserved in init.c. Is this page necessary for
> the DRI/DRM drivers to work with the Uninorth driver? I enabled this code
> snipped for the AmigaONE too to be on the safe side. :-)
It's, I think, still used by the r128 one, but it's not a very good
workaround.
> There may be another problem: it seems that it is not possible to flush the
> TLB cache of the ArticiaS with a specific register setting. At least MAI
> didn't specify a bit for this purpose in the code. I have to do some reverse
> engineering here. :-)
Hrm... You definitely need a way to flush it
> > - The AGP aperture itself. The main issue there is wether your chipset
> > makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
> > doesn't for example, it;'s only visible to the graphic chip. That is why
> > the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
> > generate AGP mappings by using the real memory pages and putting them
> > together into a virtual mapping instead of doing a direct mapping of the
> > AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
> > remapping of pages is enough.
> Good question! How would I have to modify the Uninorth driver to use a
> direct mapping of the AGP aperture on the bus?
Don't set cant_use_aperture to 1 :)
Ben.
^ permalink raw reply
* Question about SCC Ethernet driver
From: David Tao @ 2006-01-18 1:28 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
Hello there,
Present MPC8260 SCC Ethernet driver supports one 10M Ethernet port for SCC1 or SCC2. And there is a patch on the net said to support one Ethernet port on any of SCC1 - SCC4. As we hope to use all the SCCs for 10M Ethernet ports, we need to change the driver. Questions:
1. Is it possible to implement 7 Ethernet ports (3 FCCs and 4 SCCs) on a MPC8270? I didn't see any hardware restriction on this. Performance may be an issue?
2. Is there a driver which supports multiple SCC Ethernet ports simultanously?
Thanks for any help or information.
Regards,
David
---------------------------------
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
[-- Attachment #2: Type: text/html, Size: 1101 bytes --]
^ permalink raw reply
* Re: Question about SCC Ethernet driver
From: Dan Malek @ 2006-01-18 2:04 UTC (permalink / raw)
To: David Tao; +Cc: Linuxppc-embedded
In-Reply-To: <20060118012837.70518.qmail@web32113.mail.mud.yahoo.com>
On Jan 17, 2006, at 8:28 PM, David Tao wrote:
> Present MPC8260 SCC Ethernet driver supports=A0one 10M Ethernet port =
for=20
> SCC1 or SCC2.
Not any more. Take a look at drivers/net/fs_enet in the 2.6 kernels.
I'm sure Pantelis will have more information when he reads this.
> 1. Is it possible to=A0implement 7 Ethernet ports (3 FCCs and 4 SCCs) =
on=20
> a MPC8270? I didn't see any hardware restriction on this. Performance=20=
> may be an issue?=A0
Depends what you want to do with the data in the CPU core and the
clock speeds you have chosen. The CPM can handle the data traffic on
the wires if you run it over 133 MHz.
Thanks.
-- Dan
^ permalink raw reply
* Re: Question about SCC Ethernet driver
From: Pantelis Antoniou @ 2006-01-18 7:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f1e571d3a8b8813c95659dea615cace9@embeddededge.com>
On Wednesday 18 January 2006 04:04, Dan Malek wrote:
>=20
> On Jan 17, 2006, at 8:28 PM, David Tao wrote:
>=20
> > Present MPC8260 SCC Ethernet driver supports=A0one 10M Ethernet port fo=
r=20
> > SCC1 or SCC2.
>=20
> Not any more. Take a look at drivers/net/fs_enet in the 2.6 kernels.
> I'm sure Pantelis will have more information when he reads this.
>=20
The current driver (fs_enet) can handle enets on every SCC. Nobody has
tested this configuration yet however.
> > 1. Is it possible to=A0implement 7 Ethernet ports (3 FCCs and 4 SCCs) o=
n=20
> > a MPC8270? I didn't see any hardware restriction on this. Performance=20
> > may be an issue?=A0
>=20
> Depends what you want to do with the data in the CPU core and the
> clock speeds you have chosen. The CPM can handle the data traffic on
> the wires if you run it over 133 MHz.
>
Your main problem will be dual port RAM conflicts with other peripheral.
In theory CPM can handle it.
> Thanks.
>=20
> -- Dan
>=20
Regards
Pantelis
^ permalink raw reply
* Feedback: Support for fn key on Apple PowerBooks
From: Frank Arnold @ 2006-01-18 10:27 UTC (permalink / raw)
To: linuxppc-dev
Hi,
finally this patch seems to have made it into recent Fedora Rawhide
kernel. Thanks for your work.
I have some trouble with it. Actually, the mapping of function keys F1
to F10 seems to be inverse. I have to press fn + function key to get a
plain function key event. Pressing a function key only gives me those
fancy new keycodes for brightness, mute, and so on. Page up, Page down,
Home, and End are working like expected.
My system: PowerBook5,6 (vendor id 0x020F)
Kernel: 2.6.15-1.1858_FC5, as per Changelog 2.6.15-git12
-- Frank
^ permalink raw reply
* Re: Feedback: Support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2006-01-18 11:20 UTC (permalink / raw)
To: Frank Arnold; +Cc: linuxppc-dev
In-Reply-To: <1137580063.3466.134.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Wed, Jan 18, 2006 at 11:27:43AM +0100, Frank Arnold wrote:
> I have some trouble with it. Actually, the mapping of function keys F1
> to F10 seems to be inverse. I have to press fn + function key to get a
> plain function key event. Pressing a function key only gives me those
> fancy new keycodes for brightness, mute, and so on. Page up, Page down,
> Home, and End are working like expected.
Mac OS X behaviour (default):
echo 1 > /sys/modules/usbhid/parameters/pb_fnmode
F keys first:
echo 2 > /sys/modules/usbhid/parameters/pb_fnmode
Disable special keys completly, but report Fn to userland:
echo 0 > /sys/modules/usbhid/parameters/pb_fnmode
You could have been able to find that out easily by looking at the
source code.
Greets,
Michael
--
Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/
"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Arthur Othieno @ 2006-01-18 11:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060116121244.GB7171@suse.de>
On Mon, Jan 16, 2006 at 01:12:44PM +0100, Olaf Hering wrote:
>
> Everything is merged into arch/powerpc now.
> Stop cross-posting.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> Documentation/powerpc/hvcs.txt | 2 +-
> MAINTAINERS | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
[snip]
> Index: linux-2.6.15-olh/MAINTAINERS
> ===================================================================
> --- linux-2.6.15-olh.orig/MAINTAINERS
> +++ linux-2.6.15-olh/MAINTAINERS
> @@ -527,7 +527,7 @@ S: Supported
> BROADBAND PROCESSOR ARCHITECTURE
> P: Arnd Bergmann
> M: arnd@arndb.de
> -L: linuxppc64-dev@ozlabs.org
> +L: linuxppc-dev@ozlabs.org
> W: http://linuxppc64.org
> S: Supported
>
> @@ -1606,7 +1606,7 @@ P: Anton Blanchard
> M: anton@samba.org
> M: anton@au.ibm.com
> W: http://linuxppc64.org
> -L: linuxppc64-dev@ozlabs.org
> +L: linuxppc-dev@ozlabs.org
> S: Supported
>
> LINUX SECURITY MODULE (LSM) FRAMEWORK
What about the s/linuxppc64\.org/penguinppc\.org/g case? Or is
penguinppc64.org preferable? Or am I just taking it too far? ;)
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Olaf Hering @ 2006-01-18 12:07 UTC (permalink / raw)
To: Arthur Othieno; +Cc: linuxppc-dev
In-Reply-To: <20060118110905.GA23678@krypton>
On Wed, Jan 18, Arthur Othieno wrote:
> What about the s/linuxppc64\.org/penguinppc\.org/g case? Or is
> penguinppc64.org preferable? Or am I just taking it too far? ;)
They are redirected on DNS or HTTP level.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: General GIT MO question
From: Andrey Volkov @ 2006-01-18 12:28 UTC (permalink / raw)
To: Grant Likely; +Cc: David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <43CD2003.3020903@secretlab.ca>
Grant Likely wrote:
> David H. Lynch Jr. wrote:
>> I appreciate you feedback on the E12/UartLite stuff I posted earlier.
> no problem
>
>> I have gotten sufficiently compitent with git that I can use it as a
>> source code manager.
>> But despite perusing through a fairly significant amount of git docs, I
>> have not really grasped how to get from how I work to what seems to be
>> the norm for patch subimissions.
> Heh, your tracking the same path of pain that I went through 2 months
> ago. :)
>
>> Fixing a bug or adding a small feature is one thing. You have a base,
>> and and end result and a simple diff. But I am porting to a whole new
>> board, adding support for two new serial drivers, and adding boot to
>> init serial IO support - all at once, as well as dealing with bugs and
>> mis-steps along the way.
>>
>> I can figure out how to get git to do alot of nice things, but I can
>> not figure out how to get it to produce a nice modularized set of
>> patches that includes only those things relevant for kernel submission.
> Here's what I do, assuming that my changes are in the 'master' branch,
> and 'master' is based off of 'origin'. BTW, I also use the cogito with git.
>
> 1. create a new branch 'cleanup' off of origin so it doesn't have any of
> my patches in it.
> $ git branch cleanup origin
> $ git checkout origin
>
> 2. get a list of all my patches; I use 'cg log' and look for the sha1
> 'commit' tags.
> $ cg log master
> p
> 3a. start 'cherry-picking' my patches one-by-one from 'master' to
> 'cleanup'. Feel free to use this to reorder patches
> $ git cherry-pick -r <first-commit-sha1>
> $ git cherry-pick -r <second-commit-sha1>
> $ git cherry-pick -r <third-commit-sha1>
>
> 3b. If I want to modify the patch before committing; I use the -n flag
> to only apply the changes; clean up the change, then commit it with the
> -c flag. Also do this if a patch conflicts.
> $ git cherry-pick -r -n <messy-commit-sha1>
> $ <edit stuff>
> $ cg commit -c <messy-commit-sha1> # Use the original change message
>
> 3c. Cherry picking works for merging patches too
> $ git cherry-pick -r -n <partial-patch1>
> $ git cherry-pick -r -n <partial-patch2>
> $ git cherry-pick -r -n <partial-patch3>
> $ cg commit
>
> 4. generate patch files for submission to the mailing list
> $ git-format-patch -o <output dir> origin cleanup
>
> 5. (optional) make 'cleanup' the new 'master
> $ git branch -f master cleanup
> $ git checkout master
>
>> I am looking for a clue here. How do you produce a clean set of
>> granular patches including only what you want and not the all the steps
>> and mis-steps along the way ?
>
>
Or use stg (http://www.procode.org/stgit/),
steps 1-2 you could made by
stg new
steps 3 trough 5 by :
stg refresh/stg export
--
Regards
Andrey Volkov
^ permalink raw reply
* 2.6.16-rc1: iptables broken on ppc32?
From: Mikael Pettersson @ 2006-01-18 14:09 UTC (permalink / raw)
To: linuxppc-dev, netfilter-devel, linux-kernel
When trying out kernel 2.6.16-rc1 on a ppc32 box (G4 eMac),
the kernel refused to load my /etc/sysconfig/iptables. strace
on /sbin/iptables-restore shows that the kernel returns EINVAL
instead of accepting the configuration:
setsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\214\0p\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1664) = -1 EINVAL (Invalid argument)
The exact same configuration is accepted and works on an x86 box
also running 2.6.16-rc1, and of course the configuration worked
in all kernels up to and including 2.6.15 on the ppc32 box.
A much simplified /etc/sysconfig/iptables that fails on ppc32 but
works on x86 is the following:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT
COMMIT
My 2.6.16-rc1 kernel configuration includes
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
and the iptable_filter, ip_tables, and x_tables modules were all loaded,
just like they were on the working x86 box.
User-space on the ppc32 box is YDL 4.0 with iptables-1.2.9-2.3.1.
/Mikael
^ permalink raw reply
* Re: Feedback: Support for fn key on Apple PowerBooks
From: Frank Arnold @ 2006-01-18 14:30 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linuxppc-dev
In-Reply-To: <20060118112049.GA32634@hansmi.ch>
Am Mittwoch, den 18.01.2006, 12:20 +0100 schrieb Michael Hanselmann:
> On Wed, Jan 18, 2006 at 11:27:43AM +0100, Frank Arnold wrote:
> > I have some trouble with it. Actually, the mapping of function keys F1
> > to F10 seems to be inverse. I have to press fn + function key to get a
> > plain function key event. Pressing a function key only gives me those
> > fancy new keycodes for brightness, mute, and so on. Page up, Page down,
> > Home, and End are working like expected.
>
> Mac OS X behaviour (default):
> echo 1 > /sys/modules/usbhid/parameters/pb_fnmode
Thank you, now I've got it.
I never really used Mac OS X and didn't know about this behavior.
Personally I would prefer fkeysfirst as default setting. It's much more
sane on Linux because function keys are frequently used in different
applications. I nearly break my fingers when trying to get to the GNOME
main menu with fkeyslast.
Anyway, perhaps I'm biased. I can live with both, now that I know where
to set it.
Frank
^ permalink raw reply
* Badness in kref_get at lib/kref.c:32, of_get_parent broken
From: Olaf Hering @ 2006-01-18 15:18 UTC (permalink / raw)
To: linuxppc-dev
2.6.16-rc1-git1 gives these warnings in early boot:
Total memory = 512MB; using 1024kB for hash table (at cfe00000)
Linux version 2.6.16-rc1-git1-pegasos2 (olaf@pomegranate) (gcc version 3.3.3 (SuSE Linux)) #21 Wed Jan 18 15:15:25 CET 2006
Found initrd at 0xc2711000:0xc293d578
Found legacy serial port 0 for /pci@80000000/isa@C/serial@i2F8
port=2f8, taddr=ffffffff, irq=ffffffff, clk=1843200, speed=0
chrp type = 6
Pegasos l2cr : L2 cache was not active, activating
PCI bus 0 controlled by pci at 80000000
Badness in kref_get at /home/olaf/kernel/olh/ppc64/linux-2.6.16-rc1-olh/lib/kref.c:32
Call Trace:
[C0379D00] [C0007A20] show_stack+0x5c/0x184 (unreliable)
[C0379D30] [C000E150] program_check_exception+0x184/0x584
[C0379D90] [C000F6D8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at kref_get+0xc/0x24
LR = of_node_get+0x24/0x3c
[C0379E50] [C004FD20] __pte_alloc_kernel+0x64/0x80 (unreliable)
[C0379E70] [C000CB04] of_get_parent+0x34/0x58
[C0379E90] [C0009C04] of_get_address+0x24/0x174
[C0379ED0] [C000A1F4] of_address_to_resource+0x24/0x68
[C0379F00] [C038917C] chrp_find_bridges+0x114/0x470
[C0379F90] [C0388E38] chrp_setup_arch+0x1fc/0x32c
[C0379FB0] [C03829A0] setup_arch+0x144/0x188
[C0379FD0] [C037A45C] start_kernel+0x34/0x1a8
[C0379FF0] [000037A0] 0x37a0
Badness in kref_get at /home/olaf/kernel/olh/ppc64/linux-2.6.16-rc1-olh/lib/kref.c:32
Call Trace:
[C0379C90] [C0007A20] show_stack+0x5c/0x184 (unreliable)
[C0379CC0] [C000E150] program_check_exception+0x184/0x584
[C0379D20] [C000F6D8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at kref_get+0xc/0x24
LR = of_node_get+0x24/0x3c
[C0379DE0] [00002700] 0x2700 (unreliable)
[C0379E00] [C000CB04] of_get_parent+0x34/0x58
[C0379E20] [C0009DD4] of_translate_address+0x2c/0x2fc
[C0379EA0] [C000A0D4] __of_address_to_resource+0x30/0xc4
[C0379ED0] [C000A21C] of_address_to_resource+0x4c/0x68
[C0379F00] [C038917C] chrp_find_bridges+0x114/0x470
[C0379F90] [C0388E38] chrp_setup_arch+0x1fc/0x32c
[C0379FB0] [C03829A0] setup_arch+0x144/0x188
[C0379FD0] [C037A45C] start_kernel+0x34/0x1a8
[C0379FF0] [000037A0] 0x37a0
PCI bus 0 controlled by pci at c0000000
Top of RAM: 0x20000000, Total RAM: 0x20000000
Memory hole size: 0MB
On node 0 totalpages: 131072
DMA zone: 131072 pages, LIFO batch:31
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: debug sysrq=1 root=/dev/hda7
PID hash table entries: 4096 (order: 12, 65536 bytes)
time_init: decrementer frequency = 33.333333 MHz
time_init: processor frequency = 0.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 0k
Memory: 511232k/524288k available (3064k kernel code, 12564k reserved, 484k data, 457k bss, 144k init)
Calibrating delay loop... 66.56 BogoMIPS (lpj=133120)
Mount-cache hash table entries: 512
checking if image is initramfs... it is
Freeing initrd memory: 2225k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
PCI: Enabling device 0001:01:08.0 (0002 -> 0003)
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: No ATY,RefCLK property !
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=200.25 MHz
radeonfb: PLL min 20000 max 40000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
Console: switching to colour frame buffer device 80x25
radeonfb (0001:01:08.0): ATI Radeon Y`
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0c.1
VP_IDE: chipset revision 6
VP_IDE: VIA vt8231 (rev 10) IDE UDMA100 controller on pci0000:00:0c.1
VP_IDE: 100% native mode on irq 14
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: SAMSUNG SP0802N, ATA DISK drive
ide0 at 0x1000-0x1007,0x100e on irq 14
Probing IDE interface ide1...
hdc: TSSTcorpCD/DVDW TS-H552U, ATAPI CD/DVD-ROM drive
ide1 at 0x1010-0x1017,0x101e on irq 15
hda: max request size: 512KiB
hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: RDSK (512) hda1 (LNX^@)(res 2 spb 1) hda2 (SWP^@)(res 2 spb 1) hda3 (LNX^@)(res 2 spb 1) hda4 (LNX^@)(res 2 spb 1) hda5 (LNX^@)(res 2 spb 1) hda6 (LNX^@)(res 2 spb 1) hda7 (LNX^@)(res 2 spb 1)
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
PCI: Enabling device 0000:00:05.0 (0000 -> 0002)
ohci_hcd 0000:00:05.0: OHCI Host Controller
ohci_hcd 0000:00:05.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:05.0: irq 9, io mem 0x80000000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
PCI: Enabling device 0000:00:05.1 (0000 -> 0002)
ohci_hcd 0000:00:05.1: OHCI Host Controller
ohci_hcd 0000:00:05.1: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:05.1: irq 9, io mem 0x80001000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
/home/olaf/kernel/olh/ppc64/linux-2.6.16-rc1-olh/drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
atkbd.c: keyboard reset failed on isa0060/serio1
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
TCP westwood registered
TCP htcp registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 144k init
input: AT Translated Set 2 keyboard as /class/input/input0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 1044216k swap on /dev/hda2. Priority:-1 extents:1 across:1044216k
EXT3 FS on hda7, internal journal
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
PCI: Enabling device 0000:00:05.2 (0000 -> 0002)
ehci_hcd 0000:00:05.2: EHCI Host Controller
ehci_hcd 0000:00:05.2: new USB bus registered, assigned bus number 3
ehci_hcd 0000:00:05.2: irq 9, io mem 0x80002000
ehci_hcd 0000:00:05.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 5 ports detected
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
PCI: Enabling device 0000:00:0d.0 (0005 -> 0007)
eth0: VIA Rhine II at 0x80002100, 00:0b:2f:4b:f6:8f, IRQ 9.
eth0: MII PHY found at address 16, status 0x786d advertising 01e1 Link 45e1.
PCI: Enabling device 0000:00:0c.5 (0000 -> 0001)
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x3BC
parport0: PC-style at 0x3bc, irq 7 [PCSPP]
ieee1394: Initialized config rom entry `ip1394'
parport_pc: VIA parallel port: io=0x3BC, irq=7
PCI: Enabling device 0000:00:01.0 (0000 -> 0003)
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[80002800-80002fff] Max Packet=[2048] IR/IT contexts=[8/8]
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011060000004b2f]
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
--
short story of a lazy sysadmin:
alias appserv=wotan
^ 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