* Re: 8272ADS and Linux 2.6.12
From: Allen Curtis @ 2005-07-15 3:05 UTC (permalink / raw)
To: SIP COP 009; +Cc: linuxppc-embedded
In-Reply-To: <5a4792c0050714120571fff071@mail.gmail.com>
> => setenv bootargs console=ttyCPM0,115200 root=/dev/ram
> => bootm fe600000
> ## Booting image at fe600000 ...
> Image Name: 2.6.12 for 8272
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 875845 Bytes = 855.3 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
Can you provide your kernel configuration information regarding the
serial ports. Which serial port is your console port? Check the
following configuration options:
CONFIG_SERIAL_CONSOLE
CONFIG_SCC_CONSOLE
CONFIG_SERIAL_CORE
CONFIG_SERIAL_CORE_CONSOLE
Another observation is that you are trying to boot with a RAM disk but
you have not provided the RAM disk address to the bootm command. This
is not your current problem since you don't get that far.
- Allen
^ permalink raw reply
* [PATCH] I2C-MPC: Restore code removed
From: Kumar Gala @ 2005-07-15 2:58 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linuxppc-embedded
Greg,
If we can get this to Linus before 2.6.13 is released that would be a good
thing.
I2C-MPC: Restore code removed
A previous patch to remove support for the OCP device model was way
to generious and moved some of the platform device model code, oops.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 0a224850142b1169b5a67735e51268057d24b833
tree fd8ba3598b6ba6585e2dd90c2d53138d7e6c7d17
parent 1eccf76f7b943d1e4b722c7f0847876127cad8b7
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 14 Jul 2005 21:41:36 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 14 Jul 2005 21:41:36 -0500
drivers/i2c/busses/i2c-mpc.c | 94 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -288,6 +288,100 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
+static int fsl_i2c_probe(struct device *device)
+{
+ int result = 0;
+ struct mpc_i2c *i2c;
+ struct platform_device *pdev = to_platform_device(device);
+ struct fsl_i2c_platform_data *pdata;
+ struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
+
+ if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
+ return -ENOMEM;
+ }
+ memset(i2c, 0, sizeof(*i2c));
+
+ i2c->irq = platform_get_irq(pdev, 0);
+ i2c->flags = pdata->device_flags;
+ init_waitqueue_head(&i2c->queue);
+
+ i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
+
+ if (!i2c->base) {
+ printk(KERN_ERR "i2c-mpc - failed to map controller\n");
+ result = -ENOMEM;
+ goto fail_map;
+ }
+
+ if (i2c->irq != 0)
+ if ((result = request_irq(i2c->irq, mpc_i2c_isr,
+ SA_SHIRQ, "i2c-mpc", i2c)) < 0) {
+ printk(KERN_ERR
+ "i2c-mpc - failed to attach interrupt\n");
+ goto fail_irq;
+ }
+
+ mpc_i2c_setclock(i2c);
+ dev_set_drvdata(device, i2c);
+
+ i2c->adap = mpc_ops;
+ i2c_set_adapdata(&i2c->adap, i2c);
+ i2c->adap.dev.parent = &pdev->dev;
+ if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
+ printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
+ goto fail_add;
+ }
+
+ return result;
+
+ fail_add:
+ if (i2c->irq != 0)
+ free_irq(i2c->irq, NULL);
+ fail_irq:
+ iounmap(i2c->base);
+ fail_map:
+ kfree(i2c);
+ return result;
+};
+
+static int fsl_i2c_remove(struct device *device)
+{
+ struct mpc_i2c *i2c = dev_get_drvdata(device);
+
+ i2c_del_adapter(&i2c->adap);
+ dev_set_drvdata(device, NULL);
+
+ if (i2c->irq != 0)
+ free_irq(i2c->irq, i2c);
+
+ iounmap(i2c->base);
+ kfree(i2c);
+ return 0;
+};
+
+/* Structure for a device driver */
+static struct device_driver fsl_i2c_driver = {
+ .name = "fsl-i2c",
+ .bus = &platform_bus_type,
+ .probe = fsl_i2c_probe,
+ .remove = fsl_i2c_remove,
+};
+
+static int __init fsl_i2c_init(void)
+{
+ return driver_register(&fsl_i2c_driver);
+}
+
+static void __exit fsl_i2c_exit(void)
+{
+ driver_unregister(&fsl_i2c_driver);
+}
+
+module_init(fsl_i2c_init);
+module_exit(fsl_i2c_exit);
+
MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
MODULE_DESCRIPTION
("I2C-Bus adapter for MPC107 bridge and MPC824x/85xx/52xx processors");
^ permalink raw reply
* problems on isp1362 driver
From: David Zhang @ 2005-07-15 0:14 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 283 bytes --]
Hi all,
We are using Philips ISP1362 USB controller on WinCE 4.2. It seems that we
are encountering "ATL interrupt" missing problem. I am wondering if any of
you ever had the similar problem.
Any suggestions how to solve the problem? Thanks a lot in advance.
David Zhang
[-- Attachment #2: Type: text/html, Size: 1073 bytes --]
^ permalink raw reply
* Re: ptrace on linux 2.6.12 causes oops
From: Marcelo Tosatti @ 2005-07-14 11:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc-embedded
In-Reply-To: <EA68D741-EF23-461C-9ECB-49BB0D24367D@freescale.com>
On Thu, Jul 14, 2005 at 08:31:50AM -0500, Kumar Gala wrote:
> What system is this on?
Thats 8xx (Anton told me on IRC earlier)...
^ permalink raw reply
* Re: ptrace on linux 2.6.12 causes oops
From: Marcelo Tosatti @ 2005-07-14 11:19 UTC (permalink / raw)
To: aris; +Cc: linux-ppc-embedded
In-Reply-To: <20050714202715.GS19321@oops.ghostprotocols.net>
On Thu, Jul 14, 2005 at 05:27:15PM -0300, aris@conectiva.com.br wrote:
> > when i try to run strace or gdbserver on a program, the following comes:
> >
> > NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
> > LR [c000b060] flush_dcache_icache_page+0x20/0x30
> > Call trace:
> > [c000b154] update_mmu_cache+0x7c/0xa4
> > [c005ae98] do_wp_page+0x460/0x5ec
> > [c005c8a0] handle_mm_fault+0x7cc/0x91c
> > [c005ccec] get_user_pages+0x2fc/0x65c
> > [c0027104] access_process_vm+0x9c/0x1d4
> > [c00076e0] sys_ptrace+0x240/0x4a4
> > [c0002bd0] ret_from_syscall+0x0/0x44
> > mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
> > mm/memory.c/1306
> please try to reproduce with 2.6.13-rc2. seems much like the problem Marcelo
> fixed recently (dcbst misbehaviour with unpopulated TLB entries)
Yep, just that now its the ptraceing process which is faulting in the page,
instead of the (ptraced) process itself.
So Anton, can you move the _tlbie() call up to
&& !test_bit(PG_arch_1, &page->flags)) {
<---------- HERE
if (vma->vm_mm == current->active_mm)
__flush_dcache_icache((void *) address);
else
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
So that it covers both cases instead of just (vma->vm_mm == current->active_mm) ?
Its safe to do it because the address space ID is ignored by tlbie accordingly
to the manual page:
The ASID value in the entry is ignored for the purpose of
matching an invalidate address, thus multiple entries can be invalidated
if they have the same effective address and different ASID values.
^ permalink raw reply
* Re: Using lswi/stswi inside the kernel
From: Segher Boessenkool @ 2005-07-14 20:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E6D8678E-33FD-492F-A773-12B0F87C2EBB@freescale.com>
> Yes, not all PowerPC implementations actually implement this
> instructions. Also, on a number of them there is no performance
> improvement when using the instructions.
Read: severe performance degradation ;-)
Segher
^ permalink raw reply
* Re: ptrace on linux 2.6.12 causes oops
From: aris @ 2005-07-14 20:27 UTC (permalink / raw)
To: Anton Wöllert; +Cc: linux-ppc-embedded
In-Reply-To: <faba7798050714012370af5e74@mail.gmail.com>
> when i try to run strace or gdbserver on a program, the following comes:
>
> NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
> LR [c000b060] flush_dcache_icache_page+0x20/0x30
> Call trace:
> [c000b154] update_mmu_cache+0x7c/0xa4
> [c005ae98] do_wp_page+0x460/0x5ec
> [c005c8a0] handle_mm_fault+0x7cc/0x91c
> [c005ccec] get_user_pages+0x2fc/0x65c
> [c0027104] access_process_vm+0x9c/0x1d4
> [c00076e0] sys_ptrace+0x240/0x4a4
> [c0002bd0] ret_from_syscall+0x0/0x44
> mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
> mm/memory.c/1306
please try to reproduce with 2.6.13-rc2. seems much like the problem Marcelo
fixed recently (dcbst misbehaviour with unpopulated TLB entries)
--
Aristeu
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: Jon Loeliger @ 2005-07-14 20:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20050712040623.GG3945@localhost.localdomain>
On Mon, 2005-07-11 at 23:06, David Gibson wrote:
> On Mon, Jul 11, 2005 at 04:22:30PM -0500, Jon Loeliger wrote:
> > On Sun, 2005-07-10 at 23:55, David Gibson wrote:
> > > On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
> [snip]
> > > Biggest thing is that rather than passing the tree itself and the
> > > memreserve info about as two parameters all over the place, I'd rather
> > > create a new structure which has both (and later can have anything
> > > else that might be needed).
> >
> > If you'd like, I'll do this work.
>
> That would be helpful. You'll need to rediff, though, I merged a
> couple of bugfixes from your patch that weren't directly related to
> the memreserve stuff.
David,
Here is an updated version of the patch that obsoletes
the previous one I submitted. I have incorporated all
of your syntactic suggestions except not using the
split-64 values (ie, this still uses 'struct data').
It primarily merges in the changes that you adopted
from earlier and implements a new structure at the
base of the parse tree to hold both the device tree
and the header information. I called that new stucuture
'struct header_tree'. Feel free to dream up something
better. :-)
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Thanks,
jdl
diff --git a/dtc-lexer.l b/dtc-lexer.l
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -87,6 +87,11 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
return ']';
}
+"/memreserve/" {
+ DPRINT("Keyword: /memreserve/\n");
+ return DT_MEMRESERVE;
+ }
+
{PROPCHAR}+ {
DPRINT("PropName: %s\n", yytext);
yylval.str = strdup(yytext);
diff --git a/dtc-parser.y b/dtc-parser.y
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -24,8 +24,6 @@
int yylex (void);
void yyerror (char const *);
-extern struct node *device_tree;
-
%}
%union {
@@ -41,6 +39,7 @@ extern struct node *device_tree;
int hexlen;
}
+%token DT_MEMRESERVE
%token <str> DT_PROPNAME
%token <str> DT_NODENAME
%token <cval> DT_CELL
@@ -51,11 +50,13 @@ extern struct node *device_tree;
%token <str> DT_REF
%type <data> propdata
+%type <data> headersection
%type <data> celllist
%type <data> bytestring
%type <prop> propdef
%type <proplist> proplist
+%type <node> devicetree
%type <node> nodedef
%type <node> subnode
%type <nodelist> subnodes
@@ -66,9 +67,29 @@ extern struct node *device_tree;
%%
-devicetree: {
- assert(device_tree == NULL);
- } '/' nodedef { device_tree = name_node($3, "", NULL); }
+sourcefile:
+ headersection
+ devicetree
+ {
+ build_header_tree($1, $2);
+ }
+ ;
+
+headersection:
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | DT_MEMRESERVE '=' '<' celllist '>' ';'
+ {
+ $$ = build_mem_reserve($4);
+ }
+ ;
+
+devicetree: '/' nodedef
+ {
+ $$ = name_node($2, "", NULL);
+ }
;
nodedef: '{' proplist subnodes '}' ';' {
diff --git a/dtc.c b/dtc.c
--- a/dtc.c
+++ b/dtc.c
@@ -102,7 +102,7 @@ static void usage(void)
int main(int argc, char *argv[])
{
- struct node *dt;
+ struct header_tree *ht;
char *inform = "dts";
char *outform = "dts";
char *outname = "-";
@@ -151,12 +151,12 @@ int main(int argc, char *argv[])
if (streq(inform, "dts")) {
inf = dtc_open_file(arg);
- dt = dt_from_source(inf);
+ ht = dt_from_source(inf);
} else if (streq(inform, "fs")) {
- dt = dt_from_fs(arg);
+ ht = dt_from_fs(arg);
} else if(streq(inform, "dtb")) {
inf = dtc_open_file(arg);
- dt = dt_from_blob(inf);
+ ht = dt_from_blob(inf);
} else {
die("Unknown input format \"%s\"\n", inform);
}
@@ -164,10 +164,10 @@ int main(int argc, char *argv[])
if (inf && (inf != stdin))
fclose(inf);
- if (! dt)
+ if (! ht || ! ht->root)
die("Couldn't read input tree\n");
- if (! check_device_tree(dt)) {
+ if (! check_device_tree(ht->root)) {
fprintf(stderr, "Input tree has errors\n");
if (! force)
exit(1);
@@ -183,11 +183,11 @@ int main(int argc, char *argv[])
}
if (streq(outform, "dts")) {
- write_tree_source(outf, dt, 0);
+ write_tree_source(outf, ht);
} else if (streq(outform, "dtb")) {
- write_dt_blob(outf, dt, outversion, reservenum);
+ write_dt_blob(outf, ht, outversion);
} else if (streq(outform, "asm")) {
- write_dt_asm(outf, dt, outversion, reservenum);
+ write_dt_asm(outf, ht, outversion);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
diff --git a/dtc.h b/dtc.h
--- a/dtc.h
+++ b/dtc.h
@@ -118,6 +118,24 @@ struct data data_add_fixup(struct data d
int data_is_one_string(struct data d);
+struct data build_mem_reserve(struct data d);
+
+
+/*
+ * Combined Header and Tree information.
+ */
+struct header_tree {
+ struct data mem_reserve_data; /* mem reserve from header */
+ struct node *root; /* root of the device tree */
+};
+
+struct header_tree *alloc_header_tree(struct data mem_reserve_data,
+ struct node *tree);
+
+void build_header_tree(struct data mem_reserve_data,
+ struct node *tree);
+
+
/* DT constraints */
#define MAX_PROPNAME_LEN 31
@@ -175,20 +193,19 @@ enum flat_dt_format {
FFMT_ASM,
};
-void write_dt_blob(FILE *f, struct node *tree, int version, int reservenum);
-void write_dt_asm(FILE *f, struct node *tree, int version, int reservenum);
+void write_dt_blob(FILE *f, struct header_tree *ht, int version);
+void write_dt_asm(FILE *f, struct header_tree *ht, int version);
-struct node *dt_from_blob(FILE *f);
+struct header_tree *dt_from_blob(FILE *f);
/* Tree source */
-void write_tree_source(FILE *f, struct node *tree, int level);
-
-struct node *dt_from_source(FILE *f);
+void write_tree_source(FILE *f, struct header_tree *ht);
+struct header_tree *dt_from_source(FILE *f);
/* FS trees */
-struct node *dt_from_fs(char *dirname);
+struct header_tree *dt_from_fs(char *dirname);
/* misc */
diff --git a/flattree.c b/flattree.c
--- a/flattree.c
+++ b/flattree.c
@@ -287,11 +287,12 @@ static void flatten_tree(struct node *tr
}
static void make_bph(struct boot_param_header *bph,
- struct version_info *vi,
- int reservenum,
- int dtsize, int strsize)
+ struct version_info *vi,
+ struct data *mem_reserve_data,
+ int dtsize, int strsize)
{
int reserve_off;
+ int reservenum = mem_reserve_data->len / sizeof(struct reserve_entry);
int reservesize = (reservenum+1) * sizeof(struct reserve_entry);
memset(bph, 0xff, sizeof(*bph));
@@ -316,7 +317,7 @@ static void make_bph(struct boot_param_h
bph->size_dt_strings = cpu_to_be32(strsize);
}
-void write_dt_blob(FILE *f, struct node *tree, int version, int reservenum)
+void write_dt_blob(FILE *f, struct header_tree *ht, int version)
{
struct version_info *vi = NULL;
int i;
@@ -335,18 +336,31 @@ void write_dt_blob(FILE *f, struct node
dtbuf = empty_data;
strbuf = empty_data;
- flatten_tree(tree, &bin_emitter, &dtbuf, &strbuf, vi);
+ flatten_tree(ht->root, &bin_emitter, &dtbuf, &strbuf, vi);
bin_emit_cell(&dtbuf, OF_DT_END);
- make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
+ /*
+ * Make header.
+ */
+ make_bph(&bph, vi, &ht->mem_reserve_data, dtbuf.len, strbuf.len);
+
+ fwrite(&bph, vi->hdr_size, 1, f);
/* Align the reserve map to an 8 byte boundary */
for (i = vi->hdr_size; i < be32_to_cpu(bph.off_mem_rsvmap); i++)
fputc(0, f);
- fwrite(&bph, vi->hdr_size, 1, f);
- for (i = 0; i < reservenum+1; i++)
- fwrite(&re, sizeof(re), 1, f);
+ /*
+ * Reserve map entries.
+ * Since the blob is relocatable, the address of the map is not
+ * determinable here, so no entry is made for the DT itself.
+ * Each entry is an (address, size) pair of u64 values.
+ * Always supply a zero-sized temination entry.
+ */
+ fwrite(ht->mem_reserve_data.val, ht->mem_reserve_data.len, 1, f);
+ re.address = 0;
+ re.size = 0;
+ fwrite(&re, sizeof(re), 1, f);
fwrite(dtbuf.val, dtbuf.len, 1, f);
fwrite(strbuf.val, strbuf.len, 1, f);
@@ -372,7 +386,7 @@ void dump_stringtable_asm(FILE *f, struc
}
}
-void write_dt_asm(FILE *f, struct node *tree, int version, int reservenum)
+void write_dt_asm(FILE *f, struct header_tree *ht, int version)
{
struct version_info *vi = NULL;
int i;
@@ -416,20 +430,30 @@ void write_dt_asm(FILE *f, struct node *
fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/* size_dt_strings */\n",
symprefix, symprefix);
- /* align the reserve map to a doubleword boundary */
+ /*
+ * Reserve map entries.
+ * Align the reserve map to a doubleword boundary.
+ * Each entry is an (address, size) pair of u64 values.
+ * Since the ASM file variant can relocate and compute the address
+ * and size of the the device tree itself, and an entry for it.
+ * Always supply a zero-sized temination entry.
+ */
asm_emit_align(f, 8);
emit_label(f, symprefix, "reserve_map");
- /* reserve map entry for the device tree itself */
fprintf(f, "\t.long\t0, _%s_blob_start\n", symprefix);
fprintf(f, "\t.long\t0, _%s_blob_end - _%s_blob_start\n",
symprefix, symprefix);
- for (i = 0; i < reservenum+1; i++) {
- fprintf(f, "\t.llong\t0\n");
- fprintf(f, "\t.llong\t0\n");
+
+ if (ht->mem_reserve_data.len > 0) {
+ fprintf(f, "/* Memory reserve map from source file */\n");
+ asm_emit_data(f, ht->mem_reserve_data);
}
+ fprintf(f, "\t.llong\t0\n");
+ fprintf(f, "\t.llong\t0\n");
+
emit_label(f, symprefix, "struct_start");
- flatten_tree(tree, &asm_emitter, f, &strbuf, vi);
+ flatten_tree(ht->root, &asm_emitter, f, &strbuf, vi);
fprintf(f, "\t.long\tOF_DT_END\n");
emit_label(f, symprefix, "struct_end");
@@ -560,6 +584,43 @@ struct property *flat_read_property(stru
return build_property(name, val, NULL);
}
+
+static struct data flat_read_mem_reserve(struct inbuf *inb)
+{
+ char *p;
+ int len = 0;
+ int done = 0;
+ cell_t cells[4];
+ struct data d;
+
+ d = empty_data;
+
+ /*
+ * Each entry is a pair of u64 (addr, size) values for 4 cell_t's.
+ * List terminates at an entry with size equal to zero.
+ *
+ * First pass, count entries.
+ */
+ p = inb->ptr;
+ do {
+ flat_read_chunk(inb, &cells[0], 4 * sizeof(cell_t));
+ if (cells[2] == 0 && cells[3] == 0) {
+ done = 1;
+ } else {
+ ++len;
+ }
+ } while (!done);
+
+ /*
+ * Back up for pass two, reading the whole data value.
+ */
+ inb->ptr = p;
+ d = flat_read_data(inb, len * 4 * sizeof(cell_t));
+
+ return d;
+}
+
+
static char *nodename_from_path(char *ppath, char *cpath)
{
char *lslash;
@@ -667,16 +728,21 @@ static struct node *unflatten_tree(struc
return node;
}
-struct node *dt_from_blob(FILE *f)
+
+struct header_tree *dt_from_blob(FILE *f)
{
- u32 magic, totalsize, off_dt, off_str, version, size_str;
+ u32 magic, totalsize, version, size_str;
+ u32 off_dt, off_str, off_mem_rsvmap;
int rc;
char *blob;
struct boot_param_header *bph;
char *p;
struct inbuf dtbuf, strbuf;
+ struct inbuf memresvbuf;
int sizeleft;
+ struct data mem_reserve_data;
struct node *tree;
+ struct header_tree *ht;
u32 val;
int flags = 0;
@@ -734,18 +800,21 @@ struct node *dt_from_blob(FILE *f)
off_dt = be32_to_cpu(bph->off_dt_struct);
off_str = be32_to_cpu(bph->off_dt_strings);
+ off_mem_rsvmap = be32_to_cpu(bph->off_mem_rsvmap);
version = be32_to_cpu(bph->version);
fprintf(stderr, "\tmagic:\t\t\t0x%x\n", magic);
fprintf(stderr, "\ttotalsize:\t\t%d\n", totalsize);
fprintf(stderr, "\toff_dt_struct:\t\t0x%x\n", off_dt);
fprintf(stderr, "\toff_dt_strings:\t\t0x%x\n", off_str);
- fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n",
- be32_to_cpu(bph->off_mem_rsvmap));
+ fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n", off_mem_rsvmap);
fprintf(stderr, "\tversion:\t\t0x%x\n", version );
fprintf(stderr, "\tlast_comp_version:\t0x%x\n",
be32_to_cpu(bph->last_comp_version));
+ if (off_mem_rsvmap >= totalsize)
+ die("Mem Reserve structure offset exceeds total size\n");
+
if (off_dt >= totalsize)
die("DT structure offset exceeds total size\n");
@@ -767,12 +836,16 @@ struct node *dt_from_blob(FILE *f)
flags |= FTF_FULLPATH | FTF_NAMEPROPS | FTF_VARALIGN;
}
+ inbuf_init(&memresvbuf,
+ blob + off_mem_rsvmap, blob + totalsize);
inbuf_init(&dtbuf, blob + off_dt, blob + totalsize);
inbuf_init(&strbuf, blob + off_str, blob + totalsize);
if (version >= 3)
strbuf.limit = strbuf.base + size_str;
+ mem_reserve_data = flat_read_mem_reserve(&memresvbuf);
+
val = flat_read_word(&dtbuf);
if (val != OF_DT_BEGIN_NODE)
@@ -786,5 +859,7 @@ struct node *dt_from_blob(FILE *f)
free(blob);
- return tree;
+ ht = alloc_header_tree(mem_reserve_data, tree);
+
+ return ht;
}
diff --git a/fstree.c b/fstree.c
--- a/fstree.c
+++ b/fstree.c
@@ -80,8 +80,9 @@ static struct node *read_fstree(char *di
return tree;
}
-struct node *dt_from_fs(char *dirname)
+struct header_tree *dt_from_fs(char *dirname)
{
+ struct header_tree *ht;
struct node *tree;
tree = read_fstree(dirname);
@@ -89,6 +90,7 @@ struct node *dt_from_fs(char *dirname)
fill_fullpaths(tree, "");
- return tree;
+ ht = alloc_header_tree(empty_data, tree);
+ return ht;
}
diff --git a/treesource.c b/treesource.c
--- a/treesource.c
+++ b/treesource.c
@@ -20,20 +20,60 @@
#include "dtc.h"
-struct node *device_tree;
-
extern FILE *yyin;
extern int yyparse(void);
+extern void yyerror(char const *);
+
+static struct header_tree *the_header_tree;
+
+
+struct header_tree *alloc_header_tree(struct data mem_reserve_data,
+ struct node *tree)
+{
+ struct header_tree *ht;
+
+ ht = xmalloc(sizeof(*ht));
+ ht->root = tree;
+ ht->mem_reserve_data = mem_reserve_data;
+
+ return ht;
+}
+
-struct node *dt_from_source(FILE *f)
+void build_header_tree(struct data mem_reserve_data,
+ struct node *tree)
{
+ struct header_tree *ht;
+
+ ht = alloc_header_tree(mem_reserve_data, tree);
+
+ the_header_tree = ht;
+}
+
+
+struct data build_mem_reserve(struct data d)
+{
+ /*
+ * FIXME: Should reconcile the -R parameter here now?
+ */
+ if (d.len % 16 != 0) {
+ yyerror("Memory Reserve entries are <u64 addr, u64 size>\n");
+ }
+ return d;
+}
+
+
+struct header_tree *dt_from_source(FILE *f)
+{
+ the_header_tree = NULL;
+
yyin = f;
if (yyparse() != 0)
return NULL;
- fill_fullpaths(device_tree, "");
+ fill_fullpaths(the_header_tree->root, "");
- return device_tree;
+ return the_header_tree;
}
static void write_prefix(FILE *f, int level)
@@ -75,7 +115,8 @@ static enum proptype guess_type(struct p
}
-void write_tree_source(FILE *f, struct node *tree, int level)
+
+void write_tree_source_node(FILE *f, struct node *tree, int level)
{
struct property *prop;
struct node *child;
@@ -133,8 +174,39 @@ void write_tree_source(FILE *f, struct n
}
for_each_child(tree, child) {
fprintf(f, "\n");
- write_tree_source(f, child, level+1);
+ write_tree_source_node(f, child, level+1);
}
write_prefix(f, level);
fprintf(f, "};\n");
}
+
+
+void write_tree_source(FILE *f, struct header_tree *ht)
+{
+ int i;
+ int ncells;
+ cell_t *cp;
+
+ if (ht->mem_reserve_data.len > 0) {
+ fprintf(f, "/memreserve/ =\t<\n");
+ cp = (cell_t *)ht->mem_reserve_data.val;
+ ncells = ht->mem_reserve_data.len / sizeof(cell_t);
+ for (i = 0; i < ncells; i++) {
+ if (i % 4 == 0) {
+ fprintf(f, "\t\t\t");
+ }
+ fprintf(f, "%x", be32_to_cpu(*cp++));
+ if (i % 4 == 1) {
+ fprintf(f, " ");
+ } else if (i % 4 == 3) {
+ fprintf(f, "\n");
+ } else {
+ fprintf(f, " ");
+ }
+ }
+ fprintf(f, "\t\t>;\n\n");
+ }
+
+ write_tree_source_node(f, ht->root, 0);
+}
+
^ permalink raw reply
* Re: 8272ADS and Linux 2.6.12
From: SIP COP 009 @ 2005-07-14 19:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <E65A8A95-7352-40A3-9A86-EF437F0132D0@freescale.com>
Kumar,
Thanks for u'r reply. I tried it but it does not seem to work.
Here's my uboot info...
U-Boot 1.1.1 (Oct 29 2004 - 18:28:57)
MPC8272 Reset Status: External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300
- dfbrg 1, corecnf 0x0a, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 13, Mask 0.0 0K50M) at 400 MHz
Board: Motorola MPC8272ADS
DRAM: 64 MB
Now running in RAM - U-Boot at: 03fc4000
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: FCC1 ETHERNET
Hit any key to stop autoboot: 0=20
=3D> setenv bootargs console=3DttyCPM0,115200 root=3D/dev/ram
=3D> bootm fe600000
## Booting image at fe600000 ...
Image Name: 2.6.12 for 8272
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 875845 Bytes =3D 855.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Hang here...
Anymore thots and pointers ?
Thanks!
ashutosh
On 7/14/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> You may need to check the bootargs to insure that console=3DttyCPM0
>=20
> - kumar
>=20
> On Jul 14, 2005, at 1:55 AM, SIP COP 009 wrote:
>=20
> > Hello,
> >
> > We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We
> > wanted to move to 2.6. I downloaded the latest 2.6.12 sources and
> > compiled the sources for this platform. The kernel is built, have run
> > the mkimage tool, but the kernel wont boot. It just hangs after
> > decompressing the image.
> >
> > Any ideas ? Anything different that needs to be done for 2.6 ? Or any
> > known issues ?
> >
> > Thanks!
> > ashutosh
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>=20
>
^ permalink raw reply
* ptrace on linux 2.6.12 causes oops
From: Anton Wöllert @ 2005-07-14 15:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <faba77980507140809ad923db@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
it's on a tqm850l with mpc850. i've done the following:
in update_mmu_cache:
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
// if (vma->vm_mm == current->active_mm){
// _tlbie(address);
// __flush_dcache_icache((void *) address);
// } else
__flush_dcache_icache(page _address(page));
// flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
}
like it is in ppc64. now it works. the flush_dcache_icache_page calls
__flush_dcache_icache_phys, which temporary turns off the mmu for
data-addressing. a bit strange i think. but unfortunately i have too less
knowledge about kernel-internal ppc-stuff :(
anton
[-- Attachment #2: Type: text/html, Size: 2401 bytes --]
^ permalink raw reply
* Re: MPC5200 Rev B Deep Sleep Mode
From: Grant Likely @ 2005-07-14 14:55 UTC (permalink / raw)
To: Susheel Raj; +Cc: linuxppc-embedded
In-Reply-To: <20050714083427.64168.qmail@web8508.mail.in.yahoo.com>
On 7/14/05, Susheel Raj <susheel_nuguru@yahoo.co.in> wrote:
> Hi all,
>=20
> I am new to my job and needs help from you. I have
> to make this new core into Deep Sleep Mode where all
> the periperals and most of the clock oscilaltors are
> shut down for power saving and the core can be waked
> using one asyncronous external interrupt.
>=20
> Does anyone have any idea if the previous version of
> this core (MPC5200) has this service. Any sort of
> suggetions, guidelines or redirections would be of
> great help and would be appreciated.
>=20
General questions about chips are off topic on this list. You can
easily ask Freescale support this question. (Open a support ticket)
http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=3D05
g.
^ permalink raw reply
* mpc8xx and ld.so problem
From: Joakim Tjernlund @ 2005-07-14 13:32 UTC (permalink / raw)
To: linuxppc-embedded
Theo Gjaltema wrote:
> Has anyone an idea why only this large application failed? busybox_1.0
> and more applications work fine.
> system is a: mcp862/32Mb SDRAM started from u-boot 0.4.1,
> kernel enhanced with atm/utopia driver.
I think you hit this bug that was fixed a while ago.
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016490.html
^ permalink raw reply
* Re: ptrace on linux 2.6.12 causes oops
From: Kumar Gala @ 2005-07-14 13:31 UTC (permalink / raw)
To: Anton Wöllert; +Cc: linux-ppc-embedded
In-Reply-To: <faba7798050714012370af5e74@mail.gmail.com>
What system is this on?
- kumar
On Jul 14, 2005, at 3:23 AM, Anton W=F6llert wrote:
> Hello
>
> when i try to run strace or gdbserver on a program, the following =20
> comes:
>
> Oops: kernel access of bad area, sig: 11 [#2]
> NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: =20
> 0300 Not tainted
> MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
> DAR: 00000010, DSISR: C2000000
> TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
> Last syscall: 26
> GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF =20
> 00F58000 00000001
> GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 =20
> 01000800 00000001
> GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 =20
> C0839300 C01E0000
> GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 =20
> C02ACB00 C02ACB00
> NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
> LR [c000b060] flush_dcache_icache_page+0x20/0x30
> Call trace:
> [c000b154] update_mmu_cache+0x7c/0xa4
> [c005ae98] do_wp_page+0x460/0x5ec
> [c005c8a0] handle_mm_fault+0x7cc/0x91c
> [c005ccec] get_user_pages+0x2fc/0x65c
> [c0027104] access_process_vm+0x9c/0x1d4
> [c00076e0] sys_ptrace+0x240/0x4a4
> [c0002bd0] ret_from_syscall+0x0/0x44
> mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked =20
> by mm/memory.c/1306
>
> and strace or gdbserver of course says segmentation fault. with =20
> gdbserver, this happens every time. with strace, the first time it =20
> works nearly all time, but when i strace a second time program =20
> again, it segfaults. i think the access_process_vm is accessed =20
> trough PEEKDATA and PEEKTEXT in sys_ptrace. so here some more =20
> debug :) :
>
> DEBUG: peekdata @ 1006d4ec
> DEBUG: peektext @ 1006d4f0
> DEBUG: peekdata @ 1006d4f0
> DEBUG: peektext @ 1006d4f4
> DEBUG: peekdata @ 1006d4f4
> DEBUG: peektext @ 1006d4f8
> DEBUG: peekdata @ 1006d4f8
> DEBUG: peektext @ 1006d4fc
> DEBUG: peekdata @ 1006d4fc
> DEBUG: peektext @ 1006d500
> DEBUG: peekdata @ 1006d500
> DEBUG: peektext @ 1006d504
> DEBUG: peekdata @ 1006d504
> DEBUG: peektext @ 1006d508
> DEBUG: peekdata @ 1006d508
> DEBUG: peektext @ 1006d50c
> DEBUG: peekdata @ 1006d50c
> DEBUG: peektext @ 1006d510
> DEBUG: peekdata @ 1006d510
> DEBUG: peektext @ 1006d514
> DEBUG: peekdata @ 1006d514
> DEBUG: peektext @ 1006d518
> DEBUG: peekdata @ 1006d518
> DEBUG: peektext @ 1006d51c
> DEBUG: peekdata @ 1006d51c
> DEBUG: peektext @ 1006d520
> DEBUG: peekdata @ 1006d520
> DEBUG: peektext @ 1006d524
> DEBUG: peekdata @ 1006d524
> DEBUG: peektext @ 1006d528
> DEBUG: peekdata @ 1006d528
> DEBUG: peektext @ 1006d52c
> DEBUG: peekdata @ 1006d52c
> DEBUG: peektext @ 00000000
> DEBUG: peekdata @ 00000000
> DEBUG: peektext @ 3000ac18
> DEBUG: peekdata @ 3000ac18
> DEBUG: peektext @ 3000ac18
> DEBUG: peekdata @ 3000ac18
> DEBUG: flush_dcache_icache_page
> Oops: kernel access of bad area, sig: 11 [#2]
> NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: =20
> 0300 Not tainted
> MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
> DAR: 00000010, DSISR: C2000000
> TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
> Last syscall: 26
> GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF =20
> 00F58000 00000001
> GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 =20
> 01000800 00000001
> GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 =20
> C0839300 C01E0000
> GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 =20
> C02ACB00 C02ACB00
> NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
> LR [c000b060] flush_dcache_icache_page+0x20/0x30
> Call trace:
> [c000b154] update_mmu_cache+0x7c/0xa4
> [c005ae98] do_wp_page+0x460/0x5ec
> [c005c8a0] handle_mm_fault+0x7cc/0x91c
> [c005ccec] get_user_pages+0x2fc/0x65c
> [c0027104] access_process_vm+0x9c/0x1d4
> [c00076e0] sys_ptrace+0x240/0x4a4
> [c0002bd0] ret_from_syscall+0x0/0x44
> mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked =20
> by mm/memory.c/1306
>
>
>
>
> <ATT11632593.txt>
>
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: Segher Boessenkool @ 2005-07-14 13:29 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20050714010246.GC15769@sneetch.ozlabs.ibm.com>
> My mistake, I misunderstood the terminology. But the basic point is
> that lots of things in the kernel already assume a cell is 32-bits, so
> it would be silly to try and change that here. This is not true for
> the memreserve values.
Of course you should use 32-bit values; but please just don't call it
a cell, there's nothing more confusing than messing up terminology.
>> Btw -- beware of the fact that such an "int" does _not_ have any
>> alignment restrictions -- so you better read it byte by byte...
>
> Erm.. in what context. dtc never reads ints from the blob format as
> ints - properties are just byte strings to it. At present you can't
> mix cell input format with other sorts, which means the ints must, in
> fact, be aligned, since properties are.
When reading integers from properties that have been created by an OF
implementation. Whether this is a problem for DTC or not, I don't know;
I just thought I'd mention the problem to you, people fall in that trap
again and again.
Segher
^ permalink raw reply
* Re: 8272ADS and Linux 2.6.12
From: Kumar Gala @ 2005-07-14 13:25 UTC (permalink / raw)
To: SIP COP 009; +Cc: linuxppc-embedded
In-Reply-To: <5a4792c0050713235574522cfb@mail.gmail.com>
You may need to check the bootargs to insure that console=ttyCPM0
- kumar
On Jul 14, 2005, at 1:55 AM, SIP COP 009 wrote:
> Hello,
>
> We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We
> wanted to move to 2.6. I downloaded the latest 2.6.12 sources and
> compiled the sources for this platform. The kernel is built, have run
> the mkimage tool, but the kernel wont boot. It just hangs after
> decompressing the image.
>
> Any ideas ? Anything different that needs to be done for 2.6 ? Or any
> known issues ?
>
> Thanks!
> ashutosh
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Using lswi/stswi inside the kernel
From: Kumar Gala @ 2005-07-14 13:24 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: linuxppc-dev
In-Reply-To: <20050714125232.GA13456@janus>
Yes, not all PowerPC implementations actually implement this
instructions. Also, on a number of them there is no performance
improvement when using the instructions.
- kumar
On Jul 14, 2005, at 7:52 AM, Frank van Maarseveen wrote:
> Are there any issues I should be aware of?
>
> I think most SAVE_GPR* and REST_GPR* macros could be replaced by a
> single lswi/stswi instruction.
>
> --
> Frank
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Using lswi/stswi inside the kernel
From: Frank van Maarseveen @ 2005-07-14 12:52 UTC (permalink / raw)
To: linuxppc-dev
Are there any issues I should be aware of?
I think most SAVE_GPR* and REST_GPR* macros could be replaced by a
single lswi/stswi instruction.
--
Frank
^ permalink raw reply
* Porting Linux on radstone ppc7a board
From: smiling_23 @ 2005-07-14 12:22 UTC (permalink / raw)
To: linuxppc-embedded
HI to all,
I am studying the Manuals related ppc7a,I have to write board
setup code . How to write board setup code, What are the basic things i have
to consider for writing it. If there are any articles related to this topic
please give me the links.
With thnks and regards,
cjag
^ permalink raw reply
* MPC5200 Rev B Deep Sleep Mode
From: Susheel Raj @ 2005-07-14 8:34 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am new to my job and needs help from you. I have
to make this new core into Deep Sleep Mode where all
the periperals and most of the clock oscilaltors are
shut down for power saving and the core can be waked
using one asyncronous external interrupt.
Does anyone have any idea if the previous version of
this core (MPC5200) has this service. Any sort of
suggetions, guidelines or redirections would be of
great help and would be appreciated.
I hope atleast few of them kind enough to reply me back.
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* ptrace on linux 2.6.12 causes oops
From: Anton Wöllert @ 2005-07-14 8:23 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050701101713.GC11121@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]
Hello
when i try to run strace or gdbserver on a program, the following comes:
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
mm/memory.c/1306
and strace or gdbserver of course says segmentation fault. with gdbserver,
this happens every time. with strace, the first time it works nearly all
time, but when i strace a second time program again, it segfaults. i think
the access_process_vm is accessed trough PEEKDATA and PEEKTEXT in
sys_ptrace. so here some more debug :) :
DEBUG: peekdata @ 1006d4ec
DEBUG: peektext @ 1006d4f0
DEBUG: peekdata @ 1006d4f0
DEBUG: peektext @ 1006d4f4
DEBUG: peekdata @ 1006d4f4
DEBUG: peektext @ 1006d4f8
DEBUG: peekdata @ 1006d4f8
DEBUG: peektext @ 1006d4fc
DEBUG: peekdata @ 1006d4fc
DEBUG: peektext @ 1006d500
DEBUG: peekdata @ 1006d500
DEBUG: peektext @ 1006d504
DEBUG: peekdata @ 1006d504
DEBUG: peektext @ 1006d508
DEBUG: peekdata @ 1006d508
DEBUG: peektext @ 1006d50c
DEBUG: peekdata @ 1006d50c
DEBUG: peektext @ 1006d510
DEBUG: peekdata @ 1006d510
DEBUG: peektext @ 1006d514
DEBUG: peekdata @ 1006d514
DEBUG: peektext @ 1006d518
DEBUG: peekdata @ 1006d518
DEBUG: peektext @ 1006d51c
DEBUG: peekdata @ 1006d51c
DEBUG: peektext @ 1006d520
DEBUG: peekdata @ 1006d520
DEBUG: peektext @ 1006d524
DEBUG: peekdata @ 1006d524
DEBUG: peektext @ 1006d528
DEBUG: peekdata @ 1006d528
DEBUG: peektext @ 1006d52c
DEBUG: peekdata @ 1006d52c
DEBUG: peektext @ 00000000
DEBUG: peekdata @ 00000000
DEBUG: peektext @ 3000ac18
DEBUG: peekdata @ 3000ac18
DEBUG: peektext @ 3000ac18
DEBUG: peekdata @ 3000ac18
DEBUG: flush_dcache_icache_page
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
mm/memory.c/1306
[-- Attachment #2: Type: text/html, Size: 4221 bytes --]
^ permalink raw reply
* Help required Porting Linux on radstone PPC7a
From: smiling_23 @ 2005-07-14 7:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
I am trying to port Linux kenel 2.6.12 on Radstone PPC7a board. I am new
to this board. If any one is working on this board help me in porting linux.
Thanks and regards,
cjag
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: Pantelis Antoniou @ 2005-07-14 7:15 UTC (permalink / raw)
To: ming lei; +Cc: linuxppc-embedded
In-Reply-To: <20050714015703.34280.qmail@web61015.mail.yahoo.com>
ming lei wrote:
> Dan,
>
> No one intents to make memory corruption in kernel
> space but it happens sometimes.
>
> Say I have a global var in my kernel module which
> called test-mod, it picks up a physical page allocated
> by some code with kmalloc and later kfreed(suppose
> when it does, the whole page gets freed). But then
> this code forgets a pointer(which maped to this
> physical page) already freed and modifies the pointer,
> the write gets thru since that virt address's PTE
> still valid and points to the physical page currently
> used by test-mod. So the memory corruption happens.
>
> Maybe I miss something in the linux kernel code that
> prevents this double PTE thing.
>
> Ming
>
If you want to guard against stuff like this you have
some options...
1) Run different services on the same cpu on a a hypervisor
like Xen.
2) Run most of the module's code in user space, and keep
kernel space code to a minimum.
3) Use QNX.
Regards
Pantelis
^ permalink raw reply
* 8272ADS and Linux 2.6.12
From: SIP COP 009 @ 2005-07-14 6:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We
wanted to move to 2.6. I downloaded the latest 2.6.12 sources and
compiled the sources for this platform. The kernel is built, have run
the mkimage tool, but the kernel wont boot. It just hangs after
decompressing the image.
Any ideas ? Anything different that needs to be done for 2.6 ? Or any
known issues ?
Thanks!
ashutosh
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Anton Wöllert @ 2005-07-14 5:44 UTC (permalink / raw)
To: Theo Gjaltema, linuxppc-embedded
In-Reply-To: <42D5361B.2070402@chello.nl>
Theo Gjaltema wrote:
> Has anyone an idea why only this large application failed? busybox_1.0
> and more applications work fine.
> system is a: mcp862/32Mb SDRAM started from u-boot 0.4.1,
> kernel enhanced with atm/utopia driver.
>
> This driver causes the CPM sometimes to hang when performing a memset,
> can this be caused by the same problem?
> (CPM stops responding, console buffers are not flused anymore and
> kernel stops waiting for buffers)
>
> Greetings,
> Theo Gjaltema
>
the problem ( so i think ) is, that larger applications will need more
space, which in turn is satisfied by malloc (or mmap with fd = -1).
these allocated pages are not real initialized after malloc ( they will
be initialized completely, if a write on it is done, which will cause
the page fault handler, that does the hardware mmu-stuff, so that a
write can be done). so they will cause a page fault on a first access.
no problem so long, but when the memset.S routine in libc tries to set
all to zero, it uses the dcbz instructions. this instruction then causes
a page fault or better a TLB miss (if i'm right). after the exception is
raised, the address where the write to was done is looked up in the DAR
(data address register), which could be bogus on the dcb* instruction
(on 8xx, where is the errata for that?).
to sum up, the chance, that a memset( .., '\0', ..) with dcbz is done on
a page (that has just registered structures in the kernel, and not
cached in the tlb or even marked as writeable) is bigger :)
that's my opinion. if someone has more knowledge about that, or if i'm
wrong - please! correct me.
anton
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: ming lei @ 2005-07-14 1:57 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <17068cbdcbb1e2de531d33eb07f768e5@embeddededge.com>
Dan,
No one intents to make memory corruption in kernel
space but it happens sometimes.
Say I have a global var in my kernel module which
called test-mod, it picks up a physical page allocated
by some code with kmalloc and later kfreed(suppose
when it does, the whole page gets freed). But then
this code forgets a pointer(which maped to this
physical page) already freed and modifies the pointer,
the write gets thru since that virt address's PTE
still valid and points to the physical page currently
used by test-mod. So the memory corruption happens.
Maybe I miss something in the linux kernel code that
prevents this double PTE thing.
Ming
--- Dan Malek <dan@embeddededge.com> wrote:
>
> On Jul 13, 2005, at 2:48 PM, ming lei wrote:
>
> > Why linux kernel does such thing and no one
> consider
> > it's a problem?
>
> Because we don't write software that accesses the
> memory
> from both of those locations, unless it is very
> intentional
> and necessary. If you are just fishing for ways
> software
> _could_ do bad things, there are tons of them. It's
> our
> job to write it so it doesn't :-)
>
> Thanks.
>
>
> -- Dan
>
>
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ 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