[ECOS] eCos tools binary installation under Cygwin

[ECOS] eCos tools binary installation under Cygwin

[Grant Edwards]

I've built and installed the ARM development tools under
NT4/Cygwin using the instructions at:

    http://sources.redhat.com/ecos/tools/win-arm-elf.html

Assuming I've got a second computer running NT4 w/ the same
version of Cygwin, can I just copy the /tools directory to the
second computer, or do I need to copy the source/build
directories and do a "make install" on the second machine?

I don't use Windows much, and my past experience with copying
application program directory trees from one machine to another
hasn't been very successful.  Under Win32, installing an app
seems to weave bits of the app deep into the system in
inextricable (and inexplicable) ways.

I'm hoping that stuff built/installed under Cygwin behaves in a
more Unix-like way...  ;)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] eCos tools binary installation under Cygwin

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I've built and installed the ARM development tools under
> NT4/Cygwin using the instructions at:
> 
>     http://sources.redhat.com/ecos/tools/win-arm-elf.html
> 
> Assuming I've got a second computer running NT4 w/ the same
> version of Cygwin, can I just copy the /tools directory to the
> second computer, or do I need to copy the source/build
> directories and do a "make install" on the second machine?

You can just copy the /tools directory if it's going to live in the same
place on that machine (i.e. /tools).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] eCos tools binary installation under Cygwin

[Ling Su]

Hi, Jifl,

Do you ever meet following errors when you run pci1.exe test, following is
what I met even I use the most updated cvs release, it is the same as
before. The PCI bus scan failed for a SIGBUS bus error...Could you please
take a look? Thanks!

Regards,
-Ling

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
(gdb) set remotebaud 38400
(gdb) target remotebaud /dev/ttyS0
Undefined target command: "remotebaud /dev/ttyS0".  Try "help target".
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80003a50 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0xb4 lma 0x80100000
Loading section .text, size 0xd8b0 lma 0x801000b4
Loading section .ctors, size 0x28 lma 0x8010d964
Loading section .dtors, size 0x14 lma 0x8010d98c
Loading section .rodata, size 0x7c9c lma 0x8010d9a0
Loading section .data, size 0xa204 lma 0x80115640
Start address 0x801000a4 , load size 129088
Transfer rate: 27176 bits/sec, 502 bytes/write.
(gdb) cont
Continuing.
Found device on bus 0, devfn 0x00:
 Note that board is active. Probed sizes and CPU addresses invalid!
 Device configuration failed - device already enabled
 Vendor    0x1033 [NEC][NEC Corporation]
 Device    0x001A [UNKNOWN]
 Command   0x0146, Status 0x0280
 Class/Rev 0x06800001 [Bridge Device][Other][]
 Header 0x11FF0E
 SubVendor 0x1111, Sub ID 0xFF19
 BAR[0]    0x1C000000 / probed size 0x00000000 / CPU addr 0x1111FF15
 BAR[1]    0x80000000 / probed size 0x00000000 / CPU addr 0x00000000
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0x1111FF16
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0x00000000
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0x1111FF17
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0x00000000
 Wired to HAL vector 11
[New thread 3]

Program received signal SIGBUS, Bus error.
[Switching to thread 3]
warning: Warning: GDB can't find the start of the function at 0x80104820.

    GDB is unable to find the start of the function at 0x80104820
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x80104820 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0x80104820 in ?? ()
    at
/opt/ecos_cvs/ecos/packages/language/c/libc/startup/current/src/cstartup.cxx
:98
98
CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_LIBC);(gdb)

Re: [ECOS] eCos tools binary installation under Cygwin

[Jonathan Larmour]

Ling Su wrote:
> 
> Hi, Jifl,
> 
> Do you ever meet following errors when you run pci1.exe test, following is
> what I met even I use the most updated cvs release, it is the same as
> before. The PCI bus scan failed for a SIGBUS bus error...Could you please
> take a look? Thanks!

I built pci1 from the latest sources (should be no different in any
relevant way to yours) and ran pci1. I got:

