Board boots when in BDM, hangs otherwise

Board boots when in BDM, hangs otherwise

[Joshua Horvath]

I've got a custom 855T based board that I'm having trouble getting Linux to
boot up on consistently.

I've written a simple bootloader that allows me to TFTP an image to RAM and
execute it.  If I download this program via the BDM port and run it, everything
works fine.  The ethernet download works fine and the kernel boots without a
hitch.

I then progammed this code into flash and although everything appears to work
correctly, Linux won't boot after downloading the image to RAM.  I've verified
that the image is in fact uncorrupted after download so I would expect it to
boot correctly.  The bootup goes like this:

loaded at:     00210000 0021C578
relocated to:  00100000 0010C578
board data at: 001001C8 001001E4
relocated to:  00200100 0020011C
zimage at:     00217000 00282603
initrd at:     00282603 00459440
avail ram:     0045A000 01000000

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.2.13 (srossi@boston.ccrl.mot.com) (gcc version 2.95.2 19991024
(
release)) #152 Wed Apr 26 15:22:16 CDT 2000
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.46 BogoMIPS
clear_bit(0, c01381c0)
NIP: C0007030 XER: E000217F LR: C0007030 REGS: c00dcb50 TRAP: 0300
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c00dac90[0] 'swapper' mm->pgd c00d9000 Last syscall: 0
last math 00000000
GPR00: C0007030 C00DCC00 C00DAC90 0000001A 00000001 00000017 00000000 C00F6849
GPR08: 00000017 C00F0000 FF002808 C00DCB40 95113133 000191B8 00004C00 00000000
GPR16: 00000000 C04DCC00 C00F0000 C0120000 C0120000 00000000 00000000 C015B000
GPR24: C0120760 00000000 C012075C C1000000 C00F0000 00000001 C1000000 00000001
Call backtrace:
C0007030 C00EBC5C C00EA6E4 C000221C
Kernel panic: kernel access of bad area pc c0007030 lr c0007030 address
C1000000
 tsk swapper/0
In swapper task - not syncing
Rebooting in 180 seconds..


I'm using the EST VisionICE box to do the BDM download.  Now, the weird thing
is, if I do an "IN" command (which does some basic initialization and puts the
processor in debug mode) and then jump to flash and execute my code, everything
works fine.  My bootloader code also does board initialization and as far as I
can tell I'm setting up the registers the exact same way, so I can't figure out
what is getting configured differently by the VisionICE box.  I've disabled the
MMU and the caches.

