How to get rom code to go on FADS?

How to get rom code to go on FADS?

[Dan A. Dickey]

Ok, so I have the 8xxrom code running on my fads board;
and so far I've only been able to run it by using the
ADI connected to the debug port.  I noticed the other
day that it was actually running without the ADI connected.
(Lights blinking, RS232 status LED coming on, etc...)

However, I cannot seem to figure out how to cause this to
happen at will.  Is there some configuration thing I need
to set via the debug port?  (Using mpc8bug95 on a windows
machine talking to the ADI board connected to the debug
port).

If anyone is familar with how this is done, I'd appreciate
a reply.   Thanks again.
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

What do you mean, exactly?  How to get it to run stand-alone?  The
way I understand it, the 8xxROM code is designed to work stand-alone.

Do you mean running with the ADI&MPC8bug connected?  In that case,
you could try reseting the ADS board without letting MPC8bug run its
default configuration scripts (type "reset :ni" I believe).  This will
not initialize any of the on-chip registers.  You might have to turn
on the ADS board, start MPC8bug, shut off the ADS board, turn the
ADS board back on again, then run "reset :ni" in order for this to
work properly, since MPC8bug does a reset when it starts.  This will
make sure the registers are in their default state.  Once you do that,
you should be able to do a "go", and the CPU should start automatically
at 0x0100.  Remember though, MPC8bug doesn't do address translation, so
it will have problems displaying memory locations once the MMU's have
been enabled.

"Dan A. Dickey" wrote:
>
> Ok, so I have the 8xxrom code running on my fads board;
> and so far I've only been able to run it by using the
> ADI connected to the debug port.  I noticed the other
> day that it was actually running without the ADI connected.
> (Lights blinking, RS232 status LED coming on, etc...)
>
> However, I cannot seem to figure out how to cause this to
> happen at will.  Is there some configuration thing I need
> to set via the debug port?  (Using mpc8bug95 on a windows
> machine talking to the ADI board connected to the debug
> port).
>
> If anyone is familar with how this is done, I'd appreciate
> a reply.   Thanks again.
>         -Dan
>

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
> What do you mean, exactly?  How to get it to run stand-alone?  The
> way I understand it, the 8xxROM code is designed to work stand-alone.

Yes, I understand the 8xxROM code works that way.
Ok, I'll try to explain more clearly...

The 8xxROM code runs nicely with the ADI&mpc8bug connected.
No problems at all.

However, the 8xxROM code does not run *at all* without the ADI &
mpc8bug.
In fact, I'm pretty sure that no instruction at all are being
executed...
(I've modified 8xxrom code to setup IMMR, BR1/OR1 to point at BCSR;
 and then can toggle the AUX LAMP led - all this as about the first
 thing in the reset code).
(And, the above does toggle the AUX led just nicely - *WITH* adi &
mpc8bug).

But, when I exit mpc8bug95 and disconnect the ADI ribbon cable from the
FADS and toggle the power on the FADS; about all I get is the RUN, 5V,
SDRAM, DRAM, and FLASH leds on.  No toggling AUX; nothing else for
as long as I leave it on.  Kind of like its in a constant reset
condition.

Like I mentioned in my previous post, at one point in time I did indeed
see the AUX lamp blinking (*without* the ADI connected) and RS232 light
come on after powering on the FADS.  But, that was several weeks ago
and I'm not sure how this happened.  I'd like to be able to reliably
reproduce that state (ok - I know; according to previous posts, when
one is using a FADS you throw out any chance of reliability).

About at that time, I was wondering what the power up configuration
is set to, and how it gets changed.  I understand that the hardware
asserts something on the bus at power-up (reset?) time to help the
powerpc initialize itself.  I'm wondering if this is correct, and
if it is possible to change this via mpc8bug.  Perhaps mpc8bug puts
this word into a state such that it won't go (Freeze mode or something).
So, I was hoping someone would have the answer to this question.
I'll be working on this tomorrow.

Ok, looking at the users manual now...
It's the Hard Reset Configuration Word (11.3.1.1) that gets put on
the data bus.  It has all sorts of interesting things in it that
presumably can help or hinder the powerpc in getting through a reset.

> Do you mean running with the ADI&MPC8bug connected?  In that case,
> you could try reseting the ADS board without letting MPC8bug run its
> default configuration scripts (type "reset :ni" I believe).  This will
> not initialize any of the on-chip registers.  You might have to turn
> on the ADS board, start MPC8bug, shut off the ADS board, turn the
> ADS board back on again, then run "reset :ni" in order for this to
> work properly, since MPC8bug does a reset when it starts.  This will
> make sure the registers are in their default state.  Once you do that,
> you should be able to do a "go", and the CPU should start automatically
> at 0x0100.

I haven't tried the above, but will do so.

>  Remember though, MPC8bug doesn't do address translation, so
> it will have problems displaying memory locations once the MMU's have
> been enabled.

Yes, I'm aware of that.

Richard, thanks for your reply.
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
> Richard Hendricks wrote:
> > What do you mean, exactly?  How to get it to run stand-alone?  The
> > way I understand it, the 8xxROM code is designed to work stand-alone.
>
> Yes, I understand the 8xxROM code works that way.
> Ok, I'll try to explain more clearly...
>
> The 8xxROM code runs nicely with the ADI&mpc8bug connected.
> No problems at all.

Okay.

> However, the 8xxROM code does not run *at all* without the ADI &
> mpc8bug.
> In fact, I'm pretty sure that no instruction at all are being
> executed...

Now that's interesting.

> (I've modified 8xxrom code to setup IMMR, BR1/OR1 to point at BCSR;
>  and then can toggle the AUX LAMP led - all this as about the first
>  thing in the reset code).
> (And, the above does toggle the AUX led just nicely - *WITH* adi &
> mpc8bug).

Is this precisely and exactly the only thing you do?  Here's a copy of
some Metrowerks code that I use to run from flash.  It includes
everything
from 0x0100 to initializing the the UPM and whatnot:

