Board boots when in BDM, hangs otherwise

Joshua Horvath Josh_Horvath-AJH051 at email.mot.com
Tue May 2 23:59:47 EST 2000


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 at 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 at znyx.com
> >
>

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





More information about the Linuxppc-embedded mailing list