2.6.x on 405CR

2.6.x on 405CR

[Piotr Perak]

Hi.

Anyone seen 2.6.x kernel working on 405CR?
I can't make it boot.

Piotr Perak

Re: 2.6.x on 405CR

[Matt Porter]

On Mon, Sep 27, 2004 at 12:46:07PM +0200, Piotr Perak wrote:
> Hi.
> 
> Anyone seen 2.6.x kernel working on 405CR?
> I can't make it boot.

I can't recall anybody around here having a 405CR.  That's probably
why you didn't get a reponse the first time you posted this.

Since you are failing in ocp_add_one_device() and you have a
processor which doesn't have a chip definition in 2.6, the
problem is probably somewhere there.  Doublecheck your
arch/ppc/platforms/4xx/ibm405cr.c (you do have one, right?)
against a known good one in arch/ppc/platforms/4xx/ibm405gp.c

I wish I could rent you my BDI2000 to speed up your debugging,
but we're too far away from each other. :)

-Matt

Re: 2.6.x on 405CR

[Jon Masters]

On Mon, 27 Sep 2004 06:57:58 -0700, Matt Porter
<mporter@kernel.crashing.org> wrote:
> On Mon, Sep 27, 2004 at 12:46:07PM +0200, Piotr Perak wrote:
> > Hi.
> >
> > Anyone seen 2.6.x kernel working on 405CR?
> > I can't make it boot.

> I can't recall anybody around here having a 405CR.  That's probably
> why you didn't get a reponse the first time you posted this.

I might get access to one at some point - I'll be getting my Virtex II
tree up and running on 2.6 (PowerPC 405D) sometime soon hopefully too.

> I wish I could rent you my BDI2000 to speed up your debugging,
> but we're too far away from each other. :)

I hate you guys. I'm using insight on an XP box with that horrid
Xilinx xygwin - it's not aware of any virtual memory and I have no
symbols nicely available so it's all done by hand.

Jon.

Re: 2.6.x on 405CR

[Matt Porter]

[oops...we are supposed to be on linuxppc-embedded now]

On Mon, Sep 27, 2004 at 03:10:47PM +0100, Jon Masters wrote:
> On Mon, 27 Sep 2004 06:57:58 -0700, Matt Porter
> <mporter@kernel.crashing.org> wrote:
> > On Mon, Sep 27, 2004 at 12:46:07PM +0200, Piotr Perak wrote:
> > > Hi.
> > >
> > > Anyone seen 2.6.x kernel working on 405CR?
> > > I can't make it boot.
> 
> > I can't recall anybody around here having a 405CR.  That's probably
> > why you didn't get a reponse the first time you posted this.
> 
> I might get access to one at some point - I'll be getting my Virtex II
> tree up and running on 2.6 (PowerPC 405D) sometime soon hopefully too.

Great, it would be nice to have some COTS 405CR board in the tree.
If somebody wants to send me one, I'll do it, otherwise send patches.

> > I wish I could rent you my BDI2000 to speed up your debugging,
> > but we're too far away from each other. :)
> 
> I hate you guys. I'm using insight on an XP box with that horrid
> Xilinx xygwin - it's not aware of any virtual memory and I have no
> symbols nicely available so it's all done by hand.

Ouch...cygwin stuff is very ghetto.  Maybe we can take up a collection
for you. :)

-Matt

Re: 2.6.x on 405CR

[Matt Porter]

On Mon, Sep 27, 2004 at 12:46:07PM +0200, Piotr Perak wrote:
> Hi.
> 
> Anyone seen 2.6.x kernel working on 405CR?
> I can't make it boot.
 
Move this to linuxppc-embedded as per the mailing list split.

-Matt

Re: 2.6.x on 405CR

[Piotr Perak]

On Mon, 27 Sep 2004, Matt Porter wrote:
> Since you are failing in ocp_add_one_device() and you have a
> processor which doesn't have a chip definition in 2.6, the
> problem is probably somewhere there.  Doublecheck your
> arch/ppc/platforms/4xx/ibm405cr.c (you do have one, right?)
> against a known good one in arch/ppc/platforms/4xx/ibm405gp.c
>
 
I use ibm405cr.c that works with our running kernel 2.4.23.