__start is located at 0x0100
> asm void __start(void)
> {
> 	nofralloc							/* MWERKS: explicitly no stack */
> 										/* frame allocation */
>
> 	/*
> 	 *	PowerPC EABI init registers (stack, small data areas)
> 	 */
> 	bl		__init_registers
>
> 	/*
> 	 *	board-level initialization
> 	 */
> 	bl		__init_hardware
>
> 	/*
> 	 *	Memory access is safe now.
> 	 */
>
> 	/*
> 	 *	Prepare a terminating stack record.
> 	 */
> 	li		r0, 0xFFFF				/* load up r0 with 0xFFFFFFFF */
> 	stwu	r1, -8(r1)				/* Decrement stack by 8 bytes, (write word)*/
> 	stw		r0, 4(r1)				/* Make an illegal return address of 0xFFFFFFFF */
> 	stw		r0,	0(r1)				/* Make an illegal back chain address of 0xFFFFFFFF */

__init_registers looks like:
> asm static void __init_registers(void)
> {
> 	nofralloc						/* see above on usage of nofralloc */
> 	/*
> 	 *	initialize stack pointer
> 	 */
>
> 	lis		r1, _stack_addr@h		/* _stack_addr is generated by linker */
> 	ori		r1, r1, _stack_addr@l
>
> 	/*
> 	 *	initialize small data area pointers (EABI)
> 	 */
> 	lis		r2, _SDA2_BASE_@h		/* __SDA2_BASE_ is generated by linker */
> 	ori		r2, r2, _SDA2_BASE_@l
>
> 	lis		r13, _SDA_BASE_@h		/* _SDA_BASE_ is generated by linker */
> 	ori		r13, r13, _SDA_BASE_@l
>
> 	blr
> }

And __init_hardware looks like:
> asm void __init_hardware(void)
> {
> 	/*
> 	 *	Initialize Motorola ADS board unless running with MWDebug.
> 	 *	Uncomment the initialization below if running with MPC8BUG
> 	 *	or standalone.  You may need to perform other initializations.
> 	 */
> 	nofralloc
>
> 	/*
> 	 *	When customizing, be aware that the memory controller may not be
> 	 *	configured.  R1, R2, and R13 are already initialized and cannot be used.
> 	 *  Stack pointer is configured, but the memory it points to is not!
> 	 */
>
> 	/* Our address is really in high Flash ROM space.  When reset, execution
> 	 * starts at 0x0100.  This code fragment jumps us to the correct
> 	 * high memory area */
>
> 	lis r3, __init_hardware@h  /* high address of __start */
> 	ori r3, r3, __init_hardware@l
> 	addi r3, r3, 0x0014  /* Jumps us into the NOPs below */
> 	mtctr r3
> 	bctr
>
> 	nop
> 	nop
>
>     /* Now we need to fix the LR since it points back to 0x0000_010x,
>      * not 0x0280_010x like it needs to after we muck up the BCSR's */
>
>     mflr r3
>     oris r3, r3, 0x0280
>     mtlr r3
>
> //Setup MSR
> 	addi r4, r0, 0x1002
> 	mtmsr r4
> 	mtspr SRR1, r4
>
> //Setup IMMR
> 	lis r4, 0x0220
> 	ori r4, r4, 0x0000
> 	mtspr IMMR, r4
>
> //Disable and Invalidate I and D caches
> 	lis r3, DISABLE_CACHE
> 	mtspr IC_CST, r3
> 	isync
> 	mtspr DC_CST, r3
>
> 	lis r3, INVALID_CACHE
> 	mtspr IC_CST, r3
> 	isync
> 	mtspr DC_CST, r3
>
> //Setup SYPCR & disable software watchdog
> 	lis r3, 0xffff
> 	ori r3, r3, 0xff08
> 	stw	r3, SYPCR(r4)
>
>
> //Setup SIUMCR to 0x0101_2440
> 	addis r5, r0, 0x0101
> 	ori r5, r5, 0x2440
> 	stw r5, SIUMCR(r4)
>
> //UPM init stuff...(skipped)
> //BCSR settings
> 	lis r17, 0x0210
> 	ori r17, r17, 0x0001
>
> 	lis r18, 0xffff
> 	ori r18, r18, 0x8110
>
> 	stw r17, BR1(r4)
> 	stw r18, OR1(r4)
>
> //Clear TimeBase and PIT interrupts
> //Freeze TB and PIT in debug mode
> 	li r3, 0x00c2
> 	sth r3, TBSCR(r4)
>
> 	li r3, 0x0082
> 	sth r3, PISCR(r4)
>
> //Setup the rest of the core registers
>
> //Normal mode, no show cycles
> 	lis r3, 0x0000
> 	ori r3, r3, 0x0007
> 	mtspr ICTRL, r3
>
> //DER = 0x0, all exceptions to target
> 	lis r3, 0xfdc7
> 	ori r3, r3, 0x400f
> 	mtspr DER, r3
>
> //Clear ICR
> 	mtspr ICR, r3
>
> 	blr
>
> }

Maybe if you could post the "bare-bones" init code you are trying
to use, we can offer more help.

> But, when I exit mpc8bug95 and disconnect the ADI ribbon cable from the
> FADS and toggle the power on the FADS; about all I get is the RUN, 5V,
> SDRAM, DRAM, and FLASH leds on.  No toggling AUX; nothing else for
> as long as I leave it on.  Kind of like its in a constant reset
> condition.

Strange.  Try this:

1.  Connect the ADI cable.
2.  Turn on the board.
3.  Start MPC8bug
4.  Turn off the board.
5.  Turn the board back on.
6.  Execute "reset :ni" on MPC8bug.  This will cause a reset, but not
    initialize any of the internal registers.
7.  Setup a break point in your code using "br <address>"
8.  Type "go"

Your code should run up to the breakpoint.  Since this is well before
the MMU is initialized, it shouldn't be a problem.  Just remember
that a breakpoint does overwrite the contents of SRR0 and SRR1, so
(for example), you shouldn't breakpoint in the middle of writing to
either of them.  This procedure should allow you to debug your boot
code.

> Like I mentioned in my previous post, at one point in time I did indeed
> see the AUX lamp blinking (*without* the ADI connected) and RS232 light
> come on after powering on the FADS.  But, that was several weeks ago
> and I'm not sure how this happened.  I'd like to be able to reliably
> reproduce that state (ok - I know; according to previous posts, when
> one is using a FADS you throw out any chance of reliability).

I find it kinda strange that people state this over and over.
I must just be remarkably lucky in that my three ADS boards are
super-troopers, taking a real beating and still merrily running
along.  They've had components removed, and their daughtercards
exchanged constantly over the last few years, changing parts as
well.

> About at that time, I was wondering what the power up configuration
> is set to, and how it gets changed.  I understand that the hardware
> asserts something on the bus at power-up (reset?) time to help the
> powerpc initialize itself.  I'm wondering if this is correct, and
> if it is possible to change this via mpc8bug.  Perhaps mpc8bug puts
> this word into a state such that it won't go (Freeze mode or something).
> So, I was hoping someone would have the answer to this question.
> I'll be working on this tomorrow.

The Hard Reset Configuration Word has a default value for the FADS
board.  It's controlled by the FPGA's on the board.  MPC8bug,
through the BCSR's, can affect the value, but when stand-alone
the default is used.

> Ok, looking at the users manual now...
> It's the Hard Reset Configuration Word (11.3.1.1) that gets put on
> the data bus.  It has all sorts of interesting things in it that
> presumably can help or hinder the powerpc in getting through a reset.
>
> > Do you mean running with the ADI&MPC8bug connected?  In that case,
> > you could try reseting the ADS board without letting MPC8bug run its
> > default configuration scripts (type "reset :ni" I believe).  This will
> > not initialize any of the on-chip registers.  You might have to turn
> > on the ADS board, start MPC8bug, shut off the ADS board, turn the
> > ADS board back on again, then run "reset :ni" in order for this to
> > work properly, since MPC8bug does a reset when it starts.  This will
> > make sure the registers are in their default state.  Once you do that,
> > you should be able to do a "go", and the CPU should start automatically
> > at 0x0100.
>
> I haven't tried the above, but will do so.
>
> >  Remember though, MPC8bug doesn't do address translation, so
> > it will have problems displaying memory locations once the MMU's have
> > been enabled.
>
> Yes, I'm aware of that.
>
> Richard, thanks for your reply.
>         -Dan
>

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[duncanp]

On 12 May, Dan A. Dickey wrote:
>

[..snip..]

>
> However, the 8xxROM code does not run *at all* without the ADI &
> mpc8bug.
> In fact, I'm pretty sure that no instruction at all are being
> executed...
> (I've modified 8xxrom code to setup IMMR, BR1/OR1 to point at BCSR;
>  and then can toggle the AUX LAMP led - all this as about the first
>  thing in the reset code).
> (And, the above does toggle the AUX led just nicely - *WITH* adi &
> mpc8bug).
>
> But, when I exit mpc8bug95 and disconnect the ADI ribbon cable from the
> FADS and toggle the power on the FADS; about all I get is the RUN, 5V,
> SDRAM, DRAM, and FLASH leds on.  No toggling AUX; nothing else for
> as long as I leave it on.  Kind of like its in a constant reset
> condition.
>

This reminds me of something silly i've done in the past - Have you
remembered to disable the hardware watchdog?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
...
> Maybe if you could post the "bare-bones" init code you are trying
> to use, we can offer more help.

Ok, here is the start.S I'm using - its pretty much from 8xxROM,
but with some changes by me.
	-Dan

/*  8xxROM - Startup Code for the FADS8xx series of Embedded Boards
 *  Copyright (C) 1998  Dan Malek <dmalek@jlc.net>
 *  Copyright (C) 1999  Magnus Damm <kieraypc01.p.y.kie.era.ericsson.se>
 *
 *  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
 *
 *  The processor starts at 0x00000100 and the code is executed
 *  from flash. The code is organized to be at an other address
 *  in memory, but as long we don't jump around before relocating.
 *  board_init lies at a quite high address and when the cpu has
 *  jumped there, everything is ok.
 *  This works because the cpu gives the flash (CS0) the whole
 *  address space at startup, and board_init lies as a echo of
 *  the flash somewhere up there in the memorymap.
 *
 *  board_init will change CS0 to be positioned at the correct
 *  address and (s)dram will be positioned at address 0
 */
#include "config.h"

#define CONFIG_8xx 1
#define _LINUX_CONFIG_H 1

#include "ppc_asm.tmpl"
#include "ppc_defs.h"

#include <asm/processor.h>
#include <asm/cache.h>
#include <asm/mmu.h>
#include <board/board.h>

/* We don't want the  MMU yet.
*/
#undef MSR_KERNEL
#define MSR_KERNEL MSR_

        .text
        .globl  version_string
version_string:
        .string "8xxROM 0.3.0"
        . =
0x100

        .globl  _start
Xreset:
        addis   r2,0,_start@h
        ori             r2,r2,_start@l
        mtspr   LR,r2
        bclr    20,0


/* Machine check */
        STD_EXCEPTION(0x200, MachineCheck, MachineCheckException)

/* Data Storage exception.  "Never" generated on the 860. */
        STD_EXCEPTION(0x300, DataStorage, UnknownException)

/* Instruction Storage exception.  "Never" generated on the 860. */
        STD_EXCEPTION(0x400, InstStorage, UnknownException)

/* External Interrupt exception. */
        STD_EXCEPTION(0x500, ExtInterrupt, UnknownException)

/* Alignment exception. */
        . = 0x600
Alignment:
        EXCEPTION_PROLOG
        mfspr   r4,DAR
        stw     r4,_DAR(r21)
        mfspr   r5,DSISR
        stw     r5,_DSISR(r21)
        addi    r3,r1,STACK_FRAME_OVERHEAD
        li      r20,MSR_KERNEL
        rlwimi  r20,r23,0,16,16         /* copy EE bit from saved MSR */
        lis     r6, transfer_to_handler@h
        ori     r6, r6, transfer_to_handler@l
        mtlr    r6
        blrl
        .long   AlignmentException
        .long   int_return

/* Program check exception */
        . = 0x700
ProgramCheck:
        EXCEPTION_PROLOG
        addi    r3,r1,STACK_FRAME_OVERHEAD
        li      r20,MSR_KERNEL
        rlwimi  r20,r23,0,16,16         /* copy EE bit from saved MSR */
        lis     r6, transfer_to_handler@h
        ori     r6, r6, transfer_to_handler@l
        mtlr    r6
        blrl
        .long   ProgramCheckException
        .long   int_return

        /* No FPU on MPC8xx.  This exception is not supposed to
happen.
        */
        STD_EXCEPTION(0x800, FPUnavailable, UnknownException)

        /* I guess we could implement decrementer, and may have
         * to someday for timekeeping.
         */
        STD_EXCEPTION(0x900, Decrementer, UnknownException)
        STD_EXCEPTION(0xa00, Trap_0a, UnknownException)
        STD_EXCEPTION(0xb00, Trap_0b, UnknownException)

        STD_EXCEPTION(0xc00, SystemCall, UnknownException)
        STD_EXCEPTION(0xd00, SingleStep, UnknownException)

        STD_EXCEPTION(0xe00, Trap_0e, UnknownException)
        STD_EXCEPTION(0xf00, Trap_0f, UnknownException)

        /* On the MPC8xx, this is a software emulation interrupt.  It
occurs
         * for all unimplemented and illegal instructions.
         */
        STD_EXCEPTION(0x1000, SoftEmu, SoftEmuException)

        STD_EXCEPTION(0x1100, InstructionTLBMiss, UnknownException)
        STD_EXCEPTION(0x1200, DataTLBMiss, UnknownException)
        STD_EXCEPTION(0x1300, InstructionTLBError, UnknownException)
        STD_EXCEPTION(0x1400, DataTLBError, UnknownException)

        STD_EXCEPTION(0x1500, Reserved5, UnknownException)
        STD_EXCEPTION(0x1600, Reserved6, UnknownException)
        STD_EXCEPTION(0x1700, Reserved7, UnknownException)
        STD_EXCEPTION(0x1800, Reserved8, UnknownException)
        STD_EXCEPTION(0x1900, Reserved9, UnknownException)
        STD_EXCEPTION(0x1a00, ReservedA, UnknownException)
        STD_EXCEPTION(0x1b00, ReservedB, UnknownException)

        STD_EXCEPTION(0x1c00, DataBreakpoint, UnknownException)
        STD_EXCEPTION(0x1d00, InstructionBreakpoint, UnknownException)
        STD_EXCEPTION(0x1e00, PeripheralBreakpoint, UnknownException)
        STD_EXCEPTION(0x1f00, DevPortBreakpoint, UnknownException)


        .globl  _end_of_vectors
_end_of_vectors:


        . = 0x2000

_start:
        /* the original fadsrom code by Dan Malek did a lot of setup
*/
        /* in assembler, I moved most of the code to C for readability
*/

        addis   r3, 0, _start@h
        ori             r3, r3, _start@l
        addi    r3, r3, 0x0014  /* Jumps us into the NOPs below */
        mtctr
r3
        bctr

        nop
        nop

        /* Now we need to fix the LR since it points back to
0x0000_010x,
         * not 0x0280_010x like it needs to after we muck up the BCSR's
*/

        mflr    r3
        oris    r3, r3, 0x0280
        mtlr    r3

        addis   r0,0,0

        addi    r3, r0, MSR_    /* Set ME, RI flags */
        mtmsr   r3
        mtspr   SRR1, r3        /* Make SRR1 match MSR */

        /* Make the LR equal the PC. */
        oris    r3,r0,sync_jump@h
        ori             r3,r3,sync_jump@l
        mtspr   LR,r3
        bclr    20,0
sync_jump:

#if 1
        /* position IMMR */

        lis     r1, IMMR_VALUE@h
        ori     r1, r1, 0
        mtspr   638, r1

bror1start:
        /* need to setup BR1/OR1 to get to the BCSR on the fads */
        lis r9,0xffff
        ori r9,r9,0x8110
        lis r10,0x0210
        ori r10,r10,0x0001
        stw r9,0x10C(r1)
        stw r10,0x108(r1)

        /* signal on */
        lis     r8,0x210
        ori     r8,r8,16
        lis r9,0x210
        ori r9,r9,16
        lwz r10,0(r9)
        rlwinm r9,r10,0,4,2
        stw r9,0(r8)

#if 1
        /* signal delay */
        lis r8,0x5
sdloop1:
        addi r8,r8,-1
        li r9,-1
        cmpw r0,r8,r9
        bc 4,2,sdcont1
        b sdstop1
sdcont1:
        b sdloop1
sdstop1:
#endif

        /* signal off */
        lis     r8,0x210
        ori     r8,r8,16
        lis r9,0x210
        ori r9,r9,16
        lwz r10,0(r9)
        oris r9,r10,0x1000
        stw r9,0(r8)

#if 1
        /* signal delay */
        lis r8,0x5
sdloop2:
        addi r8,r8,-1
        li r9,-1
        cmpw r0,r8,r9
        bc 4,2,sdcont2
        b sdstop2
sdcont2:
        b sdloop2
sdstop2:
#endif

        /* signal on */
        lis     r8,0x210
        ori     r8,r8,16
        lis r9,0x210
        ori r9,r9,16
        lwz r10,0(r9)
        rlwinm r9,r10,0,4,2
        stw r9,0(r8)
#endif

        addis   r0,0,0

         /* invalidate all tlb's */

        tlbia
        isync

#if 1
        /* Reset the caches.
        */

        lis     r21, IDC_UNALL@h        /* Unlock all */
        mtspr   IC_CST, r21
        mtspr   DC_CST, r21

        lis     r21, IDC_INVALL@h       /* Invalidate all */
        mtspr   IC_CST, r21
        mtspr   DC_CST, r21

        lis     r21, IDC_DISABLE@h      /* Disable data cache */
        mtspr   DC_CST, r21

#if 0
        lis     r21, IDC_ENABLE@h       /* Enable instruction cache */
#else
        lis     r21, IDC_DISABLE@h      /* Disable instruction cache */
#endif
        mtspr   IC_CST, r21
#endif

        /* initialize some sprs that are hard to access from c */

        /* Disable serialized ifetch and show cycles (i.e. set processor
         * to normal mode).
         * this is also a silicon bug workaround, see errata
         */

        li      r21, 0x0007
        mtspr   ICTRL, r21

        /* Disable debug mode entry.
        */

        li      r21, 0
        mtspr   DER, r21

        /* position IMMR */

        lis     r1, IMMR_VALUE@h
        mtspr   638, r1

        /* set up the stack to the internal DPRAM */
/*      oris    r1,r0,0 */
        ori             r1,r1,0x3000
        /* load the stack pointer 72 bytes down from top of stack to
ensure one
         * stack frame of safety margin.
         */
        stwu    r0,-72(r1)

        /* let the c-code set up the rest */

        lis     r2,board_init@h
        ori     r2,r2,board_init@l
        mtlr    r2                   /* Easiest way to do an absolute
jump */

blr

        /* board_init will call start_main as the last thing it does. */

        .globl  start_main

start_main:

        /* Initialize stack pointer and jump to main function.
         * the c-code passed the stackpointer in r3 and the
         * argument to main in r4.
         */

        mr      r1, r3          /* first argument from c-code */
        mr      r3, r4          /* second argument to first */
        mr      r4, r5          /* third argument to second */
        bl      main_loop

1:      b       1b              /* Loop forever if main exits */


/*
 * This code finishes saving the registers to the exception frame
 * and jumps to the appropriate handler for the exception.
 * Register r21 is pointer into trap frame, r1 has new stack pointer.
 */
        .globl  transfer_to_handler
transfer_to_handler:
        stw     r22,_NIP(r21)
        lis     r22,MSR_POW@h
        andc    r23,r23,r22
        stw     r23,_MSR(r21)
        SAVE_GPR(7, r21)
        SAVE_4GPRS(8, r21)
        SAVE_8GPRS(12, r21)
        SAVE_8GPRS(24, r21)
#if 0
        andi.   r23,r23,MSR_PR
        mfspr   r23,SPRG3               /* if from user, fix up tss.regs
*/
        beq     2f
        addi    r24,r1,STACK_FRAME_OVERHEAD
        stw     r24,PT_REGS(r23)
2:      addi    r2,r23,-TSS             /* set r2 to current */
        tovirt(r2,r2,r23)
#endif
        mflr    r23
        andi.   r24,r23,0x3f00          /* get vector offset */
        stw     r24,TRAP(r21)
        li      r22,0
        stw     r22,RESULT(r21)
        mtspr   SPRG2,r22               /* r1 is now kernel sp */
#if 0
        addi    r24,r2,TASK_STRUCT_SIZE /* check for kernel stack
overflow */
        cmplw   0,r1,r2
        cmplw
1,r1,r24
        crand   1,1,4
        bgt     stack_ovf               /* if r2 < r1 <
r2+TASK_STRUCT_SIZE */
#endif
        lwz     r24,0(r23)              /* virtual address of handler */
        lwz     r23,4(r23)              /* where to go when done */
        mtspr   SRR0,r24
        mtspr   SRR1,r20
        mtlr    r23
        SYNC
        rfi                             /* jump to handler, enable MMU
*/

int_return:
        mfmsr   r30             /* Disable interrupts */
        li      r4,0
        ori     r4,r4,MSR_EE
        andc    r30,r30,r4
        SYNC                    /* Some chip revs need this... */
        mtmsr   r30
        SYNC
        lwz     r2,_CTR(r1)
        lwz     r0,_LINK(r1)
        mtctr   r2
        mtlr    r0
        lwz     r2,_XER(r1)
        lwz     r0,_CCR(r1)
        mtspr   XER,r2
        mtcrf   0xFF,r0
        REST_10GPRS(3, r1)
        REST_10GPRS(13, r1)
        REST_8GPRS(23, r1)
        REST_GPR(31, r1)
        lwz     r2,_NIP(r1)     /* Restore environment */
        lwz     r0,_MSR(r1)
        mtspr   SRR0,r2
        mtspr   SRR1,r0
        lwz     r0,GPR0(r1)
        lwz     r2,GPR2(r1)
        lwz     r1,GPR1(r1)
        SYNC
        rfi

/* Cache functions.
*/
        .globl  icache_enable
icache_enable:
        SYNC
        lis     r3, IDC_INVALL@h
        mtspr   IC_CST, r3
        lis     r3, IDC_ENABLE@h
        mtspr   IC_CST, r3
        blr

        .globl  icache_disable
icache_disable:
        SYNC
        lis     r3, IDC_DISABLE@h
        mtspr   IC_CST, r3
        blr

        .globl  dcache_enable
dcache_enable:
#if 0
        SYNC
#endif
#if 1
        lis     r3, 0x0400              /* Set cache mode with MMU off
*/
        mtspr   MD_CTR, r3
#endif

        lis     r3, IDC_INVALL@h
        mtspr   DC_CST, r3
#if 0
        lis     r3, DC_SFWT@h
        mtspr   DC_CST, r3
#endif
        lis     r3, IDC_ENABLE@h
        mtspr   DC_CST, r3
        blr

        .globl  dcache_disable
dcache_disable:
        SYNC
        lis     r3, IDC_DISABLE@h
        mtspr   DC_CST, r3
        lis     r3, IDC_INVALL@h
        mtspr   DC_CST, r3
        blr

        .globl  dc_stat
dc_stat:
        mfspr   r3, DC_CST
        blr

        .globl  dc_read
dc_read:
        mtspr   DC_ADR, r3
        mfspr   r3, DC_DAT
        blr

#if 1
        .globl  udelay
udelay:
        mulli   r4,r3,1000      /* nanoseconds */
        addi    r4,r4,59
        li      r5,60
        divw    r4,r4,r5        /* BUS ticks */
1:      mftbu   r5
        mftb
r6
        mftbu   r7
        cmp     0,r5,r7
        bne     1b              /* Get [synced] base time */
        addc    r9,r6,r4        /* Compute end time */
        addze   r8,r5
2:      mftbu   r5
        cmp     0,r5,r8
        blt     2b
        bgt     3f
        mftb    r6
        cmp     0,r6,r9
        blt     2b
3:      blr
#endif


        .globl  get_immr
get_immr:
        mfspr   r3, 638
        blr

        .globl get_pvr
get_pvr:
        mfspr   r3, PVR
        blr


        .globl wr_ic_cst
wr_ic_cst:
        mtspr   IC_CST, r3
        blr

        .globl rd_ic_cst
rd_ic_cst:
        mfspr   r3, IC_CST
        blr

        .globl wr_ic_adr
wr_ic_adr:
        mtspr   IC_ADR, r3
        blr


        .globl wr_dc_cst
wr_dc_cst:
        mtspr   DC_CST, r3
        blr

        .globl rd_dc_cst
rd_dc_cst:
        mfspr   r3, DC_CST
        blr

        .globl
wr_dc_adr
wr_dc_adr:
        mtspr   DC_ADR, r3
        blr

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
>
>         /* Now we need to fix the LR since it points back to
> 0x0000_010x,
>          * not 0x0280_010x like it needs to after we muck up the BCSR's
> */
>
>         mflr    r3
>         oris    r3, r3, 0x0280
>         mtlr    r3
>
>         addis   r0,0,0
>
>         addi    r3, r0, MSR_    /* Set ME, RI flags */
>         mtmsr   r3
>         mtspr   SRR1, r3        /* Make SRR1 match MSR */
>
>         /* Make the LR equal the PC. */
>         oris    r3,r0,sync_jump@h
>         ori             r3,r3,sync_jump@l
>         mtspr   LR,r3
>         bclr    20,0
> sync_jump:

Kinda odd you leave the mflr, oris, mtlr and then change it to match the
PC.
Since you are not being called from another function, you really
shouldn't
need either. (IE, what's the point in making the LR equal to the PC?
Would probably make more sense to make it point to, say, the Machine
Check exception)

> #if 1
>         /* position IMMR */
>
>         lis     r1, IMMR_VALUE@h
>         ori     r1, r1, 0
>         mtspr   638, r1
>
> bror1start:
>         /* need to setup BR1/OR1 to get to the BCSR on the fads */
>         lis r9,0xffff
>         ori r9,r9,0x8110
>         lis r10,0x0210
>         ori r10,r10,0x0001
>         stw r9,0x10C(r1)
>         stw r10,0x108(r1)


>         /* signal on */
>         lis     r8,0x210
>         ori     r8,r8,16
>         lis r9,0x210
>         ori r9,r9,16
>         lwz r10,0(r9)
>         rlwinm r9,r10,0,4,2
>         stw r9,0(r8)

Hm.. Whay are you ori'ing in 16?  BCSR1 should be at 0x4, not 0x10.  You
end
up dropping r9 onto BCSR0, which can't be a good thing.  Try changing
the
two ori's to ori r8,r8,4 and ori r9, r9, 4.  Let me know what happens!

> #if 1
>         /* signal delay */
>         lis r8,0x5
> sdloop1:
>         addi r8,r8,-1
>         li r9,-1
>         cmpw r0,r8,r9
>         bc 4,2,sdcont1
>         b sdstop1
> sdcont1:
>         b sdloop1
> sdstop1:
> #endif
>
>         /* signal off */
>         lis     r8,0x210
>         ori     r8,r8,16
>         lis r9,0x210
>         ori r9,r9,16
>         lwz r10,0(r9)
>         oris r9,r10,0x1000
>         stw r9,0(r8)
>
> #if 1
>         /* signal delay */
>         lis r8,0x5
> sdloop2:
>         addi r8,r8,-1
>         li r9,-1
>         cmpw r0,r8,r9
>         bc 4,2,sdcont2
>         b sdstop2
> sdcont2:
>         b sdloop2
> sdstop2:
> #endif
>
>         /* signal on */
>         lis     r8,0x210
>         ori     r8,r8,16
>         lis r9,0x210
>         ori r9,r9,16
>         lwz r10,0(r9)
>         rlwinm r9,r10,0,4,2
>         stw r9,0(r8)
> #endif
>
>         addis   r0,0,0
>
>          /* invalidate all tlb's */
>
>         tlbia
>         isync
>
> #if 1
>         /* Reset the caches.
>         */
>
>         lis     r21, IDC_UNALL@h        /* Unlock all */
>         mtspr   IC_CST, r21
>         mtspr   DC_CST, r21
>
>         lis     r21, IDC_INVALL@h       /* Invalidate all */
>         mtspr   IC_CST, r21
>         mtspr   DC_CST, r21
>
>         lis     r21, IDC_DISABLE@h      /* Disable data cache */
>         mtspr   DC_CST, r21
>
> #if 0
>         lis     r21, IDC_ENABLE@h       /* Enable instruction cache */
> #else
>         lis     r21, IDC_DISABLE@h      /* Disable instruction cache */
> #endif
>         mtspr   IC_CST, r21
> #endif
>
>         /* initialize some sprs that are hard to access from c */
>
>         /* Disable serialized ifetch and show cycles (i.e. set processor
>          * to normal mode).
>          * this is also a silicon bug workaround, see errata
>          */
>
>         li      r21, 0x0007
>         mtspr   ICTRL, r21
>
>         /* Disable debug mode entry.
>         */
>
>         li      r21, 0
>         mtspr   DER, r21
>
>         /* position IMMR */
>
>         lis     r1, IMMR_VALUE@h
>         mtspr   638, r1
>
>         /* set up the stack to the internal DPRAM */
> /*      oris    r1,r0,0 */
>         ori             r1,r1,0x3000
>         /* load the stack pointer 72 bytes down from top of stack to
> ensure one
>          * stack frame of safety margin.
>          */
>         stwu    r0,-72(r1)
>
>         /* let the c-code set up the rest */
>
>         lis     r2,board_init@h
>         ori     r2,r2,board_init@l
>         mtlr    r2                   /* Easiest way to do an absolute
> jump */
>
> blr
>
>         /* board_init will call start_main as the last thing it does. */
>
>         .globl  start_main
>
> start_main:
>
>         /* Initialize stack pointer and jump to main function.
>          * the c-code passed the stackpointer in r3 and the
>          * argument to main in r4.
>          */
>
>         mr      r1, r3          /* first argument from c-code */
>         mr      r3, r4          /* second argument to first */
>         mr      r4, r5          /* third argument to second */
>         bl      main_loop
>
> 1:      b       1b              /* Loop forever if main exits */
>
> /*
>  * This code finishes saving the registers to the exception frame
>  * and jumps to the appropriate handler for the exception.
>  * Register r21 is pointer into trap frame, r1 has new stack pointer.
>  */
>         .globl  transfer_to_handler
> transfer_to_handler:
>         stw     r22,_NIP(r21)
>         lis     r22,MSR_POW@h
>         andc    r23,r23,r22
>         stw     r23,_MSR(r21)
>         SAVE_GPR(7, r21)
>         SAVE_4GPRS(8, r21)
>         SAVE_8GPRS(12, r21)
>         SAVE_8GPRS(24, r21)
> #if 0
>         andi.   r23,r23,MSR_PR
>         mfspr   r23,SPRG3               /* if from user, fix up tss.regs
> */
>         beq     2f
>         addi    r24,r1,STACK_FRAME_OVERHEAD
>         stw     r24,PT_REGS(r23)
> 2:      addi    r2,r23,-TSS             /* set r2 to current */
>         tovirt(r2,r2,r23)
> #endif
>         mflr    r23
>         andi.   r24,r23,0x3f00          /* get vector offset */
>         stw     r24,TRAP(r21)
>         li      r22,0
>         stw     r22,RESULT(r21)
>         mtspr   SPRG2,r22               /* r1 is now kernel sp */
> #if 0
>         addi    r24,r2,TASK_STRUCT_SIZE /* check for kernel stack
> overflow */
>         cmplw   0,r1,r2
>         cmplw
> 1,r1,r24
>         crand   1,1,4
>         bgt     stack_ovf               /* if r2 < r1 <
> r2+TASK_STRUCT_SIZE */
> #endif
>         lwz     r24,0(r23)              /* virtual address of handler */
>         lwz     r23,4(r23)              /* where to go when done */
>         mtspr   SRR0,r24
>         mtspr   SRR1,r20
>         mtlr    r23
>         SYNC
>         rfi                             /* jump to handler, enable MMU
> */
>
> int_return:
>         mfmsr   r30             /* Disable interrupts */
>         li      r4,0
>         ori     r4,r4,MSR_EE
>         andc    r30,r30,r4
>         SYNC                    /* Some chip revs need this... */
>         mtmsr   r30
>         SYNC
>         lwz     r2,_CTR(r1)
>         lwz     r0,_LINK(r1)
>         mtctr   r2
>         mtlr    r0
>         lwz     r2,_XER(r1)
>         lwz     r0,_CCR(r1)
>         mtspr   XER,r2
>         mtcrf   0xFF,r0
>         REST_10GPRS(3, r1)
>         REST_10GPRS(13, r1)
>         REST_8GPRS(23, r1)
>         REST_GPR(31, r1)
>         lwz     r2,_NIP(r1)     /* Restore environment */
>         lwz     r0,_MSR(r1)
>         mtspr   SRR0,r2
>         mtspr   SRR1,r0
>         lwz     r0,GPR0(r1)
>         lwz     r2,GPR2(r1)
>         lwz     r1,GPR1(r1)
>         SYNC
>         rfi
>
> /* Cache functions.
> */
>         .globl  icache_enable
> icache_enable:
>         SYNC
>         lis     r3, IDC_INVALL@h
>         mtspr   IC_CST, r3
>         lis     r3, IDC_ENABLE@h
>         mtspr   IC_CST, r3
>         blr
>
>         .globl  icache_disable
> icache_disable:
>         SYNC
>         lis     r3, IDC_DISABLE@h
>         mtspr   IC_CST, r3
>         blr
>
>         .globl  dcache_enable
> dcache_enable:
> #if 0
>         SYNC
> #endif
> #if 1
>         lis     r3, 0x0400              /* Set cache mode with MMU off
> */
>         mtspr   MD_CTR, r3
> #endif
>
>         lis     r3, IDC_INVALL@h
>         mtspr   DC_CST, r3
> #if 0
>         lis     r3, DC_SFWT@h
>         mtspr   DC_CST, r3
> #endif
>         lis     r3, IDC_ENABLE@h
>         mtspr   DC_CST, r3
>         blr
>
>         .globl  dcache_disable
> dcache_disable:
>         SYNC
>         lis     r3, IDC_DISABLE@h
>         mtspr   DC_CST, r3
>         lis     r3, IDC_INVALL@h
>         mtspr   DC_CST, r3
>         blr
>
>         .globl  dc_stat
> dc_stat:
>         mfspr   r3, DC_CST
>         blr
>
>         .globl  dc_read
> dc_read:
>         mtspr   DC_ADR, r3
>         mfspr   r3, DC_DAT
>         blr
>
> #if 1
>         .globl  udelay
> udelay:
>         mulli   r4,r3,1000      /* nanoseconds */
>         addi    r4,r4,59
>         li      r5,60
>         divw    r4,r4,r5        /* BUS ticks */
> 1:      mftbu   r5
>         mftb
> r6
>         mftbu   r7
>         cmp     0,r5,r7
>         bne     1b              /* Get [synced] base time */
>         addc    r9,r6,r4        /* Compute end time */
>         addze   r8,r5
> 2:      mftbu   r5
>         cmp     0,r5,r8
>         blt     2b
>         bgt     3f
>         mftb    r6
>         cmp     0,r6,r9
>         blt     2b
> 3:      blr
> #endif
>
>         .globl  get_immr
> get_immr:
>         mfspr   r3, 638
>         blr
>
>         .globl get_pvr
> get_pvr:
>         mfspr   r3, PVR
>         blr
>
>         .globl wr_ic_cst
> wr_ic_cst:
>         mtspr   IC_CST, r3
>         blr
>
>         .globl rd_ic_cst
> rd_ic_cst:
>         mfspr   r3, IC_CST
>         blr
>
>         .globl wr_ic_adr
> wr_ic_adr:
>         mtspr   IC_ADR, r3
>         blr
>
>         .globl wr_dc_cst
> wr_dc_cst:
>         mtspr   DC_CST, r3
>         blr
>
>         .globl rd_dc_cst
> rd_dc_cst:
>         mfspr   r3, DC_CST
>         blr
>
>         .globl
> wr_dc_adr
> wr_dc_adr:
>         mtspr   DC_ADR, r3
>         blr
>

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
>
> "Dan A. Dickey" wrote:
> >
> >
> >         /* Now we need to fix the LR since it points back to
> > 0x0000_010x,
> >          * not 0x0280_010x like it needs to after we muck up the BCSR's
> > */
> >
> >         mflr    r3
> >         oris    r3, r3, 0x0280
> >         mtlr    r3
> >
> >         addis   r0,0,0
> >
> >         addi    r3, r0, MSR_    /* Set ME, RI flags */
> >         mtmsr   r3
> >         mtspr   SRR1, r3        /* Make SRR1 match MSR */
> >
> >         /* Make the LR equal the PC. */
> >         oris    r3,r0,sync_jump@h
> >         ori             r3,r3,sync_jump@l
> >         mtspr   LR,r3
> >         bclr    20,0
> > sync_jump:
>
> Kinda odd you leave the mflr, oris, mtlr and then change it to match the
> PC.
> Since you are not being called from another function, you really
> shouldn't
> need either. (IE, what's the point in making the LR equal to the PC?
> Would probably make more sense to make it point to, say, the Machine
> Check exception)

This stuff up above came from Motorola's 860 Initialization code.
I claim mostly ignorance when it comes to the 860/850; I have a
high degree of desire to *not* learn assembly for this processor.
But I do understand that I will have at least be able to read it,
and write some things.  Mostly, I'm hoping to leverage off of
what others have already done; and contribute in other areas.

> > #if 1
> >         /* position IMMR */
> >
> >         lis     r1, IMMR_VALUE@h
> >         ori     r1, r1, 0
> >         mtspr   638, r1
> >
> > bror1start:
> >         /* need to setup BR1/OR1 to get to the BCSR on the fads */
> >         lis r9,0xffff
> >         ori r9,r9,0x8110
> >         lis r10,0x0210
> >         ori r10,r10,0x0001
> >         stw r9,0x10C(r1)
> >         stw r10,0x108(r1)
>
>
> >         /* signal on */
> >         lis     r8,0x210
> >         ori     r8,r8,16
> >         lis r9,0x210
> >         ori r9,r9,16
> >         lwz r10,0(r9)
> >         rlwinm r9,r10,0,4,2
> >         stw r9,0(r8)
>
> Hm.. Whay are you ori'ing in 16?  BCSR1 should be at 0x4, not 0x10.  You
> end
> up dropping r9 onto BCSR0, which can't be a good thing.  Try changing
> the
> two ori's to ori r8,r8,4 and ori r9, r9, 4.  Let me know what happens!

Going along with my ignorance of assembly, the above I copied out
of a .s file - the result of writing the above in C and asking the
compiler
to produce the .s.  Cut & paste is a wonderful thing.  :)  However,
sometimes it comes back to haunt you.  It'd be my guess that I did
not change one of the register names correctly (after doing the cut &
paste, I changed the registers to be something more "appropriate").

