Re: [9fans] /sys/include/ip.h 5c(1) - LONG POST
Ethan Grammatikidis wrote: On Sat, 10 Oct 2009 04:15:59 +0800 W B Hacker wrote: The only 'glue' needed was level-shifters - discrete transistors on my OSI Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up until the 16XXX derivative of the 8250 was sucked into a 'bridge' chipset. I remember being quite surprised by the first UARTs which had level shifters on the chip, and they came out around 1993 or so didn't they? As far as I know it was hardly possible to handle RS-232's 25V signals on the same die as logic functions back in the 80s. It wasn't 'hard' - especially since the 25V, though more common then than now - was more likely to be between 7 to 15 volt, and 5V would usually get the job done... But it just wasn't smart. The separate circuitry - or even its PC board traces - all too often had to act as a fuse - protecting the more expensive part of the kit with a cheap and easy to replace module. PCDOS was lousy at I/O, and Windows no better. Linux either. Makes me sad. ;-J Don't be too harsh. All Linux lacks is a decent kernel. ;-) Bill
Re: [9fans] /sys/include/ip.h 5c(1) - LONG POST
On Sat, 10 Oct 2009 04:15:59 +0800 W B Hacker wrote: > > The only 'glue' needed was level-shifters - discrete transistors on my OSI > Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up > until > the 16XXX derivative of the 8250 was sucked into a 'bridge' chipset. > I remember being quite surprised by the first UARTs which had level shifters on the chip, and they came out around 1993 or so didn't they? As far as I know it was hardly possible to handle RS-232's 25V signals on the same die as logic functions back in the 80s. > PCDOS was lousy at I/O, and Windows no better. Linux either. Makes me sad. ;-J -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] /sys/include/ip.h 5c(1)
On Wed, 7 Oct 2009 08:24:47 +0200 Rodriguez Faszanatas wrote: > > If you aren't trying to build a terminal, the marvell sheevaplug > > works well > > That is the point. My employer is interestet in a "non-intel" terminal. > And yeap you're right, the beagle isn't that nice. > I'm almost sure Gumstix have a display module too... Aha! I am not wrong: http://www.gumstix.com/store/catalog/product_info.php?products_id=195 No idea if Plan 9 runs on any Gumstix, the brand seems neglected in favour of the BeagleBoard outside the OpenEmbedded crowd. No idea why. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] /sys/include/ip.h 5c(1) - LONG POST
lu...@proxima.alt.za wrote: wikipedia agrees with lucio on this point http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues The majority within IBM never wanted into that part of the market in the first place, as it was seen as cannibalizing not only 3XXX terminal sales, but the entire, highly profitable, big-iron+interface+network+services infrastructure behind said terminals. do you have a reference for this? There's truth on both sides, IBM had committed to the PC because Apple was stealing the show, No - they neither knew nor cared about that. Thinking here is being boxed by a 'personal computer' worldview. Big bucks NOW - small change THEN. Vanishing margins now. Let's talk about IBM's middle initial - where the money was. 'Business' They 'committed' to the PC because it was 3270-capable, yet was far more flexible than a 3270 AND could go head-to-head with everything from an ADM-3A, SOROQ IQ-120, TVI-9xx, Wyse 1XX thru 3XX (color) DEC VT-52 up (including color) HP terminals, Sun workstation (low-end), Xerox, Wang, Data General, [GE, Honeywell, Bull] (eventually merged), CDC, ICL/Fujitsu/Siemens, Nixdorf, Burroughs, Univac --> Unisys, etc.. any or all of whom were lining up to eat at least a slice of what IBM saw as 'their' lunch, low, middle, or high end. DEC alone DID eat a very large chunk of it at their peak, and HP MPE-3000 still won't die. Having a configurable box that could be a dumb OR smart terminal OR go head-to-head with a Xerox, Wang, or baby DEC - moreover a box with an IBM logo - made selling the mainframe and midframe and support much easier, simplified inventory, and started to erode the low-end of all the OTHER competitors. Poisoning THE OTHER GUY's well more than IBM's well, if you will. Apple, CP/M, AT&T Bellmac and the entire Unix movement - were not even a blip on the radar *commercially*. The 'enemy' was DEC .. and to a lesser extent, HP, SUN, Unisys, and even Wang's quite competent office networks. > but within IBM there were definitely movements keeping the PC at bay. My understanding was that the 8250, crappy UART that it was, was used specifically because SDLC required synchronous RS-232 and the 8250 didn't have it. The INS8250 most certainly DID have it. All you had to do was connect the lines. I've run them on the George Morrow Designs 'Empire' S-100 board at 112KBps synchronous and 56 KBps async for hours on end. The only 'glue' needed was level-shifters - discrete transistors on my OSI Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up until the 16XXX derivative of the 8250 was sucked into a 'bridge' chipset. The 'can't do more than 9.6' issue was purely an OS problem on the PC. The same 240-odd byte Forth routine that ran the chipsets on the Morrow S-100 boar ported with no more than a base-address change to the IBM PC. Under LMI Forth, the PCDOS and its brain-dead interrupt handling used to boot into LMI Forth were pushed aside, and the 'can't do' IBM PC MB also ran well at baud rates not to be seen again until OS/2 on 386 with 16550. Note that the 8251 was compatible with the 8088 (both Intel designs, if I'm not mistaken), where the 8250 came from National Semiconductors and required additional glue logic (and had write-only registers and no RESET, shudder!). Not accurate. The problem is that there were TWO chips with the '8250' name, and they were not alike. The INS8250 adopted by IBM had only ONE byte of buffering - but it was enough if you were a machine-code, ASM, or Forth programmer. PCDOS was lousy at I/O, and Windows no better. In telco logging gear, OS/2, by comparison, could drive dozens of the same chipset serial ports at the same time - every one of them at speeds Windows wouldn't be able to match on ONE port for a decade or more. BTW - The 'Empire' also used a pair of the Intel 8259 PIC, but correctly cascaded: 8 X 8 = 64 less the cascade line = 63 hardware interrupt lines. IBM Boca not only FUBARRED by tying the NMI line to a (generally non-existent) memory parity checker, insuring there was NFW to analyze or recover from such an error, they ran the 8259 PIC on the AT in add-on instead of cascade: 8 + 8 = 16, less the cascade line (2/9) = 15 usable interrupts. Dumb. Fact is, IBM had distinct, sometimes contrasting marketing objectives. I suspect that fighting the Taiwanese menace was as high on the agenda as anything could possibly get. IBM's turnover exceeds that of many entire nations. MS edges them as a 'software company' - but software is nearly 100% of MS biz, and only 20% of IBM's. IBM's global headcount exceeds that of many US cities, and even a few entire state populations. That is going to insure a good deal of 'sometimes contrasting' contradiction. It wasn't Taiwan back then, but the *Japanese* who were seen as a threat to IBM revenue - especially after ex-IBM'er Gene Amdahl got Hitachi to make plug-compatible m
Re: [9fans] /sys/include/ip.h 5c(1)
> wikipedia agrees with lucio on this point > http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues > >> The majority within IBM never wanted into that part of the market in the >> first >> place, as it was seen as cannibalizing not only 3XXX terminal sales, but the >> entire, highly profitable, big-iron+interface+network+services >> infrastructure >> behind said terminals. > > do you have a reference for this? There's truth on both sides, IBM had committed to the PC because Apple was stealing the show, but within IBM there were definitely movements keeping the PC at bay. My understanding was that the 8250, crappy UART that it was, was used specifically because SDLC required synchronous RS-232 and the 8250 didn't have it. Note that the 8251 was compatible with the 8088 (both Intel designs, if I'm not mistaken), where the 8250 came from National Semiconductors and required additional glue logic (and had write-only registers and no RESET, shudder!). Fact is, IBM had distinct, sometimes contrasting marketing objectives. I suspect that fighting the Taiwanese menace was as high on the agenda as anything could possibly get. In "Big Blues" (I think that is the book title) it is suggested that IBM did not have a proper focus and the PC was a knee-jerk reaction that should have been planned considerably better. ++L
Re: [9fans] /sys/include/ip.h 5c(1) LONG POST
erik quanstrom wrote: lu...@proxima.alt.za wrote: but by 1990 with microchannel &c. things were much more closed off. i thought only one company ever really made microchannel, and even they weren't terribly in earnest in the end, except on non-PC things like RS6000. IBM tried to recover control over the PC market by introducing MCA, bargaining that public sentiment would swing in their favour. They might have had that in mind as a secondary reason - but I doubt even that. wikipedia agrees with lucio on this point http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues 'Wikipedia' does not always compute. That article ass u me s that the MCA was needed ONLY for PC's. Wrong answer as far as IBM goes. The majority within IBM never wanted into that part of the market in the first place, as it was seen as cannibalizing not only 3XXX terminal sales, but the entire, highly profitable, big-iron+interface+network+services infrastructure behind said terminals. do you have a reference for this? Probably an hpfs-386 disk or three full - but half a century on [1] from my first IBM 701 run, and with Irish Alzheimer's and senile dementia don't expect me to *find* them. i worked at a company around 1990 that was heavily into ibm mainframes. (so much so, that they sold PROFS to ibm.) we all had 3270 terminals, and if you were lucky, you had a pc. email, calandaring, all that great stuff was done centrally 1500 miles away on ibm mainframes. the pc could do none of the criticial functions that the mainframe system could perform. we didn't have networking for the pc. heck, there was only one machine fat enough to run windows 3.1, which didn't even do networking. You waz bein' robbed. The secret to high 'PC" peformance as at 1990-94? Fast private network for the WAN. No 'Weendows' 100 MBps TCNS for the LAN. No 'Weendows' Hercules monochrome graphics and DRDOS, else ATI SVGA and OS/2 2.11. No 'Weendows' Did I forget anything? Oh .. ** NO effing 'Weendows' ** No way. No how. No where. so even 3 years after the release of microchannel, we would never have considered pcs as 3270 replacements. i don't remember any machines that could have even run 3270 emulators, if they existed. A year-one IBM 'PC-1' 8-bit ISA could run 3270 emu just fine - part of what it needed was in the BIOS, and the onboard 64K RAM was enough for block-mode buffers. Just needed a NIC appropriate to the local concentrator, optionally a keyboard swap. Ditto OS/2. 3270 emulation only got 'difficult' if you wanted to run it on *Windows*. perhaps we were the wiredest ibm site ever, but i think not. and judging from what i saw, the mca guys would have wasted time thinking about 3270 emulators. They didn't have to. MCA-bus machines could emulate the central 370 itself - and anything earlier - that those terminals once connected to. 308X and newer mainframes were another matter. ah, the summer of broken arrows. good times. - erik Yah - well... I can't edit plaintext files remotely any faster today (Joe, Pico, Nano, Mined) over cable modem ssh internet than I could (BRIEF) over dedicated 56 Kbps fifteen years ago, so 'progress' has been eaten by TCP/IP overhead, Ethernet overhead (world's second worst protocol), congestion, throttling, packet-loss ..and GUI's. Died in the wool Plan 9 guys are no doubt ROFL by now at that last part... ;-) Bill [1] In order of first use, IBM 701, WECO M33, Burroughs AN/GSA-51, IBM/MIT Whirlwind II, (AKA MITRE AN/FSQ-7)
Re: [9fans] /sys/include/ip.h 5c(1)
> lu...@proxima.alt.za wrote: > >>> but by 1990 with microchannel &c. things were much more closed off. > >> i thought only one company ever really made microchannel, > >> and even they weren't terribly in earnest in the end, > >> except on non-PC things like RS6000. > > > > IBM tried to recover control over the PC market by introducing MCA, > > bargaining that public sentiment would swing in their favour. > > They might have had that in mind as a secondary reason - but I doubt even > that. > wikipedia agrees with lucio on this point http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues > The majority within IBM never wanted into that part of the market in the > first > place, as it was seen as cannibalizing not only 3XXX terminal sales, but the > entire, highly profitable, big-iron+interface+network+services infrastructure > behind said terminals. do you have a reference for this? i worked at a company around 1990 that was heavily into ibm mainframes. (so much so, that they sold PROFS to ibm.) we all had 3270 terminals, and if you were lucky, you had a pc. email, calandaring, all that great stuff was done centrally 1500 miles away on ibm mainframes. the pc could do none of the criticial functions that the mainframe system could perform. we didn't have networking for the pc. heck, there was only one machine fat enough to run windows 3.1, which didn't even do networking. so even 3 years after the release of microchannel, we would never have considered pcs as 3270 replacements. i don't remember any machines that could have even run 3270 emulators, if they existed. perhaps we were the wiredest ibm site ever, but i think not. and judging from what i saw, the mca guys would have wasted time thinking about 3270 emulators. ah, the summer of broken arrows. good times. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
lu...@proxima.alt.za wrote: but by 1990 with microchannel &c. things were much more closed off. i thought only one company ever really made microchannel, and even they weren't terribly in earnest in the end, except on non-PC things like RS6000. IBM tried to recover control over the PC market by introducing MCA, bargaining that public sentiment would swing in their favour. They might have had that in mind as a secondary reason - but I doubt even that. The majority within IBM never wanted into that part of the market in the first place, as it was seen as cannibalizing not only 3XXX terminal sales, but the entire, highly profitable, big-iron+interface+network+services infrastructure behind said terminals. A more immediate need was for something better than ISA bus to meet the needs of their mid-range servers - some of which would eventually grow - at least per the manuals - to accomodate expansion trays with slots for over fifty cards (PCI at that) - more than double the actually usable max for ISA bus signalling, moreover over a longer physical plan. They could not have been more mistaken, one could easily call this the "Betamax error". As soon as the other PC manufacturers of note (HP, Intel, Wang Labs, I forget who else) Prime movers were HP and Compaq. Earliest small-fry (in those days) to deliver to 'whomever' wanted a MB was Asus. Novell Netware servers built on EISA to take advantage of duplexed fast SCSI controllers and fiber-optic server-to-router TCNS 100 MBps (Arcnet) interconnects plus 100 MBps TCNS over-coax to the ISA-bus workstations were in their day rather serious ass-kickers - most especially with Microway add-in 'Number Smasher' CPU+FPU cards. As is often the case, the link was - and remains - the bottleneck. released EISA .. which, while far more welcome in the field, had slot-count / round-trip timing limitations that made it technically inferior to MCA, and by a largish margin, if one wanted a really high slot-count. > (which was quickly replaced by PCI), Ditto, absent a 'bridge' chipset that was for a long time largely a DEC controlled item AND NOT cheap. Go see how many 'consumer' MB you can find with more than four all-usable-at-once PCI slots. Hardly common even in 'server grade' MB. Thankfully much has moved into on-planar silicon long-since, so less need. IBM's efforts were nullified. ++L IBM is in many ways an anarchistic loose confederation of competing Divisions. At sum, they are technically agnostic enough to simply 'follow the money'. Feudal Microsoft, OTOH, want the money to follow *them*. ;-) Bill
Re: [9fans] /sys/include/ip.h 5c(1)
>>but by 1990 with microchannel &c. things were much more closed off. > > i thought only one company ever really made microchannel, > and even they weren't terribly in earnest in the end, > except on non-PC things like RS6000. IBM tried to recover control over the PC market by introducing MCA, bargaining that public sentiment would swing in their favour. They could not have been more mistaken, one could easily call this the "Betamax error". As soon as the other PC manufacturers of note (HP, Intel, Wang Labs, I forget who else) released EISA (which was quickly replaced by PCI), IBM's efforts were nullified. ++L
Re: [9fans] /sys/include/ip.h 5c(1)
I once worked for a telco who's exchanges where connected to their billing machines via a pair of IBM PS2 MCA machines, they also had one spare machine. I was there in about 1997 and everyone very worried what might happen if they lost more than one of these machines. The last I heard the large, complex, fault tolerant Unix system that they built to replace them still didn't work well enough to be relied on. -Steve
Re: [9fans] /sys/include/ip.h 5c(1)
On Thu Oct 8 16:43:50 EDT 2009, fors...@vitanuova.com wrote: > >but by 1990 with microchannel &c. things were much more closed off. > > i thought only one company ever really made microchannel, > and even they weren't terribly in earnest in the end, > except on non-PC things like RS6000. in the end, they weren't terribly earnest about pcs. :-) intel made the i82310 chipset. and most 1990 ps/2 models were mca based. http://en.wikipedia.org/wiki/Micro_Channel_architecture http://www.yourdictionary.com/computer/ibm-pc i have an microchannel xga card around here somewhere. it's probablly got a pound of gold in it. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
>but by 1990 with microchannel &c. things were much more closed off. i thought only one company ever really made microchannel, and even they weren't terribly in earnest in the end, except on non-PC things like RS6000.
Re: [9fans] /sys/include/ip.h 5c(1)
> Thinking about it a bit more ... when systems become more and more > closed, as x86 systems are becoming now, the field of innovation is > reduced to what a single company can think of -- the monopoly > provider, so to speak. you're right "nobody wants to do that" is not a good argument. but on the other hand, it's not clear to me that the slippery slope "more and more closed" holds. it could also be that things go in cycles. when i started in pcs (1983), everything was wide open. but by 1990 with microchannel &c. things were much more closed off. new things tend to be closed off for various reasons. sometimes i think companies are embarassed to document first attempts. the problem with arm and whatnot is that there is no standard platform. so drivers in the embedded world tend to have a much shorter lifetime than pcs, since platforms churn so quickly. and the differences tend to be deeper. so the left hand taketh what the right hand giveth. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
Thinking about it a bit more ... when systems become more and more closed, as x86 systems are becoming now, the field of innovation is reduced to what a single company can think of -- the monopoly provider, so to speak. When systems become more closed, you hear stuff like this: "The percentage of people who want to do this, compared to the number of people who just want to buy a finished computer, is way down in the noise. It's a marketing / sales / ROI issue." I can not possibly recall how many times I've heard that over the years. Many of the companies that pushed this line the hardest are dead now. One of the first times I heard it was DEC marketing guys talking about Unix. They didn't like the fact that Unix discovered a bug in the 11/70 that the DEC operating systems did not. They also made it clear it was not going to get fixed: "you guys are not a big market -- nobody else has this problem". Systems that are open, as the embedded ARM-based systems are now, have a far wider field of innovation. Nobody is making a PentiumStix or a PentiumPlug. Nobody is doing an x86-based Oswald. You can't. You can't learn what you need to know. Although, mind you, the OLPC is x86-based. But, it actually proves the point: the open source BIOS code development was supported by the vendors: first, AMD, and second, VIA. I understand vendor resistance to non-vendor research and innovation. It's not a big market, never has been. But, in the end, it can come back and burn the vendors. ron
Re: [9fans] /sys/include/ip.h 5c(1)
>> microcode for the Perkin-Elmer 3220 was fun and useful as well. > > that's interesting. i found this paper and am studying it. are there > obvious advantages? I think there were quite a few independent projects at different places adding special-purpose instructions to accelerate particular algorithms. Improving on the original P-E (Interdata?) microcode wasn't hard. For example the base instruction set had instructions for inserting/deleting elements in a doubly-linked list, which were actually slower to execute than just doing the equivalent sequence of loads & stores.
Re: [9fans] /sys/include/ip.h 5c(1)
> but writing > microcode for the Perkin-Elmer 3220 was fun and useful as well. that's interesting. i found this paper and am studying it. are there obvious advantages? http://delivery.acm.org/10.1145/81/802436/p67-roskos.pdf?key1=802436&key2=6946894521&coll=GUIDE&dl=GUIDE&CFID=55468637&CFTOKEN=38162083
Re: [9fans] /sys/include/ip.h 5c(1)
In article <13426df10910061432y17cf8632ta09af4ffe2153...@mail.gmail.com> you write: >On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins wrote: >> I understand all your points, and many of them are good ones. But there >> really are places where you don't want to go, and into the chipset >> is one of them. > >Not really the case. People do want to go there, so they can do >interesting things like put an FPGA into a CPU socket. The percentage of people who want to do this, compared to the number of people who just want to buy a finished computer, is way down in the noise. It's a marketing / sales / ROI issue. And again, at least for the client side chipsets, you REALLY don't want to go there. Writing firmware for them is a big job. >Non-x86 vendors in the embedded space don't say things like " there >really are places where you don't want to go" in my experience. The chipsets we're talking about are not for the embedded space. At least the ones I'm familiar with. Intel is targeting the embedded space with SOC (System On Chip) solutions. Good, bad, indifferent, I have no clue. >Just >look at the fact that so many ARM-based boards use U-boot -- GPL'ed >firmware. That's why so much of the really cool stuff at various >conferences nowadays usually involves non-x86 embedded systems -- you >can do interesting things there you can't do in the x86 world any more >-- things you used to see done on x86es now get done on other systems. Intel (for better or worse, I'm not making a value judgement) makes marketing calls; where will they sell the most chips and chipsets? Embedded is certainly a market they want to move into (c.f. the recent purchase of Wind River), but it's not the main market now. Much of the embedded world is moving to Linux and/or some version of Windows (MIDs, smart phones, c.f. Moblin). For them, what Intel provides is fine. The circles you move in are different, and definitely more interesting, but also much smaller that most of what the rest of the world is doing. Again, NOT a value judgement about your work or about how Intel works, just my take on things. Thanks, Arnold -- Aharon (Arnold) Robbins arnold AT skeeve DOT com P.O. Box 354Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 50 729-7545 D.N. Shimshon 99785 ISRAEL
Re: [9fans] /sys/include/ip.h 5c(1)
> Just like you wouldn't have wanted to redo the microcode > in your Vax 11/750, even if you could have. Speak for yourself. I don't know about the VAX, but writing microcode for the Perkin-Elmer 3220 was fun and useful as well. It was nicely integerated into Unix, so different processes could have their own bits of microcode swapped into the control store when they were dispatched. Real Programmers weren't afraid of going down to the bare metal in those days.
Re: [9fans] /sys/include/ip.h 5c(1)
> If you aren't trying to build a terminal, the marvell sheevaplug > works well That is the point. My employer is interestet in a "non-intel" terminal. And yeap you're right, the beagle isn't that nice.
Re: [9fans] /sys/include/ip.h 5c(1)
ron minnich wrote: On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt wrote: For something "nobody would want to do", there sure are a lot of hits for "pcs750.bin". It's the difference between "nobody would want to do it" and "we don't want you do it" ;-) ron To me, the 'meat' of the issue is not open vs closed - but rather the evolutionary point wherein it is no longer about preserving a superior concept, but the coming of a sort of circling of the wagons mentality because resistance to change or innovation, preservation of 'backward compatibility', 'our way', 'standards' and 'incremental improvements' are all valued more highly than taking risks of major change to adapt to a benefit centric world that doesn't really care about the history or prestige of any given company or 'way'. They just want 'stuff that works better' - and more cheaply, to boot. As early as the 1960's, the term 'intellectual incest' was being applied, and IMNSHO it seems to fit many F/OSS projects as easily as closed, commercial ones. Bill Hacker
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt wrote: > For something "nobody would want to do", there sure are a > lot of hits for "pcs750.bin". It's the difference between "nobody would want to do it" and "we don't want you do it" ;-) ron
Re: [9fans] /sys/include/ip.h 5c(1)
> i thought several universities did modify the microcode in > various ways, to test some research ideas, or just to improve > things. As I understand it, on the 750 floating-point errors were accidentally traps instead of faults, or the other way around. DEC said "oops, well, we guess it's model-dependent whether floating-point errors are traps or faults". The BSD guys patched the microcode. For something "nobody would want to do", there sure are a lot of hits for "pcs750.bin". Dave Eckhardt
Re: [9fans] /sys/include/ip.h 5c(1)
> >Just like you wouldn't have wanted to redo the microcode > >in your Vax 11/750, even if you could have. > > i thought several universities did modify the microcode in various ways, > to test some research ideas, or just to improve things. like this one http://portal.acm.org/citation.cfm?id=1007771.55619 i had thought the purdue dual-processor vax had microcode changes, but indeed it did not. this machine for all the world looks like a modern intel i7 or amd opteron system. the issues discussed are also pretty much the same today. http://computer-refuge.org/classiccmp/dp_vax/dual-vax11-780.pdf - erik
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins wrote: > I understand all your points, and many of them are good ones. But there > really are places where you don't want to go, and into the chipset > is one of them. Not really the case. People do want to go there, so they can do interesting things like put an FPGA into a CPU socket. Non-x86 vendors in the embedded space don't say things like " there really are places where you don't want to go" in my experience. Just look at the fact that so many ARM-based boards use U-boot -- GPL'ed firmware. That's why so much of the really cool stuff at various conferences nowadays usually involves non-x86 embedded systems -- you can do interesting things there you can't do in the x86 world any more -- things you used to see done on x86es now get done on other systems. ron
Re: [9fans] /sys/include/ip.h 5c(1)
>Just like you wouldn't have wanted to redo the microcode >in your Vax 11/750, even if you could have. i thought several universities did modify the microcode in various ways, to test some research ideas, or just to improve things.
Re: [9fans] /sys/include/ip.h 5c(1)
In article <13426df10910061021g3b033abbia134769baee93...@mail.gmail.com> you write: >as bad as the ARM may be, it can't hold a candle to what the pentium has >become: >1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX >2. RISC CPU in the Ethernet part running ThreadX >3. Simple CPU in the southbridge (ICH) running, well, who knows. But >the entire system won't come up without that CPU coming up, and the >code for that CPU is (of course!) never going to be available in any >general sense. Much of this is available as "Intel AMT", part of vPro(R) technology. Start googling, you'll find information and maybe even a blog or two from yours truly. I won't say that manageability standards are wonderful; they're not. But you can do some amazing things by talking to those CPUs in the chipset, even when the main CPU is down. >All of this stuff is without any useful docs -- intentionally. You >can't write code for (1) and (2) because the code in the FLASH has to >be signed with Intel's private key, public version of which is *burned >into the chip in read-only registers*. You bet. Intel doesn't want to be on the wrong end of some lawyers when somebody puts their own code into the chipset and wipes out their company's crown jewels from the hard drive. Welcome to America, Land Of The Lawsuit. >How much do you feel like trusting this platform? Think of it as "smart hardware". Seriously. If the I/O and networking happen according to the documentation, then don't worry about how Intel makes it happen. >Daniel Liu of RIT studied (1) and (2) this summer, we're going to drop >a paper into some publication this fall we hope. I'd like to see this. >PCs used to be open. They are now quite closed. I am holding out hope >for the ARM as the next open thing. I realize the OMAP 35 manual is >long, but at least there is a manual you can get! You can always build a board with other peoples' chipsets. I understand all your points, and many of them are good ones. But there really are places where you don't want to go, and into the chipset is one of them. Just like you wouldn't have wanted to redo the microcode in your Vax 11/750, even if you could have. Arnold -- Aharon (Arnold) Robbins arnold AT skeeve DOT com P.O. Box 354Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 50 729-7545 D.N. Shimshon 99785 ISRAEL
Re: [9fans] /sys/include/ip.h 5c(1)
ron minnich wrote: On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX wrote: I don't think DEC deserves this branding. In my experience they were one of the most open hardware companies around. It was sad to watch the Alpha blow its early lead due to internal politics. Get with somebody who was in DEC at the time trying to make Alpha succeed and you'll hear some interesting tales. Long before the Alpha, DEC put something like its PAL code into its disk interfaces - only it was set to activate with a subsequent version of VAX/VMS. I forget the name of the Denver-based company that had taken significant share of the VAX storage market only to have their products blow up (figuratively) when the os was later upgraded. The company went down the tubes rapidly after that. What the idealistic Ken Olsen exerted control over was good open stuff. Things like PAL code happened behind his back. When he found out, he didn't believe in wielding the ax. Much too naive to be a CEO. Too nice, actually. Wes
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX wrote: > I don't think DEC deserves this branding. In my experience they were > one of the most open hardware companies around. Back when they were still > DEC, of course. You never dealt with Alpha maybe. The story is long and sad. One word: PALcode. DEC deliberately limited PALcode access so that 3rd party board vendors could not make boards as good as DECs. It did not seem to matter that these vendors were selling Alphas ... only that their Alpha board should not be "too good". This story is just one of many w.r.t. DEC. It was sad to watch the Alpha blow its early lead due to internal politics. Get with somebody who was in DEC at the time trying to make Alpha succeed and you'll hear some interesting tales. Does this situation have a present-day equivalent in the PC world? Yes. ron
Re: [9fans] /sys/include/ip.h 5c(1)
> Varian Data, General Automation, SDS/XDS, DEC, Data General, Honeywell, CDC, > GE I don't think DEC deserves this branding. In my experience they were one of the most open hardware companies around. Back when they were still DEC, of course. --lyndon
Re: [9fans] /sys/include/ip.h 5c(1)
ron minnich wrote: On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker wrote: Anyone know if the AMD environment is any more 'open'? way, way, more open. same with via. They regularly contribute chipset source code to coreboot. That's my measure. I hadn't paid much attention to the ARM until the recent '2 GHz' blurb, but that's a game-changer. I think the PC guys have got to start watching the rear view mirror. I've seen the transition from mainframe->mini->workstation->pc in several sectors, and one driving factor was openness. Each time a given vendor class got into this "crown jewels and core IP" mode, and started locking out the users, something come along to knock it off its perch. Varian Data, General Automation, SDS/XDS, DEC, Data General, Honeywell, CDC, GE, Singer, Friden the IT roadside is littered with those 'late holocene' deposits... > And, in each case, the newcomer was initially slower and not quite as good was what it replaced, which led to the status quo vendors to ignore it until it was too late. Excuses are eerily the same, each time, almost without regard to the product family: "nobody else wants that" "we no longer release that information" etc. etc. etc. It's amazing. ron Emphaticaly so! And the march goes on... Look at the common-sense approach of the latest Nokia PDA hardware gadget. Puts the average desktop of a decade ago in the shade in all but physical size. CPU is CPU, graphics and signal processing each get their own processors and clock rates. BFBI, but it sure unloads the CPU and makes powering-down what isn't required at the moment far easier. Too sad it didn't use an inherently leaner kernel . . . ;-) Bill
Re: [9fans] /sys/include/ip.h 5c(1)
> Excuses are eerily the same, each time, almost without regard to the > product family: > "nobody else wants that" > "we no longer release that information" > etc. etc. etc. intel has been good to me. perhaps i'm just doing different things. my experience with intel has been that if it's not available on the web (and the documentation for most southbridges, intel hd audio, intel gma video, many wireless chipsets, most intel gbe/10gbe chipsets is), one can execute an nda and get access. the guys in charge of that are great to work with. and the amount of stuff available on the web has been increasing in the last 3 years. and their documentation is miles better than average. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker wrote: > > Anyone know if the AMD environment is any more 'open'? way, way, more open. same with via. They regularly contribute chipset source code to coreboot. That's my measure. > I hadn't paid much attention to the ARM until the recent '2 GHz' blurb, but > that's a game-changer. I think the PC guys have got to start watching the rear view mirror. I've seen the transition from mainframe->mini->workstation->pc in several sectors, and one driving factor was openness. Each time a given vendor class got into this "crown jewels and core IP" mode, and started locking out the users, something come along to knock it off its perch. And, in each case, the newcomer was initially slower and not quite as good was what it replaced, which led to the status quo vendors to ignore it until it was too late. Excuses are eerily the same, each time, almost without regard to the product family: "nobody else wants that" "we no longer release that information" etc. etc. etc. It's amazing. ron
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 11:06 AM, erik quanstrom wrote: > the one that you didn't mention is the one that bothers me: smm mode. > this has been around for a very long time. smm mode takes a special > interrupt and takes over the cpu and runs some real-mode code. things > like ps/2 emulation for usb mice and keyboards rely on smm mode. > this can really blow up your timing, if you have timing constraints. don't worry, SMM mode is going to keep getting more and more heavily used. Oh, wait, that's a bad thing. oh well. ron
Re: [9fans] /sys/include/ip.h 5c(1)
ron minnich wrote: On Tue, Oct 6, 2009 at 9:55 AM, wrote: The cortex-a8 arms are arm v7-a architecture. L2 page table entries have changed format. The a8 includes trustzone, so many registers have forked, producing a "secure" and a "nonsecure" version of the register. The arm v7-a manual is a 2,150-page pdf file and the omap35x SoC manual is a 3,500-page pdf file; both documents refer you to other documents for some details. Some co-processor control registers that used to exist to clear caches and TLBs have vanished. I'm sure there's more that I've blocked. as bad as the ARM may be, it can't hold a candle to what the pentium has become: 1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX 2. RISC CPU in the Ethernet part running ThreadX 3. Simple CPU in the southbridge (ICH) running, well, who knows. But the entire system won't come up without that CPU coming up, and the code for that CPU is (of course!) never going to be available in any general sense. (1) and (2) hold conversations with each other. Doing what? You're not supposed to know. All of this stuff is without any useful docs -- intentionally. You can't write code for (1) and (2) because the code in the FLASH has to be signed with Intel's private key, public version of which is *burned into the chip in read-only registers*. How much do you feel like trusting this platform? Daniel Liu of RIT studied (1) and (2) this summer, we're going to drop a paper into some publication this fall we hope. PCs used to be open. They are now quite closed. I am holding out hope for the ARM as the next open thing. I realize the OMAP 35 manual is long, but at least there is a manual you can get! ron Anyone know if the AMD environment is any more 'open'? Worse? What about VIA (C6 and 'Nano') and their supporing ~bridge chipset(s)? ISTR OpenBSD has just upped the specific support for VIA 'glue' chipset, and they don't usually go where decent information cannot be freely had. I hadn't paid much attention to the ARM until the recent '2 GHz' blurb, but that's a game-changer. Bill
Re: [9fans] /sys/include/ip.h 5c(1)
> as bad as the ARM may be, it can't hold a candle to what the pentium has > become: > 1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX > 2. RISC CPU in the Ethernet part running ThreadX > 3. Simple CPU in the southbridge (ICH) running, well, who knows. But > the entire system won't come up without that CPU coming up, and the > code for that CPU is (of course!) never going to be available in any > general sense. the difference is that intel have hidden their µarch changes behind a fixed instruction set. this means that even the bios engineer does not care what µarch the cpu is actually running. i would think that's a feature. i have never heard of threadx in the ethernet part, though i have spent more than my fair share of hours paging through yellow books. (perhaps you're speaking of non-intel parts?) do you have some references? is there some reason you care what the ethernet part is doing to provide a normal register or preboot interface? the southbridge does run some hairy junk. both ahci and ide interfaces require special firmware. i would consider the fact that you can't introspect it to be a feature. the one that you didn't mention is the one that bothers me: smm mode. this has been around for a very long time. smm mode takes a special interrupt and takes over the cpu and runs some real-mode code. things like ps/2 emulation for usb mice and keyboards rely on smm mode. this can really blow up your timing, if you have timing constraints. > can't write code for (1) and (2) because the code in the FLASH has to > be signed with Intel's private key, public version of which is *burned > into the chip in read-only registers*. it's a fine line between hardware and software. or maybe there is no line. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue, Oct 6, 2009 at 9:55 AM, wrote: > The cortex-a8 arms are arm v7-a architecture. L2 page table > entries have changed format. The a8 includes trustzone, so > many registers have forked, producing a "secure" and a "nonsecure" > version of the register. The arm v7-a manual is a 2,150-page pdf > file and the omap35x SoC manual is a 3,500-page pdf file; both > documents refer you to other documents for some details. Some > co-processor control registers that used to exist to clear caches > and TLBs have vanished. I'm sure there's more that I've blocked. > > as bad as the ARM may be, it can't hold a candle to what the pentium has become: 1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX 2. RISC CPU in the Ethernet part running ThreadX 3. Simple CPU in the southbridge (ICH) running, well, who knows. But the entire system won't come up without that CPU coming up, and the code for that CPU is (of course!) never going to be available in any general sense. (1) and (2) hold conversations with each other. Doing what? You're not supposed to know. All of this stuff is without any useful docs -- intentionally. You can't write code for (1) and (2) because the code in the FLASH has to be signed with Intel's private key, public version of which is *burned into the chip in read-only registers*. How much do you feel like trusting this platform? Daniel Liu of RIT studied (1) and (2) this summer, we're going to drop a paper into some publication this fall we hope. PCs used to be open. They are now quite closed. I am holding out hope for the ARM as the next open thing. I realize the OMAP 35 manual is long, but at least there is a manual you can get! ron
Re: [9fans] /sys/include/ip.h 5c(1)
> the marvell sheevaplug > works well does that imply that there is a working port? -Steve
Re: [9fans] /sys/include/ip.h 5c(1)
The cortex-a8 arms are arm v7-a architecture. L2 page table entries have changed format. The a8 includes trustzone, so many registers have forked, producing a "secure" and a "nonsecure" version of the register. The arm v7-a manual is a 2,150-page pdf file and the omap35x SoC manual is a 3,500-page pdf file; both documents refer you to other documents for some details. Some co-processor control registers that used to exist to clear caches and TLBs have vanished. I'm sure there's more that I've blocked.
Re: [9fans] /sys/include/ip.h 5c(1)
On Tue Oct 6 12:18:40 EDT 2009, ge...@plan9.bell-labs.com wrote: > The beagleboard is somewhat painful. It has a cortex-a8 cpu, > which is quite a bit more complex than older arms. is there specific pain to the a8 arms, or is it just that everything is a bit less tidy? - erik
Re: [9fans] /sys/include/ip.h 5c(1)
The beagleboard is somewhat painful. It has a cortex-a8 cpu, which is quite a bit more complex than older arms. The lack of built-in ethernet means that getting USB going is vital, but the EHCI registers provoke access exceptions and the OTG registers are like no USB interface we've ever seen before. A beagleboard with built-in ethernet is available from www.igep-platform.com and looks like a better bet (assuming that they include programming documentation for their ethernet controller). If you aren't trying to build a terminal, the marvell sheevaplug works well: $100 in quantity one, 1.2GHz ARM926EJ-S, 512MB of ram, some flash, built-in gigabit ethernet, (OTG) USB with a superset of the EHCI registers (so not completely hopeless).
Re: [9fans] /sys/include/ip.h 5c(1)
yeap, done. is there someone actively working on a port to the beagleboard? just to eliminate duplicate work. i found ron's ts7200 which is a nice starting point. On Mon, Oct 5, 2009 at 3:50 PM, erik quanstrom wrote: > On Mon Oct 5 09:46:01 EDT 2009, rodri...@gmail.com wrote: > > > thanks erik, > > i had to update the 5* sources by hand. pull thought they are up to date. > > > > rod > > you may also wish to apply the patch i posted to make the > comma operator work. > > - erik > >
Re: [9fans] /sys/include/ip.h 5c(1)
On Mon Oct 5 09:46:01 EDT 2009, rodri...@gmail.com wrote: > thanks erik, > i had to update the 5* sources by hand. pull thought they are up to date. > > rod you may also wish to apply the patch i posted to make the comma operator work. - erik
Re: [9fans] /sys/include/ip.h 5c(1)
thanks erik, i had to update the 5* sources by hand. pull thought they are up to date. rod On Mon, Oct 5, 2009 at 3:16 PM, erik quanstrom wrote: > > Trying to build /sys/src/libip for the arm today, I found that mk was > dying. > > > > /sys/include/ip.h:128 eipfmt.c:3 incomplete structure element: payload > > > > Is this a known problem? > > i think you need to update your compiler source code and rebuild. > 5c builds all the libraries for me. > > - erik > >
Re: [9fans] /sys/include/ip.h 5c(1)
> Trying to build /sys/src/libip for the arm today, I found that mk was dying. > > /sys/include/ip.h:128 eipfmt.c:3 incomplete structure element: payload > > Is this a known problem? i think you need to update your compiler source code and rebuild. 5c builds all the libraries for me. - erik
[9fans] /sys/include/ip.h 5c(1)
Hi, Trying to build /sys/src/libip for the arm today, I found that mk was dying. /sys/include/ip.h:128 eipfmt.c:3 incomplete structure element: payload Is this a known problem? Rod
