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

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)

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

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

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

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

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

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

[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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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]

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]

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

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

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

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

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

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

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

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

[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

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

[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 --]