I'll try your suggestion shortly - however, the processor never
reaches this point in execution.

Following your recommendation of powering off/on and just doing a
"reset :ni", I've been able to learn more.  I'm not sure what at
the moment, but things definitely are not working the way they
should - while the above code runs just fine when doing a "reset :h".

I'll let you know more soon.
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

"Dan A. Dickey" wrote:
...
> I'll let you know more soon.

Ok, I'm down to this bit of code:
        .text
        .globl  version_string
version_string:
        .string "8xxROM 0.3.0"
        . = 0x100

        .globl  _start
Xreset:
        addis   r2,0,_start@h
        ori             r2,r2,_start@l
        mtspr   LR,r2
        bclr    20,0
        nop

nop
... intermediate code suppressed ...

        .globl  _end_of_vectors
_end_of_vectors:


        . = 0x2000

_start:
        /* the original fadsrom code by Dan Malek did a lot of setup
*/
        /* in assembler, I moved most of the code to C for readability
*/

        addis   r3, 0, _start@h
        ori             r3, r3, _start@l
        addi    r3, r3, 0x0014  /* Jumps us into the NOPs below */
        mtctr   r3
        bctr

        nop
        nop

#if 0
        /* Now we need to fix the LR since it points back to
0x0000_010x,
         * not 0x0280_010x like it needs to after we muck up the BCSR's
*/

        mflr    r3
        oris    r3, r3, 0x0280
        mtlr    r3
