[ECOS] RedBoot

[ECOS] RedBoot

[satish s mantri]

sir,
I am presently working on ecos (synthetic linux).I want to install RedBoot on i386 how do i proceed.
Thanks
Satish 

Re: Re: [ECOS] redboot

[Syed Ismail]

On Mon, 19 Nov 2007 Gary Thomas wrote :
> Syed Ismail wrote:
> > Hi
> > I Am working on redboot. I want to call a few defined 
> functions like do_fconfig();  do_exec(); in source code 
>  as soon as redboot prompt comes up. Where do i do this 
> and What are the command line arguements to pass.
> >   
> Your question is a bit vague.  Are you asking how to 
> execute a set of
> commands
> automatically when RedBoot comes up?  If so, look at 
> startup scripts.
> 
> -- 
> Gary Thomas

 I am in quite a mess,(hardware), actually. Please bear with me. I know i can execute any commands by writing a startup/boot script. I want to call it from code. for example, the command "version" is executed as do_version(0,0); in cyg_start().
         Similarly i want to call two fuctions, "do_load()" and "do_exec()" here. Can you please tell me the command line arguements to pass for these functions. I am just trying to skip a more messy problem by doing this. pl help. 
                                         Thank You

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] redboot

[Gary Thomas]

Syed Ismail wrote:
> 
> 
> On Mon, 19 Nov 2007 Gary Thomas wrote :
>> Syed Ismail wrote:
>>> Hi
>>> I Am working on redboot. I want to call a few defined 
>> functions like do_fconfig();  do_exec(); in source code 
>>  as soon as redboot prompt comes up. Where do i do this 
>> and What are the command line arguements to pass.
>>>   
>> Your question is a bit vague.  Are you asking how to 
>> execute a set of
>> commands
>> automatically when RedBoot comes up?  If so, look at 
>> startup scripts.
>>
>> -- 
>> Gary Thomas
> 
>  I am in quite a mess,(hardware), actually. Please bear with me. I know i can execute any commands by writing a startup/boot script. I want to call it from code. for example, the command "version" is executed as do_version(0,0); in cyg_start().

Why?  What's wrong with using a script?

>          Similarly i want to call two fuctions, "do_load()" and "do_exec()" here. Can you please tell me the command line arguements to pass for these functions. I am just trying to skip a more messy problem by doing this. pl help. 

It's pretty messy to call such functions directly.  You'd have to supply
a valid argc/argv list which corresponds to the arguments you need.

Again, why?

n.b. vague/unresponsive answers will most likely be ignored.




-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] redboot

[Syed Ismail]

Hi
I Am working on redboot. I want to call a few defined functions like do_fconfig();  do_exec(); in source code  as soon as redboot prompt comes up. Where do i do this and What are the command line arguements to pass.
                                                Thank You

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] redboot

[Gary Thomas]

Syed Ismail wrote:
> Hi
> I Am working on redboot. I want to call a few defined functions like do_fconfig();  do_exec(); in source code  as soon as redboot prompt comes up. Where do i do this and What are the command line arguements to pass.
>   
Your question is a bit vague.  Are you asking how to execute a set of
commands
automatically when RedBoot comes up?  If so, look at startup scripts.

-- 
Gary Thomas
Capt, CAP CO-021
home/office: (970) 352-4947,  cell: (970) 481-5112


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: Re: [ECOS] Redboot

[Syed Ismail]

On Mon, 12 Nov 2007 Andrew Lunn wrote :
> On Mon, Nov 12, 2007 at 08:38:52AM -0000, Syed Ismail 
> wrote:
> > 
> > Hi
> >   When i run redboot on my custom board, i get the 
> following message.
> > 
> > **Warning** FLASH configuration checksum error or 
> invalid key
> > Use 'fconfig -i' to [re]initialize database
> > 
> > fis list gives this
> > Name              FLASH addr  Mem addr    Length      
> Entry point
> > ReReoooococoigig  0xF000F000  0xF000F000  0x10001000  
> 0x00000000
> > 
> > 
> > What could be the issue. Could it be flash device 
> incompatibility. Please help.
> 
> Did you notice that Redboot says this:
> 
> Use 'fconfig -i' to [re]initialize database
> 
> What happens when you do this?
> 
> You may also want to try
> 
> fis init
> 
> The RedBoot manual is:
> 
> http://ecos.sourceware.org/docs-latest/redboot/redboot-g-
> uide.html
> 
>      Andrew
Hi
 I found that redboot configuration does not get written into flash properly. So, the checksum error. For example, config key1 0BADFACE gets written as FACEFACE. Where could be the issue. 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot

[Gary Thomas]

Syed Ismail wrote:
> 
> 
> On Mon, 12 Nov 2007 Andrew Lunn wrote :
>> On Mon, Nov 12, 2007 at 08:38:52AM -0000, Syed Ismail 
>> wrote:
>>> Hi
>>>   When i run redboot on my custom board, i get the 
>> following message.
>>> **Warning** FLASH configuration checksum error or 
>> invalid key
>>> Use 'fconfig -i' to [re]initialize database
>>>
>>> fis list gives this
>>> Name              FLASH addr  Mem addr    Length      
>> Entry point
>>> ReReoooococoigig  0xF000F000  0xF000F000  0x10001000  
>> 0x00000000
>>>
>>> What could be the issue. Could it be flash device 
>> incompatibility. Please help.
>>
>> Did you notice that Redboot says this:
>>
>> Use 'fconfig -i' to [re]initialize database
>>
>> What happens when you do this?
>>
>> You may also want to try
>>
>> fis init
>>
>> The RedBoot manual is:
>>
>> http://ecos.sourceware.org/docs-latest/redboot/redboot-g-
>> uide.html
>>
>>      Andrew
> Hi
>  I found that redboot configuration does not get written into flash properly. So, the checksum error. For example, config key1 0BADFACE gets written as FACEFACE. Where could be the issue. 

It looks like your FLASH doesn't read 32 bit quantities properly.
Unless your FLASH driver sets 'CYGSEM_IO_FLASH_READ_INDIRECT', RedBoot
will read the FLASH (FIS directory, FCONFIG data, etc) directly from
the FLASH, using the most expedient means possible.  On most platforms,
this will be using normal 'memcpy()'.  Depending on how your device
and system are configured, this will possibly go through a data cache
which may also be causing problems.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Redboot

[Syed Ismail]

Hi
  When i run redboot on my custom board, i get the following message.

**Warning** FLASH configuration checksum error or invalid key
Use 'fconfig -i' to [re]initialize database

fis list gives this
Name              FLASH addr  Mem addr    Length      Entry point
ReReoooococoigig  0xF000F000  0xF000F000  0x10001000  0x00000000


What could be the issue. Could it be flash device incompatibility. Please help.


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot

[Andrew Lunn]

On Mon, Nov 12, 2007 at 08:38:52AM -0000, Syed Ismail wrote:
> 
> Hi
>   When i run redboot on my custom board, i get the following message.
> 
> **Warning** FLASH configuration checksum error or invalid key
> Use 'fconfig -i' to [re]initialize database
> 
> fis list gives this
> Name              FLASH addr  Mem addr    Length      Entry point
> ReReoooococoigig  0xF000F000  0xF000F000  0x10001000  0x00000000
> 
> 
> What could be the issue. Could it be flash device incompatibility. Please help.

Did you notice that Redboot says this:

Use 'fconfig -i' to [re]initialize database

What happens when you do this?

You may also want to try

fis init

The RedBoot manual is:

http://ecos.sourceware.org/docs-latest/redboot/redboot-guide.html

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Redboot

[Syed Ismail]