(gdb) c
Continuing.
Found device on bus 0, devfn 0x00:
 Note that board is active. Probed sizes and CPU addresses invalid!
 Device configuration failed - device already enabled
 Vendor    0x1033 [NEC][NEC Corporation]
 Device    0x001A [UNKNOWN]
 Command   0x0146, Status 0x0280
 Class/Rev 0x06800001 [Bridge Device][Other][]
 Header 0x11FF0E
 SubVendor 0x1111, Sub ID 0xFF19
 BAR[0]    0x1C000000 / probed size 0x00000000 / CPU addr 0x1111FF15
 BAR[1]    0x80000000 / probed size 0x00000000 / CPU addr 0x00000000
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0x1111FF16
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0x00000000
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0x1111FF17
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0x00000000
 Wired to HAL vector 11
Found device on bus 0, devfn 0x18:
 Device configuration succeeded
 Vendor    0x1011 [DEC][Digital Equipment Corporation]
 Device    0x0009 [DC21140][Fast Ethernet Ctrlr]
 Command   0x0000, Status 0x0280
 Class/Rev 0x02000022 [Network Controller][Ethernet][]
 Header 0x11FF0E
 SubVendor 0x1111, Sub ID 0xFF19
 BAR[0]    0x00000001 / probed size 0xFFFFFF81 / CPU addr 0xAC000000
 BAR[1]    0x00000000 / probed size 0xFFFFFF80 / CPU addr 0xC0000000
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 Wired to HAL vector 14
 
Strings in [] are from the PCI Code List at http://www.yourvote.com/pci
It seems that some of the device information has not been registered in
the PCI Code List. Please consider improving the database by registering
the [UNKNOWN] information for your devices. Thanks.
PASS:<pci1 test OK>
EXIT:<done>

I will send you the executable by private mail to see if it works on your
board.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

[ECOS] eCos PCI problem and NEC vrc4373 build option.

[Ling Su]

> Jonathan Larmour wrote:
> >
> > I will send you the executable by private mail to see if it works on
your
> > board.
>
> Attached, gzipped. I kept the debug info in case it's useful, although the
> path names will be wrong of course.
>

Your code works pretty fine on my board. I remember I have something might
be different in my configuration. I usually can not straight forward use the
code generated by "ecosconfig new vrc4373", I usually modify two things, one
is to delete the "-O2" option for compiler, another is to set both the
serial port drive baud rate to 38400b/s. If I don't delete the -O2 option,
the gdb usually hang there after I type "cont" after successfully download
the code. This problem has been reported by Charles on this list, his work
around solution is not to optimize the code, I follow the suggestion and it
works. I tried several NEC board, the result is the same, I must delete
the -O2 option every time. Jifl, do you apply this usually? or everything
just works fine for your board? I think this option might bring some
differences for our pci1.exe code. But anyway, yours code just works fine on
my board, probably my toolchain is not as good as yours. :) I use
binutils2.10 and egcs20000313 snapshot, insight 5.0. (I follow Charles
suggestion on this list actually.), I am not sure if his pci test program
works fine or not.

Any good suggestion? Please kindly let me know. I will be grateful!

Regards,
-Ling

[ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Ling Su wrote:
> 
>  I tried several NEC board, the result is the same, I must delete
> the -O2 option every time. Jifl, do you apply this usually? or everything
> just works fine for your board?

Everything works just fine with my tools by default - that's probably the
difference :-/.

I'm out of ideas for what to do (for free :-/ ) other than trying different
snapshots of tools, or trying to diagnose the problems in the compiler and
reporting these as bug reports to the gcc folks - it's almost certainly
some gcc problem.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

[ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Ling Su]

>
> I'm out of ideas for what to do (for free :-/ ) other than trying
different
> snapshots of tools, or trying to diagnose the problems in the compiler and
> reporting these as bug reports to the gcc folks - it's almost certainly
> some gcc problem.
>

Thanks a lot! Jifl.

Could you please tell me what snapshot you exactly use for free, or I need
to pay some money for the answer? :-)