#endif

        addis   r0,0,0

        addi    r3, r0, MSR_    /* Set ME, RI flags */
        mtmsr   r3
        mtspr   SRR1, r3        /* Make SRR1 match MSR */

#if 0
        /* Make the LR equal the PC. */
        oris    r3,r0,sync_jump@h
        ori             r3,r3,sync_jump@l
        mtspr   LR,r3
        bclr    20,0
sync_jump:
#endif

#if
1
        /* position IMMR */

        lis     r1, IMMR_VALUE@h
        ori     r1, r1, 0
        mtspr   638, r1

bror1start:
        /* need to setup BR1/OR1 to get to the BCSR on the fads */
        lis r9,0xffff
        ori r9,r9,0x8110
        lis r10,0x0210
        ori r10,r10,0x0001
        stw r9,0x10C(r1)
        stw
r10,0x108(r1)

Ok, so I build this and put it into the flash.
While mpc8bug & the ADI are connected I power off, wait a bit, power on.
Enter "reset :ni" at the mpc8bug prompt.
Then, "br 02802038"  (bror1start: address),
followed by "go 100".

I get the following from mpc8bug:
f850SARBug> br 02802038
f850SARBug> go 100
  Use Ctrl-C to abort execution !
warning: might be in unrecoverable exception state (SRR1[RI]=0)
exception: DEVELOPMENT PORT INTERRUPT
0x00000100      3c400280 addis r2,r0,0x280
f850SARBug>

