[ECOS] loader.bin sources?

[ECOS] loader.bin sources?

[Jamie Guinan]

Where are the sources for loaders/powerpc-cogent/gdbload.bin,
from eCos 1.2.1?

-Jamie

================================================================
Jamie Guinan                         Blue Button Solutions, Inc.
guinan@bluebutton.com                  http://www.bluebutton.com
================================================================

Re: [ECOS] loader.bin sources?

[Jonathan Larmour]

In article < Pine.LNX.3.96.990716140929.541A-100000@newt.home.net > you write:
>
>Where are the sources for loaders/powerpc-cogent/gdbload.bin,
>from eCos 1.2.1?

They are effectively just a configuration of eCos. Here's what to do:

1. Create a build directory and cd into it.

2. Run: tclsh <sourcedir>/pkgconf.tcl --target powerpc --platform cogent --startup rom --disable-kernel --disable-uitron --disable-libc --disable-libm --disable-io --disable-io_serial --disable-wallclock --disable-watchdog

Where <sourcedir> is the path to your source repository. Use "cygtclsh80"
in place of "tclsh" if you are on Windows, rather than Unix.

3. Edit pkgconf/hal.h *by hand* and enable the following "#define"s:

CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
CYG_HAL_ROM_MONITOR

You should also comment out the line:
#define CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT

4. Run: make

5. Run: make -C hal/common/current/src/stubrom

The file hal/common/current/src/stubrom/stubrom will be an ELF excutable
of the ROM. Use powerpc-eabi-objcopy to convert this to the appropriate
format for your PROM burner.

Hmm... perhaps I should put this in the FAQ. It's not very obvious :-).
Can you let me know if this works for you, and I'll do that.

Thanks,

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] loader.bin sources?

[Jamie Guinan]

On Fri, 16 Jul 1999, Jonathan Larmour wrote:

> 3. Edit pkgconf/hal.h *by hand* and enable the following "#define"s:
> 
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
> CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
> CYG_HAL_ROM_MONITOR
> 
> You should also comment out the line:
> #define CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT

I found that I had to #undef CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
or else I got "undefined reference to `dbg_currthread'" from
function "stub_lock_scheduler".

And there was no CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT to be
commented out.  GDB_BREAK_SUPPORT appears to handle ctrl-c
breaks, though.

Aside from that, I did manage to build a new stubrom image.
Thanks for the directions!

What I want to do next is make an stubrom image for the FADS 823
board.  I understand that the FADS is unsupported, but my client
(he has a Cygnus support contract) pointed me at the MBX HAL 
for an example.  For starters, it looks like the Cogent has
external 16550 uarts whereas the MBX and FADS use on-chip
SMCs or SCCs.

Bummer, I didn't bring home a copy of the MBX HAL code.  Any idea 
when the MBX code will make it into public CVS?

-Jamie

[ECOS] MBX stubrom (was [ECOS] loader.bin sources?)

[Jamie Guinan]

On Sun, 18 Jul 1999, Jamie Guinan wrote:

> What I want to do next is make an stubrom image for the FADS 823
> board.  I understand that the FADS is unsupported, but my client
> (he has a Cygnus support contract) pointed me at the MBX HAL 
> for an example.  For starters, it looks like the Cogent has
> external 16550 uarts whereas the MBX and FADS use on-chip
> SMCs or SCCs.
> 
> Bummer, I didn't bring home a copy of the MBX HAL code.  Any idea 
> when the MBX code will make it into public CVS?

No need, I have an NT system with the official-release eCos 1.2.3
available.

I tried building the MBX stubrom, but the command you suggested 
failed as follows,

$ cygtclsh80.exe ../packages/pkgconf.tcl --target powerpc --platform mbx
--startup rom --disable-kernel --disable uitron --disable-libc
--disable-libm --disable-io --disable-io_serial --disable-wallclock
--disable-watchdog
$ make
$ make -C hal/common/v1_2_3/src/stubrom
//D/PROGRA~1/CYGNUS~1/ECOS/ECOS-M~1/install/lib/libtarget.a(hal_powerpc_hal_intr.o):
In function `hal_IRQ_init':
//D/PROGRA~1/CYGNUS~1/ECOS/ECOS-M~1/install/include/cyg/hal/hal_intr.h:525:
undefined reference to `cyg_interrupt_post_dsr'
collect2: ld returned 1 exit status

Is there a different procedure for 1.2.3?

I've been following "initialize_stub()" through headers and sources,
and its pretty straight-forward, but I would like to have a
reproducible baseline to start with.

Thanks again,
-Jamie

RE: [ECOS] MBX stubrom (was [ECOS] loader.bin sources?)

[Gary Thomas]

Here's the script I use to do this (running on another platform).
Perhaps it will lend some help.  (Note: we're working on improving
both the documentation and procedure for making stubs...)

----------------- STUBS_config ------------------------------------
#! /bin/sh

tcl $1/pkgconf.tcl                                         \
  --target=arm --platform=pid --startup=stubs                   \
  --disable CYGPKG_KERNEL --disable CYGPKG_UITRON               \
  --disable CYGPKG_LIBC --disable CYGPKG_LIBM                   \
  --disable CYGPKG_ERROR --disable CYGPKG_IO                    \
  --disable CYGPKG_IO_SERIAL --disable CYGPKG_DEVICES_WALLCLOCK \
  --disable CYGPKG_DEVICES_WATCHDOG