Another question I have is, is there any documents on what improvement has
been done on a specific platform (like NECvrc4373)? I checked the NEWS in
the new cvs release, it doesn't give me a clear idea on what exact will
appear on the vrc4373 platform. For example, the Redboot can not be applied
now on vrc4373. How about the network support for vrc4373 then? It does have
a DEC ethernet chip on PCI bus.

BTW, I remeber I asked you another question last time,  if I plug a PCI card
in one of the PCI slots, why the pci1.exe test program can not find it and
display some Vendor information, I tried the code you send to me, it doesn't
work, either. Any clue?

I do want to pay something for a technical support, but I just wonder if the
support quality can compare with the experts as you on the list. :)

Regards,
-Ling

[ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Ling Su wrote:
> 
> Could you please tell me what snapshot you exactly use for free, or I need
> to pay some money for the answer? :-)

We have our own commerically supported and verified versions of gcc/gdb
etc.
 
> Another question I have is, is there any documents on what improvement has
> been done on a specific platform (like NECvrc4373)? I checked the NEWS in
> the new cvs release, it doesn't give me a clear idea on what exact will
> appear on the vrc4373 platform. For example, the Redboot can not be applied
> now on vrc4373. How about the network support for vrc4373 then? It does have
> a DEC ethernet chip on PCI bus.

Not on the roadmap yet - no-one is paying us to work on it, and as far as I
know, no-one on the net is doing anything.

So the only things in the NEWS file of relevance to the vrc4373 are the
generic items. But there's still quite a lot of those!
 
> BTW, I remeber I asked you another question last time,  if I plug a PCI card
> in one of the PCI slots, why the pci1.exe test program can not find it and
> display some Vendor information, I tried the code you send to me, it doesn't
> work, either. Any clue?

Ah, I sent you a reply but the list wasn't CC'd. Whatever.
 
> I do want to pay something for a technical support, but I just wonder if the
> support quality can compare with the experts as you on the list. :)

Hah. Well, for a start I would answer all your mails rather than sometimes
not having time and leaving them. And we'd give you tools certified to work
with eCos so these problems would have been behind you ages ago!

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Alfredo Knecht]

Dear list,

Jonathan, do you really mean that redhat is actually maintaining two
separate threads of gdd/gdb/ecos, and that the one we're sweating on (I
myself for one) is just some sort of bait?
And all this in the name of the sacred open source, the plan being to get
us hooked on the light and buggy weed, then sell us the harder stuff for
real cash?
This is an interesting business model indeed, and reminds me of another one.
So, if I understand it right, the purpose of the open-source part including
this list is to bring us to the point where we say "now that the project is
late, we went this far, and invested all this time on that ecos thing,
there is no alternative left" ...as to plunk down a lot of good money to
get what was there all the time in the first place, namely the various
shrink-wrapped products like VxWorks, Psos, QNX, and the like?

Or am I missing something eye-opening?

Regards, Alfredo


At 23:58 30.08.00 +0100, you wrote:
>Ling Su wrote:
>> 
>> Could you please tell me what snapshot you exactly use for free, or I need
>> to pay some money for the answer? :-)
>
>We have our own commerically supported and verified versions of gcc/gdb
>etc.
> 
>> Another question I have is, is there any documents on what improvement has
>> been done on a specific platform (like NECvrc4373)? I checked the NEWS in
>> the new cvs release, it doesn't give me a clear idea on what exact will
>> appear on the vrc4373 platform. For example, the Redboot can not be applied
>> now on vrc4373. How about the network support for vrc4373 then? It does
have
>> a DEC ethernet chip on PCI bus.
>
>Not on the roadmap yet - no-one is paying us to work on it, and as far as I
>know, no-one on the net is doing anything.
>
>So the only things in the NEWS file of relevance to the vrc4373 are the
>generic items. But there's still quite a lot of those!
> 
>> BTW, I remeber I asked you another question last time,  if I plug a PCI
card
>> in one of the PCI slots, why the pci1.exe test program can not find it and
>> display some Vendor information, I tried the code you send to me, it
doesn't
>> work, either. Any clue?
>
>Ah, I sent you a reply but the list wasn't CC'd. Whatever.
> 
>> I do want to pay something for a technical support, but I just wonder if
the
>> support quality can compare with the experts as you on the list. :)
>
>Hah. Well, for a start I would answer all your mails rather than sometimes
>not having time and leaving them. And we'd give you tools certified to work
>with eCos so these problems would have been behind you ages ago!
>
>Jifl
>-- 
>Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
>"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
>
>
************************************************************************
Alfredo Knecht       Fax  ++41 91 610 8970          Tel ++41 91 610 8960
SUPSI-ICIMSI         aknecht@cimsi.cim.ch        http://www.cimsi.cim.ch

