[ECOS] RE: MBX Board

[ECOS] RE: MBX Board

[Jesper Skov]

>>>>> "amassa@cts" == amassa@cts com <amassa@cts.com> writes:

amassa@cts> Sorry for not posting to the discussion list directly, but
amassa@cts> as I told Jonathan before, because of my ISP my emails to
amassa@cts> the discussion list bounce back with an error thinking
amassa@cts> that I am spamming the discussion list.  I am trying to
amassa@cts> get it straightened out with my ISP but it is a slow
amassa@cts> process.  So I appologize for not posting to the list
amassa@cts> directly, but I will as soon as I can, but for now, I hope
amassa@cts> you can help me this way.

amassa@cts> As far as my problem goes, the memory region in the
amassa@cts> target.ld file is:

amassa@cts> MEMORY { ram : ORIGIN = 0, LENGTH = 0x400000 rom : ORIGIN
amassa@cts> = 0xfe000000, LENGTH = 0x800000 }


Which makes the error message rather confusing since it complained
about not being able to fit in 32kB - but neither block has such a
small length according to the above.

amassa@cts> And I tried a build from scratch on a different system and
amassa@cts> I still get the same error message.

Try this:

thinktwice:> ecosconfig new mbx stubs
7 conflict(s) resolved:
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied:  CYG_HAL_STARTUP == "ROM" 
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied: ! CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied: CYGSEM_HAL_ROM_MONITOR
 CYGBLD_BUILD_COMMON_GDB_STUBS:
  Requires constraint not satisfied: CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied: CYGBLD_BUILD_COMMON_GDB_STUBS
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied: ! CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT
 CYGBLD_BUILD_GDB_STUBS:
  Requires constraint not satisfied: ! CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM
thinktwice:> ecosconfig remove CYGPKG_IO
thinktwice:> ecosconfig remove CYGPKG_IO_SERIAL
thinktwice:> ecosconfig remove CYGPKG_ERROR    
thinktwice:> ecosconfig tree               
thinktwice:> make

And try to get the latest sources from CVS. You were using 1.3.1
sources, right?

amassa@cts> One thing I did try is changing the clock speed.  My MBX
amassa@cts> board has a 40 MHz clock.  The default on the stub build
amassa@cts> for the MBX board is 50 MHz.  I have been building with
amassa@cts> the 40 MHz selection.  However, last night just for grins
amassa@cts> I tried to load into flash a version with the 50 MHz
amassa@cts> version.  This gave some type of output from the MBX
amassa@cts> board, but then the processor crashed.

amassa@cts> Do you know of some problem using the 40 MHz selection?

amassa@cts> Has a stub been tested on the 40 MHz MBX board?

I can build for both 40 and 50 MHz configs, and I know we have boards
of both types running eCos.

Jesper

[ECOS] RE: MBX Board

[Jesper Skov]

>>>>> "amassa@cts" == amassa@cts com <amassa@cts.com> writes:

amassa@cts> It seems that there is some type of problem with the baud
amassa@cts> rate generator setup.  I am using version 1.3.1 of eCos.

amassa@cts> What directory are those commands run from?

Those are the command-line commands for building a stub. If you use
the config tool, try to remove the IO, IO_SERIAL and ERROR packages
before building the stub. It should reduce size a bit.

amassa@cts> Just for testing, I set the DIV16 bit in the BRGC1
amassa@cts> register when the baud rate is calculated in quicc_smc1.c
amassa@cts> line 111 (using 0x10001 instead of 0x10000).  And using
amassa@cts> the 40 MHz clock selection, I was able to see some output
amassa@cts> from the board.  I see a gdb packet come out and then the
amassa@cts> board keeps outputting ASCII character 0x81 (129 decimal).
amassa@cts> I then tried to run the eCos tests from the configuration
amassa@cts> tool and the host cannot connect to the target.

amassa@cts> Do you know what the problem might be?

No, sorry.

amassa@cts> Is it normal for the stub to output characters like this -
amassa@cts> I remember the email that Jonathan sent, he said that
amassa@cts> there would just be 1 packet from the board (stub) and it
amassa@cts> would be sent any time I hit return.  I don't see this
amassa@cts> behavior.

amassa@cts> Any help would be greatly appreciated.  I feel I'm getting
amassa@cts> close to understanding what might be the problem.

Well, it seems you'll have to do some investigation on your own.

Jesper

RE: [ECOS] Re: MBX Board

[Gary Thomas]

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
>>>>> 
>>> 
> 

RE: [ECOS] Re: MBX Board

[Gary Thomas]

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.

> 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

> 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.

> 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
>>> 
> 

RE: [ECOS] Re: MBX Board

[Gary Thomas]

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
> 

[ECOS] Re: MBX Board

[Jonathan Larmour]

"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