So, to me at the moment; it appears to not even be reaching bror1start.
Any suggestions?

Something here just seems plain wrong - some little thing that is
pretty innocuous but because its not set right, turns out to be
a showstopper.  As soon as I (or someone else) finds it, it'll be
a "Doh - of course we need to do that...".

Any and all suggestions will be appreciated (and quite possibly tried).
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Ok, I've now learned that even a simple:

_start:
	b	_start

fails with the development port interrupt.
Really odd...
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

"Dan A. Dickey" wrote:
>
> Richard Hendricks wrote:
> >
> > "Dan A. Dickey" wrote:
...
> > > #if 1
> > >         /* position IMMR */
> > >
> > >         lis     r1, IMMR_VALUE@h
> > >         ori     r1, r1, 0
> > >         mtspr   638, r1
> > >
> > > bror1start:
> > >         /* need to setup BR1/OR1 to get to the BCSR on the fads */
> > >         lis r9,0xffff
> > >         ori r9,r9,0x8110
> > >         lis r10,0x0210
> > >         ori r10,r10,0x0001
> > >         stw r9,0x10C(r1)
> > >         stw r10,0x108(r1)
> >
> >
> > >         /* signal on */
> > >         lis     r8,0x210
> > >         ori     r8,r8,16
> > >         lis r9,0x210
> > >         ori r9,r9,16
> > >         lwz r10,0(r9)
> > >         rlwinm r9,r10,0,4,2
> > >         stw r9,0(r8)
> >
> > Hm.. Whay are you ori'ing in 16?  BCSR1 should be at 0x4, not 0x10.  You
> > end
> > up dropping r9 onto BCSR0, which can't be a good thing.  Try changing
> > the
> > two ori's to ori r8,r8,4 and ori r9, r9, 4.  Let me know what happens!
>
> Going along with my ignorance of assembly, the above I copied out
> of a .s file - the result of writing the above in C and asking the
> compiler
> to produce the .s.  Cut & paste is a wonderful thing.  :)  However,
> sometimes it comes back to haunt you.  It'd be my guess that I did
> not change one of the register names correctly (after doing the cut &
> paste, I changed the registers to be something more "appropriate").
>
> I'll try your suggestion shortly - however, the processor never
> reaches this point in execution.

