* Re: [JOB] Senior Embedded Linux Video Engineer
From: David H. Lynch Jr. @ 2006-07-15 3:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44B7ECD7.3080807@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
Tim Bird wrote:
> Olof Johansson wrote:
>
>> Ick. Why not just create a linuxppc-jobs@ozlabs org instead of hiding it
>> somewhere in the CELF organization...?
>>
>
> Well, it would be either a public list or on CELF's public wiki.
> I'm not sure how this would be "hiding it".
> -- Tim
>
Aparently there are people that do not want job related postings of
any kind on this list.
I can respect that. To the same extent there are those of us who are
looking for work and appreciate means to get the work we love instead of
having to take the work we can get.
I have my own personal worries about even a job list. There are a
plethora of jobsites. And I can trivially do a search for Embedded Linux
and get a plethora of job oportunities.
But they are all employment - primarily contract employment. There
seem to be no resources available for those of us looking for actual
consulting work.
I mean you would think this would be the ultimate consulting task -
give me a board and a few weeks without sleep and I will bring forth
Linux for you.
Anyway, we all have our preferences. I would love to see an embedded
Linux Consultants list that was chock full of consulting oportunities.
I would bring it up myself - but my ISP basically sucks, and I can
not even host a decent web site for my own consulting business.
I would even be willing to risk its being overrun with employment,
and contract for hire, and contract employment gigs that have zero
appeal to me - but may be of
interest to others here.
I would NOT restrict it to PPC's. I come to linuxppc-embedded to
look for ppc information. But I will do embedded linux work of any kind
that will pay the mortgage - heck, I would do web programming rather
than rejoin the rat race.
Unfortunately the rats are looming.
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Electronics
> =============================
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 3750 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Mike Kravetz @ 2006-07-15 0:41 UTC (permalink / raw)
To: Nathan Lynch
Cc: Bryan Rosenburg, linuxppc-dev, Paul Mackerras, Arnd Bergmann,
Christopher Yeoh
In-Reply-To: <20060715001545.GK19076@localdomain>
On Fri, Jul 14, 2006 at 07:15:45PM -0500, Nathan Lynch wrote:
> Hmm, isn't it possible that the stats could be corrupted if we process
> an interrupt/softirq which does an hcall while the stats are being
> updated? Maybe it's not a show-stopper, but it seems to me that
> accuracy could suffer under some workloads.
Yes, they can become inaccurate. Is this what you mean by 'corrupted' or
you thinking of something worse?
There is going to be a trade off between accuracy and the overhead of the
data gathering. What really needs to happen is some good benchmarking to
measure the costs of different approaches. I'm pretty sure I can get
someone to provide such data.
In this patch, I have minimized the overhead in data collection at the
cost of accuracy.
--
Mike
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Nathan Lynch @ 2006-07-15 0:15 UTC (permalink / raw)
To: Mike Kravetz
Cc: Bryan Rosenburg, linuxppc-dev, Paul Mackerras, Arnd Bergmann,
Christopher Yeoh
In-Reply-To: <20060714234034.GC11487@monkey.ibm.com>
Mike Kravetz wrote:
> +static inline void update_stats(unsigned long opcode, unsigned long t_before)
> +{
> + unsigned long op_index = opcode >> 2;
> + struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
> +
> + hs->total_time += (mftb() - t_before);
> + hs->num_calls++;
> +}
> +
> +/*
> + * plpar_hcall wrapper
> + */
> +long plpar_hcall(unsigned long opcode,
> + unsigned long arg1,
> + unsigned long arg2,
> + unsigned long arg3,
> + unsigned long arg4,
> + unsigned long *out1,
> + unsigned long *out2,
> + unsigned long *out3)
> +{
> + long rc;
> + unsigned long t_before;
> +
> + t_before = mftb();
> + rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
> +
> + update_stats(opcode, t_before);
> + return rc;
> +}
Hmm, isn't it possible that the stats could be corrupted if we process
an interrupt/softirq which does an hcall while the stats are being
updated? Maybe it's not a show-stopper, but it seems to me that
accuracy could suffer under some workloads.
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-15 0:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bryan Rosenburg, linuxppc-dev, Nathan Lynch, Paul Mackerras,
Christopher Yeoh
In-Reply-To: <200607150200.03494.arnd@arndb.de>
On Sat, Jul 15, 2006 at 02:00:02AM +0200, Arnd Bergmann wrote:
> What happened to the question whether to use PURR values for also measuring
> cycles spent executing the hcall as opposed to cycles that passed before
> the hcall returns. Did that turn out not giving extra information after all
> or was there a different reason to drop that idea?
Oops, forgot that as an additional issue/question. In this patch, I went
back to mftb() as 'wall time' made more sense for the group wanting this
functionality. It is easy to switch, or collect both (I think). Since I
started with mftb went to PURR and then back to mftb, it certainly does
look like an agument to try and collect both. :)
--
Mike
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Arnd Bergmann @ 2006-07-15 0:00 UTC (permalink / raw)
To: linuxppc-dev
Cc: Bryan Rosenburg, Nathan Lynch, Paul Mackerras, Christopher Yeoh
In-Reply-To: <20060714233739.GA11487@monkey.ibm.com>
On Saturday 15 July 2006 01:37, Mike Kravetz wrote:
> In addition, there has been some discussion of these patches on IRC.
> Some remaining issues/questions are:
> - Exactly how much overhead does the statistic gathering introduce?
> - What would be the cost of disabling preemption for more accurate statistics?
> - What would be the cost of disabling interrupts for more accurate statistics?
> - Should we extend this statistic gathering to RTAS calls?
What happened to the question whether to use PURR values for also measuring
cycles spent executing the hcall as opposed to cycles that passed before
the hcall returns. Did that turn out not giving extra information after all
or was there a different reason to drop that idea?
Arnd <><
^ permalink raw reply
* [PATCH 3/3] powerpc: Instrument Hypervisor Calls: add debugfs files
From: Mike Kravetz @ 2006-07-14 23:41 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, Bryan Rosenburg, linuxppc-dev, Nathan Lynch,
Christopher Yeoh
In-Reply-To: <20060714233739.GA11487@monkey.ibm.com>
Make statistics available via files in debugfs.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-14 23:32:01.000000000 +0000
+++ linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-14 23:32:54.000000000 +0000
@@ -205,3 +205,94 @@ long plpar_hcall_9arg_9ret(unsigned long
update_stats(opcode, t_before);
return rc;
}
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < MAX_HCALL_OPCODES)
+ return (void *)(unsigned long)(*pos + 1);
+
+ return NULL;
+}
+
+static void *hc_next(struct seq_file *m, void *p, loff_t * pos)
+{
+ ++*pos;
+
+ return hc_start(m, pos);
+}
+
+static void hc_stop(struct seq_file *m, void *p)
+{
+}
+
+static int hc_show(struct seq_file *m, void *p)
+{
+ unsigned long h_num = (unsigned long)p;
+ struct hcall_stats *hs = (struct hcall_stats *)m->private;
+
+ if (hs[h_num].num_calls)
+ seq_printf(m, "%lu %lu %lu\n", h_num<<2, hs[h_num].num_calls,
+ hs[h_num].total_time);
+
+ return 0;
+}
+
+static struct seq_operations hcall_inst_seq_ops = {
+ .start = hc_start,
+ .next = hc_next,
+ .stop = hc_stop,
+ .show = hc_show
+};
+
+static int hcall_inst_seq_open(struct inode *inode, struct file *file)
+{
+ int rc;
+ struct seq_file *seq;
+
+ rc = seq_open(file, &hcall_inst_seq_ops);
+ seq = file->private_data;
+ seq->private = file->f_dentry->d_inode->u.generic_ip;
+
+ return rc;
+}
+
+static struct file_operations hcall_inst_seq_fops = {
+ .open = hcall_inst_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+#define HCALL_ROOT_DIR "hcall_inst"
+#define CPU_NAME_BUF_SIZE 32
+
+static int __init hcall_inst_init(void)
+{
+ struct dentry *hcall_root;
+ struct dentry *hcall_file;
+ char cpu_name_buf[CPU_NAME_BUF_SIZE];
+ int cpu;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return 0;
+
+ hcall_root = debugfs_create_dir(HCALL_ROOT_DIR, NULL);
+ if (!hcall_root)
+ return -ENOMEM;
+
+ for_each_cpu(cpu) {
+ snprintf(cpu_name_buf, CPU_NAME_BUF_SIZE, "cpu%d", cpu);
+ hcall_file = debugfs_create_file(cpu_name_buf, S_IRUGO,
+ hcall_root,
+ per_cpu(hcall_stats, cpu),
+ &hcall_inst_seq_fops);
+ if (!hcall_file)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+__initcall(hcall_inst_init);
^ permalink raw reply
* [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Mike Kravetz @ 2006-07-14 23:40 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, Bryan Rosenburg, linuxppc-dev, Nathan Lynch,
Christopher Yeoh
In-Reply-To: <20060714233739.GA11487@monkey.ibm.com>
Add wrappers which perform the actual hypervisor call instrumentation.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17.4/arch/powerpc/Kconfig.debug linux-2.6.17.4.work/arch/powerpc/Kconfig.debug
--- linux-2.6.17.4/arch/powerpc/Kconfig.debug 2006-07-06 20:02:28.000000000 +0000
+++ linux-2.6.17.4.work/arch/powerpc/Kconfig.debug 2006-07-14 23:28:20.000000000 +0000
@@ -18,6 +18,19 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES && DEBUG_FS
+ help
+ Adds code to keep track of the number of hypervisor calls made and
+ the amount of time spent in hypervisor calls. A directory named
+ hcall_inst is added at the root of the debugfs filesystem. Within
+ the hcall_inst directory are files that contain CPU specific call
+ statistics.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr linux-2.6.17.4/arch/powerpc/platforms/pseries/Makefile linux-2.6.17.4.work/arch/powerpc/platforms/pseries/Makefile
--- linux-2.6.17.4/arch/powerpc/platforms/pseries/Makefile 2006-07-06 20:02:28.000000000 +0000
+++ linux-2.6.17.4.work/arch/powerpc/platforms/pseries/Makefile 2006-07-14 23:28:20.000000000 +0000
@@ -9,3 +9,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall.S 2006-07-06 20:02:28.000000000 +0000
+++ linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall.S 2006-07-14 23:28:20.000000000 +0000
@@ -11,7 +11,35 @@
#include <asm/hvcall.h>
#include <asm/processor.h>
#include <asm/ppc_asm.h>
-
+
+/*
+ * If hcall statistics are desired, all routines are wrapped with code
+ * that does the statistic gathering.
+ */
+#ifndef CONFIG_HCALL_STATS
+#define PLPAR_HCALL plpar_hcall
+#define PLPAR_HCALL_NORETS plpar_hcall_norets
+#define PLPAR_HCALL_8ARG_2RET plpar_hcall_8arg_2ret
+#define PLPAR_HCALL_4OUT plpar_hcall_4out
+#define PLPAR_HCALL_7ARG_7RET plpar_hcall_7arg_7ret
+#define PLPAR_HCALL_9ARG_9RET plpar_hcall_9arg_9ret
+#else
+#define PLPAR_HCALL plpar_hcall_base
+#define PLPAR_HCALL_NORETS plpar_hcall_norets_base
+#define PLPAR_HCALL_8ARG_2RET plpar_hcall_8arg_2ret_base
+#define PLPAR_HCALL_4OUT plpar_hcall_4out_base
+#define PLPAR_HCALL_7ARG_7RET plpar_hcall_7arg_7ret_base
+#define PLPAR_HCALL_9ARG_9RET plpar_hcall_9arg_9ret_base
+
+/*
+ * A special 'indirect' call to a C based wrapper if statistics are desired.
+ * See plpar_hcall_norets_C function header for more details.
+ */
+_GLOBAL(plpar_hcall_norets)
+ b plpar_hcall_norets_C
+
+#endif
+
#define STK_PARM(i) (48 + ((i)-3)*8)
.text
@@ -25,7 +53,7 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
-_GLOBAL(plpar_hcall)
+_GLOBAL(PLPAR_HCALL)
HMT_MEDIUM
mfcr r0
@@ -52,7 +80,7 @@ _GLOBAL(plpar_hcall)
/* Simple interface with no output values (other than status) */
-_GLOBAL(plpar_hcall_norets)
+_GLOBAL(PLPAR_HCALL_NORETS)
HMT_MEDIUM
mfcr r0
@@ -76,7 +104,7 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
-_GLOBAL(plpar_hcall_8arg_2ret)
+_GLOBAL(PLPAR_HCALL_8ARG_2RET)
HMT_MEDIUM
mfcr r0
@@ -102,7 +130,7 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
-_GLOBAL(plpar_hcall_4out)
+_GLOBAL(PLPAR_HCALL_4OUT)
HMT_MEDIUM
mfcr r0
@@ -144,7 +172,7 @@ _GLOBAL(plpar_hcall_4out)
unsigned long *out6, 102(R1)
unsigned long *out7); 100(R1)
*/
-_GLOBAL(plpar_hcall_7arg_7ret)
+_GLOBAL(PLPAR_HCALL_7ARG_7RET)
HMT_MEDIUM
mfcr r0
@@ -193,7 +221,7 @@ _GLOBAL(plpar_hcall_7arg_7ret)
unsigned long *out8, 94(R1)
unsigned long *out9, 92(R1)
*/
-_GLOBAL(plpar_hcall_9arg_9ret)
+_GLOBAL(PLPAR_HCALL_9ARG_9RET)
HMT_MEDIUM
mfcr r0
diff -Naupr linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17.4/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.17.4.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-14 23:28:44.000000000 +0000
@@ -0,0 +1,207 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * 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 Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/cpumask.h>
+#include <asm/hvcall.h>
+#include <asm/firmware.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Common update of the per-CPU/per-hcall statistics
+ */
+static inline void update_stats(unsigned long opcode, unsigned long t_before)
+{
+ unsigned long op_index = opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ hs->total_time += (mftb() - t_before);
+ hs->num_calls++;
+}
+
+/*
+ * plpar_hcall wrapper
+ */
+long plpar_hcall(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+/*
+ * A C based wrapper for plpar_hcall_norets
+ * The wrapper for plpar_hcall_norets is a special case because the function
+ * takes a variable number of arguments. It is almost impossible to write a
+ * wrapper for a function that takes a variable number of arguments in C.
+ * Therefore, there is an assembly routine in hvCall.S that simply branches
+ * to this C wrapper. This 'indirection' takes care of the variable arguments
+ * issue. This C wrapper has a fixed maximum number of arguments.
+ */
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_norets_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+/*
+ * plpar_hcall_8arg_2ret wrapper
+ */
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_8arg_2ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, out1);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+/*
+ * plpar_hcall_4out wrapper
+ */
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_4out_base(opcode, arg1, arg2, arg3, arg4, out1,
+ out2, out3, out4);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+/*
+ * plpar_hcall_7arg_7ret wrapper
+ */
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_7arg_7ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, out1, out2, out3, out4,
+ out5, out6, out7);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+/*
+ * plpar_hcall_9arg_9ret wrapper
+ */
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9)
+{
+ long rc;
+ unsigned long t_before;
+
+ t_before = mftb();
+ rc = plpar_hcall_9arg_9ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9, out1, out2,
+ out3, out4, out5, out6, out7, out8,
+ out9);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
diff -Naupr linux-2.6.17.4/include/asm-powerpc/hvcall.h linux-2.6.17.4.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17.4/include/asm-powerpc/hvcall.h 2006-07-14 23:27:52.000000000 +0000
+++ linux-2.6.17.4.work/include/asm-powerpc/hvcall.h 2006-07-14 23:28:20.000000000 +0000
@@ -292,6 +292,86 @@ long plpar_hcall_9arg_9ret(unsigned long
unsigned long *out8,
unsigned long *out9);
+
+/* For hcall instrumentation. One structure per-hcall, per-CPU */
+struct hcall_stats {
+ unsigned long num_calls; /* number of calls (on this CPU) */
+ unsigned long total_time; /* total cputime (PURR) of calls. */
+};
+
+/* If Hypervisor call instrumentation is enabled, the assembly routine
+ * names are changed from 'plpar_hcall*' to 'plpar_hcall*_base' and
+ * 'plpar_hcall*' routines become instrumented wrappers. The following
+ * are declarations for the renamed 'plpar_hcall*_base' routines.
+ */
+long plpar_hcall_base (unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall_norets_base(unsigned long opcode, ...);
+
+long plpar_hcall_8arg_2ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_4out_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_7arg_7ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_9arg_9ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Mike Kravetz @ 2006-07-14 23:39 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, Bryan Rosenburg, linuxppc-dev, Nathan Lynch,
Christopher Yeoh
In-Reply-To: <20060714233739.GA11487@monkey.ibm.com>
Move all the Hypervisor call definitions to to a single header file.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17.4/drivers/net/ibmveth.h linux-2.6.17.4.work/drivers/net/ibmveth.h
--- linux-2.6.17.4/drivers/net/ibmveth.h 2006-07-06 20:02:28.000000000 +0000
+++ linux-2.6.17.4.work/drivers/net/ibmveth.h 2006-07-14 23:05:37.000000000 +0000
@@ -41,16 +41,6 @@
#define IbmVethMcastRemoveFilter 0x2UL
#define IbmVethMcastClearFilterTable 0x3UL
-/* hcall numbers */
-#define H_VIO_SIGNAL 0x104
-#define H_REGISTER_LOGICAL_LAN 0x114
-#define H_FREE_LOGICAL_LAN 0x118
-#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
-#define H_SEND_LOGICAL_LAN 0x120
-#define H_MULTICAST_CTRL 0x130
-#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
-#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
-
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
plpar_hcall_norets(H_REGISTER_LOGICAL_LAN, ua, buflst, rxq, fltlst, mac)
diff -Naupr linux-2.6.17.4/include/asm-powerpc/hvcall.h linux-2.6.17.4.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17.4/include/asm-powerpc/hvcall.h 2006-07-06 20:02:28.000000000 +0000
+++ linux-2.6.17.4.work/include/asm-powerpc/hvcall.h 2006-07-14 23:05:37.000000000 +0000
@@ -155,9 +155,15 @@
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
#define H_COPY_RDMA 0x110
+#define H_REGISTER_LOGICAL_LAN 0x114
+#define H_FREE_LOGICAL_LAN 0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN 0x120
+#define H_MULTICAST_CTRL 0x130
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
@@ -187,11 +193,14 @@
#define H_GET_HCA_INFO 0x1B8
#define H_GET_PERF_COUNT 0x1BC
#define H_MANAGE_TRACE 0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
+#define MAX_HCALL_OPCODES (H_ENABLE_CRQ >> 2)
+
#ifndef __ASSEMBLY__
/* plpar_hcall() -- Generic call interface using above opcodes
^ permalink raw reply
* [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-14 23:37 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, Bryan Rosenburg, linuxppc-dev, Nathan Lynch,
Christopher Yeoh
Hi Paul,
Here is an updated version of the patch(es) to instrument hcalls. All
issues from the previous versions have been addressed. Although, I
haven't really discovered an elegant solution to the assembly routine
name juggling.
In addition, there has been some discussion of these patches on IRC.
Some remaining issues/questions are:
- Exactly how much overhead does the statistic gathering introduce?
- What would be the cost of disabling preemption for more accurate statistics?
- What would be the cost of disabling interrupts for more accurate statistics?
- Should we extend this statistic gathering to RTAS calls?
I would like to get this basic code integrated and then start to address
some of these questions. The IBM performance group will help in
benchmarking to determine overhead.
Please note that all code is behind a config option (off by default) with
zero impact unless enabled.
--
Mike
^ permalink raw reply
* Re: Kexec initial registers
From: Benjamin Herrenschmidt @ 2006-07-14 21:08 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <4CE0FC89-084F-42E8-8E3B-8D2C41AC06F2@watson.ibm.com>
On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
> This is what I have so far:
>
> r3: address of device tree blob
> r4: address that kernel was loaded
> r5: not OF (=0)
Correct and that's all that should be needed
> r13: local_paca address (0?)
You shouldn't have to care about r13 at all, it should be set by the
kernel before it's used. If not, please let us know as that means there
is a bug :)
Ben.
^ permalink raw reply
* Re: some problems on the SystemACE driver.
From: Ming Liu @ 2006-07-14 21:06 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
Dear Ameet,
Here is the normal log without -d when make zImage. Please check it.
Waiting for your result. Have fun in the weekend. :)
>I appreciate you testing the patch. Don't worry... we will solve it. And
>I am not an expert either... you probably know more than me!
Thanks for your encouraging. Let's do it! Hopefully we can finish it
a.s.a.p. Good luck for us!
Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
[-- Attachment #2: log --]
[-- Type: text/plain, Size: 30355 bytes --]
CHK include/linux/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/split-include
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
HOSTCC scripts/kconfig/mconf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf -s arch/ppc/Kconfig
#
# using defaults found in .config
#
SPLIT include/linux/autoconf.h -> include/config/*
CC arch/ppc/kernel/asm-offsets.s
GEN include/asm-ppc/asm-offsets.h
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
CC init/main.o
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
CC init/do_mounts.o
LD init/mounts.o
CC init/initramfs.o
CC init/calibrate.o
LD init/built-in.o
HOSTCC usr/gen_init_cpio
GEN usr/initramfs_data.cpio.gz
AS usr/initramfs_data.o
LD usr/built-in.o
AS arch/ppc/kernel/entry.o
CC arch/ppc/kernel/traps.o
CC arch/ppc/kernel/time.o
AS arch/ppc/kernel/misc.o
CC arch/ppc/kernel/setup.o
CC arch/ppc/kernel/ppc_htab.o
CC arch/ppc/kernel/dma-mapping.o
LD arch/ppc/kernel/built-in.o
AS arch/ppc/kernel/head_4xx.o
LDS arch/ppc/kernel/vmlinux.lds
CC arch/powerpc/kernel/semaphore.o
CC arch/powerpc/kernel/cputable.o
CC arch/powerpc/kernel/ptrace.o
CC arch/powerpc/kernel/syscalls.o
CC arch/powerpc/kernel/irq.o
CC arch/powerpc/kernel/align.o
CC arch/powerpc/kernel/signal_32.o
CC arch/powerpc/kernel/pmc.o
CC arch/powerpc/kernel/vdso.o
CC arch/powerpc/kernel/init_task.o
CC arch/powerpc/kernel/process.o
AS arch/powerpc/kernel/systbl.o
CC arch/powerpc/kernel/idle.o
LDS arch/powerpc/kernel/vdso32/vdso32.lds
VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
VDSO32A arch/powerpc/kernel/vdso32/datapage.o
VDSO32A arch/powerpc/kernel/vdso32/cacheflush.o
VDSO32A arch/powerpc/kernel/vdso32/note.o
VDSO32L arch/powerpc/kernel/vdso32/vdso32.so
AS arch/powerpc/kernel/vdso32/vdso32_wrapper.o
LD arch/powerpc/kernel/vdso32/built-in.o
LD arch/powerpc/kernel/built-in.o
LD arch/ppc/platforms/built-in.o
CC arch/ppc/mm/fault.o
CC arch/ppc/mm/init.o
CC arch/ppc/mm/mem_pieces.o
CC arch/ppc/mm/mmu_context.o
CC arch/ppc/mm/pgtable.o
CC arch/ppc/mm/4xx_mmu.o
LD arch/ppc/mm/built-in.o
AS arch/ppc/lib/checksum.o
AS arch/ppc/lib/string.o
CC arch/ppc/lib/strcase.o
AS arch/ppc/lib/div64.o
LD arch/ppc/lib/built-in.o
CC arch/ppc/syslib/xilinx_pic.o
CC arch/ppc/syslib/ppc_sys.o
CC arch/ppc/syslib/ppc4xx_setup.o
LD arch/ppc/syslib/built-in.o
AS arch/powerpc/sysdev/dcr.o
LD arch/powerpc/sysdev/built-in.o
CC arch/powerpc/lib/bitops.o
LD arch/powerpc/lib/built-in.o
CC arch/ppc/platforms/4xx/xilinx_ml403.o
CC arch/ppc/platforms/4xx/virtex.o
LD arch/ppc/platforms/4xx/built-in.o
CC arch/powerpc/math-emu/math.o
arch/powerpc/math-emu/math.c:56: warning: conflicting types for built-in
function 'fabs'
CC arch/powerpc/math-emu/fmr.o
CC arch/powerpc/math-emu/lfd.o
CC arch/powerpc/math-emu/stfd.o
CC arch/powerpc/math-emu/fabs.o
arch/powerpc/math-emu/fabs.c:7: warning: conflicting types for built-in
function 'fabs'
CC arch/powerpc/math-emu/fadd.o
arch/powerpc/math-emu/fadd.c: In function `fadd':
arch/powerpc/math-emu/fadd.c:31: warning: right shift count is negative
arch/powerpc/math-emu/fadd.c:31: warning: left shift count >= width of type
arch/powerpc/math-emu/fadd.c:13: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fadd.c:13: warning: 'R_f0' might be used uninitialized
in this function
arch/powerpc/math-emu/fadd.c:13: warning: 'R_f1' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fadds.o
arch/powerpc/math-emu/fadds.c: In function `fadds':
arch/powerpc/math-emu/fadds.c:32: warning: right shift count is negative
arch/powerpc/math-emu/fadds.c:32: warning: left shift count >= width of type
arch/powerpc/math-emu/fadds.c:14: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fadds.c:14: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fadds.c:14: warning: 'R_f1' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fcmpo.o
CC arch/powerpc/math-emu/fcmpu.o
CC arch/powerpc/math-emu/fctiw.o
arch/powerpc/math-emu/fctiw.c: In function `fctiw':
arch/powerpc/math-emu/fctiw.c:15: warning: left shift count >= width of type
arch/powerpc/math-emu/fctiw.c:15: warning: left shift count >= width of type
arch/powerpc/math-emu/fctiw.c:12: warning: 'r' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fctiwz.o
arch/powerpc/math-emu/fctiwz.c: In function `fctiwz':
arch/powerpc/math-emu/fctiwz.c:20: warning: left shift count >= width of
type
arch/powerpc/math-emu/fctiwz.c:20: warning: left shift count >= width of
type
arch/powerpc/math-emu/fctiwz.c:13: warning: 'r' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fdiv.o
arch/powerpc/math-emu/fdiv.c: In function `fdiv':
arch/powerpc/math-emu/fdiv.c:46: warning: left shift count is negative
arch/powerpc/math-emu/fdiv.c:13: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fdiv.c:13: warning: 'R_f0' might be used uninitialized
in this function
arch/powerpc/math-emu/fdiv.c:13: warning: 'R_f1' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fdivs.o
arch/powerpc/math-emu/fdivs.c: In function `fdivs':
arch/powerpc/math-emu/fdivs.c:48: warning: left shift count is negative
arch/powerpc/math-emu/fdivs.c:14: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fdivs.c:14: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fdivs.c:14: warning: 'R_f1' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fmadd.o
arch/powerpc/math-emu/fmadd.c: In function `fmadd':
arch/powerpc/math-emu/fmadd.c:36: warning: right shift count is negative
arch/powerpc/math-emu/fmadd.c:36: warning: left shift count >= width of type
arch/powerpc/math-emu/fmadd.c:41: warning: right shift count is negative
arch/powerpc/math-emu/fmadd.c:41: warning: left shift count >= width of type
arch/powerpc/math-emu/fmadd.c:11: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fmadd.c:11: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fmadd.c:11: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fmadd.c:15: warning: 'T_e' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fmadds.o
arch/powerpc/math-emu/fmadds.c: In function `fmadds':
arch/powerpc/math-emu/fmadds.c:37: warning: right shift count is negative
arch/powerpc/math-emu/fmadds.c:37: warning: left shift count >= width of
type
arch/powerpc/math-emu/fmadds.c:42: warning: right shift count is negative
arch/powerpc/math-emu/fmadds.c:42: warning: left shift count >= width of
type
arch/powerpc/math-emu/fmadds.c:12: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fmadds.c:12: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fmadds.c:12: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fmadds.c:16: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fmsub.o
arch/powerpc/math-emu/fmsub.c: In function `fmsub':
arch/powerpc/math-emu/fmsub.c:36: warning: right shift count is negative
arch/powerpc/math-emu/fmsub.c:36: warning: left shift count >= width of type
arch/powerpc/math-emu/fmsub.c:44: warning: right shift count is negative
arch/powerpc/math-emu/fmsub.c:44: warning: left shift count >= width of type
arch/powerpc/math-emu/fmsub.c:11: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fmsub.c:11: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fmsub.c:11: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fmsub.c:15: warning: 'T_e' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fmsubs.o
arch/powerpc/math-emu/fmsubs.c: In function `fmsubs':
arch/powerpc/math-emu/fmsubs.c:37: warning: right shift count is negative
arch/powerpc/math-emu/fmsubs.c:37: warning: left shift count >= width of
type
arch/powerpc/math-emu/fmsubs.c:45: warning: right shift count is negative
arch/powerpc/math-emu/fmsubs.c:45: warning: left shift count >= width of
type
arch/powerpc/math-emu/fmsubs.c:12: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fmsubs.c:12: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fmsubs.c:12: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fmsubs.c:16: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fmul.o
arch/powerpc/math-emu/fmul.c: In function `fmul':
arch/powerpc/math-emu/fmul.c:34: warning: right shift count is negative
arch/powerpc/math-emu/fmul.c:34: warning: left shift count >= width of type
arch/powerpc/math-emu/fmul.c:13: warning: 'R_e' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fmuls.o
arch/powerpc/math-emu/fmuls.c: In function `fmuls':
arch/powerpc/math-emu/fmuls.c:35: warning: right shift count is negative
arch/powerpc/math-emu/fmuls.c:35: warning: left shift count >= width of type
arch/powerpc/math-emu/fmuls.c:14: warning: 'R_e' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fnabs.o
CC arch/powerpc/math-emu/fneg.o
CC arch/powerpc/math-emu/types.o
arch/powerpc/math-emu/types.c: In function `fp_unpack_d':
arch/powerpc/math-emu/types.c:13: warning: left shift count is negative
arch/powerpc/math-emu/types.c: In function `fp_pack_d':
arch/powerpc/math-emu/types.c:28: warning: right shift count is negative
arch/powerpc/math-emu/types.c:28: warning: right shift count is negative
arch/powerpc/math-emu/types.c:28: warning: left shift count is negative
arch/powerpc/math-emu/types.c:28: warning: right shift count is negative
arch/powerpc/math-emu/types.c: In function `fp_pack_ds':
arch/powerpc/math-emu/types.c:41: warning: right shift count is negative
arch/powerpc/math-emu/types.c:45: warning: left shift count is negative
arch/powerpc/math-emu/types.c:46: warning: right shift count is negative
arch/powerpc/math-emu/types.c:46: warning: right shift count is negative
arch/powerpc/math-emu/types.c:46: warning: left shift count is negative
arch/powerpc/math-emu/types.c:46: warning: right shift count is negative
CC arch/powerpc/math-emu/fnmadd.o
arch/powerpc/math-emu/fnmadd.c: In function `fnmadd':
arch/powerpc/math-emu/fnmadd.c:36: warning: right shift count is negative
arch/powerpc/math-emu/fnmadd.c:36: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmadd.c:41: warning: right shift count is negative
arch/powerpc/math-emu/fnmadd.c:41: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmadd.c:11: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadd.c:11: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadd.c:11: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadd.c:15: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fnmadds.o
arch/powerpc/math-emu/fnmadds.c: In function `fnmadds':
arch/powerpc/math-emu/fnmadds.c:37: warning: right shift count is negative
arch/powerpc/math-emu/fnmadds.c:37: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmadds.c:42: warning: right shift count is negative
arch/powerpc/math-emu/fnmadds.c:42: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmadds.c:12: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadds.c:12: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadds.c:12: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmadds.c:16: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fnmsub.o
arch/powerpc/math-emu/fnmsub.c: In function `fnmsub':
arch/powerpc/math-emu/fnmsub.c:36: warning: right shift count is negative
arch/powerpc/math-emu/fnmsub.c:36: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmsub.c:44: warning: right shift count is negative
arch/powerpc/math-emu/fnmsub.c:44: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmsub.c:11: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsub.c:11: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsub.c:11: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsub.c:15: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fnmsubs.o
arch/powerpc/math-emu/fnmsubs.c: In function `fnmsubs':
arch/powerpc/math-emu/fnmsubs.c:37: warning: right shift count is negative
arch/powerpc/math-emu/fnmsubs.c:37: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmsubs.c:45: warning: right shift count is negative
arch/powerpc/math-emu/fnmsubs.c:45: warning: left shift count >= width of
type
arch/powerpc/math-emu/fnmsubs.c:12: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsubs.c:12: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsubs.c:12: warning: 'R_f1' might be used
uninitialized in this function
arch/powerpc/math-emu/fnmsubs.c:16: warning: 'T_e' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fres.o
CC arch/powerpc/math-emu/frsp.o
CC arch/powerpc/math-emu/frsqrte.o
CC arch/powerpc/math-emu/fsel.o
CC arch/powerpc/math-emu/lfs.o
arch/powerpc/math-emu/lfs.c: In function `lfs':
arch/powerpc/math-emu/lfs.c:30: warning: left shift count is negative
CC arch/powerpc/math-emu/fsqrt.o
arch/powerpc/math-emu/fsqrt.c: In function `fsqrt':
arch/powerpc/math-emu/fsqrt.c:30: warning: left shift count is negative
arch/powerpc/math-emu/fsqrt.c:30: warning: left shift count is negative
arch/powerpc/math-emu/fsqrt.c:30: warning: left shift count is negative
arch/powerpc/math-emu/fsqrt.c:30: warning: left shift count is negative
arch/powerpc/math-emu/fsqrt.c:30: warning: right shift count is negative
arch/powerpc/math-emu/fsqrt.c:12: warning: 'R_c' might be used uninitialized
in this function
arch/powerpc/math-emu/fsqrt.c:12: warning: 'R_s' might be used uninitialized
in this function
arch/powerpc/math-emu/fsqrt.c:12: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fsqrt.c:12: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fsqrt.c:12: warning: 'R_f1' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fsqrts.o
arch/powerpc/math-emu/fsqrts.c: In function `fsqrts':
arch/powerpc/math-emu/fsqrts.c:31: warning: left shift count is negative
arch/powerpc/math-emu/fsqrts.c:31: warning: left shift count is negative
arch/powerpc/math-emu/fsqrts.c:31: warning: left shift count is negative
arch/powerpc/math-emu/fsqrts.c:31: warning: left shift count is negative
arch/powerpc/math-emu/fsqrts.c:31: warning: right shift count is negative
arch/powerpc/math-emu/fsqrts.c:13: warning: 'R_c' might be used
uninitialized in this function
arch/powerpc/math-emu/fsqrts.c:13: warning: 'R_s' might be used
uninitialized in this function
arch/powerpc/math-emu/fsqrts.c:13: warning: 'R_e' might be used
uninitialized in this function
arch/powerpc/math-emu/fsqrts.c:13: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fsqrts.c:13: warning: 'R_f1' might be used
uninitialized in this function
CC arch/powerpc/math-emu/fsub.o
arch/powerpc/math-emu/fsub.c: In function `fsub':
arch/powerpc/math-emu/fsub.c:34: warning: right shift count is negative
arch/powerpc/math-emu/fsub.c:34: warning: left shift count >= width of type
arch/powerpc/math-emu/fsub.c:13: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fsub.c:13: warning: 'R_f0' might be used uninitialized
in this function
arch/powerpc/math-emu/fsub.c:13: warning: 'R_f1' might be used uninitialized
in this function
CC arch/powerpc/math-emu/fsubs.o
arch/powerpc/math-emu/fsubs.c: In function `fsubs':
arch/powerpc/math-emu/fsubs.c:35: warning: right shift count is negative
arch/powerpc/math-emu/fsubs.c:35: warning: left shift count >= width of type
arch/powerpc/math-emu/fsubs.c:14: warning: 'R_e' might be used uninitialized
in this function
arch/powerpc/math-emu/fsubs.c:14: warning: 'R_f0' might be used
uninitialized in this function
arch/powerpc/math-emu/fsubs.c:14: warning: 'R_f1' might be used
uninitialized in this function
CC arch/powerpc/math-emu/mcrfs.o
CC arch/powerpc/math-emu/mffs.o
CC arch/powerpc/math-emu/mtfsb0.o
CC arch/powerpc/math-emu/mtfsb1.o
CC arch/powerpc/math-emu/mtfsf.o
CC arch/powerpc/math-emu/mtfsfi.o
CC arch/powerpc/math-emu/stfiwx.o
CC arch/powerpc/math-emu/stfs.o
arch/powerpc/math-emu/stfs.c: In function `stfs':
arch/powerpc/math-emu/stfs.c:27: warning: right shift count is negative
CC arch/powerpc/math-emu/udivmodti4.o
LD arch/powerpc/math-emu/built-in.o
CC kernel/sched.o
CC kernel/fork.o
CC kernel/exec_domain.o
CC kernel/panic.o
CC kernel/printk.o
CC kernel/profile.o
CC kernel/exit.o
CC kernel/itimer.o
CC kernel/time.o
CC kernel/softirq.o
CC kernel/resource.o
CC kernel/sysctl.o
CC kernel/capability.o
CC kernel/ptrace.o
CC kernel/timer.o
CC kernel/user.o
CC kernel/signal.o
CC kernel/sys.o
CC kernel/kmod.o
CC kernel/workqueue.o
CC kernel/pid.o
CC kernel/rcupdate.o
CC kernel/extable.o
CC kernel/params.o
CC kernel/posix-timers.o
CC kernel/kthread.o
CC kernel/wait.o
CC kernel/kfifo.o
CC kernel/sys_ni.o
CC kernel/posix-cpu-timers.o
CC kernel/mutex.o
CC kernel/hrtimer.o
CC kernel/futex.o
CC kernel/intermodule.o
CC kernel/kallsyms.o
CC kernel/ksysfs.o
CC kernel/softlockup.o
CC kernel/irq/handle.o
CC kernel/irq/manage.o
CC kernel/irq/spurious.o
CC kernel/irq/proc.o
LD kernel/irq/built-in.o
CC kernel/seccomp.o
LD kernel/built-in.o
CC mm/bootmem.o
CC mm/filemap.o
CC mm/mempool.o
CC mm/oom_kill.o
CC mm/fadvise.o
CC mm/page_alloc.o
CC mm/page-writeback.o
CC mm/pdflush.o
CC mm/readahead.o
CC mm/swap.o
CC mm/truncate.o
CC mm/vmscan.o
CC mm/prio_tree.o
CC mm/util.o
CC mm/mmzone.o
CC mm/fremap.o
CC mm/highmem.o
CC mm/madvise.o
CC mm/memory.o
CC mm/mincore.o
CC mm/mlock.o
CC mm/mmap.o
CC mm/mprotect.o
CC mm/mremap.o
CC mm/msync.o
CC mm/rmap.o
CC mm/vmalloc.o
CC mm/page_io.o
CC mm/swap_state.o
CC mm/swapfile.o
CC mm/thrash.o
CC mm/shmem.o
CC mm/slab.o
CC mm/filemap_xip.o
LD mm/built-in.o
CC fs/open.o
CC fs/read_write.o
CC fs/file_table.o
CC fs/buffer.o
CC fs/bio.o
CC fs/super.o
CC fs/block_dev.o
CC fs/char_dev.o
CC fs/stat.o
CC fs/exec.o
CC fs/pipe.o
CC fs/namei.o
CC fs/fcntl.o
CC fs/ioctl.o
CC fs/readdir.o
CC fs/select.o
CC fs/fifo.o
CC fs/locks.o
CC fs/dcache.o
CC fs/inode.o
CC fs/attr.o
CC fs/bad_inode.o
CC fs/file.o
CC fs/filesystems.o
CC fs/namespace.o
CC fs/aio.o
CC fs/seq_file.o
CC fs/xattr.o
CC fs/libfs.o
CC fs/fs-writeback.o
CC fs/mpage.o
CC fs/direct-io.o
CC fs/ioprio.o
CC fs/pnode.o
CC fs/drop_caches.o
CC fs/splice.o
CC fs/sync.o
CC fs/inotify.o
CC fs/eventpoll.o
CC fs/binfmt_script.o
CC fs/binfmt_elf.o
CC fs/mbcache.o
CC fs/posix_acl.o
CC fs/xattr_acl.o
CC fs/dnotify.o
CC fs/autofs/dirhash.o
CC fs/autofs/init.o
CC fs/autofs/inode.o
CC fs/autofs/root.o
CC fs/autofs/symlink.o
CC fs/autofs/waitq.o
LD fs/autofs/autofs.o
LD fs/autofs/built-in.o
CC fs/autofs4/init.o
CC fs/autofs4/inode.o
CC fs/autofs4/root.o
CC fs/autofs4/symlink.o
CC fs/autofs4/waitq.o
CC fs/autofs4/expire.o
LD fs/autofs4/autofs4.o
LD fs/autofs4/built-in.o
CC fs/devpts/inode.o
LD fs/devpts/devpts.o
LD fs/devpts/built-in.o
CC fs/ext2/balloc.o
CC fs/ext2/bitmap.o
CC fs/ext2/dir.o
CC fs/ext2/file.o
CC fs/ext2/fsync.o
CC fs/ext2/ialloc.o
CC fs/ext2/inode.o
CC fs/ext2/ioctl.o
CC fs/ext2/namei.o
CC fs/ext2/super.o
CC fs/ext2/symlink.o
CC fs/ext2/xattr.o
CC fs/ext2/xattr_user.o
CC fs/ext2/xattr_trusted.o
CC fs/ext2/acl.o
CC fs/ext2/xattr_security.o
CC fs/ext2/xip.o
LD fs/ext2/ext2.o
LD fs/ext2/built-in.o
CC fs/nls/nls_base.o
LD fs/nls/built-in.o
CC fs/partitions/check.o
CC fs/partitions/msdos.o
LD fs/partitions/built-in.o
CC fs/proc/mmu.o
CC fs/proc/task_mmu.o
CC fs/proc/inode.o
CC fs/proc/root.o
CC fs/proc/base.o
CC fs/proc/generic.o
CC fs/proc/array.o
CC fs/proc/kmsg.o
CC fs/proc/proc_tty.o
CC fs/proc/proc_misc.o
CC fs/proc/kcore.o
LD fs/proc/proc.o
LD fs/proc/built-in.o
CC fs/ramfs/inode.o
CC fs/ramfs/file-mmu.o
LD fs/ramfs/ramfs.o
LD fs/ramfs/built-in.o
CC fs/sysfs/inode.o
CC fs/sysfs/file.o
CC fs/sysfs/dir.o
CC fs/sysfs/symlink.o
CC fs/sysfs/mount.o
CC fs/sysfs/bin.o
CC fs/sysfs/group.o
LD fs/sysfs/built-in.o
LD fs/built-in.o
CC ipc/util.o
CC ipc/msgutil.o
CC ipc/msg.o
CC ipc/sem.o
CC ipc/shm.o
LD ipc/built-in.o
CC security/commoncap.o
LD security/built-in.o
LD crypto/built-in.o
CC block/elevator.o
CC block/ll_rw_blk.o
CC block/ioctl.o
CC block/genhd.o
CC block/scsi_ioctl.o
CC block/noop-iosched.o
CC block/as-iosched.o
CC block/deadline-iosched.o
CC block/cfq-iosched.o
LD block/built-in.o
CC drivers/base/core.o
CC drivers/base/sys.o
CC drivers/base/bus.o
CC drivers/base/dd.o
CC drivers/base/driver.o
CC drivers/base/class.o
CC drivers/base/platform.o
CC drivers/base/cpu.o
CC drivers/base/firmware.o
CC drivers/base/init.o
CC drivers/base/map.o
CC drivers/base/dmapool.o
CC drivers/base/attribute_container.o
CC drivers/base/transport_class.o
CC drivers/base/power/shutdown.o
LD drivers/base/power/built-in.o
LD drivers/base/built-in.o
CC drivers/block/loop.o
CC drivers/block/xilinx_sysace/adapter.o
drivers/block/xilinx_sysace/adapter.c:221: warning: 'xsysace_restart'
defined but not used
CC drivers/block/xilinx_sysace/xbasic_types.o
CC drivers/block/xilinx_sysace/xsysace.o
CC drivers/block/xilinx_sysace/xsysace_g.o
CC drivers/block/xilinx_sysace/xsysace_intr.o
CC drivers/block/xilinx_sysace/xsysace_l.o
CC drivers/block/xilinx_sysace/xsysace_compactflash.o
CC drivers/block/xilinx_sysace/xsysace_jtagcfg.o
LD drivers/block/xilinx_sysace/xilinx_sysace.o
LD drivers/block/xilinx_sysace/built-in.o
LD drivers/block/built-in.o
LD drivers/cdrom/built-in.o
CC drivers/char/mem.o
CC drivers/char/random.o
CC drivers/char/tty_io.o
CC drivers/char/n_tty.o
CC drivers/char/tty_ioctl.o
CC drivers/char/pty.o
CC drivers/char/misc.o
CC drivers/char/vt_ioctl.o
CC drivers/char/vc_screen.o
CC drivers/char/consolemap.o
CONMK drivers/char/consolemap_deftbl.c
CC drivers/char/consolemap_deftbl.o
CC drivers/char/selection.o
CC drivers/char/keyboard.o
CC drivers/char/vt.o
SHIPPED drivers/char/defkeymap.c
CC drivers/char/defkeymap.o
LD drivers/char/built-in.o
LD drivers/firmware/built-in.o
CC drivers/hwmon/hwmon.o
LD drivers/hwmon/built-in.o
CC drivers/input/input.o
CC drivers/input/mousedev.o
LD drivers/input/built-in.o
CC drivers/input/serio/serio.o
CC drivers/input/serio/i8042.o
CC drivers/input/serio/serport.o
LD drivers/input/serio/built-in.o
LD drivers/media/common/built-in.o
LD drivers/media/built-in.o
LD drivers/mfd/built-in.o
LD drivers/misc/built-in.o
CC drivers/mtd/mtdcore.o
CC drivers/mtd/mtdpart.o
CC drivers/mtd/redboot.o
drivers/mtd/redboot.c: In function `parse_redboot_partitions':
drivers/mtd/redboot.c:103: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:104: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:105: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:106: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:107: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:108: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
drivers/mtd/redboot.c:109: warning: passing arg 1 of `__swab32s' from
incompatible pointer type
CC drivers/mtd/mtdchar.o
CC drivers/mtd/mtdblock.o
CC drivers/mtd/mtd_blkdevs.o
CC drivers/mtd/chips/chipreg.o
CC drivers/mtd/chips/cfi_probe.o
CC drivers/mtd/chips/cfi_util.o
CC drivers/mtd/chips/cfi_cmdset_0002.o
drivers/mtd/chips/cfi_cmdset_0002.c: In function `cfi_amdstd_init':
drivers/mtd/chips/cfi_cmdset_0002.c:1766: warning: `inter_module_register'
is deprecated (declared at include/linux/module.h:563)
drivers/mtd/chips/cfi_cmdset_0002.c: In function `cfi_amdstd_exit':
drivers/mtd/chips/cfi_cmdset_0002.c:1773: warning: `inter_module_unregister'
is deprecated (declared at include/linux/module.h:564)
CC drivers/mtd/chips/gen_probe.o
LD drivers/mtd/chips/built-in.o
LD drivers/mtd/devices/built-in.o
LD drivers/mtd/maps/built-in.o
LD drivers/mtd/nand/built-in.o
LD drivers/mtd/onenand/built-in.o
LD drivers/mtd/built-in.o
CC drivers/net/Space.o
CC drivers/net/loopback.o
CC drivers/net/xilinx_temac/adapter.o
CC drivers/net/xilinx_temac/xtemac.o
CC drivers/net/xilinx_temac/xtemac_intr.o
CC drivers/net/xilinx_temac/xtemac_intr_sgdma.o
CC drivers/net/xilinx_temac/xtemac_sgdma.o
CC drivers/net/xilinx_temac/xtemac_intr_fifo.o
CC drivers/net/xilinx_temac/xtemac_fifo.o
CC drivers/net/xilinx_temac/xtemac_l.o
CC drivers/net/xilinx_temac/xtemac_control.o
LD drivers/net/xilinx_temac/xilinx_temac.o
LD drivers/net/xilinx_temac/built-in.o
LD drivers/net/built-in.o
CC drivers/serial/serial_core.o
CC drivers/serial/8250.o
CC drivers/serial/8250_early.o
LD drivers/serial/built-in.o
LD drivers/video/backlight/built-in.o
CC drivers/video/console/dummycon.o
LD drivers/video/console/built-in.o
LD drivers/video/built-in.o
CC drivers/xilinx_edk/xilinx_syms.o
CC drivers/xilinx_edk/xbasic_types.o
CC drivers/xilinx_edk/xpacket_fifo_v2_00_a.o
CC drivers/xilinx_edk/xpacket_fifo_l_v2_00_a.o
CC drivers/xilinx_edk/xdmav2.o
CC drivers/xilinx_edk/xdmav2_intr.o
CC drivers/xilinx_edk/xdmav2_sg.o
CC drivers/xilinx_edk/xdmav2_simple.o
LD drivers/xilinx_edk/built-in.o
LD drivers/built-in.o
drivers/xilinx_edk/built-in.o(.sdata+0x0): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of
`XWaitInAssert'
drivers/block/built-in.o(.sdata+0x0):drivers/block/loop.c:91: first defined
here
drivers/xilinx_edk/built-in.o(.sbss+0x4): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of
`XAssertStatus'
drivers/block/built-in.o(.sbss+0x38):drivers/block/loop.c:98: first defined
here
drivers/xilinx_edk/built-in.o(.text+0x44): In function `XAssertSetCallback':
drivers/xilinx_edk/xbasic_types.c:134: multiple definition of
`XAssertSetCallback'
drivers/block/built-in.o(.text+0x24bc):drivers/block/xilinx_sysace/xbasic_types.c:134:
first defined here
drivers/xilinx_edk/built-in.o(.text+0x0): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of `XAssert'
drivers/block/built-in.o(.text+0x2478):drivers/block/xilinx_sysace/xbasic_types.c:105:
first defined here
drivers/xilinx_edk/built-in.o(.text+0x50): In function `XNullHandler':
drivers/xilinx_edk/xbasic_types.c:153: multiple definition of `XNullHandler'
drivers/block/built-in.o(.text+0x24c8):drivers/block/xilinx_sysace/xbasic_types.c:153:
first defined here
make[1]: *** [drivers/built-in.o] Error 1
make: *** [drivers] Error 2
^ permalink raw reply
* Re: [Fwd: Re: [Ilugc] help regarding powerpc and vga card]
From: Benjamin Herrenschmidt @ 2006-07-14 19:20 UTC (permalink / raw)
To: sudheer; +Cc: Sivasankar Chander, linuxppc-embedded
In-Reply-To: <44B77452.1070106@gmail.com>
> >> All PCI VGA cards for use on x86 PCs have a ROMscan
> BIOS
> >> extension on them. This initializes the card after POST -
> basically,
> >> the motherboard BIOS transfers control to the BIOS on the
> >> PCI VGA card, which then initializes itself. If control is
> not
> >> transfered to the VGA BIOS on the card, the VGA controller
> >> stays isolated and will not respond to PCI device
> enumeration,
> >> etc.
> >
> I have a doubt here. How does the processor know that the card
> sitting
> here is a vga card
> and control should be transfered to initialize it. I think it
> can know
> that it is a vga card only by reading the config space .
> And bios is necesary for vga card to work in its normal way.
> Is it
> necesary for bios to be initialised to get detected.
> Please correct me if i am wrong.
You are not wrong (though your mailer sucks). The initial poster seems
to be a bit confused.
All PCI video cards (VGA or not) shall respond to PCI config spaces
normally. They can be enumerated, and if they carry a BIOS image (or any
other firmware support like an Open Firmware F-Code driver), it should
be accessible via the standard PCI expansion ROM BAR.
There is no such thing as "the VGA controller stays isolated" or
whatever sort of crap. However, it is true that the video card needs to
be initialized to be able to actually output anything useful, and
depending on the chip, it's generically a complex procedure involving
setting up all sorts of PLLs, initializing the card's memory controller
and performing the appropriate SDRAM init sequence, initializing the
various external chips like TMDS transmitters on the card etc etc...
That is normally done by the card's firmware which generally sits in the
card's PCI expansion ROM (not always though, it's getting common
nowadays on x86 laptops for example to have the video card's BIOS mixes
with the main BIOS to save a flash chip). The most common type of
firmware is indeed an x86 video BIOS, which can run on non-x86 platforms
through an emulator like x86emu (a common practice, works fairly well
afaik).
Note that what that BIOS does it to poke the card's registers, which are
accessible via the card's normal PCI BARs :) At least most of the time.
Some cards do indeed require some use of the legacy VGA registers for
initialization, which means issuing IO cycles on the bus to fixed VGA
addresses, but that's pretty much irrelevant.
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Olof Johansson @ 2006-07-14 19:17 UTC (permalink / raw)
To: Tim Bird
Cc: Olof Johansson, Stephen Rothwell, linuxppc-dev, linuxppc-embedded
In-Reply-To: <44B7ECD7.3080807@am.sony.com>
On Fri, Jul 14, 2006 at 12:13:27PM -0700, Tim Bird wrote:
> Olof Johansson wrote:
> > Ick. Why not just create a linuxppc-jobs@ozlabs org instead of hiding it
> > somewhere in the CELF organization...?
>
> Well, it would be either a public list or on CELF's public wiki.
> I'm not sure how this would be "hiding it".
Sorry, I was replying from the viewpoing of a linuxppc-dev reader, not a
linuxppc-embedded reader. I'm willing to say that almost noone of us
visit the CELF pages very often, or at all.
-Olof
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Segher Boessenkool @ 2006-07-14 19:14 UTC (permalink / raw)
To: bbosch; +Cc: Stephen Rothwell, linuxppc-embedded, linuxppc-dev
In-Reply-To: <17591.43974.871998.267718@waldo.lisle.iphase.com>
> On the other hand, a couple weeks ago, proclus@gnu-darwin.org posted a
> very long, meandering political statement, most of which seemed to
> have very little to do with PowerPC Linux and I didn't notice anyone
> complain on these lists.
I complained on another list -- he sent it _everywhere_.
> (Which is just as well since my objection
> off-list resulted only in a long pointless argument in which it became
> clear that rational debate would get me nowhere.)
Yes indeed.
Segher
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Tim Bird @ 2006-07-14 19:13 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <20060714180309.GA9121@pb15.lixom.net>
Olof Johansson wrote:
> Ick. Why not just create a linuxppc-jobs@ozlabs org instead of hiding it
> somewhere in the CELF organization...?
Well, it would be either a public list or on CELF's public wiki.
I'm not sure how this would be "hiding it".
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* no "ash" process load
From: morelli.gab @ 2006-07-14 19:02 UTC (permalink / raw)
To: linuxppc-embedded
hi to all
I have a problem when load the kernel-2.6 in my board.
it can't execute the process ash.
how can i set the file "inittab" in way to resolve the problem?
this is the message given back.
mtdblock_release
ok
mtdblock_open
ok
.....
mtdblock: read on "cramfs" at 0x93400, size 0x200
mtdblock: read on "cramfs" at 0x93600, size 0x200
mtdblock: read on "cramfs" at 0x93800, size 0x200
mtdblock: read on "cramfs" at 0x93a00, size 0x200
mtdblock: read on "cramfs" at 0x93c00, size 0x200
mtdblock: read on "cramfs" at 0x93e00, size 0x200
Usage: ash 0123456SsQq=F1BbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
Usage: ash 0123456SsQqAaBbCcUu
...
thanks
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Frank @ 2006-07-14 18:41 UTC (permalink / raw)
To: Linas Vepstas, Wolfgang Denk
Cc: linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <20060714163814.GD11943@austin.ibm.com>
--- Linas Vepstas <linas@austin.ibm.com> wrote:
> On Fri, Jul 14, 2006 at 06:21:00PM +0200, Wolfgang Denk wrote:
> >
> > > Should I post our embedded PPC kernel related work
> openings here?
> >
> > NO!!!
> >
> > This is a technical discussion group. Job offerings,
> commercial ads
> > and all this stuff is off topic here. Please re-read the
> list info at
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded resp.
> -dev
> >
> > It says: "...discussions/patches should pertain to
> software
> > development for the kernel core ppc32 embedded processor
> support and
> > any driver/chip/board support for ppc32 based embedded
> systems."
> >
> > "Software development". This does not allow for job offers,
> ads or
> > other crap.
>
> I respectfully disagree. There may well be people who would
> rather
> work on PowerPC Linux kernels more than any other thing in the
> world,
> and it is entirely appropriate for job openings for PowerPC
> Linux kernel
> programmers to be posted here.
>
> Much as I would like to be, and not for lack of trying,
> indpendently
> wealthy off some dot-com IPO, so that I may code on whatever I
> wished,
> I have, in fact, failed at this, and must stick to actual
> employment
> to feed, cloth and educate my family. I am not alone.
>
> There is a long precedent for this in academic societies, and
> you will
> find job postings in Nature, Science, Physics Today and
> American
> Mathematical Monthly. Frankly, there simply are not so many
> job
> opporunities that we, much like engineers and scientists in
> general,
> can afford to thumb our noses at them.
>
> If you in fact are especially fortunate, then perhaps you
> could
> mentor someone younger: someone who is hot, smart, and fresh
> out of
> college, a good talent, who has contributed good patches, but
> is now
> faced with the need to find rent and beer money. What advice
> can you
> give them, "tough luck Squidward, go work at the Krusty Krab?"
>
> --linas/ozlabs.org/mailman/listinfo/linuxppc-dev
Maybe you should stand on a corner with a sign that says:
"Will code for food"...
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: Xilinx hard TEMAC
From: Rick Moleres @ 2006-07-14 18:43 UTC (permalink / raw)
To: dhlii, linuxppc-embedded
David,
<snip>
>=20
> The choice and configuration of the TEMAC was driven by FPGA
> realestate.
>=20
> My perception was that the "Hard" Temac was based on silicon
already
> in the FX (much like the PowerPC) while the "Soft" TEMAC is primarily
> implimented within the FPGA (much like the MicroBlaze).
>=20
> Is that distinction between "soft" and "hard" correct ?
>=20
That is the correct distinction between "soft" and "hard". Just know
that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
> If not is the only significant distinction between the PLB_TEMAC
> supported by the EDK and the LL_TEMAC the bus interface ?
Yes, this is one of the distinctions between LL TEMAC and PLB TEMAC. :-)
> I should not think the difference between different bus
interfaces
> should be radically different in terms of FPGA cells. While
implimenting
> the MAC in the FPGA would likely be expensive in realestate.
> I can try to argue for the PLB_TEMAC - as something that will
have
> Xilinx/MV support and may get incorporated in the standard Kernel - If
> the cost in cells is not substantial.
>=20
I believe LL_TEMAC is smaller than PLB_TEMAC, and so this could be a
tough sell for you if FPGA space is at a premium. When put in a system
with other stuff (e.g., memory controller, etc...) the size gets closer,
but I think GSRD is still smaller. Sorry, I don't have the numbers.
There were improvements to PLB TEMAC in EDK 8.1.2 to address some size
issues, and even more planned down the road to hopefully converge the
two.
>=20
>=20
> > The Linux driver posted for the TEMAC (by MontaVista) is for the
> > PLB_TEMAC. Updates to this driver may also be released with the EDK
> > (e.g., EDK 8.1.2 updated the driver to include checksum offload).
There
> > is a Linux driver for the LL_TEMAC that comes with GSRD, but my
group's
> > efforts go toward the PLB_TEMAC as that is the EDK IP we want to
promote
> > and whose drivers we'd like to see in kernel.org.
> >
> How can I get a copy of the GSRD LL_TEMAC ? Is it a 2.4 or 2.6
driver
> ?
>=20
You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
design, and inside of that design somewhere you'll find a Linux 2.4
driver for the LL TEMAC.
> > By the way, there is no relation to the IBM EMAC.
> >
> These things are worth knowing.
>=20
> The T still means Tri. is there some specific EMAC that was used
as
> a reference for the design or is the TEMAC entirely a Xilinx creation
?
>=20
It's a Xilinx creation as far as I know.
> > Hope that helps,
> > -Rick
> >
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Geoff Thorpe @ 2006-07-14 18:40 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, linuxppc-embedded, Stephen Rothwell
In-Reply-To: <20060714180309.GA9121@pb15.lixom.net>
Olof Johansson wrote:
>Personally, I don't mind getting the ads just to know who is growing
>out there and so on, but I don't want them sorted into the folder with
>technical stuff, and I don't want to rely on people tagging the subject
>right.
>
>
In this case, a list moderator was contacted prior to the post. So...
why not just extend the idea and have potential employers[1] provide
their "openings" (erm) to such a moderator who sends a not-too-frequent
digest to the list encapsulating any/all such offerings. That way, the
subject *will* be tagged correctly, the rate of "off-topic" postings is
inherently throttled/coalesced, and anyone who might be remotely
interested will be exposed to such opportunities without having to
actively go searching (ipso facto, those HR types will be less inclined
to carpet-bomb the entire internet for fear that their offerings go
otherwise unnoticed). Hell, if the subject header was appropriately
keyworded - Wolfgang could even procmail it to /dev/null ;-)
[1] this could also cover other commercial/potential-list-abuse subjects
like speaking engagements, survey requests, [tbd]. If it got too big, it
could be replaced with a summary of headings and URLs. Whatever.
Just my first-glance $0.02,
Geoff
^ permalink raw reply
* Kexec initial registers
From: Jimi Xenidis @ 2006-07-14 16:02 UTC (permalink / raw)
To: linuxppc-dev
This is what I have so far:
r3: address of device tree blob
r4: address that kernel was loaded
r5: not OF (=0)
r13: local_paca address (0?)
anything else?
Did I miss the document on this?
-JX
^ permalink raw reply
* Re: how to get individual patches
From: Grant Likely @ 2006-07-14 18:22 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44B7DEC3.1090308@dlasys.net>
On 7/14/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
> Thank You git bisect has proven to be incredibly interesting.
>
> One question/problem - maybe an incomplete understanding of git.
>
> What I need to do is get to some version of 2.6.16 - as they all work
> for me.
>
> cut in my patches.
>
> And THEN start bisecting while retaining my patches.
>
> Is that going to work or am I going to have to repatch each time ?
AFAIK, yes you will have to repatch every time; I typically write a
little helper script to lessen the pain:
git bisect good|bad # depends on whether it works or not
patch < [patchfile]
compile, test, etc
cg restore -f # Remove the patches
git bisect good|bad # lather, rinse, repeate
>
> Basically can I use git to insert a patch into the middle of its delta
> history and then advance forward from there ?
I don't think so; no automatically; but if you don't commit your
changes then it's easy to drop the change the patch makes.
git-rebase does something similar to what you're trying to do; but
it's complex to use (especially if there are conflicts) and might
conflict w/ the git-bisect tool
>
> It is rapidly becoming obvious that competence with git could have big
> payback.
:)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: how to get individual patches
From: David H. Lynch Jr. @ 2006-07-14 18:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0606280209m4ce91cb0wc3cab2f2d3aec1a7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
Grant Likely wrote:
> On 6/28/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>> The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>>
>> How can I find the individual patches that make up the transition
>> from 2.6.16.21 to 2.6.17 ?
>>
>
> Unfortunately, there isn't a direct line between .16.21 and .17 which
> makes it complicated. Does your bsp work with .16? If so; you can
> use the 'git bisect' command to figure out exactly where the
> regression occured.
>
> If it doesn't work on .16; you can do a bisect between .16 and .16.21
> to figure out what patch is missing between .16 and .17.
>
> $ git bisect good v2.6.16
> $ git bisect bad # the head of the tree
> compile, test, etc.
> $ git bisect good|bad # depends on whether it works or not
> compile, test, etc
> $ git bisect good|bad # you get the idea... repeat until it's narrowed down
> $ git log # see where you are in the git tree.
>
>
Thank You git bisect has proven to be incredibly interesting.
One question/problem - maybe an incomplete understanding of git.
What I need to do is get to some version of 2.6.16 - as they all
work for me.
cut in my patches.
And THEN start bisecting while retaining my patches.
Is that going to work or am I going to have to repatch each time ?
Basically can I use git to insert a patch into the middle of its
delta history and then advance forward from there ?
It is rapidly becoming obvious that competence with git could have
big payback.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 2991 bytes --]
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Olof Johansson @ 2006-07-14 18:03 UTC (permalink / raw)
To: Tim Bird; +Cc: linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <44B7D485.3000604@am.sony.com>
On Fri, Jul 14, 2006 at 10:29:41AM -0700, Tim Bird wrote:
> Wolfgang Denk wrote:
> > In message <20060714184305.4d16550a.sfr@canb.auug.org.au> you wrote:
> >> Richard asked the list admins before he sent this message and we decided
> >> it would be OK if he identifed the message in its subject.
> >
> > Hello List Admins,
> >
> > please keep these lists a technical discussion forum with good
> > signal-noise ration. Don't allow people to spam these lists with job
> > offers or other crap.
>
> To lessen the pressure to do this on lists, how about if CELF
> maintains some kind of job board on its wiki, or creates a separate
> list for this? Some member companies (employee seekers) and
> job seekers have asked about this in the past.
>
> I'll discuss this at our AG meeting next week.
Ick. Why not just create a linuxppc-jobs@ozlabs org instead of hiding it
somewhere in the CELF organization, especially since it's not neccessarily
constrained to embedded jobs? That solves the problem for all involved
parties, those who are looking for jobs or want to be in the loop on
what is going on can subscribe, others can keep away.
Stephen, care to create a list?
Personally, I don't mind getting the ads just to know who is growing
out there and so on, but I don't want them sorted into the folder with
technical stuff, and I don't want to rely on people tagging the subject
right.
-Olof
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Tim Bird @ 2006-07-14 17:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Stephen Rothwell, linuxppc-embedded, linuxppc-dev
In-Reply-To: <20060714112250.CC266352B36@atlas.denx.de>
Wolfgang Denk wrote:
> In message <20060714184305.4d16550a.sfr@canb.auug.org.au> you wrote:
>> Richard asked the list admins before he sent this message and we decided
>> it would be OK if he identifed the message in its subject.
>
> Hello List Admins,
>
> please keep these lists a technical discussion forum with good
> signal-noise ration. Don't allow people to spam these lists with job
> offers or other crap.
To lessen the pressure to do this on lists, how about if CELF
maintains some kind of job board on its wiki, or creates a separate
list for this? Some member companies (employee seekers) and
job seekers have asked about this in the past.
I'll discuss this at our AG meeting next week.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* Re: JTAG PPC info ?
From: David H. Lynch Jr. @ 2006-07-14 17:04 UTC (permalink / raw)
To: bennett78, linuxppc-embedded
In-Reply-To: <1152888198.44b7ad86a50ed@webmail.digis.net>
[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]
bennett78@digis.net wrote:
> Quoting "David H. Lynch Jr." <dhlii@dlasys.net>:
>
>
>> Has anyone not covered by non-disclosure deciphered the JTAG codes
>> for the PowerPC ?
>>
>
> Is this a big secret or just skimpy Freescale documentation?
> Try emailing:
> Ed.Nuckolls@freescale.com
> This effort could help expand projects such as:
> http://sourceforge.net/projects/jtager/
> for us embedded powerpc users!
>
> For myself, right now I can't get much help from Abatron turning
> on a new MPC5200 design. My approach: debugging modified u-boot code
> running out of RAM....lots of machine checks!
>
It is my understanding that certain aspects of JTAG are specific to
the target (chip) for most devices that information is documented.
Some processors treat the JTAG communications to the processor as
proprietary.
Some make the information readily available.
It is my understanding that the interface to the PPC is only
available under NDA from IBM.
My client is building a wholely OpenSource SDK to support developing
for their target.
They have their own pseudo JTAG interface - on the host side it
emulates a JTAG Parallel port in software.
On the target side it is a full hardware JTAG.
They are trying to get a gdbserver working and there is no
OpenSource GdbServer that includes PPC support.
Right now they have a back burner project decyphering the the PPC
interface and are working through it slowly.
> Frank Bennett
> President
> Mathegraphics,LLC
> Fort Collins,CO
> www.mathegraphics.com
> bennett78@digis.net
>
>
>
>>
>> I have a situation using a custom JTAG interface that is looking to
>> impliment host side PPC debugging. JTAG access and manipulation of most
>> all other JTAG devices on the target is working.
>> Right now the problem is deciphering the JTAG commands etc to the
>> PPC itself.
>>
>>
>>
>> Ria Roy wrote:
>>
>>> Hi,
>>>
>>> Does anyone know if Macriagor's mpDemon is capable of debugging the
>>> linux kernel via the JTAG interface.
>>>
>>> Thanks in advance,
>>> Ria
>>>
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>> --
>> Dave Lynch DLA Systems
>> Software Development: Embedded Linux
>> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
>> fax: 1.253.369.9244 Cell: 1.717.587.7774
>> Over 25 years' experience in platforms, languages, and technologies too
>> numerous to list.
>>
>> "Any intelligent fool can make things bigger and more complex... It takes a
>> touch of genius - and a lot of courage to move in the opposite direction."
>> Albert Einstein
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
>
>
> -------------------------------------------------------
> Email sent through Digis Networks http://www.digis.net/
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 5531 bytes --]
^ 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