Hi
1)  When i build redboot, i get a warning-
BFD: /home/ismail/ecos/ecos-2.0/tools/bin/nov1-0_install/bin/redboot.img: warning: allocated section `.bss' not in segment.
This is what i have in .ldi file.
MEMORY
{
    ram : ORIGIN = 0x80000000, LENGTH = 0x1000000
    rom : ORIGIN = 0xA0000000, LENGTH = 0x100000
}
SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors (rom, 0xA0000000, LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (ram, 0x80000020, LMA_EQ_VMA)
    SECTION_data (ram, 0x80008000, FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}

2) I came to know execution starts from hal_platform_setup.h which is assembly lang. Will any changes here get reflected in the built .bin file. Maybe this is a crazy quesstion? I ask bcoz i tried to toggle a pin by writing code here. But none of the code i inserted gets included in the built .bin file. (It is not execution problem. The extra code isnt included). Please help.
                                           Ismail

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] RedBoot

[Yuriy V.]

Hi,

Plz can anybody tell me what is CYGHWR_REDBOOT_ARM_TRAMPOLINE_ADDRESS
in redboot_linux_exec.c

Regards,
Yuriy

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] redboot

[rameshs]

Hi,
       I installed a redboot image in tqm850 board.I have a problem in
downloading an application using 
Redboot load command through x modem or y modem.If i download an application
image with x modem it is currepting the image .It means it is not loading
the correct image.
      I used the following commad.
              load -r -v -m xmodem -b 0x40000.

      If any one knows give information about why the loaded image is
currpting.I used only the ram image.

Thank You,
S.Ramesh Chandra.

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot

[Jonathan Larmour]

rameshs@danlawinc.com wrote:
> Hi,
>        I installed a redboot image in tqm850 board.I have a problem in
> downloading an application using 
> Redboot load command through x modem or y modem.If i download an application
> image with x modem it is currepting the image .It means it is not loading
> the correct image.
>       I used the following commad.
>               load -r -v -m xmodem -b 0x40000.
> 
>       If any one knows give information about why the loaded image is
> currpting.I used only the ram image.

If you're using "-r" I take it you are sending the binary file, right? :-)

NB, the "-v" shouldn't have any effect with -m xmodem.

Try sending a .srec (and drop the -r). If that works, but binary (.bin) 
files with "-r" still don't, then let us know as that may indicate a 
problem with raw loads.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] RedBoot

[Gustav Kälvesten]

I guess you start with reading the documentation. Have a look at e.g.:
http://sources.redhat.com/ecos/docs-latest/redboot/x86pc.html
http://sources.redhat.com/ecos/boards/pcmobo.html

But RedBoot for Synthetic Linux target doesn't make sense for me. Why would you need a boot strapper?

- Gustav

> -----Original Message-----
> From: satish s mantri [mailto:satish_mantri@rediffmail.com]
> Sent: den 27 december 2001 16:07
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] RedBoot
> 
> 
> 
> sir,
> I am presently working on ecos (synthetic linux).I want to 
> install RedBoot on i386 how do i proceed.
> Thanks
> Satish 
> 

[ECOS] redboot

[mekala natarajan]

I applied the patch which was sent yesterday.
Still i face the same problem.

Mr.Anthony, are you able to do ethernet debugging
after adding the patch.


RedBoot> go 20000
$T04thread:00000000;40:00004e20;01:000055f4;#53$T04thread:00000000;40:00004e20;0
1:000055f4;#53$T04thread:00000000;40:00004e20;01:000055f4;#53$T04thread:00000000
;40:00004e20;01:000055f4;#53


mekala


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: [ECOS] RedBoot

[Anthony Massa]

> >
> > I initially single-stepped through the first for loop and the board 
>hung.
> > Then I read the very detailed comment before which explicitly says not 
>to do
> > this.  So I re-ran the application and stepped over it and it still hung 
>the
> > board.  I tried to set a breakpoint at the next function call after
> > hal_if_init(), and the board still hangs before hitting the breakpoint.
> >
> > Is there something I should look at or try?
>
>Setting a breakpoint much further in the initialization, like cyg_start.


Are you talking about setting it in stubrom.c or in vectors.S?  Is there a 
way to view the assembly source files?  When I start Insight and load my 
.img file, I am only able to browse .c and .cxx files.  Do I need to use the 
console to set the breakpoint in the .S file?

I have set a breakpoint in my cyg_user_start() routine and found that it 
never got to that point.  I was getting the unreadable output that I 
mentioned before after the "Network stack using 65536 bytes for misc space" 
message.  And then the board just seemed to be hung.

Thanks.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> > >
> > > I initially single-stepped through the first for loop and the board
> >hung.
> > > Then I read the very detailed comment before which explicitly says not
> >to do
> > > this.  So I re-ran the application and stepped over it and it still hung
> >the
> > > board.  I tried to set a breakpoint at the next function call after
> > > hal_if_init(), and the board still hangs before hitting the breakpoint.
> > >
> > > Is there something I should look at or try?
> >
> >Setting a breakpoint much further in the initialization, like cyg_start.
> 
> Are you talking about setting it in stubrom.c or in vectors.S?

Hold on, stubrom.c? It sounds like you're trying to run a GDB stub rom
image under RedBoot? All I was talking about was setting a breakpoint at
some point _after_ system initialization time.

You should have just got a clean build tree and rebuilt from scratch in the
default configuration. Just try that in the first instance and make sure
that works. Unless you know that does already work, in which case we'd want
to know what you've changed!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RedBoot

[Anthony Massa]

I am able to open my mbx.img file and download it to the target.

I have found that Insight hangs in the function hal_if_init() in
\common\hal_if.c.

Could you help me out as to what may be causing this problem?

Thanks.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I am able to open my mbx.img file and download it to the target.
> 
> I have found that Insight hangs in the function hal_if_init() in
> \common\hal_if.c.
> 
> Could you help me out as to what may be causing this problem?

Are you single stepping through it? Does it work correctly if you step over
it?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] RedBoot

[Anthony Massa]

> > I am able to open my mbx.img file and download it to the target.
> >
> > I have found that Insight hangs in the function hal_if_init() in
> > \common\hal_if.c.
> >
> > Could you help me out as to what may be causing this problem?
>
> Are you single stepping through it? Does it work correctly if you
> step over
> it?
>


I initially single-stepped through the first for loop and the board hung.
Then I read the very detailed comment before which explicitly says not to do
this.  So I re-ran the application and stepped over it and it still hung the
board.  I tried to set a breakpoint at the next function call after
hal_if_init(), and the board still hangs before hitting the breakpoint.

Is there something I should look at or try?

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I initially single-stepped through the first for loop and the board hung.
> Then I read the very detailed comment before which explicitly says not to do
> this.  So I re-ran the application and stepped over it and it still hung the
> board.  I tried to set a breakpoint at the next function call after
> hal_if_init(), and the board still hangs before hitting the breakpoint.
> 
> Is there something I should look at or try?

Setting a breakpoint much further in the initialization, like cyg_start.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] RedBoot

[Anthony Massa]

I have rebuilt ecos using the default configuration for the MBX template.  I
rebuilt my application using the new ecos build.  I then downloaded the code
and set a breakpoint at cyg_start().  I am still seeing the board hang when
I run the code.  On the RedBoot serial port I get a $T... string GDB output
message.  I can hit return when I am on the terminal connected to the serial
port and I get the same $T string GDB message.  I'm really confused as to
why this is hanging.

RE: [ECOS] RedBoot

[Anthony Massa]

I found that I was having the same problems as the ones discussed in this
post:
http://sources.redhat.com/ml/ecos-discuss/2001-04/msg00006.html

After getting past that, I am now finding that my code loads over the
Ethernet port.  However, when I run my code it prints out the networking
information, such as "Network stack using..." then I get a message:

[New thread 1]

The board then seems to hang for a little while and then the program stops.
I have breakpoints at cyg_start and cyg_user_start, however, neither of
these get hit by the debugger.  The target disconnects from the debugger as
well.

Any help?

Thanks.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I found that I was having the same problems as the ones discussed in this
> post:
> http://sources.redhat.com/ml/ecos-discuss/2001-04/msg00006.html
> 
> After getting past that, I am now finding that my code loads over the
> Ethernet port.  However, when I run my code it prints out the networking
> information, such as "Network stack using..." then I get a message:
> 
> [New thread 1]
> 
> The board then seems to hang for a little while and then the program stops.
> I have breakpoints at cyg_start and cyg_user_start, however, neither of
> these get hit by the debugger.  The target disconnects from the debugger as
> well.

Well, this may indicate that it did hit the breakpoint, but has failed for
some other reason. Does it do the same thing when you don't set
breakpoints?

Also try enabling remote protocol debugging in GDB using "set remotedebug
1" (or in newer versions, "set debug remote 1"). 

Earlier you wrote:
> I have rebuilt ecos using the default configuration for the MBX template.  I
> rebuilt my application using the new ecos build.  I then downloaded the code
> and set a breakpoint at cyg_start().  I am still seeing the board hang when
> I run the code.  On the RedBoot serial port I get a $T... string GDB output
> message.  I can hit return when I am on the terminal connected to the serial
> port and I get the same $T string GDB message.  I'm really confused as to
> why this is hanging.

The $T string means that the target is reporting a signal and trying to
inform GDB - probably the breakpoint you hit. But if it's coming out the
serial port, whereas if GDB is connected over ethernet you won't see it.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RedBoot

[Anthony Massa]

I am trying to download code using GDB/Insight with my MBX860 target running
RedBoot.  I am a little confused as to the sequence of the commands I need
to use.  What I am doing is in Insight I use Run->Connect to Target.  I then
connect via Remote/TCP using the IP address and port 9000.  I get a
successfully connected message.

What do I do next to run my code on the target?

Do I use the .img file or .srec file?

Thanks.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> I am trying to download code using GDB/Insight with my MBX860 target running
> RedBoot.  I am a little confused as to the sequence of the commands I need
> to use.  What I am doing is in Insight I use Run->Connect to Target.  I then
> connect via Remote/TCP using the IP address and port 9000.  I get a
> successfully connected message.
> 
> What do I do next to run my code on the target?
> 
> Do I use the .img file or .srec file?

The fact you are mentioning those extensions seems to indicate confusion -
those extensions are only likely to be relevant for RedBoot itself but you
say RedBoot's already on your board, so you don't have to do anything with
any other RedBoot files.

Any applications you've built in ecos will be in ELF format and can be
downloaded just by selecting it with File->Open, setting a breakpoint if
you like, probably opening the console window with View->Console to see any
output, and then hitting the Run button which should both download and run
your program.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] RedBoot

[Anthony Massa]

> >
> > I am trying to download code using GDB/Insight with my MBX860
> target running
> > RedBoot.  I am a little confused as to the sequence of the
> commands I need
> > to use.  What I am doing is in Insight I use Run->Connect to
> Target.  I then
> > connect via Remote/TCP using the IP address and port 9000.  I get a
> > successfully connected message.
> >
> > What do I do next to run my code on the target?
> >
> > Do I use the .img file or .srec file?
>
> The fact you are mentioning those extensions seems to indicate confusion -
> those extensions are only likely to be relevant for RedBoot itself but you
> say RedBoot's already on your board, so you don't have to do anything with
> any other RedBoot files.


When I compile my application, the output is an mbx.img and mbx.srec file.
I guess the confusion is that I was not referring to any RedBoot files,
rather my
application files.

>
> Any applications you've built in ecos will be in ELF format and can be
> downloaded just by selecting it with File->Open, setting a breakpoint if
> you like, probably opening the console window with View->Console
> to see any
> output, and then hitting the Run button which should both download and run
> your program.


So, I guess I would open my mbx.img file and run it.

Re: [ECOS] RedBoot

[Jonathan Larmour]

Anthony Massa wrote:
> 
> When I compile my application, the output is an mbx.img and mbx.srec file.
> I guess the confusion is that I was not referring to any RedBoot files,
> rather my
> application files.

Ah you made the srec file yourself.
 
> > Any applications you've built in ecos will be in ELF format and can be
> > downloaded just by selecting it with File->Open, setting a breakpoint if
> > you like, probably opening the console window with View->Console
> > to see any
> > output, and then hitting the Run button which should both download and run
> > your program.
> 
> So, I guess I would open my mbx.img file and run it.

Yep.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Redboot

[Jesper Skov]

>>>>> "John" == John Carter <john@rhinosys.com> writes:

John> Does anyone know why it must be programmed into the socketed
John> flash?  I need to put it into the soldered flash as well.

Doesn't really matter since they switch places in the address map
depending on the jumper settings, right?

The reason the _documentation_ contains directions for the socketed
flash is probably more or less a random decision. Not that I know for
sure. Gary did the port.

Jesper

RE: [ECOS] RedBoot

[Gary Thomas]

 
On 29-Dec-2000 Anthony Massa wrote:
> The error I get is:
> 
> Can't load 'mbx.img': operation timed out.

Are you sure that you are running a TFTP server (and not FTP)?

> 
> 
>>
>> On 28-Dec-2000 Anthony Massa wrote:
>> > The patch seems to work.  I can run my bootp server on my NT
>> workstation and
>> > with the MBX board in non-debug mode, an IP address gets assigned.
>> >
>> > I am not able to download a file, though.  I have my file in my d:\temp
>> > directory.  I startup the TFTP server program I have and try to run the
>> > following command under redboot:
>> >
>> > load -v -m TFTP d:\temp\mbx.img
>> >
>> >
>> > However, I always get an error that redboot cannot load the
>> image.  What am
>> > I doing wrong?
>> >
>>
>> What error do you get?  Some TFTP servers insist that the downloaded file
>> exist in a special directory and that the name provided [by you]
>> be relative
>> to that directory.  This is for security purposes since TFTP has
>> no authentication.
>>
>> > What port does redboot use for tftp (21)?
>>
>> The default port - UDP port #69.
>>
>> >
>> >
>> > Thanks a bunch for all the help.
>> >
>> >
>> >
>> >>
>> >> There seems to be some problems with timing in RedBoot.  Try using this
>> >> patch and see if it helps.  Note: this _may_ help with both BOOTP and
>> >> the TFTP load problems you are having.
>> >>
>> >> Index: hal/powerpc/arch/current/src/hal_intr.c
>> >> ===================================================================
>> >> RCS file: /home/cvs/ecc/ecc/hal/powerpc/arch/current/src/hal_intr.c,v
>> >> retrieving revision 1.13
>> >> diff -u -5 -p -r1.13 hal_intr.c
>> >> --- hal/powerpc/arch/current/src/hal_intr.c     2000/10/20
>> >> 23:58:56     1.13
>> >> +++ hal/powerpc/arch/current/src/hal_intr.c     2000/12/28 14:24:43
>> >> @@ -63,12 +63,13 @@ hal_delay_us(int us)
>> >>  {
>> >>      cyg_uint32 old_dec, new_dec;
>> >>      long ticks;
>> >>      // Note: the system constant CYGNUM_HAL_RTC_PERIOD
>> >> corresponds to 10,000us
>> >>      // Scale the desired number of microseconds to be a number
>> >> of decrementer ticks
>> >> +    // Note: this test says "if there is more than one
>> >> decrementer tick / us"
>> >>      if (CYGNUM_HAL_RTC_PERIOD > 10000) {
>> >> -        ticks = us * (CYGNUM_HAL_RTC_PERIOD * 100) / 1000000;
>> >> +        ticks = ((long long)us * (CYGNUM_HAL_RTC_PERIOD * 100))
>> >> / 1000000;
>> >>      } else {
>> >>          ticks = us / (CYGNUM_HAL_RTC_PERIOD * 100) / 1000000;
>> >>      }
>> >>      asm volatile("mfdec  %0;" : "=r"(old_dec) : );
>> >>      while (ticks-- > 0) {
>> >>
>> >> On 28-Dec-2000 Anthony Massa wrote:
>> >> > I am running a BOOTP server on my NT machine and now I am
>> able to also
>> >> > connect with the telnet program.  One problem is that the board
>> >> can only get
>> >> > an IP address (via BOOTP) if the debug output is enabled.
>> If not, BOOTP
>> >> > does not work.  Do you know where this problem may be?
>> >> >
>> >> >
>> >> >> On 28-Dec-2000 Anthony Massa wrote:
>> >> >> > The GDB connection port is currently 0.  Is this what I should
>> >> >> leave it as,
>> >> >> > or should I change it?
>> >> >> >
>> >> >> > Can I change it to whatever I want?
>> >> >> >
>> >> >>
>> >> >> Yes.  I'd suggest something non-priveledged, like 9000.
>> >> >>
>> >> >> > I don't know how to change the port for the Win NT telnet
>> >> >> program, do you?
>> >> >> >
>> >> >>
>> >> >> No, but surely there is a way.  You could always set RedBoot to
>> >> >> use port 23
>> >> >> which is the default telnet port.
>> >> >>
>> >> >> >
>> >> >> > This first dump is with static IP addresses.  The second is
>> >> with BOOTP
>> >> >> > enabled.
>> >> >>
>> >> >> It looks like the ESA got set correctly.  There may be some
>> >> other problem
>> >> >> with the BOOTP setup.  Probably a Win/NT question, sorry I can't
>> >> >> help much.
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > RedBoot(tm) debug environment - built 16:30:52, Dec 27 2000
>> >> >> > Platform: Motorola MBX (PowerPC 860)
>> >> >> > Copyright (C) 2000, Red Hat, Inc.
>> >> >> >
>> >> >> > RAM: 0x00000000-0x00400000
>> >> >> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
>> >> >> > IP: 192.168.0.5, Default server: 192.168.0.3
>> >> >> > RedBoot> Ethernet recv:
>> >> >> > 0x0000A83C: FFFF FFFF FFFF 0060  975B 43B8 0800
>> >> >> |.......`.[C...  |
>> >> >> > 0x0000A84A: 4500 004E AC04 0000  8011 0C48 C0A8 0003
>> >> >> |E..N.......H....|
>> >> >> > 0x0000A85A: C0A8 00FF 0089 0089  003A 9B63 823E 0110
>> >> >> |.........:.c.>..|
>> >> >> > 0x0000A86A: 0001 0000 0000 0000  2045 4846 4345 5046
>> >> >> |........ EHFCEPF|
>> >> >> > 0x0000A87A: 4646 4144 4243 4143  4143 4143 4143 4143
>> >> >> |FFADBCACACACACAC|
>> >> >> > 0x0000A88A: 4143 4143 4143 4142  4C00 0020 0001 3F4B
>> >> >> |ACACACABL.. ..?K|
>> >> >> > 0x0000A89A: 91B6                                       |..
>> >> >>         |
>> >> >> > Ethernet recv:
>> >> >> > 0x0000AE4C: FFFF FFFF FFFF 0060  975B 43B8 0800
>> >> >> |.......`.[C...  |
>> >> >> > 0x0000AE5A: 4500 004E AD04 0000  8011 0B48 C0A8 0003
>> >> >> |E..N.......H....|
>> >> >> > 0x0000AE6A: C0A8 00FF 0089 0089  003A 9B63 823E 0110
>> >> >> |.........:.c.>..|
>> >> >> > 0x0000AE7A: 0001 0000 0000 0000  2045 4846 4345 5046
>> >> >> |........ EHFCEPF|
>> >> >> > 0x0000AE8A: 4646 4144 4243 4143  4143 4143 4143 4143
>> >> >> |FFADBCACACACACAC|
>> >> >> > 0x0000AE9A: 4143 4143 4143 4142  4C00 0020 0001 CB64
>> >> >> |ACACACABL.. ...d|
>> >> >> > 0x0000AEAA: 1FB1                                       |..
>> >> >>         |
>> >> >> > Ethernet recv:
>> >> >> > 0x0000B45C: FFFF FFFF FFFF 0060  975B 43B8 0800
>> >> >> |.......`.[C...  |
>> >> >> > 0x0000B46A: 4500 004E AE04 0000  8011 0A48 C0A8 0003
>> >> >> |E..N.......H....|
>> >> >> > 0x0000B47A: C0A8 00FF 0089 0089  003A 9B63 823E 0110
>> >> >> |.........:.c.>..|
>> >> >> > 0x0000B48A: 0001 0000 0000 0000  2045 4846 4345 5046
>> >> >> |........ EHFCEPF|
>> >> >> > 0x0000B49A: 4646 4144 4243 4143  4143 4143 4143 4143
>> >> >> |FFADBCACACACACAC|
>> >> >> > 0x0000B4AA: 4143 4143 4143 4142  4C00 0020 0001 45D9
>> >> >> |ACACACABL.. ..E.|
>> >> >> > 0x0000B4BA: 8326                                       |.&
>> >> >>         |
>> >> >> > Ethernet recv:
>> >> >> > 0x0000BA6C: FFFF FFFF FFFF 0060  975B 43B8 0800
>> >> >> |.......`.[C...  |
>> >> >> > 0x0000BA7A: 4500 004E AF04 0000  8011 0948 C0A8 0003
>> >> >> |E..N.......H....|
>> >> >> > 0x0000BA8A: C0A8 00FF 0089 0089  003A 9B5F 8242 0110
>> >> >> |.........:._.B..|
>> >> >> > 0x0000BA9A: 0001 0000 0000 0000  2045 4846 4345 5046
>> >> >> |........ EHFCEPF|
>> >> >> > 0x0000BAAA: 4646 4144 4243 4143  4143 4143 4143 4143
>> >> >> |FFADBCACACACACAC|
>> >> >> > 0x0000BABA: 4143 4143 4143 4142  4C00 0020 0001 0611
>> >> >> |ACACACABL.. ....|
>> >> >> > 0x0000BACA: 04A5                                       |..
>> >> >>         |
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ==============================================
>> >> >> > START OF SECOND DUMP
>> >> >> > ==============================================
>> >> >> >
>> >> >> > RedBoot(tm) debug environment - built 16:30:52, Dec 27 2000
>> >> >> > Platform: Motorola MBX (PowerPC 860)
>> >> >> > Copyright (C) 2000, Red Hat, Inc.
>> >> >> >
>> >> >> > RAM: 0x00000000-0x00400000
>> >> >> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
>> >> >> > Ethernet send:
>> >> >> > 0x00004A64: FFFF FFFF FFFF 0800  3E27 5ADC 0800
>> >> >> |........>'Z...  |
>> >> >> > 0x00011B44: 4500 0148 0000 0000  4011 79A6 0000 0000
>> >> >> |E..H....@.y.....|
>> >> >> > 0x00011B54: FFFF FFFF 0044 0043  0134 ED71 0101 0600
>> >> >> |.....D.C.4.q....|
>> >> >> > 0x00011B64: 1234 5555 0000 0000  0000 0000 0000 0000
>> >> >> |.4UU............|
>> >> >> > 0x00011B74: 0000 0000 0000 0000  0800 3E27 5ADC 0000
>> >> >> |..........>'Z...|
>> >> >> > 0x00011B84: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011B94: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BA4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BB4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BC4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BD4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BE4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BF4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C04: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C14: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C24: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C34: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C44: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C54: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C64: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C74: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C84: 0000 0000 0000 0000
>> >> >> |........        |
>> >> >> > Ethernet send:
>> >> >> > 0x00004A64: FFFF FFFF FFFF 0800  3E27 5ADC 0800
>> >> >> |........>'Z...  |
>> >> >> > 0x00011B44: 4500 0148 0001 0000  4011 79A5 0000 0000
>> >> >> |E..H....@.y.....|
>> >> >> > 0x00011B54: FFFF FFFF 0044 0043  0134 ED71 0101 0600
>> >> >> |.....D.C.4.q....|
>> >> >> > 0x00011B64: 1234 5555 0000 0000  0000 0000 0000 0000
>> >> >> |.4UU............|
>> >> >> > 0x00011B74: 0000 0000 0000 0000  0800 3E27 5ADC 0000
>> >> >> |..........>'Z...|
>> >> >> > 0x00011B84: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011B94: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BA4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BB4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BC4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BD4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BE4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BF4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C04: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C14: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C24: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C34: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C44: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C54: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C64: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C74: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C84: 0000 0000 0000 0000
>> >> >> |........        |
>> >> >> > Ethernet send:
>> >> >> > 0x00004A64: FFFF FFFF FFFF 0800  3E27 5ADC 0800
>> >> >> |........>'Z...  |
>> >> >> > 0x00011B44: 4500 0148 0002 0000  4011 79A4 0000 0000
>> >> >> |E..H....@.y.....|
>> >> >> > 0x00011B54: FFFF FFFF 0044 0043  0134 ED71 0101 0600
>> >> >> |.....D.C.4.q....|
>> >> >> > 0x00011B64: 1234 5555 0000 0000  0000 0000 0000 0000
>> >> >> |.4UU............|
>> >> >> > 0x00011B74: 0000 0000 0000 0000  0800 3E27 5ADC 0000
>> >> >> |..........>'Z...|
>> >> >> > 0x00011B84: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011B94: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BA4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BB4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BC4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BD4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BE4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011BF4: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C04: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C14: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C24: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C34: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C44: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C54: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C64: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C74: 0000 0000 0000 0000  0000 0000 0000 0000
>> >> >> |................|
>> >> >> > 0x00011C84: 0000 0000 0000 0000
>> >> >> |........        |
>> >> >> > Can't get BOOTP info - network disabled!
>> >> >> > RedBoot>
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> On 28-Dec-2000 Anthony Massa wrote:
>> >> >> >> > I was able to change the MAC address (using fconfig).  I am
>> >> >> >> able to do ping
>> >> >> >> > from Win NT host and get back packets.  I cannot run using
>> >> >> >> BOOTP, I must use
>> >> >> >> > a static IP address.
>> >> >> >> >
>> >> >> >>
>> >> >> >> Can you send me the output from turning on the network debug
>> >> >> (via fconfig)
>> >> >> >> just to make sure that the address is getting set correctly?
>> >> >> >>
>> >> >> >> > However, I still am not able to run the telnet application and
>> >> >> >> connect to
>> >> >> >> > the MBX board.  Do you know what is the problem there?
>> >> >> >> >
>> >> >> >>
>> >> >> >> What port did you set?  You must connect to the "GDB
>> >> >> connection port", not
>> >> >> >> the default port 23 (telnet port).  Still use telnet, just
>> >> >> force the port
>> >> >> >> that RedBoot is using.
>> >> >> >>
>> >> >> >> > Do I need to run a BOOTP server from my host?
>> >> >> >> >
>> >> >> >> > Should I try a tftp server application?
>> >> >> >>
>> >> >> >> These are both up to you, based on your needs.
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> As I expected, the problem is that RedBoot/eCos can't get
>> >> >> at the NVRAM
>> >> >> >> >> information.  This is because the NVRAM is connected via the
>> >> >> >> I2C interface
>> >> >> >> >> and that is broken on the MBX!  I've not been able to
>> >> >> figure out how to
>> >> >> >> >> make it work reliably.
>> >> >> >> >>
>> >> >> >> >> However, the attached patch should let you get by.
>> It adds some
>> >> >> >> >> additional
>> >> >> >> >> information kept by RedBoot.  Basically, run 'fconfig' and
>> >> >> >> enter the ESA
>> >> >> >> >> (MAC) address manually.  Then RedBoot and eCos
>> programs will be
>> >> >> >> >> able to set
>> >> >> >> >> up the interface properly.
>> >> >> >> >>
>> >> >> >> >> Let me know if this works/helps/...  If so, I'll apply it
>> >> >> permanently.
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

RE: [ECOS] RedBoot

[Anthony Massa]

I am able to get it to start downloading the file now.

I'm getting a checksum failure at 8c840 though.

And I also run out of mbufs, do you know what the cause for this is?


>  
> On 29-Dec-2000 Anthony Massa wrote:
> > The error I get is:
> > 
> > Can't load 'mbx.img': operation timed out.
> 
> Are you sure that you are running a TFTP server (and not FTP)?
> 
> > 
> > 
> >>
> >> On 28-Dec-2000 Anthony Massa wrote:
> >> > The patch seems to work.  I can run my bootp server on my NT
> >> workstation and
> >> > with the MBX board in non-debug mode, an IP address gets assigned.
> >> >
> >> > I am not able to download a file, though.  I have my file in 
> my d:\temp
> >> > directory.  I startup the TFTP server program I have and try 
> to run the
> >> > following command under redboot:
> >> >
> >> > load -v -m TFTP d:\temp\mbx.img
> >> >
> >> >
> >> > However, I always get an error that redboot cannot load the
> >> image.  What am
> >> > I doing wrong?
> >> >
> >>
> >> What error do you get?  Some TFTP servers insist that the 
> downloaded file
> >> exist in a special directory and that the name provided [by you]
> >> be relative
> >> to that directory.  This is for security purposes since TFTP has
> >> no authentication.
> >>
> >> > What port does redboot use for tftp (21)?
> >>
> >> The default port - UDP port #69.
> >>
> >> >
> >> >
> >> > Thanks a bunch for all the help.
> >> >
> 

RE: [ECOS] RedBoot

[Gary Thomas]

On 01-Jan-2001 Anthony Massa wrote:
> I am able to get it to start downloading the file now.
> 
> I'm getting a checksum failure at 8c840 though.

Is this _with_ the timer patch I provided?

> 
> And I also run out of mbufs, do you know what the cause for this is?

Surely this is with eCos, not RedBoot (since RedBoot does not use MBUFs).
Can you duplicate it?  provide a failing case or scenario?

> 
> 
>>  
>> On 29-Dec-2000 Anthony Massa wrote:
>> > The error I get is:
>> > 
>> > Can't load 'mbx.img': operation timed out.
>> 
>> Are you sure that you are running a TFTP server (and not FTP)?
>> 
>> > 
>> > 
>> >>
>> >> On 28-Dec-2000 Anthony Massa wrote:
>> >> > The patch seems to work.  I can run my bootp server on my NT
>> >> workstation and
>> >> > with the MBX board in non-debug mode, an IP address gets assigned.
>> >> >
>> >> > I am not able to download a file, though.  I have my file in 
>> my d:\temp
>> >> > directory.  I startup the TFTP server program I have and try 
>> to run the
>> >> > following command under redboot:
>> >> >
>> >> > load -v -m TFTP d:\temp\mbx.img
>> >> >
>> >> >
>> >> > However, I always get an error that redboot cannot load the
>> >> image.  What am
>> >> > I doing wrong?
>> >> >
>> >>
>> >> What error do you get?  Some TFTP servers insist that the 
>> downloaded file
>> >> exist in a special directory and that the name provided [by you]
>> >> be relative
>> >> to that directory.  This is for security purposes since TFTP has
>> >> no authentication.
>> >>
>> >> > What port does redboot use for tftp (21)?
>> >>
>> >> The default port - UDP port #69.
>> >>
>> >> >
>> >> >
>> >> > Thanks a bunch for all the help.
>> >> >
>> 

RE: [ECOS] RedBoot

[Anthony Massa]

>
> On 01-Jan-2001 Anthony Massa wrote:
> > I am able to get it to start downloading the file now.
> >
> > I'm getting a checksum failure at 8c840 though.
>
> Is this _with_ the timer patch I provided?

Yes, with the timer patch.

>
> >
> > And I also run out of mbufs, do you know what the cause for this is?
>
> Surely this is with eCos, not RedBoot (since RedBoot does not use MBUFs).
> Can you duplicate it?  provide a failing case or scenario?
>

I don't know exactly where you draw the line between redboot and ecos, but
redboot is the only thing running on my board when this occurs.  It just
seems that when a lot of information is exchanged with the Windows NT telnet
application, this error occurs.  The only way out is a hard reboot.  I
haven't done much investigation as to where this error is generated from.




> >
> >
> >>
> >> On 29-Dec-2000 Anthony Massa wrote:
> >> > The error I get is:
> >> >
> >> > Can't load 'mbx.img': operation timed out.
> >>
> >> Are you sure that you are running a TFTP server (and not FTP)?
> >>
> >> >
> >> >
> >> >>
> >> >> On 28-Dec-2000 Anthony Massa wrote:
> >> >> > The patch seems to work.  I can run my bootp server on my NT
> >> >> workstation and
> >> >> > with the MBX board in non-debug mode, an IP address gets assigned.
> >> >> >
> >> >> > I am not able to download a file, though.  I have my file in
> >> my d:\temp
> >> >> > directory.  I startup the TFTP server program I have and try
> >> to run the
> >> >> > following command under redboot:
> >> >> >
> >> >> > load -v -m TFTP d:\temp\mbx.img
> >> >> >
> >> >> >
> >> >> > However, I always get an error that redboot cannot load the
> >> >> image.  What am
> >> >> > I doing wrong?
> >> >> >
> >> >>
> >> >> What error do you get?  Some TFTP servers insist that the
> >> downloaded file
> >> >> exist in a special directory and that the name provided [by you]
> >> >> be relative
> >> >> to that directory.  This is for security purposes since TFTP has
> >> >> no authentication.
> >> >>
> >> >> > What port does redboot use for tftp (21)?
> >> >>
> >> >> The default port - UDP port #69.
> >> >>
> >> >> >
> >> >> >
> >> >> > Thanks a bunch for all the help.
> >> >> >
> >>
>

RE: [ECOS] RedBoot

[Gary Thomas]

On 27-Dec-2000 Anthony Massa wrote:
> That's odd since I can see the correct MAC address from the EPPCbug code.
                                                              ^^^^^^^^^^^^
But not from eCos/RedBoot, that's where the problem lies.

> 
> I did build this redboot image.  What do I need to do - any help would be
> great...

Try this patch and let me know what the output is.  This will print some
additional information at the point where the driver is trying to find the
address information.

Index: hal/powerpc/mbx/current/src/hal_aux.c
===================================================================
RCS file: /home/cvs/ecc/ecc/hal/powerpc/mbx/current/src/hal_aux.c,v
retrieving revision 1.11
diff -u -5 -p -r1.11 hal_aux.c
--- hal/powerpc/mbx/current/src/hal_aux.c       2000/06/15 14:31:01     1.11
+++ hal/powerpc/mbx/current/src/hal_aux.c       2000/12/27 19:10:35
@@ -281,10 +281,12 @@ _mbx_fetch_VPD(int code, unsigned char *
     int i, len;
 
     _mbx_init_i2c();  // Fetch the data if not already
     vp = &_MBX_eeprom_data[0];
     ep = &_MBX_eeprom_data[sizeof(_MBX_eeprom_data)];
+    diag_printf("VP: %x, EP: %x, Code: %x\n", vp, ep, code);
+    diag_dump_buf(vp, 256);
     while (vp < ep) {
         if (*vp == (unsigned char)code) {
             // Found the desired item
             len = (int)vp[1];
             if (len > size) len = size;

> 
>>
>> The problem seems to be that the driver in RedBoot (eCos) can't get at the
>> ESA for your board.  It is supposed to do this by accessing some NVRAM on
>> the board and then digging it out of a data structure kept by EPPCbug.  If
>> eCos can't find the address, it falls back to a hard coded one which is
>>   0x08 0x00 0x3E 0x28 0x79 0xB8
>>
>> Did you build this RedBoot?  Can you?  If so, perhaps we can debug the
>> NVRAM code and figure out why it works for me but not for you.
>>
>> On 23-Dec-2000 Anthony Massa wrote:
>> > Gary - thanks for the offer, sorry I took this long to respond,
>> but this is
>> > the first chance at running something on my hardware platform.  I have
>> > attached two different dumps.  The first one is with BOOTP enabled.  The
>> > second is with a static IP address of 192.168.0.5.  I also did
>> a "ping" from
>> > my Windows NT workstation which received a reply from my MBX
>> board.  That is
>> > shown in the second dump as well.
>> >
>> > Any help you can give would be greatly appreciated.
>> >
>> > When I do a NIOT command under eppcbug I get the following information
>> > Controller LUN: 20
>> > Device LUN: 00
>> > Address: FA200A00
>> > P-Address: 192.168.0.5
>> > H-Address: 08 00 3E 27 5A DC
>> >
>> > ============================
>> > START OF FIRST DUMP - WITH BOOTP ENABLED
>> >
>> > RedBoot(tm) debug environment - built 09:50:42, Dec 17 2000
>> > Platform: Motorola MBX (PowerPC 860)
>> > Copyright (C) 2000, Red Hat, Inc.
>> >
>> > RAM: 0x00000000-0x00400000
>> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
>> > Ethernet send:
>> > 0x00004A44: FFFF FFFF FFFF 0800  3E28 79B8 0800
>> |........>(y...  |
>>                              ^^^^^^^^^^^^^^^
>> This is the ESA, but not the correct one for your board.  This is why the
>> BOOTP setup does not work.
>>

RE: [ECOS] RedBoot

[Anthony Massa]

Here is the dump after applying the patch you sent.

RedBoot(tm) debug environment - built 11:31:22, Dec 27 2000
Platform: Motorola MBX (PowerPC 860)
Copyright (C) 2000, Red Hat, Inc.

RAM: 0x00000000-0x00400000
FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
VP: 83A4, EP: 84A4, Code: 8
000083A4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
000083B4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
000083C4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
000083D4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
000083E4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
000083F4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008404: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008414: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008424: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008434: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008444: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008454: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008464: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008474: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008484: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
00008494: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
IP: 192.168.0.5, Default server: 192.168.0.3
RedBoot> Ethernet recv:
0x0000AA2C: FFFF FFFF FFFF 0060  975B 43B8 0064        |.......`.[C..d  |
0x0000AA3A: E0E0 03FF FF00 6000  0400 0000 00FF FFFF   |......`.........|
0x0000AA4A: FFFF FF04 5200 0000  0000 6097 5B43 B804   |....R.....`.[C..|
0x0000AA5A: 5200 0206 404D 4143  4849 4E45 3254 4F57   |R...@MACHINE2TOW|
0x0000AA6A: 4552 0000 0000 0000  0000 0000 0000 0000   |ER..............|
0x0000AA7A: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000AA8A: 0000 0000 0000 0000  0000 6097 5B43 B8E8   |..........`.[C..|
0x0000AA9A: 8500 0100 EDBD 813C


>
>
> On 27-Dec-2000 Anthony Massa wrote:
> > That's odd since I can see the correct MAC address from the
> EPPCbug code.
>                                                               ^^^^^^^^^^^^
> But not from eCos/RedBoot, that's where the problem lies.
>
> >
> > I did build this redboot image.  What do I need to do - any
> help would be
> > great...
>
> Try this patch and let me know what the output is.  This will print some
> additional information at the point where the driver is trying to find the
> address information.
>
> Index: hal/powerpc/mbx/current/src/hal_aux.c
> ===================================================================
> RCS file: /home/cvs/ecc/ecc/hal/powerpc/mbx/current/src/hal_aux.c,v
> retrieving revision 1.11
> diff -u -5 -p -r1.11 hal_aux.c
> --- hal/powerpc/mbx/current/src/hal_aux.c       2000/06/15
> 14:31:01     1.11
> +++ hal/powerpc/mbx/current/src/hal_aux.c       2000/12/27 19:10:35
> @@ -281,10 +281,12 @@ _mbx_fetch_VPD(int code, unsigned char *
>      int i, len;
>
>      _mbx_init_i2c();  // Fetch the data if not already
>      vp = &_MBX_eeprom_data[0];
>      ep = &_MBX_eeprom_data[sizeof(_MBX_eeprom_data)];
> +    diag_printf("VP: %x, EP: %x, Code: %x\n", vp, ep, code);
> +    diag_dump_buf(vp, 256);
>      while (vp < ep) {
>          if (*vp == (unsigned char)code) {
>              // Found the desired item
>              len = (int)vp[1];
>              if (len > size) len = size;
>
> >
> >>
> >> The problem seems to be that the driver in RedBoot (eCos)
> can't get at the
> >> ESA for your board.  It is supposed to do this by accessing
> some NVRAM on
> >> the board and then digging it out of a data structure kept by
> EPPCbug.  If
> >> eCos can't find the address, it falls back to a hard coded one which is
> >>   0x08 0x00 0x3E 0x28 0x79 0xB8
> >>
> >> Did you build this RedBoot?  Can you?  If so, perhaps we can debug the
> >> NVRAM code and figure out why it works for me but not for you.
> >>
> >> On 23-Dec-2000 Anthony Massa wrote:
> >> > Gary - thanks for the offer, sorry I took this long to respond,
> >> but this is
> >> > the first chance at running something on my hardware
> platform.  I have
> >> > attached two different dumps.  The first one is with BOOTP
> enabled.  The
> >> > second is with a static IP address of 192.168.0.5.  I also did
> >> a "ping" from
> >> > my Windows NT workstation which received a reply from my MBX
> >> board.  That is
> >> > shown in the second dump as well.
> >> >
> >> > Any help you can give would be greatly appreciated.
> >> >
> >> > When I do a NIOT command under eppcbug I get the following
> information
> >> > Controller LUN: 20
> >> > Device LUN: 00
> >> > Address: FA200A00
> >> > P-Address: 192.168.0.5
> >> > H-Address: 08 00 3E 27 5A DC
> >> >
> >> > ============================
> >> > START OF FIRST DUMP - WITH BOOTP ENABLED
> >> >
> >> > RedBoot(tm) debug environment - built 09:50:42, Dec 17 2000
> >> > Platform: Motorola MBX (PowerPC 860)
> >> > Copyright (C) 2000, Red Hat, Inc.
> >> >
> >> > RAM: 0x00000000-0x00400000
> >> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
> >> > Ethernet send:
> >> > 0x00004A44: FFFF FFFF FFFF 0800  3E28 79B8 0800
> >> |........>(y...  |
> >>                              ^^^^^^^^^^^^^^^
> >> This is the ESA, but not the correct one for your board.  This
> is why the
> >> BOOTP setup does not work.
> >>
>

RE: [ECOS] RedBoot

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 6268 bytes --]

As I expected, the problem is that RedBoot/eCos can't get at the NVRAM
information.  This is because the NVRAM is connected via the I2C interface
and that is broken on the MBX!  I've not been able to figure out how to
make it work reliably.

However, the attached patch should let you get by.  It adds some additional 
information kept by RedBoot.  Basically, run 'fconfig' and enter the ESA 
(MAC) address manually.  Then RedBoot and eCos programs will be able to set 
up the interface properly.

Let me know if this works/helps/...  If so, I'll apply it permanently.

On 27-Dec-2000 Anthony Massa wrote:
> Here is the dump after applying the patch you sent.
> 
> RedBoot(tm) debug environment - built 11:31:22, Dec 27 2000
> Platform: Motorola MBX (PowerPC 860)
> Copyright (C) 2000, Red Hat, Inc.
> 
> RAM: 0x00000000-0x00400000
> FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
> VP: 83A4, EP: 84A4, Code: 8
> 000083A4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 000083B4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 000083C4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 000083D4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 000083E4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 000083F4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008404: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008414: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008424: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008434: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008444: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008454: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008464: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008474: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008484: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> 00008494: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> IP: 192.168.0.5, Default server: 192.168.0.3
> RedBoot> Ethernet recv:
> 0x0000AA2C: FFFF FFFF FFFF 0060  975B 43B8 0064        |.......`.[C..d  |
> 0x0000AA3A: E0E0 03FF FF00 6000  0400 0000 00FF FFFF   |......`.........|
> 0x0000AA4A: FFFF FF04 5200 0000  0000 6097 5B43 B804   |....R.....`.[C..|
> 0x0000AA5A: 5200 0206 404D 4143  4849 4E45 3254 4F57   |R...@MACHINE2TOW|
> 0x0000AA6A: 4552 0000 0000 0000  0000 0000 0000 0000   |ER..............|
> 0x0000AA7A: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000AA8A: 0000 0000 0000 0000  0000 6097 5B43 B8E8   |..........`.[C..|
> 0x0000AA9A: 8500 0100 EDBD 813C
> 
> 
>>
>>
>> On 27-Dec-2000 Anthony Massa wrote:
>> > That's odd since I can see the correct MAC address from the
>> EPPCbug code.
>>                                                               ^^^^^^^^^^^^
>> But not from eCos/RedBoot, that's where the problem lies.
>>
>> >
>> > I did build this redboot image.  What do I need to do - any
>> help would be
>> > great...
>>
>> Try this patch and let me know what the output is.  This will print some
>> additional information at the point where the driver is trying to find the
>> address information.
>>
>> Index: hal/powerpc/mbx/current/src/hal_aux.c
>> ===================================================================
>> RCS file: /home/cvs/ecc/ecc/hal/powerpc/mbx/current/src/hal_aux.c,v
>> retrieving revision 1.11
>> diff -u -5 -p -r1.11 hal_aux.c
>> --- hal/powerpc/mbx/current/src/hal_aux.c       2000/06/15
>> 14:31:01     1.11
>> +++ hal/powerpc/mbx/current/src/hal_aux.c       2000/12/27 19:10:35
>> @@ -281,10 +281,12 @@ _mbx_fetch_VPD(int code, unsigned char *
>>      int i, len;
>>
>>      _mbx_init_i2c();  // Fetch the data if not already
>>      vp = &_MBX_eeprom_data[0];
>>      ep = &_MBX_eeprom_data[sizeof(_MBX_eeprom_data)];
>> +    diag_printf("VP: %x, EP: %x, Code: %x\n", vp, ep, code);
>> +    diag_dump_buf(vp, 256);
>>      while (vp < ep) {
>>          if (*vp == (unsigned char)code) {
>>              // Found the desired item
>>              len = (int)vp[1];
>>              if (len > size) len = size;
>>
>> >
>> >>
>> >> The problem seems to be that the driver in RedBoot (eCos)
>> can't get at the
>> >> ESA for your board.  It is supposed to do this by accessing
>> some NVRAM on
>> >> the board and then digging it out of a data structure kept by
>> EPPCbug.  If
>> >> eCos can't find the address, it falls back to a hard coded one which is
>> >>   0x08 0x00 0x3E 0x28 0x79 0xB8
>> >>
>> >> Did you build this RedBoot?  Can you?  If so, perhaps we can debug the
>> >> NVRAM code and figure out why it works for me but not for you.
>> >>
>> >> On 23-Dec-2000 Anthony Massa wrote:
>> >> > Gary - thanks for the offer, sorry I took this long to respond,
>> >> but this is
>> >> > the first chance at running something on my hardware
>> platform.  I have
>> >> > attached two different dumps.  The first one is with BOOTP
>> enabled.  The
>> >> > second is with a static IP address of 192.168.0.5.  I also did
>> >> a "ping" from
>> >> > my Windows NT workstation which received a reply from my MBX
>> >> board.  That is
>> >> > shown in the second dump as well.
>> >> >
>> >> > Any help you can give would be greatly appreciated.
>> >> >
>> >> > When I do a NIOT command under eppcbug I get the following
>> information
>> >> > Controller LUN: 20
>> >> > Device LUN: 00
>> >> > Address: FA200A00
>> >> > P-Address: 192.168.0.5
>> >> > H-Address: 08 00 3E 27 5A DC
>> >> >
>> >> > ============================
>> >> > START OF FIRST DUMP - WITH BOOTP ENABLED
>> >> >
>> >> > RedBoot(tm) debug environment - built 09:50:42, Dec 17 2000
>> >> > Platform: Motorola MBX (PowerPC 860)
>> >> > Copyright (C) 2000, Red Hat, Inc.
>> >> >
>> >> > RAM: 0x00000000-0x00400000
>> >> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
>> >> > Ethernet send:
>> >> > 0x00004A44: FFFF FFFF FFFF 0800  3E28 79B8 0800
>> >> |........>(y...  |
>> >>                              ^^^^^^^^^^^^^^^
>> >> This is the ESA, but not the correct one for your board.  This
>> is why the
>> >> BOOTP setup does not work.
>> >>
>>

[-- Attachment #2: diffs --]
[-- Type: text/x-diff, Size: 2552 bytes --]

Index: devs/eth/powerpc/quicc/current/src/if_quicc.c
===================================================================
RCS file: /home/cvs/ecc/ecc/devs/eth/powerpc/quicc/current/src/if_quicc.c,v
retrieving revision 1.5
diff -u -5 -p -r1.5 if_quicc.c
--- devs/eth/powerpc/quicc/current/src/if_quicc.c	2000/10/24 10:28:33	1.5
+++ devs/eth/powerpc/quicc/current/src/if_quicc.c	2000/12/27 23:27:26
@@ -79,10 +79,22 @@ static unsigned char quicc_eth_rxbufs[CY
 static unsigned char quicc_eth_txbufs[CYGNUM_DEVS_ETH_POWERPC_QUICC_TxNUM]
                                      [CYGNUM_DEVS_ETH_POWERPC_QUICC_BUFSIZE];
 
 static struct quicc_eth_info quicc_eth0_info;
 static unsigned char enaddr[] = { 0x08, 0x00, 0x3E, 0x28, 0x79, 0xB8};
+#ifdef CYGPKG_REDBOOT
+#include <pkgconf/redboot.h>
+#ifdef CYGSEM_REDBOOT_FLASH_CONFIG
+#include <redboot.h>
+#include <flash_config.h>
+RedBoot_config_option("Network hardware address [MAC]",
+                      quicc_esa,
+                      ALWAYS_ENABLED, true,
+                      CONFIG_ESA
+    );
+#endif
+#endif
 
 ETH_DRV_SC(quicc_eth0_sc,
            &quicc_eth0_info,   // Driver specific data
            "eth0",             // Name for this interface
            quicc_eth_start,
@@ -134,20 +146,32 @@ quicc_eth_init(struct cyg_netdevtab_entr
 {
     struct eth_drv_sc *sc = (struct eth_drv_sc *)tab->device_instance;
     struct quicc_eth_info *qi = (struct quicc_eth_info *)sc->driver_private;
     volatile EPPC *eppc = (volatile EPPC *)eppc_base();
     struct cp_bufdesc *rxbd, *txbd;
-    unsigned char *RxBUF, *TxBUF, *ep, *ap;
+    unsigned char *RxBUF, *TxBUF, *ep, *ap; 
     volatile struct ethernet_pram *enet_pram;
     volatile struct scc_regs *scc;
     int TxBD, RxBD;
     int cache_state;
     int i;
 
     // Fetch the board address from the VPD
 #define VPD_ETHERNET_ADDRESS 0x08
-    _mbx_fetch_VPD(VPD_ETHERNET_ADDRESS, enaddr, sizeof(enaddr));
+    if (_mbx_fetch_VPD(VPD_ETHERNET_ADDRESS, enaddr, sizeof(enaddr)) == 0) {
+#if defined(CYGPKG_REDBOOT) && \
+    defined(CYGSEM_REDBOOT_FLASH_CONFIG)
+        flash_get_config("quicc_esa", enaddr, CONFIG_ESA);
+#else
+        enet_pram = &eppc->pram[0].enet_scc;
+        ap = &enaddr[sizeof(enaddr)];
+        ep = (unsigned char *)&enet_pram->paddr_h;
+        for (i = 0;  i < sizeof(enaddr);  i++) {
+            *ap++ = *--ep;
+        }
+#endif
+    }
 
     // Ensure consistent state between cache and what the QUICC sees
     HAL_DCACHE_IS_ENABLED(cache_state);
     HAL_DCACHE_SYNC();
     HAL_DCACHE_DISABLE();

RE: [ECOS] RedBoot

[Anthony Massa]

I was able to change the MAC address (using fconfig).  I am able to do ping
from Win NT host and get back packets.  I cannot run using BOOTP, I must use
a static IP address.

However, I still am not able to run the telnet application and connect to
the MBX board.  Do you know what is the problem there?

Do I need to run a BOOTP server from my host?

Should I try a tftp server application?



>
> As I expected, the problem is that RedBoot/eCos can't get at the NVRAM
> information.  This is because the NVRAM is connected via the I2C interface
> and that is broken on the MBX!  I've not been able to figure out how to
> make it work reliably.
>
> However, the attached patch should let you get by.  It adds some
> additional
> information kept by RedBoot.  Basically, run 'fconfig' and enter the ESA
> (MAC) address manually.  Then RedBoot and eCos programs will be
> able to set
> up the interface properly.
>
> Let me know if this works/helps/...  If so, I'll apply it permanently.
>
> On 27-Dec-2000 Anthony Massa wrote:
> > Here is the dump after applying the patch you sent.
> >
> > RedBoot(tm) debug environment - built 11:31:22, Dec 27 2000
> > Platform: Motorola MBX (PowerPC 860)
> > Copyright (C) 2000, Red Hat, Inc.
> >
> > RAM: 0x00000000-0x00400000
> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
> > VP: 83A4, EP: 84A4, Code: 8
> > 000083A4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 000083B4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 000083C4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 000083D4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 000083E4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 000083F4: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008404: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008414: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008424: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008434: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008444: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008454: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008464: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008474: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008484: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > 00008494: FFFF FFFF FFFF FFFF  FFFF FFFF FFFF FFFF   |................|
> > IP: 192.168.0.5, Default server: 192.168.0.3
> > RedBoot> Ethernet recv:
> > 0x0000AA2C: FFFF FFFF FFFF 0060  975B 43B8 0064
> |.......`.[C..d  |
> > 0x0000AA3A: E0E0 03FF FF00 6000  0400 0000 00FF FFFF
> |......`.........|
> > 0x0000AA4A: FFFF FF04 5200 0000  0000 6097 5B43 B804
> |....R.....`.[C..|
> > 0x0000AA5A: 5200 0206 404D 4143  4849 4E45 3254 4F57
> |R...@MACHINE2TOW|
> > 0x0000AA6A: 4552 0000 0000 0000  0000 0000 0000 0000
> |ER..............|
> > 0x0000AA7A: 0000 0000 0000 0000  0000 0000 0000 0000
> |................|
> > 0x0000AA8A: 0000 0000 0000 0000  0000 6097 5B43 B8E8
> |..........`.[C..|
> > 0x0000AA9A: 8500 0100 EDBD 813C
> >
> >
> >>
> >>
> >> On 27-Dec-2000 Anthony Massa wrote:
> >> > That's odd since I can see the correct MAC address from the
> >> EPPCbug code.
> >>
> ^^^^^^^^^^^^
> >> But not from eCos/RedBoot, that's where the problem lies.
> >>
> >> >
> >> > I did build this redboot image.  What do I need to do - any
> >> help would be
> >> > great...
> >>
> >> Try this patch and let me know what the output is.  This will
> print some
> >> additional information at the point where the driver is trying
> to find the
> >> address information.
> >>
> >> Index: hal/powerpc/mbx/current/src/hal_aux.c
> >> ===================================================================
> >> RCS file: /home/cvs/ecc/ecc/hal/powerpc/mbx/current/src/hal_aux.c,v
> >> retrieving revision 1.11
> >> diff -u -5 -p -r1.11 hal_aux.c
> >> --- hal/powerpc/mbx/current/src/hal_aux.c       2000/06/15
> >> 14:31:01     1.11
> >> +++ hal/powerpc/mbx/current/src/hal_aux.c       2000/12/27 19:10:35
> >> @@ -281,10 +281,12 @@ _mbx_fetch_VPD(int code, unsigned char *
> >>      int i, len;
> >>
> >>      _mbx_init_i2c();  // Fetch the data if not already
> >>      vp = &_MBX_eeprom_data[0];
> >>      ep = &_MBX_eeprom_data[sizeof(_MBX_eeprom_data)];
> >> +    diag_printf("VP: %x, EP: %x, Code: %x\n", vp, ep, code);
> >> +    diag_dump_buf(vp, 256);
> >>      while (vp < ep) {
> >>          if (*vp == (unsigned char)code) {
> >>              // Found the desired item
> >>              len = (int)vp[1];
> >>              if (len > size) len = size;
> >>
> >> >
> >> >>
> >> >> The problem seems to be that the driver in RedBoot (eCos)
> >> can't get at the
> >> >> ESA for your board.  It is supposed to do this by accessing
> >> some NVRAM on
> >> >> the board and then digging it out of a data structure kept by
> >> EPPCbug.  If
> >> >> eCos can't find the address, it falls back to a hard coded
> one which is
> >> >>   0x08 0x00 0x3E 0x28 0x79 0xB8
> >> >>
> >> >> Did you build this RedBoot?  Can you?  If so, perhaps we
> can debug the
> >> >> NVRAM code and figure out why it works for me but not for you.
> >> >>
> >> >> On 23-Dec-2000 Anthony Massa wrote:
> >> >> > Gary - thanks for the offer, sorry I took this long to respond,
> >> >> but this is
> >> >> > the first chance at running something on my hardware
> >> platform.  I have
> >> >> > attached two different dumps.  The first one is with BOOTP
> >> enabled.  The
> >> >> > second is with a static IP address of 192.168.0.5.  I also did
> >> >> a "ping" from
> >> >> > my Windows NT workstation which received a reply from my MBX
> >> >> board.  That is
> >> >> > shown in the second dump as well.
> >> >> >
> >> >> > Any help you can give would be greatly appreciated.
> >> >> >
> >> >> > When I do a NIOT command under eppcbug I get the following
> >> information
> >> >> > Controller LUN: 20
> >> >> > Device LUN: 00
> >> >> > Address: FA200A00
> >> >> > P-Address: 192.168.0.5
> >> >> > H-Address: 08 00 3E 27 5A DC
> >> >> >
> >> >> > ============================
> >> >> > START OF FIRST DUMP - WITH BOOTP ENABLED
> >> >> >
> >> >> > RedBoot(tm) debug environment - built 09:50:42, Dec 17 2000
> >> >> > Platform: Motorola MBX (PowerPC 860)
> >> >> > Copyright (C) 2000, Red Hat, Inc.
> >> >> >
> >> >> > RAM: 0x00000000-0x00400000
> >> >> > FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
> >> >> > Ethernet send:
> >> >> > 0x00004A44: FFFF FFFF FFFF 0800  3E28 79B8 0800
> >> >> |........>(y...  |
> >> >>                              ^^^^^^^^^^^^^^^
> >> >> This is the ESA, but not the correct one for your board.  This
> >> is why the
> >> >> BOOTP setup does not work.
> >> >>
> >>
>

RE: [ECOS] RedBoot

[Gary Thomas]

The problem seems to be that the driver in RedBoot (eCos) can't get at the
ESA for your board.  It is supposed to do this by accessing some NVRAM on
the board and then digging it out of a data structure kept by EPPCbug.  If
eCos can't find the address, it falls back to a hard coded one which is
  0x08 0x00 0x3E 0x28 0x79 0xB8

Did you build this RedBoot?  Can you?  If so, perhaps we can debug the 
NVRAM code and figure out why it works for me but not for you.  

On 23-Dec-2000 Anthony Massa wrote:
> Gary - thanks for the offer, sorry I took this long to respond, but this is
> the first chance at running something on my hardware platform.  I have
> attached two different dumps.  The first one is with BOOTP enabled.  The
> second is with a static IP address of 192.168.0.5.  I also did a "ping" from
> my Windows NT workstation which received a reply from my MBX board.  That is
> shown in the second dump as well.
> 
> Any help you can give would be greatly appreciated.
> 
> When I do a NIOT command under eppcbug I get the following information
> Controller LUN: 20
> Device LUN: 00
> Address: FA200A00
> P-Address: 192.168.0.5
> H-Address: 08 00 3E 27 5A DC
> 
> ============================
> START OF FIRST DUMP - WITH BOOTP ENABLED
> 
> RedBoot(tm) debug environment - built 09:50:42, Dec 17 2000
> Platform: Motorola MBX (PowerPC 860)
> Copyright (C) 2000, Red Hat, Inc.
> 
> RAM: 0x00000000-0x00400000
> FLASH: 0xfe000000 - 0xfe080000, 8 blocks of 0x00010000 bytes each.
> Ethernet send:
> 0x00004A44: FFFF FFFF FFFF 0800  3E28 79B8 0800        |........>(y...  |
                             ^^^^^^^^^^^^^^^
This is the ESA, but not the correct one for your board.  This is why the
BOOTP setup does not work.

RE: [ECOS] Redboot

[Doug Fraser]

Hello Anthony,

One thing I would try, is convert the srec to pure binary.
Then use plh to load it into RAM at a known location.
To do this, run 'env' first, and set the load address.
For example, set it to 10000 hex.

then, assuming that you have set up your ip (niot),
and that the binary image is in /tmp/redboot.bin,

plh 20 0 /tmp/redboot.bin

You will now have the image in RAM at 10000 hex.
The length will be reported from plh when it completes.
(it reports in decimal) Assuming that it is 20000 hex bytes long,

pflash 10000 30000 fc000000

That should do it. Then power off, switch J4 to select the block
you just programmed, and power up.

(I am assuming a general knowledge of MBX and EPPC-Bug here)

Perhaps Bill Gatliff can add some details off line.
He is also working with an MBX board, and has dealt with
much of this already. Bill????

cheers

Doug

> -----Original Message-----
> From: Anthony Massa [ mailto:amassa@logici.com ]
> Sent: Thursday, December 14, 2000 4:03 PM
> To: 'eCos (E-mail)'
> Subject: [ECOS] Redboot
> 
> 
> I am trying to get redboot running on my MBX board.  I have built the
> redboot images.  However, the srec image I noticed started at address
> 0xfe000000.  I could not download this image using eppc-bug.  
> So, I used
> objcopy with the line from the documentation:
> 
> powerpc-eabi-objcopy -O srec --change-address=0x02040000 redboot.img
> redboot_mbx.srec.
> 
> I then tried to download this new image (redboot_mbx.srec).  
> I cannot see
> any output from the serial port or any response from the board.
> 
> Can you help me out and let me know what I might be forgetting to do.
> 
> Thanks.
> 
> 

[ECOS] Redboot

[Anthony Massa]

I am trying to get redboot running on my MBX board.  I have built the
redboot images.  However, the srec image I noticed started at address
0xfe000000.  I could not download this image using eppc-bug.  So, I used
objcopy with the line from the documentation:

powerpc-eabi-objcopy -O srec --change-address=0x02040000 redboot.img
redboot_mbx.srec.

I then tried to download this new image (redboot_mbx.srec).  I cannot see
any output from the serial port or any response from the board.

Can you help me out and let me know what I might be forgetting to do.

Thanks.

[ECOS] redboot

[Jörg Rapka]

Dear ecos developer

I'm very interested in the redboot of ecos.
I have downloaded the latest version from CVS.
In the sources I found the information, that
not only download by TFTP but also xyzmodem
will be supported (the documentation only
references TFTP). I compiled the sources
and tried download by xyzmodem, but it did
not work so well.
What is the status of this implementation?
What was your terminal application and protocol
used during development tests?

Best regards, Joerg

RE: [ECOS] redboot

[Gary Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On 07-Nov-2000 Jörg Rapka wrote:
> Dear ecos developer
> 
> I'm very interested in the redboot of ecos.
> I have downloaded the latest version from CVS.
> In the sources I found the information, that
> not only download by TFTP but also xyzmodem
> will be supported (the documentation only
> references TFTP). I compiled the sources
> and tried download by xyzmodem, but it did
> not work so well.
> What is the status of this implementation?
> What was your terminal application and protocol
> used during development tests?

Currently only Ymodem (or Xmodem with CRC) is implemented.

What platform did you try this on?
What problems did you encounter?

It's pretty hard to help much if all you give us is "it did
not work so well."