Ok, I've backed out your change, and am now or'ing in the 16.
Things work again.  Well; the signal lamp goes on & off.
Checking the fads users manual, the address of BCSR1 is clearly
at 02100010.  Perhaps you were thinking of word addresses or something?

And, I'm currently still stuck at the development port interrupt...
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
> Ok, I've backed out your change, and am now or'ing in the 16.
> Things work again.  Well; the signal lamp goes on & off.
> Checking the fads users manual, the address of BCSR1 is clearly
> at 02100010.  Perhaps you were thinking of word addresses or something?
>
> And, I'm currently still stuck at the development port interrupt...
>         -Dan

Doh, I thought you were using the IrDA LED.  Nevermind. 0x10 is correct.

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

Dan,
  By any chance, do you not have +12V applied?  Also, how are you
programming your Flash ROM?  Try downloading it and reading the
memory locations with MPC8bug (normally MPC8bug puts the Flash
up at 0x02800100), then power off for a minute or two, then
reset the board normally through MPC8bug and read the memory
locations again.  It almost sounds like your Flash isn't getting
programmed at all...

Do an mdi at 0x02800100 to see if your code is properly getting
programmed.  I've got a feeling that I might know what's going on.

"Dan A. Dickey" wrote:
>
> Ok, I've now learned that even a simple:
>
> _start:
>         b       _start
>
> fails with the development port interrupt.
> Really odd...
>         -Dan

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
> Dan,
>   By any chance, do you not have +12V applied?