Istituto CIM della Svizzera italiana              CH-6928 Manno (Lugano)
************************************************************************

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Alfredo Knecht wrote:
> 
> Jonathan, do you really mean that redhat is actually maintaining two
> separate threads of gdd/gdb/ecos, and that the one we're sweating on (I
> myself for one) is just some sort of bait?

No. We have tools here that we did QA with eCos on, and our compiler
engineers worked through the problems we found, fixed these bugs (i.e.
"stabilized" the sources). But most importantly, the bug fixes we found
were made to the free tools as well. And rightly so.

What we haven't done, and won't do, is continually track the free sources
to ensure no-one else then breaks the tools when used with eCos. If
problems are reported they'll be fixed (and not necessarily just by Red Hat
engineers of course), but we simply don't have the time to track every
change people make.

We try our best to fix what bugs we do find, and add improvements where we
can. But at the end of the day, it is up to the *whole* free software
community, Red Hat included, to make sure these tools are as good as they
can be.

But just to be clear - the sources Red Hat uses internally for eCos are
almost exactly the same as the public ones. The only differences are for
confidential information, ports for specific customers and unfinished code.
Ditto for gcc/gdb. There are no separate "threads". The only thing we do is
that we will occasionally "stabilize" a particular set of sources to ensure
they are of high quality for release to our customers. And all fixes
resulting from that stabilization are applied to the main free sources.
That doesn't count as a separate "thread".

> And all this in the name of the sacred open source, the plan being to get
> us hooked on the light and buggy weed, then sell us the harder stuff for
> real cash?

No the sources are of the same ilk. All that happened in this case is that
Red Hat took the time to internally stabilize the tools so that they
reliably worked with eCos. This took time, money and effort; but we still
ensured all the fixes found went into the free repository. We can't be
responsible if people subsequently broke things there again!

> This is an interesting business model indeed, and reminds me of another one.
> So, if I understand it right, the purpose of the open-source part including
> this list is to bring us to the point where we say "now that the project is
> late, we went this far, and invested all this time on that ecos thing,
> there is no alternative left" ...as to plunk down a lot of good money to
> get what was there all the time in the first place, namely the various
> shrink-wrapped products like VxWorks, Psos, QNX, and the like?
> 
> Or am I missing something eye-opening?

We try and provide free support when we have time - the activity on this
list should surely be proof of that! And not just from Red Hat folks
either. Plenty of people use eCos and the GNU tools with no problems. But
there are always going to be times when people have problems that are too
big for us to solve on the list. You can't really expect us to solve
everyone's problems!

Anyway, if you don't like it, you can get a full refund of everything you
paid :-). Seriously, this is the whole point - all the sources are there
for *you* to fix if you want. That's the power of open source for you. But
that doesn't mean you can expect someone else to fix things for you for
free!

Hope this clears things up,

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Alfredo Knecht]

Dear Jonathan,

I don't want to rub it, especially not at three in the morning, after a
frustrating evening with gcc/gdb/ecos.
From what I read on the list, you are doing an excellent job.
On the other hand, we spent five man-weeks to get the chain to run
(WINNT/ARM, and no, we are not beginners), so pardon me if I somehow felt
sympathetic with Struggling Ling Su when he got an answer which I perceived
as "gotcha - send me the money first!".

BTW, out of curiosity, how is the mechanism