I've also noticed that the code executes faster after I do an "IN" and jump to
flash (i.e. when I'm in BDM) versus when I just powerup or do a hard reset and
have the code execute automatically.

Does anyone know what the problem might be?  Since it runs correctly after
being initialized by the VisionICE box I assume something is wrong with my
hardware init routine but I can't figure out what that is.

Thanks,
-Josh

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

Re: Board boots when in BDM, hangs otherwise

[Dan Malek]

Joshua Horvath wrote:

> ....  If I download this program via the BDM port and run it, everything
> works fine.


Welcome to the wonderful world of BDM.   The bottom line is the BDM
software is likely initializing something in the processor that you are
not doing in your code.  This is an all too typical problem I have
seen in many organizations, and is the reason the first thing I do
is write processor boot roms and initialization, then throw the BDM
away before even starting on the kernel.

> .... Now, the weird thing
> is, if I do an "IN" command (which does some basic initialization and puts the
> processor in debug mode) and then jump to flash and execute my code, everything
> works fine.

Yes, indeed, you are missing something in your code.


	-- Dan

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

Re: Board boots when in BDM, hangs otherwise

[Jochen Roth]

Josh,

The EST BDM tool sets up the PPC core and some of the standard
peripherals, like the SDRAM controller, when you use the IN
command. The INN command does just reset the chip. Your boot
ROM needs to initialize all registers properly, then it should
work.

After IN, try the DR (display register) command, and DR PCI
for PCI config registers. Compare to the readouts after INN
(initialization without presets) and you see the differences.

Jochen

At 02:36 PM 5/1/00 -0500, Joshua Horvath wrote:
>
>I've got a custom 855T based board that I'm having trouble getting Linux to
>boot up on consistently.
>
>I've written a simple bootloader that allows me to TFTP an image to RAM and
>execute it.  If I download this program via the BDM port and run it, everything
>works fine.  The ethernet download works fine and the kernel boots without a
>hitch.
>
>I then progammed this code into flash and although everything appears to work
>correctly, Linux won't boot after downloading the image to RAM.  I've verified
>that the image is in fact uncorrupted after download so I would expect it to
>boot correctly.  The bootup goes like this:
>
>loaded at:     00210000 0021C578
>relocated to:  00100000 0010C578
>board data at: 001001C8 001001E4
>relocated to:  00200100 0020011C
>zimage at:     00217000 00282603
>initrd at:     00282603 00459440
>avail ram:     0045A000 01000000
>
>Linux/PPC load:
>Uncompressing Linux...done.
>Now booting the kernel
>Linux version 2.2.13 (srossi@boston.ccrl.mot.com) (gcc version 2.95.2 19991024
>(
>release)) #152 Wed Apr 26 15:22:16 CDT 2000
>Boot arguments: root=/dev/ram
>time_init: decrementer frequency = 187500000/60
>Calibrating delay loop... 49.46 BogoMIPS
>clear_bit(0, c01381c0)
>NIP: C0007030 XER: E000217F LR: C0007030 REGS: c00dcb50 TRAP: 0300
>MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>TASK = c00dac90[0] 'swapper' mm->pgd c00d9000 Last syscall: 0
>last math 00000000
>GPR00: C0007030 C00DCC00 C00DAC90 0000001A 00000001 00000017 00000000 C00F6849
>GPR08: 00000017 C00F0000 FF002808 C00DCB40 95113133 000191B8 00004C00 00000000
>GPR16: 00000000 C04DCC00 C00F0000 C0120000 C0120000 00000000 00000000 C015B000
>GPR24: C0120760 00000000 C012075C C1000000 C00F0000 00000001 C1000000 00000001
>Call backtrace:
>C0007030 C00EBC5C C00EA6E4 C000221C
>Kernel panic: kernel access of bad area pc c0007030 lr c0007030 address
>C1000000
> tsk swapper/0
>In swapper task - not syncing
>Rebooting in 180 seconds..
>
>
>I'm using the EST VisionICE box to do the BDM download.  Now, the weird thing
>is, if I do an "IN" command (which does some basic initialization and puts the
>processor in debug mode) and then jump to flash and execute my code, everything
>works fine.  My bootloader code also does board initialization and as far as I
>can tell I'm setting up the registers the exact same way, so I can't figure out
>what is getting configured differently by the VisionICE box.  I've disabled the
>MMU and the caches.
>
>I've also noticed that the code executes faster after I do an "IN" and jump to
>flash (i.e. when I'm in BDM) versus when I just powerup or do a hard reset and
>have the code execute automatically.
>
>Does anyone know what the problem might be?  Since it runs correctly after
>being initialized by the VisionICE box I assume something is wrong with my
>hardware init routine but I can't figure out what that is.
>
>Thanks,
>-Josh
>
>
--
Jochen Roth, ZNYX Networks
jochen@znyx.com


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

Re: Board boots when in BDM, hangs otherwise

[Jim Lewis]

Hi Josh,

A useful tool for figuring this out is to initialize with the INN command, download
and run the code. Then use the "sct diff" command (I think) to see what is
different between the register values on the target as opposed to those stored in
NVRAM on the VisionICE.

There is also a way to configure which register groups get downloaded when you use
the IN command. You can try turning various groups off to see which one really
matters.

Ther is one register that the IN command sets that it does not tell you about. That
is the ICTRL register, which controls serialization of the core, among other
things. On powerup, it is set to SHOW-ALL-INSTRUCTION-FETCH-CYCLES. Some 8xx
processors have problems with this. Read the errata. Check to make sure you are
setting ICTRL to something like 0x07 in your firmware.

-Jim
Jochen Roth wrote:

> Josh,
>
> The EST BDM tool sets up the PPC core and some of the standard
> peripherals, like the SDRAM controller, when you use the IN
> command. The INN command does just reset the chip. Your boot
> ROM needs to initialize all registers properly, then it should
> work.
>
> After IN, try the DR (display register) command, and DR PCI
> for PCI config registers. Compare to the readouts after INN
> (initialization without presets) and you see the differences.
>
> Jochen
>
> At 02:36 PM 5/1/00 -0500, Joshua Horvath wrote:
> >
> >I've got a custom 855T based board that I'm having trouble getting Linux to
> >boot up on consistently.
> >
> >I've written a simple bootloader that allows me to TFTP an image to RAM and
> >execute it.  If I download this program via the BDM port and run it, everything
> >works fine.  The ethernet download works fine and the kernel boots without a
> >hitch.
> >
> >I then progammed this code into flash and although everything appears to work
> >correctly, Linux won't boot after downloading the image to RAM.  I've verified
> >that the image is in fact uncorrupted after download so I would expect it to
> >boot correctly.  The bootup goes like this:
> >
> >loaded at:     00210000 0021C578
> >relocated to:  00100000 0010C578
> >board data at: 001001C8 001001E4
> >relocated to:  00200100 0020011C
> >zimage at:     00217000 00282603
> >initrd at:     00282603 00459440
> >avail ram:     0045A000 01000000
> >
> >Linux/PPC load:
> >Uncompressing Linux...done.
> >Now booting the kernel
> >Linux version 2.2.13 (srossi@boston.ccrl.mot.com) (gcc version 2.95.2 19991024
> >(
> >release)) #152 Wed Apr 26 15:22:16 CDT 2000
> >Boot arguments: root=/dev/ram
> >time_init: decrementer frequency = 187500000/60
> >Calibrating delay loop... 49.46 BogoMIPS
> >clear_bit(0, c01381c0)
> >NIP: C0007030 XER: E000217F LR: C0007030 REGS: c00dcb50 TRAP: 0300
> >MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> >TASK = c00dac90[0] 'swapper' mm->pgd c00d9000 Last syscall: 0
> >last math 00000000
> >GPR00: C0007030 C00DCC00 C00DAC90 0000001A 00000001 00000017 00000000 C00F6849
> >GPR08: 00000017 C00F0000 FF002808 C00DCB40 95113133 000191B8 00004C00 00000000
> >GPR16: 00000000 C04DCC00 C00F0000 C0120000 C0120000 00000000 00000000 C015B000
> >GPR24: C0120760 00000000 C012075C C1000000 C00F0000 00000001 C1000000 00000001
> >Call backtrace:
> >C0007030 C00EBC5C C00EA6E4 C000221C
> >Kernel panic: kernel access of bad area pc c0007030 lr c0007030 address
> >C1000000
> > tsk swapper/0
> >In swapper task - not syncing
> >Rebooting in 180 seconds..
> >
> >
> >I'm using the EST VisionICE box to do the BDM download.  Now, the weird thing
> >is, if I do an "IN" command (which does some basic initialization and puts the
> >processor in debug mode) and then jump to flash and execute my code, everything
> >works fine.  My bootloader code also does board initialization and as far as I
> >can tell I'm setting up the registers the exact same way, so I can't figure out
> >what is getting configured differently by the VisionICE box.  I've disabled the
> >MMU and the caches.
> >
> >I've also noticed that the code executes faster after I do an "IN" and jump to
> >flash (i.e. when I'm in BDM) versus when I just powerup or do a hard reset and
> >have the code execute automatically.
> >
> >Does anyone know what the problem might be?  Since it runs correctly after
> >being initialized by the VisionICE box I assume something is wrong with my
> >hardware init routine but I can't figure out what that is.
> >
> >Thanks,
> >-Josh
> >
> >
> --
> Jochen Roth, ZNYX Networks
> jochen@znyx.com
>


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

Re: Board boots when in BDM, hangs otherwise

[Joshua Horvath]

Jim,

Thanks for the tip.  The ICTRL register was the culprit.


-Josh

Jim Lewis wrote:
>
> Hi Josh,
>
> A useful tool for figuring this out is to initialize with the INN command, download
> and run the code. Then use the "sct diff" command (I think) to see what is
> different between the register values on the target as opposed to those stored in
> NVRAM on the VisionICE.
>
> There is also a way to configure which register groups get downloaded when you use
> the IN command. You can try turning various groups off to see which one really
> matters.
>
> Ther is one register that the IN command sets that it does not tell you about. That
> is the ICTRL register, which controls serialization of the core, among other
> things. On powerup, it is set to SHOW-ALL-INSTRUCTION-FETCH-CYCLES. Some 8xx
> processors have problems with this. Read the errata. Check to make sure you are
> setting ICTRL to something like 0x07 in your firmware.
>
> -Jim
> Jochen Roth wrote:
>
> > Josh,
> >
> > The EST BDM tool sets up the PPC core and some of the standard
> > peripherals, like the SDRAM controller, when you use the IN
> > command. The INN command does just reset the chip. Your boot
> > ROM needs to initialize all registers properly, then it should
> > work.
> >
> > After IN, try the DR (display register) command, and DR PCI
> > for PCI config registers. Compare to the readouts after INN
> > (initialization without presets) and you see the differences.
> >
> > Jochen
> >
> > At 02:36 PM 5/1/00 -0500, Joshua Horvath wrote:
> > >
> > >I've got a custom 855T based board that I'm having trouble getting Linux to
> > >boot up on consistently.
> > >
> > >I've written a simple bootloader that allows me to TFTP an image to RAM and
> > >execute it.  If I download this program via the BDM port and run it, everything
> > >works fine.  The ethernet download works fine and the kernel boots without a
> > >hitch.
> > >
> > >I then progammed this code into flash and although everything appears to work
> > >correctly, Linux won't boot after downloading the image to RAM.  I've verified
> > >that the image is in fact uncorrupted after download so I would expect it to
> > >boot correctly.  The bootup goes like this:
> > >
> > >loaded at:     00210000 0021C578
> > >relocated to:  00100000 0010C578
> > >board data at: 001001C8 001001E4
> > >relocated to:  00200100 0020011C
> > >zimage at:     00217000 00282603
> > >initrd at:     00282603 00459440
> > >avail ram:     0045A000 01000000
> > >
> > >Linux/PPC load:
> > >Uncompressing Linux...done.
> > >Now booting the kernel
> > >Linux version 2.2.13 (srossi@boston.ccrl.mot.com) (gcc version 2.95.2 19991024
> > >(
> > >release)) #152 Wed Apr 26 15:22:16 CDT 2000
> > >Boot arguments: root=/dev/ram
> > >time_init: decrementer frequency = 187500000/60
> > >Calibrating delay loop... 49.46 BogoMIPS
> > >clear_bit(0, c01381c0)
> > >NIP: C0007030 XER: E000217F LR: C0007030 REGS: c00dcb50 TRAP: 0300
> > >MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > >TASK = c00dac90[0] 'swapper' mm->pgd c00d9000 Last syscall: 0
> > >last math 00000000
> > >GPR00: C0007030 C00DCC00 C00DAC90 0000001A 00000001 00000017 00000000 C00F6849
> > >GPR08: 00000017 C00F0000 FF002808 C00DCB40 95113133 000191B8 00004C00 00000000
> > >GPR16: 00000000 C04DCC00 C00F0000 C0120000 C0120000 00000000 00000000 C015B000
> > >GPR24: C0120760 00000000 C012075C C1000000 C00F0000 00000001 C1000000 00000001
> > >Call backtrace:
> > >C0007030 C00EBC5C C00EA6E4 C000221C
> > >Kernel panic: kernel access of bad area pc c0007030 lr c0007030 address
> > >C1000000
> > > tsk swapper/0
> > >In swapper task - not syncing
> > >Rebooting in 180 seconds..
> > >
> > >
> > >I'm using the EST VisionICE box to do the BDM download.  Now, the weird thing
> > >is, if I do an "IN" command (which does some basic initialization and puts the
> > >processor in debug mode) and then jump to flash and execute my code, everything
> > >works fine.  My bootloader code also does board initialization and as far as I
> > >can tell I'm setting up the registers the exact same way, so I can't figure out
> > >what is getting configured differently by the VisionICE box.  I've disabled the
> > >MMU and the caches.
> > >
> > >I've also noticed that the code executes faster after I do an "IN" and jump to
> > >flash (i.e. when I'm in BDM) versus when I just powerup or do a hard reset and
> > >have the code execute automatically.
> > >
> > >Does anyone know what the problem might be?  Since it runs correctly after
> > >being initialized by the VisionICE box I assume something is wrong with my
> > >hardware init routine but I can't figure out what that is.
> > >
> > >Thanks,
> > >-Josh
> > >
> > >
> > --
> > Jochen Roth, ZNYX Networks
> > jochen@znyx.com
> >
>

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

Re: Board boots when in BDM, hangs otherwise

[Richard Hendricks]

Jim Lewis wrote:
>
> Hi Josh,
..
> Ther is one register that the IN command sets that it does not tell you about. That
> is the ICTRL register, which controls serialization of the core, among other
> things. On powerup, it is set to SHOW-ALL-INSTRUCTION-FETCH-CYCLES. Some 8xx
> processors have problems with this. Read the errata. Check to make sure you are
> setting ICTRL to something like 0x07 in your firmware.
>
> -Jim

This is also probably the source of your slowdown when running
off of BDM.

Also make sure the watchdog is disabled (Dan's code does this, I think).

If anyone is interested, I can post the startup file I use for
running from flash on the FADS board using Metrowerks.  I finally
figured out a way that I can run the same flash image standalone,
and through MPC8bug.

--
MPC823 Applications Engineering Development

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

Re: Board boots when in BDM, hangs otherwise

[Richard Hendricks]

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

Note:  This stuff only applies for Metrowerks running bare metal on the
FADS board.

Here are the instructions:
> Changes to PowerPC Runtime Source
>
> Add a __declspec(".init") before "extern void __start(void)" in
> __start.c
> Remove #pragma code_type ".init" in __start.c
> Add the following lines of code to __init_hardware() in
> __ppc_eabi_init.c and .cpp right after the nofralloc
>
>         /* 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
>
> //Do rest of board setup here, including MSR, IMMR, disable and
> invalidate caches, program UPM, ICTRL, DER, and ICR
>
> Chages to PowerPC Runtime Include
>
> Remove declspec from both __init_hardware() and ADSInit() in file
> __ppc_eabi_init.h
>
> Next recompile Runtime.
> Make sure __ppc_eabi_init in project file points to new modified
> version.
>
> Then goto the project you wish to use flash, and change the Code Address
> to start at 0x02800100.  Since __start is the only function marked as
> .init, it will now be at the correct location, 0x0100 during bootup.
>
> The runtime will also work when not flashing.
>
> This will also allow you to run standalone, and with MPC8bug attached by
> "go 02800100".

I sent them in to Metrowerks, so hopefully their next iteration will
work.  I have also included my whole _FADS.cpp init file.

"Richard Hendricks (ra6353)" wrote:
>
> Jim Lewis wrote:
> >
> > Hi Josh,
> ..
> > Ther is one register that the IN command sets that it does not tell you about. That
> > is the ICTRL register, which controls serialization of the core, among other
> > things. On powerup, it is set to SHOW-ALL-INSTRUCTION-FETCH-CYCLES. Some 8xx
> > processors have problems with this. Read the errata. Check to make sure you are
> > setting ICTRL to something like 0x07 in your firmware.
> >
> > -Jim
>
> This is also probably the source of your slowdown when running
> off of BDM.
>
> Also make sure the watchdog is disabled (Dan's code does this, I think).
>
> If anyone is interested, I can post the startup file I use for
> running from flash on the FADS board using Metrowerks.  I finally
> figured out a way that I can run the same flash image standalone,
> and through MPC8bug.
>
> --
> MPC823 Applications Engineering Development
>

--
MPC823 Applications Engineering Development

[-- Attachment #2: __ppc_eabi_init_FADS.cpp --]
[-- Type: application/x-unknown-content-type-CodeWarrior_cpp, Size: 12546 bytes --]