[ECOS] Redboot - commands missing

Gary Thomas gthomas@redhat.com
Wed Dec 5 09:38:00 GMT 2001


On Wed, 2001-12-05 at 10:23, Daniel.Andersson@combitechsystems.com
wrote:
> Hi,
> 
> I have just got redboot running on my powerpc (TQC850) but i miss a whole
> bunch of commands. I have based my port on mbx860. When i type help this is
> the result:
> 
> ----snip----
> RedBoot> version
> 
> RedBoot(tm) bootstrap and debug environment [ROM]
> Non-certified release, version UNKNOWN - built 16:28:45, Dec  5 2001
> 
> Platform: Motorola TQC (PowerPC 850)
> Copyright (C) 2000, 2001, Red Hat, Inc.
> 
> RAM: 0x00000000-0x00400000, 0x00007a20-0x00400000 available
> RedBoot> help
> Manage machine caches
>    cache [ON | OFF]
> Display/switch console channel
>    channel [-1|<channel number>]
> Compute a 32bit checksum [POSIX algorithm] for a range of memory
>    cksum -b <location> -l <length>
> Display (hex dump) a range of memory
>    dump -b <location> [-l <length>] [-s]
> Execute code at a location
>    go [-w <timeout>] [entry]
> Help about help?
>    help [<topic>]
> Load a file
>    load [-r] [-v] [-h <host>] [-m {TFTP | xyzMODEM}]
>         [-b <base_address>] <file_name>
> Reset the system
>    reset
> Display RedBoot version information
>    version
> Display (hex dump) a range of memory
>    x -b <location> [-l <length>] [-s]
> RedBoot>
> ----snip----
> 
> I miss commands like: fis, alias, manage disks, baudrate, network features.
> 
> Any idéas how to make these commands available?

Yes, add them to your RedBoot configuration :-)

The basic 'redboot' template does not include FLASH or NET support 
because these are not always available.  So we add them as needed.
If your platform has drivers for these devices, you should be able
to just use these commands to add those functions:
  % ecosconfig add flash net_drivers
  % ecosconfig tree
  % make

> 
> Regards, Daniel
> 
> 
> 
> -----Original Message-----
> From: Nick Garnett [mailto:nickg@redhat.com]
> Sent: den 5 december 2001 17:30
> To: Patrick Doyle
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] from ISR to thread
> 
> 
> "Patrick Doyle" <wpd@delcomsys.com> writes:
> 
> > > ISR code:
> > > {
> > >   cyg_drv_isr_lock()
> > >   rbuf.putdata(hw.data)
> > >   cyg_drv_isr_unlock()
> > >
> > >   cyg_drv_interrupt_acknowledge()
> > >
> > >   return cyg_isr_call_dsr
> > > }
> > This one caught me by surprise.  Why would you have to an ISR 
> lock/unlock
> > from within an ISR?  Were you just being extra careful in 
> case some other
> > (higher priority?) ISR's happen to use the same ring buffer?
> > 
> 
> Partly that. Also in SMP systems, the thread may be running on a
> different CPU, so merely disabling interrupts on this CPU has no
> effect. To make the ISR lock usable it must also contain a spinlock,
> to block other CPUs if necessary. Hence it is necessary to use it in
> ISRs too.
> 
> -- 
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK




More information about the Ecos-discuss mailing list