Pretty sure I do - it is supposed to be.  I don't have
a meter handy, so I can't actually measure it - but the
wire is there and so on (and it *is* attached to a power
supply).

>  Also, how are you
> programming your Flash ROM?  Try downloading it and reading the
> memory locations with MPC8bug (normally MPC8bug puts the Flash
> up at 0x02800100), then power off for a minute or two, then
> reset the board normally through MPC8bug and read the memory
> locations again.  It almost sounds like your Flash isn't getting
> programmed at all...

I'm pretty sure it *is* getting programmed.
I'm loading it with a "loadf theSRECfile 10000".
It loads the sections into ram, and then into flash.
After power off/on the board, I can still disassemble
the flash region (02800000) and see what I intended to
be put there.  (Yes, Xreset is at 02800100, and _start is
at 02802000).

> Do an mdi at 0x02800100 to see if your code is properly getting
> programmed.  I've got a feeling that I might know what's going on.

Good, cause I sure don't.  :)

One other point - I think I've determined that the
debug port interrupt *is* being caused by some sort
of timeout (watchdog perhaps?).  I looked a bit more
at the Motorola Init860.s and after setting up
SYPCR early enough, I don't seem to be getting that
interrupt any more.  I only managed to try that once
last night before needing to get to bed, and haven't
had a chance to look at it yet today.  Later tonight
I'll look again and see what I can see...
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

"Dan A. Dickey" wrote:
>
> Nicolas-Peter Pohland wrote:
> >
> > Did you try "rms der 0" (assuming you have the ADI board and MPC8bug SW)
>
> Nope, haven't tried that.  I'll look at it later tonight; thanks
> for the tip.

Good!  Fantastic tip.
This helps tremendously, especially in the fact that now I can
actually boot and run the kernel on my fads... while the ADI &
mpc8bug are connected.  Before that, I would always get the
InstructionTLBMiss exception - and of course, mpc8bug didn't
really know anything about the address.

Also, I'm also now running in "stand alone" mode - with the
ADI & mpc8bug disconnected.  Straight from the flash.

For me, this is great news.  I know that most of you don't
give a hoot!  :)

So, I'm attributing this recent success to:
	A)  Setting SYPCR in the rom code fairly early on.
	B)  Issuing a "rms der 0" to mpc8bug when it is connected.

I'm a happy camper at the moment.  Mostly.  :)
I just need to get my regular system setup to allow bootp and
host an nfs root for the fads.
Also, I just noticed - the kernel couldn't mount root, so it's
doing its "Rebooting in 180 seconds.." act.  However, about
all I'm seeing after that is a:
	<0>Kernel panic: Kernel Mode Software FPU Emulation
and then the duo is repeating every 180 seconds...
Not quite what I call a reboot.  I would think it would at
least manage to restart the rom initialization code.
Anyways, thats relatively minor...
have a good night!
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
> "Dan A. Dickey" wrote:
> >
> > Nicolas-Peter Pohland wrote:
> > >
> > > Did you try "rms der 0" (assuming you have the ADI board and MPC8bug SW)
> >
> > Nope, haven't tried that.  I'll look at it later tonight; thanks
> > for the tip.
>
> Good!  Fantastic tip.
> This helps tremendously, especially in the fact that now I can
> actually boot and run the kernel on my fads... while the ADI &
> mpc8bug are connected.  Before that, I would always get the
> InstructionTLBMiss exception - and of course, mpc8bug didn't
> really know anything about the address.
>
> Also, I'm also now running in "stand alone" mode - with the
> ADI & mpc8bug disconnected.  Straight from the flash.
>
> For me, this is great news.  I know that most of you don't
> give a hoot!  :)

Au Contraire, I care very much, being the MPC823 support body! :)

> So, I'm attributing this recent success to:
>         A)  Setting SYPCR in the rom code fairly early on.
>         B)  Issuing a "rms der 0" to mpc8bug when it is connected.

Interesting.  So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone?  Kinda
odd, considering the initial value of the watchdog is very long,
and you were having problems getting your Aux LED to turn on
right at the very beginning.

> I'm a happy camper at the moment.  Mostly.  :)
> I just need to get my regular system setup to allow bootp and
> host an nfs root for the fads.
> Also, I just noticed - the kernel couldn't mount root, so it's
> doing its "Rebooting in 180 seconds.." act.  However, about
> all I'm seeing after that is a:
>         <0>Kernel panic: Kernel Mode Software FPU Emulation
> and then the duo is repeating every 180 seconds...
> Not quite what I call a reboot.  I would think it would at
> least manage to restart the rom initialization code.
> Anyways, thats relatively minor...
> have a good night!
>         -Dan
>

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan Malek]

Richard Hendricks wrote:

> Interesting.  So clearing the SYPCR early in the ROM code is what
> was preventing you from getting the code to run stand-alone?

Oh, yes.  Clearing SYPCR is a very bad thing.  You end up with counter
values set to zero and immediately time out.  It seems a little strange,
as you have also cleared the enable flags.  I am sure someone at SPS
could explain the transistors flipping inside the part to make this
happen.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
>
> "Dan A. Dickey" wrote:
...
> > So, I'm attributing this recent success to:
> >         A)  Setting SYPCR in the rom code fairly early on.
> >         B)  Issuing a "rms der 0" to mpc8bug when it is connected.
>
> Interesting.  So clearing the SYPCR early in the ROM code is what
> was preventing you from getting the code to run stand-alone?  Kinda
> odd, considering the initial value of the watchdog is very long,
> and you were having problems getting your Aux LED to turn on
> right at the very beginning.