const struct ocp_def core_ocp[]  /*__initdata*/ = {
     45         { .vendor       = OCP_VENDOR_IBM,
     46           .function     = OCP_FUNC_OPB,
     47           .index        = 0,
     48           .paddr        = OPB_BASE_START,
     49           .irq          = OCP_IRQ_NA,
     50           .pm           = OCP_CPM_NA,
     51         },
     52         { .vendor       = OCP_VENDOR_IBM,
     53           .function     = OCP_FUNC_16550,
     54           .index        = 0,
     55           .paddr        = UART0_IO_BASE,
     56           .irq          = UART0_INT,
     57           .pm           = IBM_CPM_UART0
     58         },
     59         { .vendor       = OCP_VENDOR_IBM,
     60           .function     = OCP_FUNC_16550,
     61           .index        = 1,
     62           .paddr        = UART1_IO_BASE,
     63           .irq          = UART1_INT,
     64           .pm           = IBM_CPM_UART1
     65         },
     66         { .vendor       = OCP_VENDOR_IBM,
     67           .function     = OCP_FUNC_IIC,
     68           .index        = 0,
     69           .paddr        = IIC0_BASE,
     70           .irq          = IIC0_IRQ,
     71           .pm           = IBM_CPM_IIC0
     72         },
     73         { .vendor       = OCP_VENDOR_IBM,
     74           .function     = OCP_FUNC_IIC,
     75           .index        = 1,
     76           .paddr        = IIC1_BASE,
     77           .irq          = IIC1_IRQ,
     78           .pm           = IBM_CPM_IIC1
     79         },
     80         { .vendor       = OCP_VENDOR_IBM,
     81           .function     = OCP_FUNC_GPIO,
     82           .paddr        = GPIO0_BASE,
     83		  .irq          = OCP_IRQ_NA,
     84           .pm           = IBM_CPM_GPIO0
     85         },
     86
     87 /*
     88         { .vendor       = OCP_VENDOR_IBM,
     89           .function     = OCP_FUNC_USB,
     90           .paddr        = USB_BASE,
     91           .irq          = USB0_IRQ,
     92           .pm           = IBM_CPM_USB
     93         },
     94 */
     95         { .vendor       = OCP_VENDOR_INVALID
     96         }
     97 };

I was given clean and ported 2.4.23 kernel and was told to port
2.6.8.1. Based on differences I noticed between two 2.4.23 I tried to do
same (almost) in 2.6.8.1. But all I can
get is:

loaded at:     00400000 009EA220
board data at: 009E713C 009E7190
relocated to:  00405384 004053D8
zimage at:     004058D7 004F2F8B
initrd at:     004F3000 009E6782
avail ram:     009EB000 08000000

Linux/PPC load: console=ttyS0,115200 console=tty0 root=/dev/ram0
init=/linuxrc rw
Uncompressing Linux...done.
Now booting the kernel

Re: 2.6.x on 405CR

[Piotr Perak]

On Mon, 27 Sep 2004, Matt Porter wrote:

> Since you are failing in ocp_add_one_device() and you have a
> processor which doesn't have a chip definition in 2.6, the
> problem is probably somewhere there.  Doublecheck your
> arch/ppc/platforms/4xx/ibm405cr.c (you do have one, right?)
> against a known good one in arch/ppc/platforms/4xx/ibm405gp.c

Because I use ibm405cr.c which works good with 2.4.23 I think that's not
the problem. Remember the call stack?

setup_arch() - arch/ppc/kernel/setup.c
  -> ocp_early_init() - arch/ppc/syslib/ocp.c
    -> ocp_add_one_device() - arch/ppc/syslib/ocp.c
      ->  alloc_bootmem MACRO calling __alloc_bootmem_core() -
mm/bootmem.c

When I comment line calling ocp_early_init() I fail in:
 
setup_arch() - arch/ppc/kernel/setup.c
  -> paging_init() - arch/ppc/mm/init.c
    -> free_area_init() - arch/ppc/mm/page_alloc.c
      -> free_area_init_node() - arch/ppc/mm/page_alloc.c
        -> alloc_bootmem_node() MACRO calling __alloc_bootmem_node -
mm/bootmem.c
          -> __alloc_bootmem_core() - mm/bootmem.c

As you can see again __alloc_bootmem_core. So maybe there's some
problem with memory?

Forgive me if I ask stupid questions, but this the first time I have
something to do with the kernel (not counting compiling for my home PC).

Re: 2.6.x on 405CR

[Matt Porter]