>almost exactly the same as the public ones. The only differences are for
>confidential information, ports for specific customers and unfinished code.

implemented? with CVS?

Thanks, Alfredo

************************************************************************
Alfredo Knecht       Fax  ++41 91 610 8970          Tel ++41 91 610 8960
SUPSI-ICIMSI         aknecht@cimsi.cim.ch        http://www.cimsi.cim.ch

Istituto CIM della Svizzera italiana              CH-6928 Manno (Lugano)
************************************************************************

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Alfredo Knecht wrote:
> pardon me if I somehow felt
> sympathetic with Struggling Ling Su when he got an answer which I perceived
> as "gotcha - send me the money first!".

I feel sympathetic too. Poor Ling has been suffering with problems for
quite some time, and I've already spent more time helping than by rights I
should!

> BTW, out of curiosity, how is the mechanism
> 
> >almost exactly the same as the public ones. The only differences are for
> >confidential information, ports for specific customers and unfinished code.
> 
> implemented? with CVS?

That's most of it. The mechanism is no great surprise, so it's not much of
a secret really. We have an internal CVS repository where anything
confidential is marked. A script filters out that stuff, creates a new
source tree, and then diffs that against the existing public repository. A
mug (me) then goes through and manually reads the diffs to check there were
no errors in the process (although some automatic keyword checking is also
done). If there aren't any, it then gets committed as-is. That's why I'm
happy to say that the sources are basically the same :-).

Yes this can be quite time-consuming :-). But it does mean our customers
can rest secure that confidentiality is assured! And it also means that we
know that the sources we are looking at, and the sources the net folks are
looking at are the same.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Ling Su]

> Jonathan, do you really mean that redhat is actually maintaining two
> separate threads of gdd/gdb/ecos, and that the one we're sweating on (I
> myself for one) is just some sort of bait?
> And all this in the name of the sacred open source, the plan being to get
> us hooked on the light and buggy weed, then sell us the harder stuff for
> real cash?
> This is an interesting business model indeed, and reminds me of another
one.
> So, if I understand it right, the purpose of the open-source part
including
> this list is to bring us to the point where we say "now that the project
is
> late, we went this far, and invested all this time on that ecos thing,
> there is no alternative left" ...as to plunk down a lot of good money to
> get what was there all the time in the first place, namely the various
> shrink-wrapped products like VxWorks, Psos, QNX, and the like?
>


If opensource operates in this way, I don't think this is the freedom we
advocate.  But this message that the toolchain I use is different from eCos
maintainer make me sad. :(

I remember one thing, last year, I pay $400 to buy a CodeFusion from Cygnus,
actually it is not important for me, I  just want to take a look at what the
opensource IDE developement status. Of course, I think it is ok, but didn't
play with it a lot. Last month, the Source Navigator is open sourced, I
don't know what I pay the $400 for now. :-)

Last time, I talked with NEC, they said they pay a lot to Cygnus for the
toolchain on NEC MIPS, I don't know why I can not get a proper toolchain
works properly. I really follow the instruction on the eCos website
carefully.

Regards,
-Ling

Regards,
-Ling

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Ling Su wrote:
> 
> Last time, I talked with NEC, they said they pay a lot to Cygnus for the
> toolchain on NEC MIPS, I don't know why I can not get a proper toolchain
> works properly. I really follow the instruction on the eCos website
> carefully.

Well, I think I've found your problem, and it wasn't the toolchain after
all! So much for laying the blame there :-). Although the confusion was
because our tools are of a different vintage. Can you try the attached
patch and rebuild your pci1 please? 

The problem was that without the ".set noreorder" the assembler was free to
put the jr before the lw. This caused a check (as described in the comment)
in hal_bus_error_vsr to fail.

Let me know if this works and I'll check it in here.

Jifl

Index: platform.S
===================================================================
RCS file: /cvs/ecc/ecc/hal/mips/vrc4373/current/src/platform.S,v
retrieving revision 1.9
diff -u -5 -p -r1.9 platform.S
--- platform.S  2000/02/02 19:10:27     1.9
+++ platform.S  2000/08/31 00:56:39
@@ -187,10 +187,11 @@ hal_bus_error_vsr:
 ## above to work around any bus errors provoked by the VRC4373.
 
 FUNC_START(hal_pci_config_read)
 
 hal_pci_config_read_load:
+       .set noreorder
        lw      v0,0(a0)        # Read the value. If this bus-errors the
                                # handler will skip this instruction and
                                # put 0xFFFFFFFF into v0.
        jr      ra              # And return
       
nop                                                                                  

-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Ling Su]

Thanks, Jifl, the patch works well in PCI1. The left things puzzled me,

<1>. It didn't detect out the another PCI Network card on PCI slot 1, how
you every try to plug one card on the board to test?

<2>. The "-O2" option, I haven't try it yet after apply the patch, I will
let you now after I got any result.

Regards,
-Ling

> Ling Su wrote:
> >
> > Last time, I talked with NEC, they said they pay a lot to Cygnus for the
> > toolchain on NEC MIPS, I don't know why I can not get a proper toolchain
> > works properly. I really follow the instruction on the eCos website
> > carefully.
>
> Well, I think I've found your problem, and it wasn't the toolchain after
> all! So much for laying the blame there :-). Although the confusion was
> because our tools are of a different vintage. Can you try the attached
> patch and rebuild your pci1 please?
>
> The problem was that without the ".set noreorder" the assembler was free
to
> put the jr before the lw. This caused a check (as described in the
comment)
> in hal_bus_error_vsr to fail.
>
> Let me know if this works and I'll check it in here.
>
> Jifl
>
> Index: platform.S
> ===================================================================
> RCS file: /cvs/ecc/ecc/hal/mips/vrc4373/current/src/platform.S,v
> retrieving revision 1.9
> diff -u -5 -p -r1.9 platform.S
> --- platform.S  2000/02/02 19:10:27     1.9
> +++ platform.S  2000/08/31 00:56:39
> @@ -187,10 +187,11 @@ hal_bus_error_vsr:
>  ## above to work around any bus errors provoked by the VRC4373.
>
>  FUNC_START(hal_pci_config_read)
>
>  hal_pci_config_read_load:
> +       .set noreorder
>         lw      v0,0(a0)        # Read the value. If this bus-errors the
>                                 # handler will skip this instruction and
>                                 # put 0xFFFFFFFF into v0.
>         jr      ra              # And return
>
> nop
>
> --
> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223)
728762
> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own
fault
>

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Jonathan Larmour]

Ling Su wrote:
> 
> Thanks, Jifl, the patch works well in PCI1. The left things puzzled me,
> 
> <1>. It didn't detect out the another PCI Network card on PCI slot 1, how
> you every try to plug one card on the board to test?

Sorry I haven't. Nick, any ideas?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> Ling Su wrote:
> > 
> > Thanks, Jifl, the patch works well in PCI1. The left things puzzled me,
> > 
> > <1>. It didn't detect out the another PCI Network card on PCI slot 1, how
> > you every try to plug one card on the board to test?
> 
> Sorry I haven't. Nick, any ideas?
> 

Sorry, no.

Thinking about it, I suspect we never tried plugging a card into the
PCI slots on the board. This was never something we needed to do, we
only ever used the on-board PCI devices. However, there should be no
additional software issues, it should just work. So maybe there are
problems with the PCI slots on the board. Are all the power pins
working? Are there any jumpers to change to enable them?

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.

[Ling Su]

> > Thanks, Jifl, the patch works well in PCI1. The left things puzzled me,
> >
> > <1>. It didn't detect out the another PCI Network card on PCI slot 1,
how
> > you every try to plug one card on the board to test?
>
> Sorry I haven't. Nick, any ideas?
>

Today I found two old PCI graphic card, one from S3, and another from
Trident, after I plugged them in, they are both successfully detected by
pci1. The previous card was from PCtel (a winmodem actally), I guess it
might be a legacy device, not fully support PCI spec. Anyway, this question
is solved.

Thanks, Jifl and Nick.

Regards,
-Ling