* unresolved symbol
From: zhonglei @ 2005-08-24 7:11 UTC (permalink / raw)
To: linuxppc-dev
hi
My mod has no error or warning during compiling.But when I "insmod hello.o" , it shows:
hello.o : unresolved symbol TaskStart
hello.o : unresolved symbol TasksLoadImage
hello.o : unresolved symbol TasksInitAPI
...
What's the problem?
BestRegards
zhonglei
^ permalink raw reply
* Re: An old problem ...about linux mount rootfs with nfs
From: Wolfgang Denk @ 2005-08-24 7:30 UTC (permalink / raw)
To: 徐小威的EMAIL; +Cc: linuxppc-embedded
In-Reply-To: <1124852294.11078.8.camel@banana>
In message <1124852294.11078.8.camel@banana> you wrote:
>
> I used u-boot-1.1.3 and 2.4.25 linux on my custom MPC852T board, I
> can't mount /opt/eldk/ppc_8xx as rootfs.
You pass incomplete config options to the kernel.
> Hit any key to stop autoboot: 0
> => setenv hostname banana
> => setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) ip=
> $(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off
> => printenv
> bootcmd=bootm 40040000 40100000
> bootdelay=3
> baudrate=115200
> loads_echo=1
> ethprime=SCC ETHERNET
> ipaddr=10.0.14.110
> serverip=10.0.14.26
> netmask=255.255.0.0
> preboot=echo;
> netdev=eth0
^^^^^^^^^^^^^
> nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)
> ramargs=setenv bootargs root=/dev/ram rw
> addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):
> $(netmask):$(hostname):$(netdev):off panic=1
^^^^^^^^^
Here you have all the necessary prparations.
> bootargs=root=/dev/nfs rw nfsroot=10.0.14.26:/opt/eldk/ppc_8xx
> ip=10.0.14.110:10.0.14.26::255.255.0.0:banana::off
^^
But here you are missing to pass the information which ethernet interface to use.
> Kernel command line: root=/dev/nfs rw
> nfsroot=10.0.14.26:/opt/eldk/ppc_8xx
> ip=10.0.14.110:10.0.14.26::255.255.0.0:banana::off
-----------------------------------------------^^^
No interface selected.
> eth0: CPM ENET Version 0.2 on SCC4, 00:01:02:b4:36:56
> eth1: FEC ENET Version 0.3, FEC irq 9, MII irq 12, addr
> 00:01:02:b4:36:57
But there are two intefaces. Which one should the kernel use?
Just fix your bootargs.
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
You humans have that emotional need to express gratitude. "You're
welcome," I believe, is the correct response.
-- Spock, "Bread and Circuses", stardate 4041.2
^ permalink raw reply
* Re: [gmail] unresolved symbol
From: Marc Leeman @ 2005-08-24 7:54 UTC (permalink / raw)
To: zhonglei; +Cc: linuxppc-dev
In-Reply-To: <200508241511.AA32243824@RCS-9000.COM>
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
> My mod has no error or warning during compiling.But when I "insmod hello.o" , it shows:
> hello.o : unresolved symbol TaskStart
> hello.o : unresolved symbol TasksLoadImage
> hello.o : unresolved symbol TasksInitAPI
> ...
> What's the problem?
You're trying to insert a module that depends on another
module/functionality in the kernel but which you did not insert or
compile in the kernel.
--
greetz, marc
We can stick our heads between our legs and kiss our asses goodbye. It's
a saying.
Crichton - I, E.T.
scorpius 2.6.12 #1 Thu Jun 23 21:32:03 CEST 2005 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux Kernel MTD question
From: Alex Zeffertt @ 2005-08-24 8:49 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050824050304.6508167F88@ozlabs.org>
Before doing a write to /dev/mtd1 try running
~# eraseall /dev/mtd1
(eraseall is from the mtd-utils package.)
Alex
On Wed, 24 Aug 2005 13:02:31 +0800
"JohnsonCheng" <johnsoncheng@qnap.com.tw> wrote:
> Dear Ricardo and Wolfgang,
>
> Very thanks for your kindly support.
> I am sorry I made a mistake.
> Before you mount /dev/mtdblock4, you have to use mke2fs to format it.
> Now I think my MTD function is almost ready, except write.
> When I run "dd if=/dev/mtd1 of=kernel.img", it's OK.
> But when I run "dd if=kernel.img of=/dev/mtd1", it's failed. No error
> message printed, and the process time is shortly, cause Bad CRC.
>
> Thanks,
> Johnson Cheng
>
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Ricardo Scop
> Sent: Wednesday, August 24, 2005 3:17 AM
> To: JohnsonCheng; 'Robert P. J. Day'
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux Kernel MTD question
>
> Hi Johnson,
>
> On Tuesday 23 August 2005 02:31, JohnsonCheng wrote:
> > It doesn't work, too.
> > Error message: Invalid argument.
> Well, do you have an mtdblock4 entry in /dev?
>
> Also, you should specify your filesystem type to mount, like in:
>
> mount -t jffs2 /dev/mtdblock4 /mnt
>
> BTW, -t jffs2 is just an example.
>
> HTH,
>
> -Scop.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: unresolved symbol
From: Alex Zeffertt @ 2005-08-24 8:59 UTC (permalink / raw)
To: zhonglei; +Cc: linuxppc-embedded
In-Reply-To: <200508241507.AA31981680@RCS-9000.COM>
At compile time the compiler assumed these symbols would be defined externally, either by the kernel
or by another module loaded prior to hello.o. The error message says that these symbols are not
exported by the kernel (or any currently loaded modules) prior to running "insmod hello.o".
Either:
1. You need to insmod another module first (or use "modprobe hello" which may do this automatically)
2. The module defining these symbols has not used the EXPORT_SYMBOL() macro to make them exported.
3. These symbols are not defined in either the kernel or any modules.
Alex
On Wed, 24 Aug 2005 15:07:58 +0800
"zhonglei" <zhonglei@RCS-9000.COM> wrote:
> hi
> My mod has no error or warning during compiling.But when I "insmod hello.o" , it shows:
> hello.o : unresolved symbol TaskStart
> hello.o : unresolved symbol TaskLoadImage
> hello.o : unresolved symbol TaskInitAPI
> ...
> What's the problem?
> BestRegards
> zhonglei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* AC Power handling broken for desktops
From: Olaf Hering @ 2005-08-24 11:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
My G4/450 runs without AC Power, according to /proc/pmu/info:
PMU driver version : 2
PMU firmware version : 0c
AC Power : 0
Battery count : 0
It should report 1. Where is the best place to get the
PMU_PWR_AC_PRESENT into ac_line_status?
^ permalink raw reply
* RPXClassic Help
From: Travis B. Sawyer @ 2005-08-24 12:12 UTC (permalink / raw)
To: linuxppc-embedded
Greetings:
I got my hands on a couple of RPXClassic (CLLF) boards gratis
and am planning on putting them to some use with my model
railroad (overkill, but its fun!).
I have them running Das U-Boot git as of ~ 16August2005.
I'm attempting to use a kernel.org 2.4.30 kernel. (With
i2c-2.9.0 patches)
After pushing the bd_t struct into rpxclassic.h, the board
boots linux well, mounts the nfs root properly, things are
good.
I would like to get a pcmcia flash disk working. It is id'ed
by Das U-Boot:
PCMCIA:SunDisk SDP 5/3 0.6
Fixed Disk Card
IDE interface
[silicon] [unique] [single] [sleep] [standby] [idle] [low power]
Bus 0: OK
Device 0: Model: SanDisk SDP3B-64 Firm: vdd 1.00 Ser#: g3vspq15924
Type: Removable Hard Disk
Capacity: 61.2 MB = 0.0 GB (125440 x 512)
After enabling pcmcia, 8xx pccard, ide, et al (and some debug printk's)
I get the following output from the kernel:
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
PCMCIA slot B: phys mem e0000000...e8010000 (size 08010000)
Card ID: SunDisk SDP 5/3 0.6
Fixed Disk Card
IDE interface
[silicon] [unique] [single] [sleep] [standby] [idle] [low power]
Probing IDE interface ide0...
probing for hda: present=0, media=32, probetype=ATA
do_probe 471
probing for hda: present=0, media=32, probetype=ATAPI
do_probe 471
probing for hdb: present=0, media=32, probetype=ATA
do_probe 471
probing for hdb: present=0, media=32, probetype=ATAPI
do_probe 471
Linux Kernel Card Services 3.1.22
options: none
m8xx_pcmcia: Version 0.05, 14-Apr-2002
m8xx_pcmcia: RPX CLASSIC or RPX LITE using SLOT_B with IRQ 13.
Nothing shows up in /proc/ide other than 'drivers'
bash-2.05b# cat drivers
ide-disk version 1.17
ide-default version 0.9.newide
I tried googling to no avail. Any ideas?
TIA,
Travis
^ permalink raw reply
* RE: RPXClassic Help
From: Steven Blakeslee @ 2005-08-24 12:49 UTC (permalink / raw)
To: tsawyer+linuxppc, linuxppc-embedded
>Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
>ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=3Dxx PCMCIA slot B: phys mem > >e0000000...e8010000 =
(size
08010000) Card ID: SunDisk SDP 5/3 0.6
> Fixed Disk Card
> IDE interface
> [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
Probing IDE interface ide0...
>probing for hda: present=3D0, media=3D32, probetype=3DATA do_probe 471
probing for hda: present=3D0, media=3D32, >probetype=3DATAPI =
do_probe
471 probing for hdb: present=3D0, media=3D32, probetype=3DATA do_probe =
471
probing for hdb: >present=3D0, media=3D32, probetype=3DATAPI do_probe =
471
Linux Kernel Card Services 3.1.22
> options: none
>m8xx_pcmcia: Version 0.05, 14-Apr-2002
>m8xx_pcmcia: RPX CLASSIC or RPX LITE using SLOT_B with IRQ 13.
I use the PCMCIA card services at sourceforge instead of the built in
support. They work very well including ATA/IDE.
^ permalink raw reply
* Re: Source of xparameter_ml300.h
From: Andrei Konovalov @ 2005-08-24 13:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20050823170300.GA910@siegfried.thelikelysolution.ca>
Grant Likely wrote:
> Does anyone know the origin of xparameter_ml300.h? The
> Xilinx EDK generates an xparameters.h file for each design, but the
> structure of the file changes between releases.
>
> I want to know if xparameters_ml300.h is the exact output produced by
> EDK or if stuff was changed before it was submitted to the mainline
> tree. (ie. all the stuff under the "linux redefines" comment block)
EDK can also generate the "Linux BSP".
In this case EDK uses the scripts from (depending on your setup)
/opt/xilinx/edk/7.1/sw/ThirdParty/bsp/linux_v2_00_b/data/
In particular, linux_v2_1_0.tcl adds those "linux redefines"
and renames xparameters.h to xparameters_ml300.h.
> Also, where can I get the bitstream/systemace file that matches
> xparameters_ml300.h?
The most reliable way is to generate both (bitstream and
xparameters_ml300.h) by yourself. :)
But if you are speaking about the xparameters_ml300.h in the community
trees (linuxppc-2.4 and the 2.6 one from kernel.org), this file
is for the reference design by Xilinx:
http://www.xilinx.com/ise/embedded/edk6_2docs/ml300_edk3.zip
> I've got a custom ml300 image that I'm regression
> testing against, but I'd like to also test against some form of 'stock'
> image. :)
>
> Thanks,
> g.
Thanks,
Andrei
^ permalink raw reply
* Re: GDB backtrace and signal trampolines
From: Hollis Blanchard @ 2005-08-24 13:52 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: PPC64-dev List, Linux PPC Dev
In-Reply-To: <a22149f6d9cc6f65ae2f8f339d982dd2@us.ibm.com>
On Aug 11, 2005, at 10:54 AM, Hollis Blanchard wrote:
> GDB 6.3 contains this code in ppc-linux-tdep.c:
>
> static const struct frame_unwind *
> ppc_linux_sigtramp_sniffer (struct frame_info *next_frame)
> {
> struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch
> (next_frame));
>
> if (frame_pc_unwind (next_frame)
> > frame_unwind_register_unsigned (next_frame, SP_REGNUM))
> /* Assume anything that is vaguely on the stack is a signal
> trampoline. */
> return &ppc_linux_sigtramp_unwind;
> else
> return NULL;
> }
>
> Essentially it says that any time the program counter is above the
> stack pointer, we must be in a signal trampoline, and so GDB proceeds
> to grope about for a struct rt_sigframe on the stack.
>
> This is not a good assumption. I'm using a GDB stub to debug Xen, and
> as it so happens, the Xen stack is below the Xen text. That means that
> the above test always triggers, but of course there is no rt_sigframe
> on the stack, and my backtrace runs away.
FYI: I looked at a GDB snapshot (gdb-6.3.50.20050818) and the problem
had been resolved.
-Hollis
^ permalink raw reply
* [PATCH] ppc32: ppc_sys system on chip identification additions
From: Kumar Gala @ 2005-08-24 15:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Add the ability to identify an SOC by a name and id. There are cases in
which the integer identifier is not sufficient to specify a specific SOC.
In these cases we can use a string to further qualify the match.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 58d478e75ac5d6cb3a1f738a22555c3841445264
tree 999d1722d74eb8dc76f40c8f4c52966cea681cb4
parent eb5d5922d749a74f58416ca1a852651e7323449b
author Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005 10:14:42 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005 10:14:42 -0500
arch/ppc/syslib/ppc_sys.c | 51 ++++++++++++++++++++++++++++++++++++++++++++-
include/asm-ppc/ppc_sys.h | 1 +
2 files changed, 51 insertions(+), 1 deletions(-)
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,8 +36,56 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
- /* TODO */
+ unsigned int i = 0;
+ while (ppc_sys_specs[i].ppc_sys_name[0])
+ 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 (ppc_sys_specs[i].ppc_sys_name[0])
+ 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 (ppc_sys_specs[i].ppc_sys_name[0]) {
+ 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 */
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
@@ -50,6 +50,7 @@ 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_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: Source of xparameter_ml300.h
From: Grant Likely @ 2005-08-24 15:12 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <430C7C3A.4000601@ru.mvista.com>
On Wed, Aug 24, 2005 at 05:55:06PM +0400, Andrei Konovalov wrote:
> Grant Likely wrote:
> >I want to know if xparameters_ml300.h is the exact output produced by
> >EDK or if stuff was changed before it was submitted to the mainline
> >tree. (ie. all the stuff under the "linux redefines" comment block)
>
> EDK can also generate the "Linux BSP".
> In this case EDK uses the scripts from (depending on your setup)
> /opt/xilinx/edk/7.1/sw/ThirdParty/bsp/linux_v2_00_b/data/
> In particular, linux_v2_1_0.tcl adds those "linux redefines"
> and renames xparameters.h to xparameters_ml300.h.
Ahh; I've been using the standalone option. I didn't know about the tcl
script.
>
> >Also, where can I get the bitstream/systemace file that matches
> >xparameters_ml300.h?
>
> The most reliable way is to generate both (bitstream and
> xparameters_ml300.h) by yourself. :)
That's how I've gotten as far as I have :)
>
> But if you are speaking about the xparameters_ml300.h in the community
> trees (linuxppc-2.4 and the 2.6 one from kernel.org), this file
> is for the reference design by Xilinx:
>
> http://www.xilinx.com/ise/embedded/edk6_2docs/ml300_edk3.zip
Thanks!
g.
^ permalink raw reply
* Re: [PATCH] ppc32: make perfmon.o CONFIG_E500 specific
From: Marcelo Tosatti @ 2005-08-23 23:33 UTC (permalink / raw)
To: Andy Fleming; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <29D5FC3D-C2AD-440E-B929-9AA29F7300CF@freescale.com>
On Tue, Aug 23, 2005 at 05:50:15PM -0500, Andy Fleming wrote:
> I've got some untested code for 74xx (probably only 7450 for now),
> but it's several rungs down my priority list right now. :
> ( Hopefully I will have time for it soon...
OK - you can then add the proper change for inclusion inside
the #ifdef ?
Please apply the patch (or some variant of it).
^ permalink raw reply
* [PATCH 08/15] ppc32: remove use of asm/segment.h
From: Kumar Gala @ 2005-08-24 16:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0508241139100.23956@nylon.am.freescale.net>
Removed ppc32 architecture specific users of asm/segment.h and
asm-ppc/segment.h itself
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 503a812c1f9cef08e6f96b2b2cf1f32bbfef2bc6
tree b61a93eb582e90fafda6ff9d064b2ab25e7d3ede
parent 21a31cb366a764793dc532b525b95bfc3e1723a2
author Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005 10:58:02 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005 10:58:02 -0500
arch/ppc/kernel/temp.c | 1 -
arch/ppc/kernel/time.c | 1 -
arch/ppc/platforms/chrp_time.c | 1 -
arch/ppc/syslib/prep_nvram.c | 1 -
include/asm-ppc/segment.h | 1 -
5 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/ppc/kernel/temp.c b/arch/ppc/kernel/temp.c
--- a/arch/ppc/kernel/temp.c
+++ b/arch/ppc/kernel/temp.c
@@ -21,7 +21,6 @@
#include <linux/interrupt.h>
#include <linux/init.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/reg.h>
#include <asm/nvram.h>
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -58,7 +58,6 @@
#include <linux/init.h>
#include <linux/profile.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/cache.h>
diff --git a/arch/ppc/platforms/chrp_time.c b/arch/ppc/platforms/chrp_time.c
--- a/arch/ppc/platforms/chrp_time.c
+++ b/arch/ppc/platforms/chrp_time.c
@@ -22,7 +22,6 @@
#include <linux/init.h>
#include <linux/bcd.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/prom.h>
diff --git a/arch/ppc/syslib/prep_nvram.c b/arch/ppc/syslib/prep_nvram.c
--- a/arch/ppc/syslib/prep_nvram.c
+++ b/arch/ppc/syslib/prep_nvram.c
@@ -15,7 +15,6 @@
#include <linux/ioport.h>
#include <asm/sections.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/prep_nvram.h>
diff --git a/include/asm-ppc/segment.h b/include/asm-ppc/segment.h
deleted file mode 100644
--- a/include/asm-ppc/segment.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm/uaccess.h>
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Tom Rini @ 2005-08-24 18:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: olof, Stephen Rothwell, linuxppc-dev, linuxppc64-dev
In-Reply-To: <E470B224-F0FB-48D7-9A04-E42247B11554@freescale.com>
On Tue, Aug 23, 2005 at 12:05:36PM -0500, Kumar Gala wrote:
>
> On Aug 23, 2005, at 2:31 AM, Stephen Rothwell wrote:
>
> >On Tue, 23 Aug 2005 15:41:47 +1000 Benjamin Herrenschmidt
> ><benh@kernel.crashing.org> wrote:
> >
> >>
> >>Most of the ones that are in include/asm* are there because drivers
> >>outside of arch/* use them.
> >>
> >
> >Indeed. Here is the result of grepping for all of the .h files in
> >patch 3 (minus the
> >obvious noncontentious ones like errno.h ...):
>
> This seems reasonable then to have them in include/asm-powerpc. I
No it doesn't. You can easily make the drivers get the includes from
<platforms/pmac/foo.h>, arch/$(ARCH) is already always in the search
path, I believe (if not, it's easy to add Makefile things to get it).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
From: Tom Rini @ 2005-08-24 18:35 UTC (permalink / raw)
To: linux-ppc-embedded
In-Reply-To: <20050823224702.GA3864@siegfried.thelikelysolution.ca>
On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:
> [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
>
> REPOST: fixed formating problems in original patch
>
> Modifies serial_init to get base baud rate from the rs_table entry instead
> of BAUD_BASE. Will default back to BAUD_BASE if base_baud is not set.
>
> This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
> BAUD_BASE. Without the patch, if a port set the baud rate in
> SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
> would still be used.
>
> Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
> BASE_BAUD as a backup.
>
> Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
With everything in-tree, this is fine as baud_base is always set to
BASE_BAUD, but I'm wondering why this was done. Did you do a port and
not follow on this? It looks like today you could get away without
defining BASE_BAUD correctly (8250_early uses and needs this to be
correct, but I don't think this is frequently used, yet). But I'm not
sure what we gain here. Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* I2C for the 8270
From: Keith Henrickson @ 2005-08-24 18:45 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to get the 85xx driver in Linux 2.6.11 to work on the 8270,
which also has a CPM2.
I'm not sure if the driver itself works, as I cannot even get it to
fully load.
I have enabled the 'MPC (8xx and 8xxx) CPM I2C Interface' I2C Algorithm,
and the 'Motorola MPC8xx and MPC85xx CPM I2C' Hardware Bus.
So far, I have gotten it to create '/sys/bus/platform/drivers/fsl-i2c',
although there is nothing in this directory. I get this to happen by
bypassing the device_register() call and just forcing the device to
i2c_cpm_add_bus().
What I do NOT get are the devices in /dev, or any evidence in /sys that
there is a device that SHOULD go in /dev. Any ideas what I am missing?
The kernel messages that come out are as follows.
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
i2c-core: driver dev_driver registered.
fsl-cpm-i2c: CPM2 i2c driver
bus platform: add driver fsl-i2c
bus i2c: add driver eeprom
i2c-core: driver eeprom registered.
i2c-algo-cpm: CPM2 I2C algorithm module version 0.1 (Mar 22, 2005)
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Tom Rini @ 2005-08-24 20:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linuxppc64-dev, Stephen Rothwell
In-Reply-To: <200508242203.27210.arnd@arndb.de>
On Wed, Aug 24, 2005 at 10:03:26PM +0200, Arnd Bergmann wrote:
> On Middeweken 24 August 2005 20:20, Tom Rini wrote:
> > On Tue, Aug 23, 2005 at 12:05:36PM -0500, Kumar Gala wrote:
> > >
> > > This seems reasonable then to have them in include/asm-powerpc. I
> >
> > No it doesn't. You can easily make the drivers get the includes from
> > <platforms/pmac/foo.h>, arch/$(ARCH) is already always in the search
> > path, I believe (if not, it's easy to add Makefile things to get it).
>
> I don't think any architecture except ppc32 has traditionally had
> arch/$ARCH in its include path, and it would probably come as a surprise
> to many kernel developers if this were used more.
True, but it's possible that the pmac drivers could also be converted to
use something else to pass around infos, register IO and such so the
headers can still live in arch/powerpc/platforms/pmac/
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Arnd Bergmann @ 2005-08-24 20:03 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev, Tom Rini, Stephen Rothwell
In-Reply-To: <20050824182020.GB15735@smtp.west.cox.net>
On Middeweken 24 August 2005 20:20, Tom Rini wrote:
> On Tue, Aug 23, 2005 at 12:05:36PM -0500, Kumar Gala wrote:
> >
> > This seems reasonable then to have them in include/asm-powerpc. I
>
> No it doesn't. You can easily make the drivers get the includes from
> <platforms/pmac/foo.h>, arch/$(ARCH) is already always in the search
> path, I believe (if not, it's easy to add Makefile things to get it).
I don't think any architecture except ppc32 has traditionally had
arch/$ARCH in its include path, and it would probably come as a surprise
to many kernel developers if this were used more.
Currently, there seem to be hardly any users of this "feature" in ppc32
that can't be trivially converted to including local files, so I'd
rather not see this moved over to arch/powerpc.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Brad Boyer @ 2005-08-24 20:44 UTC (permalink / raw)
To: Tom Rini
Cc: Linux/m68k on Mac, linuxppc-dev, Stephen Rothwell, Arnd Bergmann,
linuxppc64-dev
In-Reply-To: <20050824201332.GD15735@smtp.west.cox.net>
On Wed, Aug 24, 2005 at 01:13:32PM -0700, Tom Rini wrote:
> On Wed, Aug 24, 2005 at 10:03:26PM +0200, Arnd Bergmann wrote:
> > On Middeweken 24 August 2005 20:20, Tom Rini wrote:
> > > No it doesn't. You can easily make the drivers get the includes from
> > > <platforms/pmac/foo.h>, arch/$(ARCH) is already always in the search
> > > path, I believe (if not, it's easy to add Makefile things to get it).
> >
> > I don't think any architecture except ppc32 has traditionally had
> > arch/$ARCH in its include path, and it would probably come as a surprise
> > to many kernel developers if this were used more.
>
> True, but it's possible that the pmac drivers could also be converted to
> use something else to pass around infos, register IO and such so the
> headers can still live in arch/powerpc/platforms/pmac/
These days, the macio bus is a real device-model bus. The code still
lives in drivers/macintosh, but it will be used by more than just
pmac machines whenever I get the 68k mac support finished. It seems
like we really should have an include/linux/macio.h, and make the
whole thing act more like a normal bus. I would like to abstract out
more of it anyway, particularly the DMA support. That way we wouldn't
have several different drivers for the same chip due to bus interface
differences (see mace.c and macmace.c for an example of current practice).
This would eliminate at least macio.h and dbdma.h. Hopefully it would
get most of the mac specific code organized in a more logical fashion.
Any comments/requirements/suggestions?
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
From: Grant Likely @ 2005-08-24 21:35 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050824183520.GC15735@smtp.west.cox.net>
On Wed, Aug 24, 2005 at 11:35:20AM -0700, Tom Rini wrote:
> On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:
>
> > [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
> >
> > REPOST: fixed formating problems in original patch
> >
> > Modifies serial_init to get base baud rate from the rs_table entry instead
> > of BAUD_BASE. Will default back to BAUD_BASE if base_baud is not set.
> >
> > This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
> > BAUD_BASE. Without the patch, if a port set the baud rate in
> > SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
> > would still be used.
> >
> > Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
> > BASE_BAUD as a backup.
> >
> > Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
>
> With everything in-tree, this is fine as baud_base is always set to
> BASE_BAUD, but I'm wondering why this was done. Did you do a port and
> not follow on this? It looks like today you could get away without
> defining BASE_BAUD correctly (8250_early uses and needs this to be
> correct, but I don't think this is frequently used, yet). But I'm not
> sure what we gain here. Thanks.
I stumbled across this while working on moving v2pro to the platform
bus. (I'm also trying to isolate xparameter.h as much as possible to
avoid recompiling the world everytime I get a new bitstream). I've got
the base baud for each port in the rs_table.
IMHO it doesn't seem right to have part of the serial parameters pulled
from rs_table and the base baud pulled from elseware. ie. it looked
like a latent bug to me, so I wrote the patch. I've also got the
impression that the serial subsystem is trying to move away from
depending on BASE_BAUD
Cheers,
g.
^ permalink raw reply
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
From: Tom Rini @ 2005-08-24 21:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050824213521.GA5397@siegfried.thelikelysolution.ca>
On Wed, Aug 24, 2005 at 03:35:21PM -0600, Grant Likely wrote:
> On Wed, Aug 24, 2005 at 11:35:20AM -0700, Tom Rini wrote:
> > On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:
> >
> > > [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
> > >
> > > REPOST: fixed formating problems in original patch
> > >
> > > Modifies serial_init to get base baud rate from the rs_table entry instead
> > > of BAUD_BASE. Will default back to BAUD_BASE if base_baud is not set.
> > >
> > > This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
> > > BAUD_BASE. Without the patch, if a port set the baud rate in
> > > SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
> > > would still be used.
> > >
> > > Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
> > > BASE_BAUD as a backup.
> > >
> > > Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
> >
> > With everything in-tree, this is fine as baud_base is always set to
> > BASE_BAUD, but I'm wondering why this was done. Did you do a port and
> > not follow on this? It looks like today you could get away without
> > defining BASE_BAUD correctly (8250_early uses and needs this to be
> > correct, but I don't think this is frequently used, yet). But I'm not
> > sure what we gain here. Thanks.
> I stumbled across this while working on moving v2pro to the platform
> bus. (I'm also trying to isolate xparameter.h as much as possible to
> avoid recompiling the world everytime I get a new bitstream). I've got
> the base baud for each port in the rs_table.
I'll buy that, and slightly modify this for 2.6.14, thanks.
> IMHO it doesn't seem right to have part of the serial parameters pulled
> from rs_table and the base baud pulled from elseware. ie. it looked
> like a latent bug to me, so I wrote the patch. I've also got the
> impression that the serial subsystem is trying to move away from
> depending on BASE_BAUD
The general problem here (Holy crap! arch/ppc/boot/common/ns16550.c uses
everything we'd like to kill from <asm*/serial.h>) is come up before,
and is being slowly fixed.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
From: Grant Likely @ 2005-08-24 22:17 UTC (permalink / raw)
To: Tom Rini, linuxppc-embedded
In-Reply-To: <20050824214734.GE15735@smtp.west.cox.net>
On Wed, Aug 24, 2005 at 02:47:34PM -0700, Tom Rini wrote:
> I'll buy that, and slightly modify this for 2.6.14, thanks.
Cool, thanks.
> The general problem here (Holy crap! arch/ppc/boot/common/ns16550.c uses
> everything we'd like to kill from <asm*/serial.h>) is come up before,
> and is being slowly fixed.
:)
Now how do I get ns16550 to use a flattened device tree in a clean way?
:P
g.
^ permalink raw reply
* Re: AC Power handling broken for desktops
From: Benjamin Herrenschmidt @ 2005-08-24 22:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050824115452.GA29148@suse.de>
On Wed, 2005-08-24 at 13:54 +0200, Olaf Hering wrote:
> My G4/450 runs without AC Power, according to /proc/pmu/info:
>
> PMU driver version : 2
> PMU firmware version : 0c
> AC Power : 0
> Battery count : 0
>
> It should report 1. Where is the best place to get the
> PMU_PWR_AC_PRESENT into ac_line_status?
Do we get the bit set from the PMU ? If not, maybe we should hard code
that value on non-laptops
Ben.
^ permalink raw reply
* SPI support for MPC85xx.
From: jbi130 @ 2005-08-24 22:37 UTC (permalink / raw)
To: linuxppc-embedded
Is there existing SPI support for MPC85xx based boards (8555E in my
case). I've checked the archives and there appear to be a few
implementations, but none of them for the 85xx.
Any pointers appreciated.
Thanks.
^ 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