Re: 2.6.x on 405CR

6 messages, 5 authors, 2004-09-29 · open the first message on its own page

Re: 2.6.x on 405CR

From: Matt Porter <mporter@kernel.crashing.org>
Date: 2004-09-28 16:43:30

On Tue, Sep 28, 2004 at 05:47:57PM +0200, Piotr Perak wrote:
On Tue, 28 Sep 2004, Matt Porter wrote:
quoted
Hrm, I see. Did your firmware change between your working 2.4 kernel
and your non-working 2.6 kernel?  If you're failing in there that would
be my first thought. I suppose that's probably not that case though.
2.4.23 still runs on board I try to port 2.6.8.1 to. So I guess firmware
is not the problem?
In that case, it shouldn't be.
 
quoted
then you're an interesting spot.  Can you trace it down to the exact
failure in __alloc_bootmem_core?
I already did it. Can you please read
http://ozlabs.org/pipermail/linuxppc-dev/2004-September/000104.html? I
described there what weird things are happening in __alloc_bootmem_core.
I see. Can you move the reset instruction to isolate the offending
instruction? 
 
BTW, it's not clear how you are guaranteeing that the processor has
bit 2 or 3 asserted before the dbcr0 load. If you preloaded r12 out of
the scope of the code fragments shown, it's clear that r12 is getting
clobbered in the subf instruction of the 2.6.8.1 fragment.

Is this a hobby project or a "for profit" project? If it's for profit,
then consider investing in a JTAG emulator (like BDI2000)...it'll pay
for itself many times over.

-Matt

Re: 2.6.x on 405CR

From: Mark Chambers <hidden>
Date: 2004-09-28 17:26:56

Is this a hobby project or a "for profit" project? If it's for profit,
then consider investing in a JTAG emulator (like BDI2000)...it'll pay
for itself many times over.
And if you're poor, the Wiggler from ocdemon.net is a big help, and
only $150.  I've only used the Wiggler under Windows, but they
have free code and gdb ports that works under linux, too.  

Mark Chambers

Re: 2.6.x on 405CR

From: Piotr Perak <hidden>
Date: 2004-09-29 11:20:20


On Tue, 28 Sep 2004, Matt Porter wrote:
quoted
quoted
then you're an interesting spot.  Can you trace it down to the exact
failure in __alloc_bootmem_core?
I already did it. Can you please read
http://ozlabs.org/pipermail/linuxppc-dev/2004-September/000104.html? I
described there what weird things are happening in __alloc_bootmem_core.
I see. Can you move the reset instruction to isolate the offending
instruction? 
 
BTW, it's not clear how you are guaranteeing that the processor has
bit 2 or 3 asserted before the dbcr0 load. If you preloaded r12 out of
the scope of the code fragments shown, it's clear that r12 is getting
clobbered in the subf instruction of the 2.6.8.1 fragment.
My mistake. I thought I was putting immediate value 12 in DBCR0 using
asm("mtspr 0x3f2, 12") in C code, but it's putting the value hold in the
r12 register. I shoul read the manual correctly. So untill now we just had
luck if our processor reset!?

Look what I trie now.

static void * __init
    147 __alloc_bootmem_core(struct bootmem_data *bdata, unsigned long
size,
    148                 unsigned long align, unsigned long goal)
    149 {
    150         unsigned long offset, remaining_size, areasize, preferred;
    151         unsigned long i, start = 0, incr;
    152         unsigned long eidx = bdata->node_low_pfn -
(bdata->node_boot_start >> PAGE_SHIFT);
    153         void *ret;
    154
    155         if(!size) {
    156                 printk("__alloc_bootmem_core(): zero-sized
request\n");
    157                 BUG();
    158         }
    159         BUG_ON(align & (align-1));
    160
    161         asm ("li 17, 12");		// <-- immediate value of 12 to r17 -
bit 2:3 set
    162         asm ("mtspr 0x3f2, 17");	// < write to DBCR0 what is in
DOESN'T reset!!!
r17
    163         asm ("mtspr 0x3f2, 12");	// resets, but I don't know what
is value of r12
 
asm code is:
23c:   3a 20 00 0c     li      r17,12
240:   7e 32 fb a6     mtdbcr0 r17
244:   7d 92 fb a6     mtdbcr0 r12

It is said in manual, that setting bits 2:3 in DBCR0 resets the
processor. In my code it doesn't. :)
Is this a hobby project or a "for profit" project? If it's for profit,
then consider investing in a JTAG emulator (like BDI2000)...it'll pay
for itself many times over.
I'm a trainee in some firm. They use 2.4.23 now in their boxes. Porting
2.6.8.1 to their board is my project. I was told that they have some
hardware debbuger, but it doesn't work with virtual memory.

Piotr Perak

Re: 2.6.x on 405CR

From: Jon Masters <hidden>
Date: 2004-09-29 12:05:29

On Wed, 29 Sep 2004 13:20:17 +0200 (CEST), Piotr Perak
[off-list ref] wrote:
I'm a trainee in some firm. They use 2.4.23 now in their boxes.
Well you and I have the 2.4.23 bit in common. I'm the entire kernel
team in the company I work at, which is somewhat fun. Also means lists
like this are really useful on occasion.
Porting 2.6.8.1 to their board is my project. I was told that they have some
hardware debbuger, but it doesn't work with virtual memory.
I don't have one capable of working with virtual memory but I do have
a JTAG debugger since JTAG is used to program all of our boards - and
using insight with a large cup of coffee, System.map and the output of
a full objdump of the kernel binary in combination with modifying the
code in memory to insert infinate loops or changing the mode in the
MSR usually works for me. Seriously, if you don't have a vm capable
debugger that's a lot of masochistic fun to be had debugging.

Jon.

Re: 2.6.x on 405CR

From: Mark Chambers <hidden>
Date: 2004-09-29 13:21:21

quoted
Porting 2.6.8.1 to their board is my project. I was told that they have
some
quoted
hardware debbuger, but it doesn't work with virtual memory.
I don't have one capable of working with virtual memory but I do have
a JTAG debugger since JTAG is used to program all of our boards - and
using insight with a large cup of coffee, System.map and the output of
a full objdump of the kernel binary in combination with modifying the
code in memory to insert infinate loops or changing the mode in the
MSR usually works for me. Seriously, if you don't have a vm capable
debugger that's a lot of masochistic fun to be had debugging.
And just to make the point - it's not the JTAG hardware which is or is not
VM capable, it's the debugger using the hardware which must be smart
enough to read the MM tables and do the translations for you. Maybe if you
post what hardware you have somebody would know of a gdb port that
supports it.  Don't let them blow you off on this - they're wasting your
time
and their money if you don't have a proper debugger.  Just tell them we all
said you need one.

Mark C.

Re: 2.6.x on 405CR

From: Jon Masters <hidden>
Date: 2004-09-29 19:49:49

Mark Chambers wrote:
And just to make the point - it's not the JTAG hardware which is or is not
VM capable, it's the debugger using the hardware which must be smart
enough to read the MM tables and do the translations for you.
Yes of course :-).
Maybe if you post what hardware you have somebody would know of a gdb port that
supports it.  Don't let them blow you off on this - they're wasting your
time and their money if you don't have a proper debugger.  Just tell them we all
said you need one.
I've managed so far without one but agree it's a good idea to get one.

;-).

Jon.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help