On Tue, Sep 28, 2004 at 11:57:44AM +0200, Piotr Perak wrote:
> 
> On Mon, 27 Sep 2004, Matt Porter wrote:
> 
> > Since you are failing in ocp_add_one_device() and you have a
> > processor which doesn't have a chip definition in 2.6, the
> > problem is probably somewhere there.  Doublecheck your
> > arch/ppc/platforms/4xx/ibm405cr.c (you do have one, right?)
> > against a known good one in arch/ppc/platforms/4xx/ibm405gp.c
> 
> Because I use ibm405cr.c which works good with 2.4.23 I think that's not
> the problem. Remember the call stack?

Which 2.4 tree?  linux-2.4, linuxppc-2.4, and linuxppc_2_4_devel haven't
had explicit 405cr support that I've noticed. Since the ocp layer has
changed that would leave open the possibility of a problem in translating
the support to the new ocp layer. 

> setup_arch() - arch/ppc/kernel/setup.c
>   -> ocp_early_init() - arch/ppc/syslib/ocp.c
>     -> ocp_add_one_device() - arch/ppc/syslib/ocp.c
>       ->  alloc_bootmem MACRO calling __alloc_bootmem_core() -
> mm/bootmem.c
> 
> When I comment line calling ocp_early_init() I fail in:
>  
> setup_arch() - arch/ppc/kernel/setup.c
>   -> paging_init() - arch/ppc/mm/init.c
>     -> free_area_init() - arch/ppc/mm/page_alloc.c
>       -> free_area_init_node() - arch/ppc/mm/page_alloc.c
>         -> alloc_bootmem_node() MACRO calling __alloc_bootmem_node -
> mm/bootmem.c
>           -> __alloc_bootmem_core() - mm/bootmem.c
> 
> As you can see again __alloc_bootmem_core. So maybe there's some
> problem with memory?

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.

> Forgive me if I ask stupid questions, but this the first time I have
> something to do with the kernel (not counting compiling for my home PC).

Well, the 405cr support issue is really throwing me for a loop here. If
you're crashing in _alloc_bootmem_core() and haven't hacked any MM code
then you're an interesting spot.  Can you trace it down to the exact
failure in __alloc_bootmem_core?

-Matt

Re: 2.6.x on 405CR

[Piotr Perak]

On Tue, 28 Sep 2004, Matt Porter wrote:

> On Tue, Sep 28, 2004 at 11:57:44AM +0200, Piotr Perak wrote:
> > Because I use ibm405cr.c which works good with 2.4.23 I think that's not
> > the problem. Remember the call stack?
> 
> Which 2.4 tree?  linux-2.4, linuxppc-2.4, and linuxppc_2_4_devel haven't
> had explicit 405cr support that I've noticed. Since the ocp layer has
> changed that would leave open the possibility of a problem in translating
> the support to the new ocp layer.

linux-2.4 ported to our board some time ago.  

> 
> > setup_arch() - arch/ppc/kernel/setup.c
> >   -> ocp_early_init() - arch/ppc/syslib/ocp.c
> >     -> ocp_add_one_device() - arch/ppc/syslib/ocp.c
> >       ->  alloc_bootmem MACRO calling __alloc_bootmem_core() -
> > mm/bootmem.c
> > 
> > When I comment line calling ocp_early_init() I fail in:
> >  
> > setup_arch() - arch/ppc/kernel/setup.c
> >   -> paging_init() - arch/ppc/mm/init.c
> >     -> free_area_init() - arch/ppc/mm/page_alloc.c
> >       -> free_area_init_node() - arch/ppc/mm/page_alloc.c
> >         -> alloc_bootmem_node() MACRO calling __alloc_bootmem_node -
> > mm/bootmem.c
> >           -> __alloc_bootmem_core() - mm/bootmem.c
> > 
> > As you can see again __alloc_bootmem_core. So maybe there's some
> > problem with memory?
> 
> 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?

> Well, the 405cr support issue is really throwing me for a loop here. If
> you're crashing in _alloc_bootmem_core() and haven't hacked any MM code
I haven't change any MM code.

> 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.

Piotr Perak

Re: 2.6.x on 405CR

[Matt Porter]

On Tue, Sep 28, 2004 at 05:47:57PM +0200, Piotr Perak wrote:
> On Tue, 28 Sep 2004, Matt Porter wrote:
> > 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.
 
> > 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

[Mark Chambers]

> 
> 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

[Piotr Perak]

On Tue, 28 Sep 2004, Matt Porter wrote:

> > > 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

[Jon Masters]

On Wed, 29 Sep 2004 13:20:17 +0200 (CEST), Piotr Perak
<peri@aqua.aspd.pwr.wroc.pl> 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

[Mark Chambers]

> > 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.
>

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

[Jon Masters]

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.