Re: [9fans] /sys/include/ip.h 5c(1)

Re: [9fans] /sys/include/ip.h 5c(1)

[erik quanstrom]

> lucio@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) LONG POST

[W B Hacker]

erik quanstrom wrote:
>> lucio@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)

[lucio]

> 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

[W B Hacker]

lucio@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 mainframes.

NEC and Hitachi/Fujitsu (same parent Keidanren) are about the only competition
IBM have now for volume production 'Big iron'.

>  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.
>

'Pee Cee' centric thinking. IBM was 'dumb like a Fox' ...again.

The PC did what it was strategically intended to do - left IBM as last-man
standing in the US and European mainframe and midframe business, and able to buy
PC and server parts cheaper than make them.

IBM will not go there again in the same way.

This go, they are using Linux to suck Sun (accomplished) and HP (in work) into a
black hole and cause Redmond to spend a ton of cash. All the while, service &
support is ever more important.  IBM has more of that than all others combined.

If/as/when it makes business sense to do so, IBM will exit the computer biz
entirely in favor of food production, electric cars, space travel - Hell *time*
travel - or whatever else they see a solid one-hundred-year profit run in.

You don't have to love 'em. Few do.

Just never ignore the resources they command.

Bill

Re: [9fans] /sys/include/ip.h 5c(1) - LONG POST

[Ethan Grammatikidis]

On Sat, 10 Oct 2009 04:15:59 +0800
W B Hacker <wbh@conducive.org> 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) - LONG POST

[W B Hacker]

Ethan Grammatikidis wrote:
> On Sat, 10 Oct 2009 04:15:59 +0800
> W B Hacker <wbh@conducive.org> 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)

[Ethan Grammatikidis]

On Wed, 7 Oct 2009 08:24:47 +0200
Rodriguez Faszanatas <rodrifaz@gmail.com> 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)

[W B Hacker]

lucio@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)

[lucio]

>>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)

[Steve Simon]

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)

[erik quanstrom]

On Thu Oct  8 16:43:50 EDT 2009, forsyth@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)

[C H Forsyth]

>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)

[erik quanstrom]

> 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)

[ron minnich]

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)

[Richard Miller]

>> 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)

[Skip Tavakkolian]

> 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/810000/802436/p67-roskos.pdf?key1=802436&key2=6946894521&coll=GUIDE&dl=GUIDE&CFID=55468637&CFTOKEN=38162083

Re: [9fans] /sys/include/ip.h 5c(1)

[Aharon Robbins]

In article <13426df10910061432y17cf8632ta09af4ffe215375b@mail.gmail.com> you write:
>On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins <arnold@skeeve.com> 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 354		Home 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)

[Richard Miller]

> 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)

[Rodriguez Faszanatas]

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

> 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.

[-- Attachment #2: Type: text/html, Size: 259 bytes --]

Re: [9fans] /sys/include/ip.h 5c(1)

[W B Hacker]

ron minnich wrote:
> On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt <davide+p9@cs.cmu.edu> 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)

[ron minnich]

On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt <davide+p9@cs.cmu.edu> 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)

[Dave Eckhardt]

> 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)

[erik quanstrom]

> >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)

[C H Forsyth]

>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)

[ron minnich]

On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins <arnold@skeeve.com> 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)

[Aharon Robbins]

In article <13426df10910061021g3b033abbia134769baee934d3@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 354		Home 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)

[Wes Kussmaul]

ron minnich wrote:
> On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX
> <lyndon@orthanc.ca> 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)

[ron minnich]

On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX
<lyndon@orthanc.ca> 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)

[Lyndon Nerenberg - VE6BBM/VE7TFX]

> 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)

[W B Hacker]

ron minnich wrote:
> On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker <wbh@conducive.org> 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)

[erik quanstrom]

> 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)

[ron minnich]

On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker <wbh@conducive.org> 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)

[ron minnich]

On Tue, Oct 6, 2009 at 11:06 AM, erik quanstrom <quanstro@quanstro.net> 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)

[W B Hacker]

ron minnich wrote:
> On Tue, Oct 6, 2009 at 9:55 AM,  <geoff@plan9.bell-labs.com> 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)

[erik quanstrom]

> 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)

[ron minnich]

On Tue, Oct 6, 2009 at 9:55 AM,  <geoff@plan9.bell-labs.com> 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)

[Steve Simon]

> the marvell sheevaplug
> works well

does that imply that there is a working port?

-Steve

Re: [9fans] /sys/include/ip.h 5c(1)

[geoff]

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)

[erik quanstrom]

On Tue Oct  6 12:18:40 EDT 2009, geoff@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)

[geoff]

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)

[Rodriguez Faszanatas]

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

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 <quanstro@quanstro.net>wrote:

> On Mon Oct  5 09:46:01 EDT 2009, rodrifaz@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
>
>

[-- Attachment #2: Type: text/html, Size: 910 bytes --]

Re: [9fans] /sys/include/ip.h 5c(1)

[erik quanstrom]

On Mon Oct  5 09:46:01 EDT 2009, rodrifaz@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)

[Rodriguez Faszanatas]

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

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 <quanstro@quanstro.net>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
>
>

[-- Attachment #2: Type: text/html, Size: 883 bytes --]

Re: [9fans] /sys/include/ip.h 5c(1)

[erik quanstrom]

> 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)

[Rodriguez Faszanatas]

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

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

[-- Attachment #2: Type: text/html, Size: 282 bytes --]