es40-developers Mailing List for AlphaServer ES40 Emulator (Page 9)
Status: Alpha
Brought to you by:
iamcamiel
Menu
▾
▴
es40-developers — ES40 Developers List
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(132) |
Mar
(117) |
Apr
(27) |
May
(1) |
Jun
(16) |
Jul
|
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian W. <bdw...@in...> - 2008-02-28 13:27:26
|
On Thu, 2008-02-28 at 12:30 +0100, Fausto Saporito wrote: > Hello Camiel, > > so it seems the emulated graphic cards are not supported under NetBSD :-) > Ok... I give up, and I'll try FreeBSD, maybe I will be more lucky. > I've been looking at that off and on for ages and I can't figure out what NetBSD is doing before it panics. The only thing I was able to see was it would look at the PCI config and then barf. Tru64 also barfs when trying to start up X. I haven't been able to find an X server for freebsd, so if you find one, let me know. Brian > Fausto > > Quoting Camiel Vanderhoeven <iam...@gm...>: > > > Hello Fausto, > > > > I'm no expert on NetBSD, but a quick google search on > > "pci_display_console" and "255/255/0" leads me to a couple of > > discussions on this message, all of them NetBSD on Alpha, so it looks > > like it's something that happens on real Alpha's as well... > > > > Camiel. > > > > On Thu, Feb 28, 2008 at 8:47 AM, Fausto Saporito <fa...@un...> wrote: > >> Hello all, > >> > >> between an OpenVMS installation and another, I downloaded the netbsd > >> 4.0 cdrom. > >> The boot seems fine, but kernel goes in panic :-) at > >> > >> panic: pci_display_console: no device at 255/255/0 > >> Stopped at 0xffffffc00005da050: ret (zero),ra > >> > >> What is 255/255/0?? a PCI address? > >> > >> regards, > >> fausto > >> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Es40-developers mailing list > >> Es4...@li... > >> https://lists.sourceforge.net/lists/listinfo/es40-developers > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Es40-developers mailing list > > Es4...@li... > > https://lists.sourceforge.net/lists/listinfo/es40-developers > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers |
|
From: Fausto S. <fa...@un...> - 2008-02-28 11:30:29
|
Hello Camiel, so it seems the emulated graphic cards are not supported under NetBSD :-) Ok... I give up, and I'll try FreeBSD, maybe I will be more lucky. Fausto Quoting Camiel Vanderhoeven <iam...@gm...>: > Hello Fausto, > > I'm no expert on NetBSD, but a quick google search on > "pci_display_console" and "255/255/0" leads me to a couple of > discussions on this message, all of them NetBSD on Alpha, so it looks > like it's something that happens on real Alpha's as well... > > Camiel. > > On Thu, Feb 28, 2008 at 8:47 AM, Fausto Saporito <fa...@un...> wrote: >> Hello all, >> >> between an OpenVMS installation and another, I downloaded the netbsd >> 4.0 cdrom. >> The boot seems fine, but kernel goes in panic :-) at >> >> panic: pci_display_console: no device at 255/255/0 >> Stopped at 0xffffffc00005da050: ret (zero),ra >> >> What is 255/255/0?? a PCI address? >> >> regards, >> fausto >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Es40-developers mailing list >> Es4...@li... >> https://lists.sourceforge.net/lists/listinfo/es40-developers >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Camiel V. <iam...@gm...> - 2008-02-28 09:18:59
|
Hello Fausto, I'm no expert on NetBSD, but a quick google search on "pci_display_console" and "255/255/0" leads me to a couple of discussions on this message, all of them NetBSD on Alpha, so it looks like it's something that happens on real Alpha's as well... Camiel. On Thu, Feb 28, 2008 at 8:47 AM, Fausto Saporito <fa...@un...> wrote: > Hello all, > > between an OpenVMS installation and another, I downloaded the netbsd > 4.0 cdrom. > The boot seems fine, but kernel goes in panic :-) at > > panic: pci_display_console: no device at 255/255/0 > Stopped at 0xffffffc00005da050: ret (zero),ra > > What is 255/255/0?? a PCI address? > > regards, > fausto > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Fausto S. <fa...@un...> - 2008-02-28 07:48:09
|
Hello all, between an OpenVMS installation and another, I downloaded the netbsd 4.0 cdrom. The boot seems fine, but kernel goes in panic :-) at panic: pci_display_console: no device at 255/255/0 Stopped at 0xffffffc00005da050: ret (zero),ra What is 255/255/0?? a PCI address? regards, fausto |
|
From: Brian W. <bdw...@in...> - 2008-02-28 02:22:24
|
On Thu, 2008-02-28 at 01:44 +0100, Fausto Saporito wrote: > Hello Brian, > > but where can I found the media and license for $100? > From HP site? ebay? > > thanks, > fausto > You can probably find the media on ebay, but the license is usually tied to a machine. Judging by the lack of hits on the HP site, it doesn't look like they are doing it anymore...which isn't surprising since the last order date for AXP was last year sometime and there's no real development going on. Brian > Quoting Brian Wheeler <bdw...@in...>: > > > There used to be one offered by Compaq, but I don't know if HP carried > > it forward. For $100 you got media and a license of some sort. > > > > If you can find a copy of the media, you can run it and do some basic > > things without having the OSF-BASE license PAK. > > > > Technically, I think the only way to run Tru64 with any enjoyment (and > > legally) is to have a license. That said, I have heard of someone that > > found a way to generate valid licenses on VMS. With the ability to do > > that, you could generate an OSF-BASE license...both VMS' LICENSE and > > OSF's lmf use the same validation methods. > > > > Brian > > > > > > On Wed, 2008-02-27 at 19:28 +0100, Fausto Saporito wrote: > >> Hello all, > >> > >> about this subject, i'm wondering if there's an hobbyist license for Tru64. > >> Do you know if it's possible to subscribe such kind of licensing? > >> > >> thanks, > >> fausto > >> > >> Quoting Brian Wheeler <bdw...@in...>: > >> > >> > Turns out that the temperatures aren't actually in BCD but in degrees > >> > Celsius. This patch is a minor refactor of DPR, plus a change to the > >> > keyboard driver to ignore the the make/break commands so it'll come up > >> > with the vga card inserted. I'm going gather up a tru64 license and see > >> > if I can get cde to run. I'll probably also try the networking. > >> > > >> > Brian > >> > > >> > > >> > > >> > On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote: > >> >> Hi Brian, > >> >> > >> >> The ES40 has a management processor that takes care of monitoring > >> >> power suppies, fans, and other hardware bits and pieces. It is > >> >> extremely difficult to find any information about this. I managed to > >> >> find some info in the ES40 service manual, and basically played a lot > >> >> with things to get them to show up properly in SRM. > >> >> > >> >> The management processor communicates with SRM - and I presume with > >> >> the OS - through a thing called Dual-Port-RAM. One port is connected > >> >> to the system bus, another to the management-processor. A lot of the > >> >> bytes are places where the OS can read device information, but in some > >> >> locations, the OS can deposit commands for the management-processor. > >> >> The following copmmands were found out through trial-and-error and > >> >> partial reverse engineering of SRM: > >> >> > >> >> Address locations for commands: > >> >> // 0xf9: buffer size > >> >> // 0xfb:fa qualifier / address > >> >> // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 > >> >> = invalid qualifier) > >> >> // 0xfd: rmc command id for response > >> >> // 0xfe: command code > >> >> // 0xff: rmc command id for command > >> >> > >> >> Command codes: > >> >> // 01: update EEPROM > >> >> // 02: update baud rate > >> >> // 03: write to OCP > >> >> // F0: update RMC flash > >> >> > >> >> It could very well be that there are more commands I don't know about, > >> >> and a failure to respond to these in a satisfactory manner may well be > >> >> the cause of the power supply failures and temperature warnings. > >> >> > >> >> You can find most of what I managed to find out in DPR.cpp. Mind you, > >> >> this is some of the oldest and least-touched code in the emulator. It > >> >> has not changed (other than some of the standard changes that have > >> >> been made to the entire emulator) for well over a year, and a lot of > >> >> my comments are still in Dutch. (I'm sorry about that...) It might be > >> >> a good idea to put some read/write tracers in DPR.cpp, and try to > >> >> figure out what Tru64 is doing with these. > >> >> > >> >> Camiel. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler > >> <bdw...@in...> wrote: > >> >> > I did a full install from dqb0 to dqa0 and while there were some > >> >> > timeouts (this build was before I started on the interrupt > >> resend code) > >> >> > it installed and configured correctly (I left it run unattended > >> >> > overnight). > >> >> > > >> >> > However, once it came up, it started announcing hardware failures :) > >> >> > > >> >> > ----------------- > >> >> > Broadcast Message from ro...@tr... (???) at 23:37 ... > >> >> > > >> >> > The redundant power supply has failed. > >> >> > > >> >> > Broadcast Message from ro...@tr... (???) at 23:37 ... > >> >> > > >> >> > The system temperature is high. Possible reasons are > >> >> > a clogged air filter or a high ambient room temperature. > >> >> > The system will shut down in 14 minutes and 0 seconds.. > >> >> > ------------------ > >> >> > > >> >> > So...is there any documentation for the hardware monitoring stuff? > >> >> > > >> >> > Brian > >> >> > > >> >> > > >> >> > > >> >> > > >> ------------------------------------------------------------------------- > >> >> > This SF.net email is sponsored by: Microsoft > >> >> > Defy all challenges. Microsoft(R) Visual Studio 2008. > >> >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> >> > _______________________________________________ > >> >> > Es40-developers mailing list > >> >> > Es4...@li... > >> >> > https://lists.sourceforge.net/lists/listinfo/es40-developers > >> >> > > >> >> > >> >> ------------------------------------------------------------------------- > >> >> This SF.net email is sponsored by: Microsoft > >> >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> >> _______________________________________________ > >> >> Es40-developers mailing list > >> >> Es4...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/es40-developers > >> > > >> > >> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Es40-developers mailing list > >> Es4...@li... > >> https://lists.sourceforge.net/lists/listinfo/es40-developers > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Es40-developers mailing list > > Es4...@li... > > https://lists.sourceforge.net/lists/listinfo/es40-developers > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers |
|
From: Fausto S. <fa...@un...> - 2008-02-28 00:44:36
|
Hello Brian, but where can I found the media and license for $100? From HP site? ebay? thanks, fausto Quoting Brian Wheeler <bdw...@in...>: > There used to be one offered by Compaq, but I don't know if HP carried > it forward. For $100 you got media and a license of some sort. > > If you can find a copy of the media, you can run it and do some basic > things without having the OSF-BASE license PAK. > > Technically, I think the only way to run Tru64 with any enjoyment (and > legally) is to have a license. That said, I have heard of someone that > found a way to generate valid licenses on VMS. With the ability to do > that, you could generate an OSF-BASE license...both VMS' LICENSE and > OSF's lmf use the same validation methods. > > Brian > > > On Wed, 2008-02-27 at 19:28 +0100, Fausto Saporito wrote: >> Hello all, >> >> about this subject, i'm wondering if there's an hobbyist license for Tru64. >> Do you know if it's possible to subscribe such kind of licensing? >> >> thanks, >> fausto >> >> Quoting Brian Wheeler <bdw...@in...>: >> >> > Turns out that the temperatures aren't actually in BCD but in degrees >> > Celsius. This patch is a minor refactor of DPR, plus a change to the >> > keyboard driver to ignore the the make/break commands so it'll come up >> > with the vga card inserted. I'm going gather up a tru64 license and see >> > if I can get cde to run. I'll probably also try the networking. >> > >> > Brian >> > >> > >> > >> > On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote: >> >> Hi Brian, >> >> >> >> The ES40 has a management processor that takes care of monitoring >> >> power suppies, fans, and other hardware bits and pieces. It is >> >> extremely difficult to find any information about this. I managed to >> >> find some info in the ES40 service manual, and basically played a lot >> >> with things to get them to show up properly in SRM. >> >> >> >> The management processor communicates with SRM - and I presume with >> >> the OS - through a thing called Dual-Port-RAM. One port is connected >> >> to the system bus, another to the management-processor. A lot of the >> >> bytes are places where the OS can read device information, but in some >> >> locations, the OS can deposit commands for the management-processor. >> >> The following copmmands were found out through trial-and-error and >> >> partial reverse engineering of SRM: >> >> >> >> Address locations for commands: >> >> // 0xf9: buffer size >> >> // 0xfb:fa qualifier / address >> >> // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 >> >> = invalid qualifier) >> >> // 0xfd: rmc command id for response >> >> // 0xfe: command code >> >> // 0xff: rmc command id for command >> >> >> >> Command codes: >> >> // 01: update EEPROM >> >> // 02: update baud rate >> >> // 03: write to OCP >> >> // F0: update RMC flash >> >> >> >> It could very well be that there are more commands I don't know about, >> >> and a failure to respond to these in a satisfactory manner may well be >> >> the cause of the power supply failures and temperature warnings. >> >> >> >> You can find most of what I managed to find out in DPR.cpp. Mind you, >> >> this is some of the oldest and least-touched code in the emulator. It >> >> has not changed (other than some of the standard changes that have >> >> been made to the entire emulator) for well over a year, and a lot of >> >> my comments are still in Dutch. (I'm sorry about that...) It might be >> >> a good idea to put some read/write tracers in DPR.cpp, and try to >> >> figure out what Tru64 is doing with these. >> >> >> >> Camiel. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler >> <bdw...@in...> wrote: >> >> > I did a full install from dqb0 to dqa0 and while there were some >> >> > timeouts (this build was before I started on the interrupt >> resend code) >> >> > it installed and configured correctly (I left it run unattended >> >> > overnight). >> >> > >> >> > However, once it came up, it started announcing hardware failures :) >> >> > >> >> > ----------------- >> >> > Broadcast Message from ro...@tr... (???) at 23:37 ... >> >> > >> >> > The redundant power supply has failed. >> >> > >> >> > Broadcast Message from ro...@tr... (???) at 23:37 ... >> >> > >> >> > The system temperature is high. Possible reasons are >> >> > a clogged air filter or a high ambient room temperature. >> >> > The system will shut down in 14 minutes and 0 seconds.. >> >> > ------------------ >> >> > >> >> > So...is there any documentation for the hardware monitoring stuff? >> >> > >> >> > Brian >> >> > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------- >> >> > This SF.net email is sponsored by: Microsoft >> >> > Defy all challenges. Microsoft(R) Visual Studio 2008. >> >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> >> > _______________________________________________ >> >> > Es40-developers mailing list >> >> > Es4...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/es40-developers >> >> > >> >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Microsoft >> >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> >> _______________________________________________ >> >> Es40-developers mailing list >> >> Es4...@li... >> >> https://lists.sourceforge.net/lists/listinfo/es40-developers >> > >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Es40-developers mailing list >> Es4...@li... >> https://lists.sourceforge.net/lists/listinfo/es40-developers > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Brian W. <bdw...@in...> - 2008-02-27 20:51:19
|
It looks like the SROM on the NIC has to be properly checksummed before Tru64 will use it. I found the tru64 device driver kit sample files online which contained the tulip driver as a sample! I've attached the files in case there are other problems we have later with the NIC. After copying the crc routine and working it into the ResetNIC function, tru64 likes the device: tu0: DECchip 21143: Revision: 3.0 tu0: auto negotiation capable device tu0 at pci0 slot 4 tu0: DEC TULIP (10/100) Ethernet Interface, hardware address: 08-00-2B-E5-40-00 tu0: no console mode: defaulting to 10BaseT (UTP) port: half duplex For tcp/ip it doesn't seem to connect to the outside world, but I can run ifconfig and configure it without errors. Brian |
|
From: Brian W. <bdw...@in...> - 2008-02-27 18:40:44
|
There used to be one offered by Compaq, but I don't know if HP carried it forward. For $100 you got media and a license of some sort. If you can find a copy of the media, you can run it and do some basic things without having the OSF-BASE license PAK. Technically, I think the only way to run Tru64 with any enjoyment (and legally) is to have a license. That said, I have heard of someone that found a way to generate valid licenses on VMS. With the ability to do that, you could generate an OSF-BASE license...both VMS' LICENSE and OSF's lmf use the same validation methods. Brian On Wed, 2008-02-27 at 19:28 +0100, Fausto Saporito wrote: > Hello all, > > about this subject, i'm wondering if there's an hobbyist license for Tru64. > Do you know if it's possible to subscribe such kind of licensing? > > thanks, > fausto > > Quoting Brian Wheeler <bdw...@in...>: > > > Turns out that the temperatures aren't actually in BCD but in degrees > > Celsius. This patch is a minor refactor of DPR, plus a change to the > > keyboard driver to ignore the the make/break commands so it'll come up > > with the vga card inserted. I'm going gather up a tru64 license and see > > if I can get cde to run. I'll probably also try the networking. > > > > Brian > > > > > > > > On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote: > >> Hi Brian, > >> > >> The ES40 has a management processor that takes care of monitoring > >> power suppies, fans, and other hardware bits and pieces. It is > >> extremely difficult to find any information about this. I managed to > >> find some info in the ES40 service manual, and basically played a lot > >> with things to get them to show up properly in SRM. > >> > >> The management processor communicates with SRM - and I presume with > >> the OS - through a thing called Dual-Port-RAM. One port is connected > >> to the system bus, another to the management-processor. A lot of the > >> bytes are places where the OS can read device information, but in some > >> locations, the OS can deposit commands for the management-processor. > >> The following copmmands were found out through trial-and-error and > >> partial reverse engineering of SRM: > >> > >> Address locations for commands: > >> // 0xf9: buffer size > >> // 0xfb:fa qualifier / address > >> // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 > >> = invalid qualifier) > >> // 0xfd: rmc command id for response > >> // 0xfe: command code > >> // 0xff: rmc command id for command > >> > >> Command codes: > >> // 01: update EEPROM > >> // 02: update baud rate > >> // 03: write to OCP > >> // F0: update RMC flash > >> > >> It could very well be that there are more commands I don't know about, > >> and a failure to respond to these in a satisfactory manner may well be > >> the cause of the power supply failures and temperature warnings. > >> > >> You can find most of what I managed to find out in DPR.cpp. Mind you, > >> this is some of the oldest and least-touched code in the emulator. It > >> has not changed (other than some of the standard changes that have > >> been made to the entire emulator) for well over a year, and a lot of > >> my comments are still in Dutch. (I'm sorry about that...) It might be > >> a good idea to put some read/write tracers in DPR.cpp, and try to > >> figure out what Tru64 is doing with these. > >> > >> Camiel. > >> > >> > >> > >> > >> > >> On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler <bdw...@in...> wrote: > >> > I did a full install from dqb0 to dqa0 and while there were some > >> > timeouts (this build was before I started on the interrupt resend code) > >> > it installed and configured correctly (I left it run unattended > >> > overnight). > >> > > >> > However, once it came up, it started announcing hardware failures :) > >> > > >> > ----------------- > >> > Broadcast Message from ro...@tr... (???) at 23:37 ... > >> > > >> > The redundant power supply has failed. > >> > > >> > Broadcast Message from ro...@tr... (???) at 23:37 ... > >> > > >> > The system temperature is high. Possible reasons are > >> > a clogged air filter or a high ambient room temperature. > >> > The system will shut down in 14 minutes and 0 seconds.. > >> > ------------------ > >> > > >> > So...is there any documentation for the hardware monitoring stuff? > >> > > >> > Brian > >> > > >> > > >> > > >> > ------------------------------------------------------------------------- > >> > This SF.net email is sponsored by: Microsoft > >> > Defy all challenges. Microsoft(R) Visual Studio 2008. > >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> > _______________________________________________ > >> > Es40-developers mailing list > >> > Es4...@li... > >> > https://lists.sourceforge.net/lists/listinfo/es40-developers > >> > > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Es40-developers mailing list > >> Es4...@li... > >> https://lists.sourceforge.net/lists/listinfo/es40-developers > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers |
|
From: Fausto S. <fa...@un...> - 2008-02-27 18:31:26
|
Hello all, about this subject, i'm wondering if there's an hobbyist license for Tru64. Do you know if it's possible to subscribe such kind of licensing? thanks, fausto Quoting Brian Wheeler <bdw...@in...>: > Turns out that the temperatures aren't actually in BCD but in degrees > Celsius. This patch is a minor refactor of DPR, plus a change to the > keyboard driver to ignore the the make/break commands so it'll come up > with the vga card inserted. I'm going gather up a tru64 license and see > if I can get cde to run. I'll probably also try the networking. > > Brian > > > > On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote: >> Hi Brian, >> >> The ES40 has a management processor that takes care of monitoring >> power suppies, fans, and other hardware bits and pieces. It is >> extremely difficult to find any information about this. I managed to >> find some info in the ES40 service manual, and basically played a lot >> with things to get them to show up properly in SRM. >> >> The management processor communicates with SRM - and I presume with >> the OS - through a thing called Dual-Port-RAM. One port is connected >> to the system bus, another to the management-processor. A lot of the >> bytes are places where the OS can read device information, but in some >> locations, the OS can deposit commands for the management-processor. >> The following copmmands were found out through trial-and-error and >> partial reverse engineering of SRM: >> >> Address locations for commands: >> // 0xf9: buffer size >> // 0xfb:fa qualifier / address >> // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 >> = invalid qualifier) >> // 0xfd: rmc command id for response >> // 0xfe: command code >> // 0xff: rmc command id for command >> >> Command codes: >> // 01: update EEPROM >> // 02: update baud rate >> // 03: write to OCP >> // F0: update RMC flash >> >> It could very well be that there are more commands I don't know about, >> and a failure to respond to these in a satisfactory manner may well be >> the cause of the power supply failures and temperature warnings. >> >> You can find most of what I managed to find out in DPR.cpp. Mind you, >> this is some of the oldest and least-touched code in the emulator. It >> has not changed (other than some of the standard changes that have >> been made to the entire emulator) for well over a year, and a lot of >> my comments are still in Dutch. (I'm sorry about that...) It might be >> a good idea to put some read/write tracers in DPR.cpp, and try to >> figure out what Tru64 is doing with these. >> >> Camiel. >> >> >> >> >> >> On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler <bdw...@in...> wrote: >> > I did a full install from dqb0 to dqa0 and while there were some >> > timeouts (this build was before I started on the interrupt resend code) >> > it installed and configured correctly (I left it run unattended >> > overnight). >> > >> > However, once it came up, it started announcing hardware failures :) >> > >> > ----------------- >> > Broadcast Message from ro...@tr... (???) at 23:37 ... >> > >> > The redundant power supply has failed. >> > >> > Broadcast Message from ro...@tr... (???) at 23:37 ... >> > >> > The system temperature is high. Possible reasons are >> > a clogged air filter or a high ambient room temperature. >> > The system will shut down in 14 minutes and 0 seconds.. >> > ------------------ >> > >> > So...is there any documentation for the hardware monitoring stuff? >> > >> > Brian >> > >> > >> > >> > ------------------------------------------------------------------------- >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2008. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > _______________________________________________ >> > Es40-developers mailing list >> > Es4...@li... >> > https://lists.sourceforge.net/lists/listinfo/es40-developers >> > >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Es40-developers mailing list >> Es4...@li... >> https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Brian W. <bdw...@in...> - 2008-02-27 15:59:00
|
Turns out that the temperatures aren't actually in BCD but in degrees Celsius. This patch is a minor refactor of DPR, plus a change to the keyboard driver to ignore the the make/break commands so it'll come up with the vga card inserted. I'm going gather up a tru64 license and see if I can get cde to run. I'll probably also try the networking. Brian On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote: > Hi Brian, > > The ES40 has a management processor that takes care of monitoring > power suppies, fans, and other hardware bits and pieces. It is > extremely difficult to find any information about this. I managed to > find some info in the ES40 service manual, and basically played a lot > with things to get them to show up properly in SRM. > > The management processor communicates with SRM - and I presume with > the OS - through a thing called Dual-Port-RAM. One port is connected > to the system bus, another to the management-processor. A lot of the > bytes are places where the OS can read device information, but in some > locations, the OS can deposit commands for the management-processor. > The following copmmands were found out through trial-and-error and > partial reverse engineering of SRM: > > Address locations for commands: > // 0xf9: buffer size > // 0xfb:fa qualifier / address > // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 > = invalid qualifier) > // 0xfd: rmc command id for response > // 0xfe: command code > // 0xff: rmc command id for command > > Command codes: > // 01: update EEPROM > // 02: update baud rate > // 03: write to OCP > // F0: update RMC flash > > It could very well be that there are more commands I don't know about, > and a failure to respond to these in a satisfactory manner may well be > the cause of the power supply failures and temperature warnings. > > You can find most of what I managed to find out in DPR.cpp. Mind you, > this is some of the oldest and least-touched code in the emulator. It > has not changed (other than some of the standard changes that have > been made to the entire emulator) for well over a year, and a lot of > my comments are still in Dutch. (I'm sorry about that...) It might be > a good idea to put some read/write tracers in DPR.cpp, and try to > figure out what Tru64 is doing with these. > > Camiel. > > > > > > On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler <bdw...@in...> wrote: > > I did a full install from dqb0 to dqa0 and while there were some > > timeouts (this build was before I started on the interrupt resend code) > > it installed and configured correctly (I left it run unattended > > overnight). > > > > However, once it came up, it started announcing hardware failures :) > > > > ----------------- > > Broadcast Message from ro...@tr... (???) at 23:37 ... > > > > The redundant power supply has failed. > > > > Broadcast Message from ro...@tr... (???) at 23:37 ... > > > > The system temperature is high. Possible reasons are > > a clogged air filter or a high ambient room temperature. > > The system will shut down in 14 minutes and 0 seconds.. > > ------------------ > > > > So...is there any documentation for the hardware monitoring stuff? > > > > Brian > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Es40-developers mailing list > > Es4...@li... > > https://lists.sourceforge.net/lists/listinfo/es40-developers > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers |
|
From: Brian W. <bdw...@in...> - 2008-02-27 14:06:13
|
Thanks for the info. I'll play around with it and see what I can come
up with.
Can you apply this patch. It tunes the interrupt re-send code so it
doesn't trigger so often.
Brian
Index: NewIde.cpp
===================================================================
RCS file: /cvsroot/es40/es40/src/NewIde.cpp,v
retrieving revision 1.16
diff -u -r1.16 NewIde.cpp
--- NewIde.cpp 27 Feb 2008 12:34:19 -0000 1.16
+++ NewIde.cpp 27 Feb 2008 14:04:51 -0000
@@ -1881,7 +1881,7 @@
if(CONTROLLER(index).interrupt_fired != 0)
{
- if((SEL_COMMAND(index).command_cycle - CONTROLLER(index).interrupt_fired) > 10)
+ if((SEL_COMMAND(index).command_cycle - CONTROLLER(index).interrupt_fired) > 200)
{
CONTROLLER(index).interrupt_pending=1;
theAli->pic_deassert(1,6+index);
On Wed, 2008-02-27 at 14:35 +0100, Camiel Vanderhoeven wrote:
> Hi Brian,
>
> The ES40 has a management processor that takes care of monitoring
> power suppies, fans, and other hardware bits and pieces. It is
> extremely difficult to find any information about this. I managed to
> find some info in the ES40 service manual, and basically played a lot
> with things to get them to show up properly in SRM.
>
> The management processor communicates with SRM - and I presume with
> the OS - through a thing called Dual-Port-RAM. One port is connected
> to the system bus, another to the management-processor. A lot of the
> bytes are places where the OS can read device information, but in some
> locations, the OS can deposit commands for the management-processor.
> The following copmmands were found out through trial-and-error and
> partial reverse engineering of SRM:
>
> Address locations for commands:
> // 0xf9: buffer size
> // 0xfb:fa qualifier / address
> // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82
> = invalid qualifier)
> // 0xfd: rmc command id for response
> // 0xfe: command code
> // 0xff: rmc command id for command
>
> Command codes:
> // 01: update EEPROM
> // 02: update baud rate
> // 03: write to OCP
> // F0: update RMC flash
>
> It could very well be that there are more commands I don't know about,
> and a failure to respond to these in a satisfactory manner may well be
> the cause of the power supply failures and temperature warnings.
>
> You can find most of what I managed to find out in DPR.cpp. Mind you,
> this is some of the oldest and least-touched code in the emulator. It
> has not changed (other than some of the standard changes that have
> been made to the entire emulator) for well over a year, and a lot of
> my comments are still in Dutch. (I'm sorry about that...) It might be
> a good idea to put some read/write tracers in DPR.cpp, and try to
> figure out what Tru64 is doing with these.
>
> Camiel.
>
>
>
>
>
> On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler <bdw...@in...> wrote:
> > I did a full install from dqb0 to dqa0 and while there were some
> > timeouts (this build was before I started on the interrupt resend code)
> > it installed and configured correctly (I left it run unattended
> > overnight).
> >
> > However, once it came up, it started announcing hardware failures :)
> >
> > -----------------
> > Broadcast Message from ro...@tr... (???) at 23:37 ...
> >
> > The redundant power supply has failed.
> >
> > Broadcast Message from ro...@tr... (???) at 23:37 ...
> >
> > The system temperature is high. Possible reasons are
> > a clogged air filter or a high ambient room temperature.
> > The system will shut down in 14 minutes and 0 seconds..
> > ------------------
> >
> > So...is there any documentation for the hardware monitoring stuff?
> >
> > Brian
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Es40-developers mailing list
> > Es4...@li...
> > https://lists.sourceforge.net/lists/listinfo/es40-developers
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Es40-developers mailing list
> Es4...@li...
> https://lists.sourceforge.net/lists/listinfo/es40-developers
|
|
From: Camiel V. <iam...@gm...> - 2008-02-27 13:35:29
|
Hi Brian, The ES40 has a management processor that takes care of monitoring power suppies, fans, and other hardware bits and pieces. It is extremely difficult to find any information about this. I managed to find some info in the ES40 service manual, and basically played a lot with things to get them to show up properly in SRM. The management processor communicates with SRM - and I presume with the OS - through a thing called Dual-Port-RAM. One port is connected to the system bus, another to the management-processor. A lot of the bytes are places where the OS can read device information, but in some locations, the OS can deposit commands for the management-processor. The following copmmands were found out through trial-and-error and partial reverse engineering of SRM: Address locations for commands: // 0xf9: buffer size // 0xfb:fa qualifier / address // 0xfc: completion code (0 = ok, 80 = error, 81 = invalid code, 82 = invalid qualifier) // 0xfd: rmc command id for response // 0xfe: command code // 0xff: rmc command id for command Command codes: // 01: update EEPROM // 02: update baud rate // 03: write to OCP // F0: update RMC flash It could very well be that there are more commands I don't know about, and a failure to respond to these in a satisfactory manner may well be the cause of the power supply failures and temperature warnings. You can find most of what I managed to find out in DPR.cpp. Mind you, this is some of the oldest and least-touched code in the emulator. It has not changed (other than some of the standard changes that have been made to the entire emulator) for well over a year, and a lot of my comments are still in Dutch. (I'm sorry about that...) It might be a good idea to put some read/write tracers in DPR.cpp, and try to figure out what Tru64 is doing with these. Camiel. On Wed, Feb 27, 2008 at 2:19 PM, Brian Wheeler <bdw...@in...> wrote: > I did a full install from dqb0 to dqa0 and while there were some > timeouts (this build was before I started on the interrupt resend code) > it installed and configured correctly (I left it run unattended > overnight). > > However, once it came up, it started announcing hardware failures :) > > ----------------- > Broadcast Message from ro...@tr... (???) at 23:37 ... > > The redundant power supply has failed. > > Broadcast Message from ro...@tr... (???) at 23:37 ... > > The system temperature is high. Possible reasons are > a clogged air filter or a high ambient room temperature. > The system will shut down in 14 minutes and 0 seconds.. > ------------------ > > So...is there any documentation for the hardware monitoring stuff? > > Brian > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Brian W. <bdw...@in...> - 2008-02-27 13:20:02
|
I did a full install from dqb0 to dqa0 and while there were some timeouts (this build was before I started on the interrupt resend code) it installed and configured correctly (I left it run unattended overnight). However, once it came up, it started announcing hardware failures :) ----------------- Broadcast Message from ro...@tr... (???) at 23:37 ... The redundant power supply has failed. Broadcast Message from ro...@tr... (???) at 23:37 ... The system temperature is high. Possible reasons are a clogged air filter or a high ambient room temperature. The system will shut down in 14 minutes and 0 seconds.. ------------------ So...is there any documentation for the hardware monitoring stuff? Brian |
|
From: Camiel V. <iam...@gm...> - 2008-02-27 12:05:55
|
Hi Brian, I've applied these changes to the repository. I've changed the fixes in the 53c810 device to let unimplemented registers return 0. Camiel. On Thu, Feb 21, 2008 at 3:39 PM, Brian Wheeler <bdw...@in...> wrote: > This patch cleans up some warnings when gcc is run with -Wall. Mostly > it is fixing RestoreState and SaveState printf cast warnings. It does > initialize some variables and changes the CSCSIDevice destructor to be > virtual and adds a newline onto a few files which don't have them. > > Brian > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > > |
|
From: brian w. <bdw...@in...> - 2008-02-27 03:00:59
|
Actually, I need to increment the cycle counter before I handle the interrupt. Here's a patch which works better. Brian On Tue, 2008-02-26 at 16:33 -0500, Brian Wheeler wrote: > This patch fixes two things: > 1) clears the busmaster active bit when the bit 1 is written to the > busmaster status register. > 2) Attempts to refire the interrupt if the controller seems to have > missed it -- before the OS declares a timeout. > > This patch fixes the vms boot problems from ide cdrom and it also > allowed me to install tru64 -- albeit with timeouts. > > The timeout refire code isn't very well tested, since it is very timing > dependent, and if you have IDE debugging turned on, es40 waits for a > keypress before re-issuing the interrupt (since I want to see what it is > doing) > > Brian > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ Es40-developers mailing list Es4...@li... https://lists.sourceforge.net/lists/listinfo/es40-developers |
|
From: Brian W. <bdw...@in...> - 2008-02-26 21:33:41
|
This patch fixes two things: 1) clears the busmaster active bit when the bit 1 is written to the busmaster status register. 2) Attempts to refire the interrupt if the controller seems to have missed it -- before the OS declares a timeout. This patch fixes the vms boot problems from ide cdrom and it also allowed me to install tru64 -- albeit with timeouts. The timeout refire code isn't very well tested, since it is very timing dependent, and if you have IDE debugging turned on, es40 waits for a keypress before re-issuing the interrupt (since I want to see what it is doing) Brian |
|
From: Hittner, D. T. <dav...@ng...> - 2008-02-26 16:28:39
|
Well, I'm work towards getting DECNET running - DECNET still BUGCHECKs the machine. Dave > -----Original Message----- > From: es4...@li... > [mailto:es4...@li...] On > Behalf Of Camiel Vanderhoeven > Sent: Tuesday, February 26, 2008 10:58 AM > To: ES40 Developer Discussions > Subject: [ES40-developers] NIC code rewrite > > Hello Everyone, > > David Hittner has re-written most of the > network-interface-code. He's implemented a bunch of things > that were missing, and that were needed to make DECnet happy. > Among these are a buffer to hold incoming packets so we don't > lose them, and true internal loopback processing. > > The sources are in CVS now. > > Camiel. > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Camiel V. <iam...@gm...> - 2008-02-26 15:58:05
|
Hello Brian, I've committed this as well. Thanks! Camiel. On Tue, Feb 26, 2008 at 3:36 PM, Brian Wheeler <bdw...@in...> wrote: > fixes for the DMA device: > * output wrapped in DEBUG_DMA ifdefs. > * no-op implementation of the different registers > > System fixes: > * ignore reads of 0x480 & 0x4c0 (TLBIV, TLBIA). It looks like > linux (and others) do a read immediately after a write. Probably to > keep the pchip's addresses in the TLB? > > In Linux's arch/alpha/kernel/core_tsunami.c: > > 184 csr = &pchip->tlbia.csr; > 185 if (((start ^ end) & 0xffff0000) == 0) > 186 csr = &pchip->tlbiv.csr; > 187 > 188 /* For TBIA, it doesn't matter what value we write. For TBI, > 189 it's the shifted tag bits. */ > 190 value = (start & 0xffff0000) >> 12; > 191 > 192 *csr = value; > 193 mb(); > 194 *csr; > > Debugging fixes: > * Require a <RETURN> after a failure call to stop before termination. > This lets the xterm stay alive so I can see what the last message was :) > > Brian > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > > |
|
From: Camiel V. <iam...@gm...> - 2008-02-26 15:57:34
|
Hello Everyone, David Hittner has re-written most of the network-interface-code. He's implemented a bunch of things that were missing, and that were needed to make DECnet happy. Among these are a buffer to hold incoming packets so we don't lose them, and true internal loopback processing. The sources are in CVS now. Camiel. |
|
From: Brian W. <bdw...@in...> - 2008-02-26 14:36:18
|
fixes for the DMA device: * output wrapped in DEBUG_DMA ifdefs. * no-op implementation of the different registers System fixes: * ignore reads of 0x480 & 0x4c0 (TLBIV, TLBIA). It looks like linux (and others) do a read immediately after a write. Probably to keep the pchip's addresses in the TLB? In Linux's arch/alpha/kernel/core_tsunami.c: 184 csr = &pchip->tlbia.csr; 185 if (((start ^ end) & 0xffff0000) == 0) 186 csr = &pchip->tlbiv.csr; 187 188 /* For TBIA, it doesn't matter what value we write. For TBI, 189 it's the shifted tag bits. */ 190 value = (start & 0xffff0000) >> 12; 191 192 *csr = value; 193 mb(); 194 *csr; Debugging fixes: * Require a <RETURN> after a failure call to stop before termination. This lets the xterm stay alive so I can see what the last message was :) Brian |
|
From: Camiel V. <iam...@gm...> - 2008-02-26 13:31:06
|
You're right. I added the comment, but not the file itself... On Tue, Feb 26, 2008 at 2:28 PM, Brian Wheeler <bdw...@in...> wrote: > DMA.o needs to be added to makefile. > > > Index: Makefile > =================================================================== > RCS file: /cvsroot/es40/es40/src/Makefile,v > retrieving revision 1.28 > diff -u -r1.28 Makefile > --- Makefile 26 Feb 2008 12:17:47 -0000 1.28 > +++ Makefile 26 Feb 2008 13:27:36 -0000 > @@ -213,6 +213,7 @@ > DiskDevice.o \ > DiskFile.o \ > DiskRam.o \ > + DMA.o \ > DPR.o \ > es40_debug.o \ > Flash.o \ > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Brian W. <bdw...@in...> - 2008-02-26 13:28:39
|
DMA.o needs to be added to makefile.
Index: Makefile
===================================================================
RCS file: /cvsroot/es40/es40/src/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- Makefile 26 Feb 2008 12:17:47 -0000 1.28
+++ Makefile 26 Feb 2008 13:27:36 -0000
@@ -213,6 +213,7 @@
DiskDevice.o \
DiskFile.o \
DiskRam.o \
+ DMA.o \
DPR.o \
es40_debug.o \
Flash.o \
|
|
From: Camiel V. <iam...@gm...> - 2008-02-26 12:18:17
|
This has been committed to the repository.
Camiel.
On Thu, Feb 21, 2008 at 2:55 PM, Brian Wheeler <bdw...@in...> wrote:
> This patch make a few changes to the backtrace functionality:
>
> * adds the -rdynamic LD flag if DEBUG_BACKTRACE is specified. This
> allows all non-static function names to appear in the backtrace.
>
> * catch SIGUSR1 to trigger the backtracer if es40 seems to have hung.
>
> * use _exit() to really really quit when a SIGSEGV is caught.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvsroot/es40/es40/src/Makefile,v
> retrieving revision 1.26
> diff -u -w -r1.26 Makefile
> --- Makefile 20 Feb 2008 21:02:50 -0000 1.26
> +++ Makefile 21 Feb 2008 13:47:38 -0000
> @@ -135,6 +135,7 @@
> # -DDEBUG_PIC Turn on Programmable Interrupt Controller debugging
> # -DDEBUG_LPT Turn on debugging for LPT Port
> # -DDEBUG_BACKTRACE Turn on backtrace dump on SIGSEGV
> +# -DDEBUG_USB Turn on debugging for USB controller
> #
> CDEBUGFLAGS = -g -DHIDE_COUNTER -DDEBUG_BACKTRACE
>
> @@ -172,6 +173,11 @@
> LDOPTIONFLAGS += -g
> endif
>
> +ifneq ($(findstring "-DDEBUG_BACKTRACE",$(CDEBUGFLAGS)),"")
> +LDOPTIONFLAGS += -rdynamic
> +endif
> +
> +
> CFLAGS = -I. -I.. \
> $(CDEBUGFLAGS) $(CTUNINGFLAGS) $(OPTIONS) $(COPTIONFLAGS)
> LDFLAGS = $(LDOPTIONFLAGS)
> @@ -265,4 +271,3 @@
> $(DEPEND) -o.do -a -- $(IDB_CFLAGS) -- $(SRCS)
> clean:
> rm -f es40 es40_idb es40_lss es40_lsm *.o *.do *.mao *.slo *.trc gui/*.o gui/*.mao gui/*.slo gui/*.do
> -
> Index: AlphaSim.cpp
> ===================================================================
> RCS file: /cvsroot/es40/es40/src/AlphaSim.cpp,v
> retrieving revision 1.40
> diff -u -w -r1.40 AlphaSim.cpp
> --- AlphaSim.cpp 7 Feb 2008 20:33:26 -0000 1.40
> +++ AlphaSim.cpp 21 Feb 2008 13:47:38 -0000
> @@ -211,7 +211,7 @@
> printf("%3d %s\n",nptrs-i, strings[i]);
> }
> free(strings);
> - exit(1);
> + if(signum==SIGSEGV) _exit(1);
> }
>
> #else
> @@ -255,6 +255,7 @@
>
> #ifdef HAS_BACKTRACE
> signal(SIGSEGV, &segv_handler);
> + signal(SIGUSR1, &segv_handler);
> #endif
>
> try
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Es40-developers mailing list
> Es4...@li...
> https://lists.sourceforge.net/lists/listinfo/es40-developers
>
|
|
From: Camiel V. <iam...@gm...> - 2008-02-26 12:00:53
|
Hi Brian, The private devid_string shouldn't be there at all. I've removed it and updated CVS. Camiel. On Thu, Feb 21, 2008 at 3:52 PM, Brian Wheeler <bdw...@in...> wrote: > I'm getting a segfault when the free(devid_string) is being run. I > added a line to print out the value of devid_string prior to the free() > and here's what I get: > > pci0.2(cirrus): $Id: Cirrus.cpp,v 1.13 2008/02/20 22:29:25 iamcamiel Exp $ > pci0.3(sym53c810): $Id: Sym53C810.cpp,v 1.5 2008/02/18 13:44:48 iamcamiel Exp $ > Devid string: 0xba0 > %SYS-F-SEGFAULT: The Alpha Simulator has Segfaulted. > -SYS-F-SEGFAULT: Backtrace follows. > backtrace() returned 12 addresses. > 12 ./es40(_Z12segv_handleri+0x1c) [0x431abc] > 11 /lib64/libc.so.6 [0x3651230f30] > 10 /lib64/libc.so.6(cfree+0x3b) [0x3651275edb] > 9 ./es40(_ZN5CDiskC2EP13CConfiguratorP7CSystemP15CDiskControllerii+0xb1) [0x43cc81] > 8 ./es40(_ZN9CDiskFileC1EP13CConfiguratorP7CSystemP15CDiskControllerii+0x19) [0x43f779] > 7 ./es40(_ZN13CConfigurator10initializeEv+0x535) [0x438515] > 6 ./es40(_ZN13CConfigurator10initializeEv+0x1ca) [0x4381aa] > 5 ./es40(_ZN13CConfigurator10initializeEv+0x1ca) [0x4381aa] > 4 ./es40(_ZN13CConfiguratorC1EPS_PcS1_S1_m+0x41b) [0x438c5b] > 3 ./es40(main+0x1a4) [0x431944] > 2 /lib64/libc.so.6(__libc_start_main+0xf4) [0x365121e074] > 1 ./es40(__gxx_personality_v0+0x119) [0x410af9] > > Is it some weird clash between Disk.h's protected devid_string and > SystemComponent's public devid_string? commenting out the free() causes > everything to work ok. > > It looks like it was added in version 1.9 which was jan 9th. Since it > has been working, I suspect that the compiler just glossed over the > problem until something recently was changed (or an optimization change) > > Brian > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Es40-developers mailing list > Es4...@li... > https://lists.sourceforge.net/lists/listinfo/es40-developers > |
|
From: Camiel V. <iam...@gm...> - 2008-02-26 11:57:26
|
Hi Brian,
I fixed the double-quote ("") issue with the new config-file syntax
checker, and committed it to CVS.
Camiel.
On Tue, Feb 26, 2008 at 12:36 PM, Camiel Vanderhoeven
<iam...@gm...> wrote:
> Hi Brian,
>
> The new parser has a problem with my config file, the following string:
> action = """c:\Program Files\PuTTY\putty.exe"" telnet://localhost:21264";
> Gives an error message saying the first ':' (in "c:") is an invalid character.
>
> Camiel.
>
>
>
>
> On Sat, Feb 23, 2008 at 9:31 PM, brian wheeler <bdw...@in...> wrote:
> > This is basically the Configurator.cpp that I sent the other day, except
> > in patch form.
> >
> > Here's how it works:
> > On the first pass (parent==0) the file is stripped down to the
> > essentials and the c-comments, strings, and braces are checked to verify
> > they are closed correctly.
> >
> > My configuration file is turned into this string:
> >
> > gui=sdl{keyboard.use_mapping=false;keyboard.map="keys.map";}
> > sys0=tsunami{rom.srm="../rom/cl67srmrom.exe";rom.decompressed="../rom/decompressed.rom";
> > rom.flash="../rom/flash.rom";rom.dpr="../rom/dpr.rom";memory.bits=30;
> > cpu0=ev68cb{icache=false;}pci0.7=ali{mouse.enabled=true;lpt.outfile="lpt.out";
> > vga_console=true;}pci0.15=ali_ide{disk0.0=file{file="../img/scratch.dsk";
> > read_only=false;cdrom=false;}disk1.0=file{file="../img/alphacd-3.1.1.iso";
> > read_only=true;cdrom=true;}}pci0.19=ali_usb{}pci0.2=cirrus{
> > rom="../rom/vgabios-0.6a.debug.bin";}pci0.3=sym53c810{}serial0=serial{port=21264;
> > action="xterm -e telnet localhost 21264";}}
> >
> > When all of the whitespace and comments are removed, the configuration
> > parser becomes much simpler: state transitions are direct (instead of
> > having to go through a 'done' phase, and no syntax checking is required
> > since the first pass already took care of it.
> >
> > Brian
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Es40-developers mailing list
> > Es4...@li...
> > https://lists.sourceforge.net/lists/listinfo/es40-developers
> >
> >
>
|
1 message has been excluded from this view by a project administrator.