patch <<END_OF_PATCH -p0
--- pkgconf/hal.h~      Wed Mar 10 13:08:58 1999
+++ pkgconf/hal.h       Thu Mar 11 15:53:16 1999
@@ -356,9 +356,9 @@
 
    }}CFG_DATA */
 
-#undef   CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
+#define  CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
 #undef   CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
-#define  CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
+#undef   CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT

END_OF_PATCH
-------------------------------------------------------------------

On 21-Jul-99 Jamie Guinan wrote:
> On Sun, 18 Jul 1999, Jamie Guinan wrote:
> 
>> What I want to do next is make an stubrom image for the FADS 823
>> board.  I understand that the FADS is unsupported, but my client
>> (he has a Cygnus support contract) pointed me at the MBX HAL 
>> for an example.  For starters, it looks like the Cogent has
>> external 16550 uarts whereas the MBX and FADS use on-chip
>> SMCs or SCCs.
>> 
>> Bummer, I didn't bring home a copy of the MBX HAL code.  Any idea 
>> when the MBX code will make it into public CVS?
> 
> No need, I have an NT system with the official-release eCos 1.2.3
> available.
> 
> I tried building the MBX stubrom, but the command you suggested 
> failed as follows,
> 
> $ cygtclsh80.exe ../packages/pkgconf.tcl --target powerpc --platform mbx
> --startup rom --disable-kernel --disable uitron --disable-libc
> --disable-libm --disable-io --disable-io_serial --disable-wallclock
> --disable-watchdog
> $ make
> $ make -C hal/common/v1_2_3/src/stubrom
> //D/PROGRA~1/CYGNUS~1/ECOS/ECOS-M~1/install/lib/libtarget.a(hal_powerpc_hal_in
> tr.o):
> In function `hal_IRQ_init':
> //D/PROGRA~1/CYGNUS~1/ECOS/ECOS-M~1/install/include/cyg/hal/hal_intr.h:525:
> undefined reference to `cyg_interrupt_post_dsr'
> collect2: ld returned 1 exit status
> 
> Is there a different procedure for 1.2.3?
> 
> I've been following "initialize_stub()" through headers and sources,
> and its pretty straight-forward, but I would like to have a
> reproducible baseline to start with.
> 
> Thanks again,
> -Jamie
> 

[ECOS] Re: MBX stubrom (was [ECOS] loader.bin sources?)

[Jonathan Larmour]

Jamie Guinan wrote:
> 
> On Sun, 18 Jul 1999, Jamie Guinan wrote:
> 
> > What I want to do next is make an stubrom image for the FADS 823
> > board.  I understand that the FADS is unsupported, but my client
> > (he has a Cygnus support contract) pointed me at the MBX HAL
> > for an example.  For starters, it looks like the Cogent has
> > external 16550 uarts whereas the MBX and FADS use on-chip
> > SMCs or SCCs.
> >
> > Bummer, I didn't bring home a copy of the MBX HAL code.  Any idea
> > when the MBX code will make it into public CVS?
> 
> No need, I have an NT system with the official-release eCos 1.2.3
> available.
> 
> I tried building the MBX stubrom, but the command you suggested
> failed as follows,
[snip]

I made a mistake - it turns out there are some differences between the MBX
and the platform I based my original answer on.

You should ensure that pkgconf/hal.h has the following "#define"s enabled:

CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
CYG_HAL_ROM_MONITOR

and the following commented out:

CYGFUN_HAL_COMMON_KERNEL_SUPPORT
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT

I actually tried it this time, and this should work :-).

The difference between it and the platform I was referring to before is that
the MBX ROM basically does nothing more than "load and go". If you want to
debug your application with GDB, you should enable 

CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and
CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT

HTH,

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Re: MBX stubrom (was [ECOS] loader.bin sources?)

[Jamie Guinan]

On Wed, 21 Jul 1999, Jonathan Larmour wrote:

> I made a mistake - it turns out there are some differences between the MBX
> and the platform I based my original answer on.

No fault of yours, I had asked about the Cogent before and you gave me
the right answer for that one.

> You should ensure that pkgconf/hal.h has the following "#define"s enabled:
> 
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> CYG_HAL_ROM_MONITOR
> 
> and the following commented out:
> 
> CYGFUN_HAL_COMMON_KERNEL_SUPPORT
> CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
> CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
> CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
> 
> I actually tried it this time, and this should work :-).

Yep, it works.  Thanks again!
 
> The difference between it and the platform I was referring to before is that
> the MBX ROM basically does nothing more than "load and go". If you want to
> debug your application with GDB, you should enable 
> 
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and
> CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT

Specifically, I would like to have the board boot up and wait for the
host-side gdb to connect to it so I can download and debug "ram"
applications.  Are those the correct defines for such behavior?
(They look right to me but you're the expert).

-Jamie

Re: [ECOS] Re: MBX stubrom (was [ECOS] loader.bin sources?)

[Jonathan Larmour]

Jamie Guinan wrote:
> 
> On Wed, 21 Jul 1999, Jonathan Larmour wrote:
> 
> > I made a mistake - it turns out there are some differences between the MBX
> > and the platform I based my original answer on.
> 
> No fault of yours, I had asked about the Cogent before and you gave me
> the right answer for that one.

Ah right. Phew :-).

> Yep, it works.  Thanks again!

Cool.
 
> > CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> > CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and
> > CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
> 
> Specifically, I would like to have the board boot up and wait for the
> host-side gdb to connect to it so I can download and debug "ram"
> applications.  Are those the correct defines for such behavior?
> (They look right to me but you're the expert).

Yep, that's right. The above defines are the ones required in your "ram"
application to be able to debug it in GDB.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault