* [ECOS] eCos tools binary installation under Cygwin @ 2000-08-29 11:37 Grant Edwards 2000-08-29 11:57 ` Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Grant Edwards @ 2000-08-29 11:37 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] eCos tools binary installation under Cygwin 2000-08-29 11:37 [ECOS] eCos tools binary installation under Cygwin Grant Edwards @ 2000-08-29 11:57 ` Jonathan Larmour 2000-08-29 12:28 ` Ling Su 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-29 11:57 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] eCos tools binary installation under Cygwin 2000-08-29 11:57 ` Jonathan Larmour @ 2000-08-29 12:28 ` Ling Su 2000-08-29 12:43 ` Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Ling Su @ 2000-08-29 12:28 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] eCos tools binary installation under Cygwin 2000-08-29 12:28 ` Ling Su @ 2000-08-29 12:43 ` Jonathan Larmour [not found] ` <39AC12F4.9C2F7678@redhat.co.uk> 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-29 12:43 UTC (permalink / raw) To: Ling Su; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <39AC12F4.9C2F7678@redhat.co.uk>]
* [ECOS] eCos PCI problem and NEC vrc4373 build option. [not found] ` <39AC12F4.9C2F7678@redhat.co.uk> @ 2000-08-29 17:18 ` Ling Su 2000-08-30 15:25 ` [ECOS] " Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Ling Su @ 2000-08-29 17:18 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-29 17:18 ` [ECOS] eCos PCI problem and NEC vrc4373 build option Ling Su @ 2000-08-30 15:25 ` Jonathan Larmour 2000-08-30 15:51 ` Ling Su 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 15:25 UTC (permalink / raw) To: Ling Su; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 15:25 ` [ECOS] " Jonathan Larmour @ 2000-08-30 15:51 ` Ling Su 2000-08-30 15:58 ` Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Ling Su @ 2000-08-30 15:51 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 15:51 ` Ling Su @ 2000-08-30 15:58 ` Jonathan Larmour 2000-08-30 16:38 ` Alfredo Knecht 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 15:58 UTC (permalink / raw) To: Ling Su; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 15:58 ` Jonathan Larmour @ 2000-08-30 16:38 ` Alfredo Knecht 2000-08-30 17:20 ` Jonathan Larmour 2000-08-30 17:42 ` Ling Su 0 siblings, 2 replies; 18+ messages in thread From: Alfredo Knecht @ 2000-08-30 16:38 UTC (permalink / raw) To: ecos-discuss; +Cc: Jonathan Larmour 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) ************************************************************************ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 16:38 ` Alfredo Knecht @ 2000-08-30 17:20 ` Jonathan Larmour 2000-08-30 18:10 ` Alfredo Knecht 2000-08-30 17:42 ` Ling Su 1 sibling, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 17:20 UTC (permalink / raw) To: Alfredo Knecht; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 17:20 ` Jonathan Larmour @ 2000-08-30 18:10 ` Alfredo Knecht 2000-08-30 18:22 ` Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Alfredo Knecht @ 2000-08-30 18:10 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss 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) ************************************************************************ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 18:10 ` Alfredo Knecht @ 2000-08-30 18:22 ` Jonathan Larmour 0 siblings, 0 replies; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 18:22 UTC (permalink / raw) To: Alfredo Knecht; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 16:38 ` Alfredo Knecht 2000-08-30 17:20 ` Jonathan Larmour @ 2000-08-30 17:42 ` Ling Su 2000-08-30 18:02 ` Jonathan Larmour 1 sibling, 1 reply; 18+ messages in thread From: Ling Su @ 2000-08-30 17:42 UTC (permalink / raw) To: ecos-discuss, Alfredo Knecht; +Cc: Jonathan Larmour > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 17:42 ` Ling Su @ 2000-08-30 18:02 ` Jonathan Larmour 2000-08-30 18:28 ` Ling Su 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 18:02 UTC (permalink / raw) To: Ling Su; +Cc: ecos-discuss, Alfredo Knecht 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 18:02 ` Jonathan Larmour @ 2000-08-30 18:28 ` Ling Su 2000-08-30 18:57 ` Jonathan Larmour 0 siblings, 1 reply; 18+ messages in thread From: Ling Su @ 2000-08-30 18:28 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 18:28 ` Ling Su @ 2000-08-30 18:57 ` Jonathan Larmour 2000-08-31 3:34 ` Nick Garnett 2000-08-31 10:57 ` Ling Su 0 siblings, 2 replies; 18+ messages in thread From: Jonathan Larmour @ 2000-08-30 18:57 UTC (permalink / raw) To: Ling Su; +Cc: ecos-discuss, Nick Garnett 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 18:57 ` Jonathan Larmour @ 2000-08-31 3:34 ` Nick Garnett 2000-08-31 10:57 ` Ling Su 1 sibling, 0 replies; 18+ messages in thread From: Nick Garnett @ 2000-08-31 3:34 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Ling Su, ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option. 2000-08-30 18:57 ` Jonathan Larmour 2000-08-31 3:34 ` Nick Garnett @ 2000-08-31 10:57 ` Ling Su 1 sibling, 0 replies; 18+ messages in thread From: Ling Su @ 2000-08-31 10:57 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss, Nick Garnett > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2000-08-31 10:57 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-08-29 11:37 [ECOS] eCos tools binary installation under Cygwin Grant Edwards 2000-08-29 11:57 ` Jonathan Larmour 2000-08-29 12:28 ` Ling Su 2000-08-29 12:43 ` Jonathan Larmour [not found] ` <39AC12F4.9C2F7678@redhat.co.uk> 2000-08-29 17:18 ` [ECOS] eCos PCI problem and NEC vrc4373 build option Ling Su 2000-08-30 15:25 ` [ECOS] " Jonathan Larmour 2000-08-30 15:51 ` Ling Su 2000-08-30 15:58 ` Jonathan Larmour 2000-08-30 16:38 ` Alfredo Knecht 2000-08-30 17:20 ` Jonathan Larmour 2000-08-30 18:10 ` Alfredo Knecht 2000-08-30 18:22 ` Jonathan Larmour 2000-08-30 17:42 ` Ling Su 2000-08-30 18:02 ` Jonathan Larmour 2000-08-30 18:28 ` Ling Su 2000-08-30 18:57 ` Jonathan Larmour 2000-08-31 3:34 ` Nick Garnett 2000-08-31 10:57 ` Ling Su
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).