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 at h		/* _stack_addr is generated by linker */
> 	ori		r1, r1, _stack_addr at l
>
> 	/*
> 	 *	initialize small data area pointers (EABI)
> 	 */
> 	lis		r2, _SDA2_BASE_ at h		/* __SDA2_BASE_ is generated by linker */
> 	ori		r2, r2, _SDA2_BASE_ at l
>
> 	lis		r13, _SDA_BASE_ at h		/* _SDA_BASE_ is generated by linker */
> 	ori		r13, r13, _SDA_BASE_ at 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 at h  /* high address of __start */
> 	ori r3, r3, __init_hardware at 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/