I believe that was at least a goodly portion of it.
It is interesting to note that the Aux LED still doesn't
blink unless the ADI & mpc8bug are connected.
Stand alone - no blinking light.  I'm going to
attribute this for the time being to the UPM not
being initialized - or some piece of hardware.
In any case, I was trying to use the Aux LED as
an indicator of how far the cpu got through the
code.  Getting to the point of an 8xxrom prompt
at which I can enter 'bootz', hit C/R, and see
linux boot up was enough for me to yank the assembly
version of the Aux LED blinking code.

I also think it was the delays I put in between
turning the light on/off that caused it to take too
long and for the watchdog to bite.

I might add that doing the "rms der 0" helped tremendously
as well.  I can now leave the ADI & mpc8bug connected
(for flashing new code) - but still allow linux to load
& start.  It doesn't without doing that (even though
8xxrom sets DER to 0!).
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Dan Malek wrote:
>
> Richard Hendricks wrote:
>
> > Interesting.  So clearing the SYPCR early in the ROM code is what
> > was preventing you from getting the code to run stand-alone?
>
> Oh, yes.  Clearing SYPCR is a very bad thing.  You end up with counter
> values set to zero and immediately time out.  It seems a little strange,
> as you have also cleared the enable flags.  I am sure someone at SPS
> could explain the transistors flipping inside the part to make this
> happen.

Ok ok...not *clearing* SYPCR.  :)

Just setting it to 0xFFFFFF88.
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
> Richard Hendricks wrote:
> >
> > "Dan A. Dickey" wrote:
> ...
> > > So, I'm attributing this recent success to:
> > >         A)  Setting SYPCR in the rom code fairly early on.
> > >         B)  Issuing a "rms der 0" to mpc8bug when it is connected.
> >
> > Interesting.  So clearing the SYPCR early in the ROM code is what
> > was preventing you from getting the code to run stand-alone?  Kinda
> > odd, considering the initial value of the watchdog is very long,
> > and you were having problems getting your Aux LED to turn on
> > right at the very beginning.
>
> I believe that was at least a goodly portion of it.
> It is interesting to note that the Aux LED still doesn't
> blink unless the ADI & mpc8bug are connected.
> Stand alone - no blinking light.

Well that's just plain odd.  If for some reason you couldn't
access the Aux LED, then you shouldn't be able to activate
any of the other stuff.  Something very bizarre is happening. :)
Have you tried activating the LED from much later in your code?

> I'm going to
> attribute this for the time being to the UPM not
> being initialized - or some piece of hardware.
> In any case, I was trying to use the Aux LED as
> an indicator of how far the cpu got through the
> code.  Getting to the point of an 8xxrom prompt
> at which I can enter 'bootz', hit C/R, and see
> linux boot up was enough for me to yank the assembly
> version of the Aux LED blinking code.
>
> I also think it was the delays I put in between
> turning the light on/off that caused it to take too
> long and for the watchdog to bite.
>
> I might add that doing the "rms der 0" helped tremendously
> as well.  I can now leave the ADI & mpc8bug connected
> (for flashing new code) - but still allow linux to load
> & start.  It doesn't without doing that (even though
> 8xxrom sets DER to 0!).

Um, that's documented so I take no blame for it. :)
See page 20-41.  If you have debug mode enabled, and
are not currently IN debug mode (ie, MPC8bug is connected,
but you are running your code), then a write to the
DP registers is ignored.

What I do to download programs to MPC8bug is:
Flash the S-Records
Just download the ELF file symbols (load blah :js) for debug
Set the DER to something reasonable like 0xfdc7400f
 (I'm very lazy about this, I added a "setder" command to .mpctcl.cfg
  at the very end.  Looks like:
	   a setder rms der 0xfdc7400f
 Laziness is the mother of invention!)
Then I unload the PLPRCR and set the MF.  Sometimes MPC8bug gets
 lost when the CPU changes clock frequencies, this gets around that.

>         -Dan

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Dan A. Dickey]

Richard Hendricks wrote:
>
> "Dan A. Dickey" wrote:
> >
> > Richard Hendricks wrote:
> > >
> > > "Dan A. Dickey" wrote:
> > ...
> > > > So, I'm attributing this recent success to:
> > > >         A)  Setting SYPCR in the rom code fairly early on.
> > > >         B)  Issuing a "rms der 0" to mpc8bug when it is connected.
> > >
> > > Interesting.  So clearing the SYPCR early in the ROM code is what
> > > was preventing you from getting the code to run stand-alone?  Kinda
> > > odd, considering the initial value of the watchdog is very long,
> > > and you were having problems getting your Aux LED to turn on
> > > right at the very beginning.
> >
> > I believe that was at least a goodly portion of it.
> > It is interesting to note that the Aux LED still doesn't
> > blink unless the ADI & mpc8bug are connected.
> > Stand alone - no blinking light.
>
> Well that's just plain odd.  If for some reason you couldn't
> access the Aux LED, then you shouldn't be able to activate
> any of the other stuff.  Something very bizarre is happening. :)
> Have you tried activating the LED from much later in your code?

Yes, works just fine.

> > I'm going to
> > attribute this for the time being to the UPM not
> > being initialized - or some piece of hardware.
> > In any case, I was trying to use the Aux LED as
> > an indicator of how far the cpu got through the
> > code.  Getting to the point of an 8xxrom prompt
> > at which I can enter 'bootz', hit C/R, and see
> > linux boot up was enough for me to yank the assembly
> > version of the Aux LED blinking code.
> >
> > I also think it was the delays I put in between
> > turning the light on/off that caused it to take too
> > long and for the watchdog to bite.
> >
> > I might add that doing the "rms der 0" helped tremendously
> > as well.  I can now leave the ADI & mpc8bug connected
> > (for flashing new code) - but still allow linux to load
> > & start.  It doesn't without doing that (even though
> > 8xxrom sets DER to 0!).
>
> Um, that's documented so I take no blame for it. :)
> See page 20-41.  If you have debug mode enabled, and
> are not currently IN debug mode (ie, MPC8bug is connected,
> but you are running your code), then a write to the
> DP registers is ignored.

Page 20-41 of what?  There's nothing like that in my
850 users manual, and the mpc8bug users manual doesn't
come close to having 20 chapters.

> What I do to download programs to MPC8bug is:
> Flash the S-Records
> Just download the ELF file symbols (load blah :js) for debug
> Set the DER to something reasonable like 0xfdc7400f
>  (I'm very lazy about this, I added a "setder" command to .mpctcl.cfg
>   at the very end.  Looks like:
>            a setder rms der 0xfdc7400f
>  Laziness is the mother of invention!)
> Then I unload the PLPRCR and set the MF.  Sometimes MPC8bug gets
>  lost when the CPU changes clock frequencies, this gets around that.

Sounds good, I'll try this.
Though, at the moment I don't have any idea what the
PLPRCR or MF are.  :)   I'll read up on them.
	-Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to get rom code to go on FADS?

[Richard Hendricks]

"Dan A. Dickey" wrote:
>
> > Um, that's documented so I take no blame for it. :)
> > See page 20-41.  If you have debug mode enabled, and
> > are not currently IN debug mode (ie, MPC8bug is connected,
> > but you are running your code), then a write to the
> > DP registers is ignored.
>
> Page 20-41 of what?  There's nothing like that in my
> 850 users manual, and the mpc8bug users manual doesn't
> come close to having 20 chapters.
>
Oooooh, you're one of those Netcomm customers. :)  I currently
support the MPC823/MPC823e.  They're very similar chips. Our
manual is slightly different from the Netcomm manual.  The
chapter in question is the Development Capabilities chapter.
I don't have an MPC850 manual handy.  Besides, ours is much
better. :)

BTW, the final version of the MPC823/MPC823e manual is now
availible on our website.  A printed version should be availible
at the LDC in a few weeks.  The Powers That Be are making us change
the cover from the spiffy one we have to a black Digital DNA one.
Feh.

--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/