RE: [ECOS] Re: MBX Board

[Gary Thomas <gthomas@redhat.com>]

On 30-May-00 amassa@cts.com wrote:
> Gary Thomas <gthomas@redhat.com> writes:
>>On 30-May-00 amassa@cts.com wrote:
>>> But then there is no way to get the EPPC-bug firmware back into the
> Flash,
>>> right?  Or can it be copied from the socketed boot ROM?
>>> 
>>
>>My board came with EPPCbug in both of them.  Simply changing the jumper
> allows
>>me to execute from one or the other.  Thus you can program the eCos GDB
> stubs
>>into the flash and still have EPPCbug available.
> 
> I understand, but it would be nice to have a way back to the original
> configuration.
> 

Just move the jumper back.

>>
>>> Did you just convert D:\Program Files\Red
>>> Hat\eCos\loaders\powerpc-mbx\gdb_module.bin into an srec format (using
>>> objcopy) and then download that?  If so, what switches did you use on
>>> objcopy.
>>> 
>>
>>It was as simple as 
>>  powerpc-eabi-objcopy -O binary gdb_module.bin gdb_module.hex
> 

Sorry, I meant 'srec' instead of 'binary'.  The extension doesn't matter.

> I thought that EPPC-Bug expects the downloaded file to be in srec format
> (with .mx extension).  Doesn't this produce a binary file?
> 
> This brings up another question for me.  Should the powerpc-eabi-xxx tools
> be used for everything?  Or can cygwin\bin\xxxx tools be used?
> 

For everything to do with the target, yes.

>>
>>> I know it might not make much sense but can I download the
> gdb_module.bin
>>> file into DRAM and execute it there and have it take control of the
> board,
>>> giving me GDB support?
>>> 
>>
>>Not really.  That module is only "comfortable" running from ROM/flash.
>>
>>> Can I just follow the instructions in the file
>>> D:\Program Files\Red
>>> Hat\eCos\packages\hal\powerpc\mbx\v1_3_1\src\Notes_GDB_stub?
>>> 
>>
>>You'd just end up recreating the 'gdb_module.bin' file above.
>>
>>> I'm a little confused with the EPPC-bug commands detailed in the
>>> Notes_GDB_stub file.  LO 0, downloads the code into DRAM?  And then what
>>> does the PFLASH 40000 60000 fc000000 instruction do?
>>> 
>>
>>Actually programs the flash chip with the contents of memory, starting
>>at location 0x40000.
>>
> 
> Contents of the DRAM memory?  So this programs the flash at address
> fc000000?  Is 40000 the location of the file in DRAM?  What is 60000?  Sorry
> for the basic questions.
> 

Yes, from DRAM.  60000 is the end of the image.

> Thanks,
> Anthony
> 
> 
>>> 
>>> Gary Thomas <gthomas@redhat.com> writes:
>>>>The MBX boards we have actually have two separate flash chips.  Based on
>>> the
>>>>use of jumper J4 you can select between the two.  My board has EPPC-bug
> in
>>> one
>>>>flash chip and eCos GDB stubs in the other.
>>>>
>>>>On 30-May-00 Jonathan Larmour wrote:
>>>>> "amassa@cts.com" wrote:
>>>>>> 
>>>>>> I am using the MBX860 board for development.  This board has the
>>> EPPC-bug
>>>>>> firmware programmed into flash.
>>>>>> 
>>>>>> What I want to do is to be able to download my own programs -
> initially
>>> just
>>>>>> a basic program.  I would like to have GDB support present as well.
>>>>>> 
>>>>>> I don't know if I need to compile a gdb stub and download that first
>>> into
>>>>>> RAM and then use that to connect insight and download my application
>>> code.
>>>>>> 
>>>>>> I would like to leave the EPPC-bug firmware as is in ROM, and not
>>> program
>>>>>> over it.
>>>>> 
>>>>> You should include the GDB support in the application you download, in
>>> the
>>>>> form of GDB stubs.
>>>>> 
>>>>> To do this, go to the "eCos HAL" package and under "Source-level
>>> debugging
>>>>> support" there is the "Include GDB stubs in HAL" option (aka
>>>>> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS), which you should enable. If you
>>> want
>>>>> Ctrl-C to work with stubs enabled, you should also enable GDB break
>>> support
>>>>> for stubs (CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT).
>>>>> 
>>>>> Jesper may have some more input.
>>>>> 
>>>>> Jifl
>>>>> -- 
>>>>> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223)
>>> 728762
>>>>> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own
>>> fault
>>>>> 
>>> 
>