[Arm-netbook] AMD considering releasing the PSP

[Julie Marchant]

Trisquel forum thread here:

https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-community

And this is the Reddit thread where it happened:

https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/def5h1b/

It would be a good idea to encourage AMD to do this. Who knows? It could
lead us to an x86 EOMA computer card of some sort in the future. ;) Not
to mention, it would just be better for us overall to have AMD on our side.

[Luke Kenneth Casson Leighton]

oo that's a great idea, good find, julie.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Julie Marchant
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-community
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/def5h1b/
It would be a good idea to encourage AMD to do this. Who knows? It could
lead us to an x86 EOMA computer card of some sort in the future. ;) Not
to mention, it would just be better for us overall to have AMD on our side.
--
Julie Marchant
https://onpon4.github.io
https://emailselfdefense.fsf.org
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phc

[Paul Boddie]

Post by Julie Marchant
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm
unity
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_
radeon_and_other/def5h1b/
It would be a good idea to encourage AMD to do this. Who knows? It could
lead us to an x86 EOMA computer card of some sort in the future. ;) Not
to mention, it would just be better for us overall to have AMD on our side.

Interesting comment:

"Unfortunately AMD is licensing Trustonic's PSP firmware. They do not have the
option to open source it."

https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/defn8l1/

Of course, this is just one aspect of AMD's technologies, but similar
obstacles probably appear along each of the paths towards freedom for all the
different things their products provide. Even with all their GPU expertise,
they are unlikely to make the technologies transparent because every patent
troll and potential competitor might try and sue them over some detail or
other. That, unfortunately, is the pact of silence all the GPU vendors adhere
to, whether or not the explanation really has much merit.

It's interesting that this happens now. I was vaguely aware that AMD had just
launched their Ryzen line of products, and was also vaguely aware that they'd
been trying to get their Zen microarchitecture out. However, AMD have a
history of underwhelming the market in many ways, so it makes one wonder what
an appeal to the "community" is all about. One can be cynical and say that
companies only appeal to anyone if the market is too tough, and once they're
doing fine again, they forget about all their friends in the "community".

Still, their stock price has gone up sixfold over the last few months, so
maybe I'm not the one to second-guess them.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments t

[Luke Kenneth Casson Leighton]

Post by Paul Boddie
been trying to get their Zen microarchitecture out. However, AMD have a
history of underwhelming the market in many ways, so it makes one wonder what

this comes down, unfortunately, to the construction of the x86
instruction set. i've written about this at length in the past, re
intel, but of course it applies to amd as well.

to achieve the same performance as pretty much any RISC processor an
x86 instruction set has to run at *at least* double that of RISC. the
reason is down to the historical compactness of the x86 instructions
(using escape-code sequences) which was fine when memory was
ultra-expensive over 20-40 years ago.

the specific mstake that AMD made was in not realising this.. and
selling their foundry (to become globalfoundries) insead of realising
that it was *absolutely essential* to stay ahead of TSMC and keep up
with Intel's geometry-ahead-of-the-game plan... which they're still
losing btw.

bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
S

[Eric Duhamel]

Post by Luke Kenneth Casson Leighton
bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

I'm rather curious about this. "x86 is dying" is a rather vague statement. Do you mean producers investing in x86 processor based hardware are likely to be pushed out of making profit by non-x86 competitors?

--
Eric Duhamel
http://www.noxbanners.net/

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-n

[Luke Kenneth Casson Leighton]

Post by Eric Duhamel

Post by Luke Kenneth Casson Leighton
bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

I'm rather curious about this. "x86 is dying" is a rather vague statement.

it's more that they're on a losing battle in the all-important
"price-performance-watt" metric due to the extra overhead associated
with x86 instruction decoding compared to RISC (that 500mhz dual-core
Cortex A9 video produced by ARM comparing to a single-core 1.6ghz atom
for example) combined with the power square law vs clock rate means
that staying at the absolute top-end of performance (i.e. *ignoring*
entirely the price-performance-watt metric) is about the only option
available.

Post by Eric Duhamel
Do you mean producers investing in x86 processor based hardware are likely to be pushed out of making profit by non-x86 competitors?

they *can't* make profit. $25 for one of the recent intel "tablet"
style processors - and that's the budget cut-down version that has a
64-bit DDR3 interface and a whopping 650 pins as opposed to a 128-bit
interface with a THOUSAND - where everyone else is aiming for FOUR i
mean they're pissing in the wind basically.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Hendrik Boom]

Post by Luke Kenneth Casson Leighton

Post by Paul Boddie
been trying to get their Zen microarchitecture out. However, AMD have a
history of underwhelming the market in many ways, so it makes one wonder what

this comes down, unfortunately, to the construction of the x86
instruction set. i've written about this at length in the past, re
intel, but of course it applies to amd as well.
to achieve the same performance as pretty much any RISC processor an
x86 instruction set has to run at *at least* double that of RISC. the
reason is down to the historical compactness of the x86 instructions
(using escape-code sequences) which was fine when memory was
ultra-expensive over 20-40 years ago.
the specific mstake that AMD made was in not realising this.. and
selling their foundry (to become globalfoundries) insead of realising
that it was *absolutely essential* to stay ahead of TSMC and keep up
with Intel's geometry-ahead-of-the-game plan... which they're still
losing btw.
bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

Intel already tried that a *long* time ago, with the Itanium. It was provided
with software that emulated the x86. But AMD made a 64-bit hardware version of the
x86 and took over the market because its hardware outran the emulation on the
Itanium, forcing Intel to follow suit or lose the Windows market.

Is the situation different now? With an ARM version of Windows, and
Microsoft's now proven ability to port Wondows to new architectures, quite
possibly.

-- hendrik

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Paul Boddie]

Post by Hendrik Boom

Post by Luke Kenneth Casson Leighton
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

Intel already tried that a *long* time ago, with the Itanium. It was
provided with software that emulated the x86. But AMD made a 64-bit
hardware version of the x86 and took over the market because its hardware
outran the emulation on the Itanium, forcing Intel to follow suit or lose
the Windows market.

Itanium was something of a special case, being of Hewlett-Packard origins and
employing an instruction set architecture that arguably made life more
difficult for tool developers. Itanium was a fiasco for quite a few hardware
manufacturers who bet big on it being a success, especially those who
abandoned their own technologies.

Besides, it was said that the big performance gains in the more recent era of
x86 were due to effectively delivering a RISC-style CPU and employing an x86
instruction-recoding front-end, although I don't personally have any
familiarity with this. There's an interesting remark about such things on the
Cyrix 6x86 Wikipedia page:

"The 6x86 is superscalar and superpipelined and performs register renaming,
speculative execution, out-of-order execution, and data dependency removal.
However, it continued to use native x86 execution and ordinary microcode only,
like Centaur's Winchip, unlike competitors Intel and AMD which introduced the
method of dynamic translation to micro-operations with Pentium Pro and K5."

https://en.wikipedia.org/wiki/Cyrix_6x86

Post by Hendrik Boom
Is the situation different now? With an ARM version of Windows, and
Microsoft's now proven ability to port Wondows to new architectures, quite
possibly.

The difference is where the market is. It was arguably the strength of the
relationship between Microsoft and Intel that kept both of them dominant in
the conventional computing market, and that led to Microsoft's reliance on
x86, even though NT was intended for and delivered for other architectures
(i860, MIPS, Alpha, PowerPC). But Microsoft has had to adapt to the market and
isn't able to define what people want any more in various areas.

What matters a lot more now is the power consumption and performance/power
ratio. AMD's new processors look interesting, for instance, but there's a big
gap between their power numbers and the kind of numbers you see for SoCs being
delivered in huge volumes for things like phones. And even Intel's offerings
have punished AMD for that in recent years.

I imagine that AMD wants to exercise its option to make x86-compatible
products as much as possible, given that few other companies are legally
clearly allowed to do so, but that could easily make the company oblivious to
opportunities elsewhere.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta

[Luke Kenneth Casson Leighton]

Post by Hendrik Boom

Post by Luke Kenneth Casson Leighton
bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

Intel already tried that a *long* time ago, with the Itanium. It was provided
with software that emulated the x86. But AMD made a 64-bit hardware version of the
x86 and took over the market because its hardware outran the emulation on the
Itanium, forcing Intel to follow suit or lose the Windows market.

i assume they tried to target the price-performance market as opposed
to the price-performance-watt market. at that top-end they would
lose.

Post by Hendrik Boom
Is the situation different now?

yes.

Post by Hendrik Boom
With an ARM version of Windows, and
Microsoft's now proven ability to port Wondows to new architectures, quite
possibly.

that's going (eventually) to eat into the top-end price-performance
market as well, but not until x86 hardware-level emulation is common
enough to get 70-80% of clock rate AT THE SAME TIME as reducing POWER
by 70-80%.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send lar

[Bill Kontos]

The problem right now is that pretty much none of the arm SoC manufacturers
adds what is needed for supporting a full desktop/ laptop experience, that
is more than 4 gb of ram, sata3, general purpose pcie lanes and more memory
bandwidth for the igpu. Most of the arm chips right now are stuck at 64 bit
ddr4 at most, and the ones we have access too ( being libre) have even less
bandwidth and are even more limited when it comes to ram.

Just an example, going from single channel to dual channel on an intel igpu
increases performance by 20-30%, and that's even on a gpu design much worse
than any powervr or mali gpu. AMD's apus are somewhat better in this regard
since they have much more advanced memory compression.

Post by Hendrik Boom

Post by Hendrik Boom

Post by Luke Kenneth Casson Leighton
bottom line, if AMD want to stay in business they need to get out of
x86. part-hardware-emulated x86 fine (like the Loongson 3H
architecture did), non-x86, fine. pure x86: dying and dead very soon.

Intel already tried that a *long* time ago, with the Itanium. It was

provided

Post by Hendrik Boom
with software that emulated the x86. But AMD made a 64-bit hardware

version of the

Post by Hendrik Boom
x86 and took over the market because its hardware outran the emulation

on the

Post by Hendrik Boom
Itanium, forcing Intel to follow suit or lose the Windows market.

i assume they tried to target the price-performance market as opposed
to the price-performance-watt market. at that top-end they would
lose.

Post by Hendrik Boom
Is the situation different now?

yes.

Post by Hendrik Boom
With an ARM version of Windows, and
Microsoft's now proven ability to port Wondows to new architectures,

quite

Post by Hendrik Boom
possibly.

that's going (eventually) to eat into the top-end price-performance
market as well, but not until x86 hardware-level emulation is common
enough to get 70-80% of clock rate AT THE SAME TIME as reducing POWER
by 70-80%.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

Post by Bill Kontos
The problem right now is that pretty much none of the arm SoC manufacturers
adds what is needed for supporting a full desktop/ laptop experience, that
is more than 4 gb of ram, sata3, general purpose pcie lanes and more memory
bandwidth for the igpu.

each of those interfaces as hard macros costs around $50k to $100k to
license. also the power budget is... well... see below. the
licensing cost (and design NREs) for using greater than 4GB of RAM -
even if ARM *actually does it* - would be cost-prohibitive.

but the thing is, there's an example SoC that breaks the example that
you've given: the rk3288. the rk3288 easily out-performs recent
high-end intel atom systems, and can do 4GB of RAM, and is available
in a *lot* of very popular chromebooks.

Post by Bill Kontos
Most of the arm chips right now are stuck at 64 bit
ddr4 at most, and the ones we have access too ( being libre) have even less
bandwidth and are even more limited when it comes to ram.
Just an example, going from single channel to dual channel on an intel igpu
increases performance by 20-30%, and that's even on a gpu design much worse
than any powervr or mali gpu.

... with the disadvantage that it increases the power budget
(relatively) by an *enormous* amount.

* 32-bit DDR3L @ 800mhz uses around 300mW
* 32-bit DDR3L @ 1600mhz uses FOUR TIMES that amount - 1.2 watts.
* 64-bit DDR3L @ 1600mhz uses around 2.5 watts

that's just for the RAM ICs, excluding the driver power budget on the
SoC itself. a 128-bit channel would be in excess of FIVE watts at
1600mhz.

if you're used to working with SoCs that *don't even need a heat-sink*...

so now you're in to heat-sinks, fans, extra-careful thermal design:
now you're in to a $200k design, now you have to *justify* that... and
there's no chinese ODM that's going to bother when they can make much
more money selling tablets and phones than they can desktops and
laptops *with no OS*.

i realise that's a circular trap.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attach

[Bill Kontos]

Yea it's the chicken and the egg problem. I was thinking of devices like
the 12'' macbook with sholdered ram and pretty much every ultrabook with an
intel ulv that has dual channel ram sholdered or in sodimms. I guess the
thermal budget issue will become less of a thing when we get to ddr4l

Post by Bill Kontos
The problem right now is that pretty much none of the arm SoC

manufacturers

Post by Bill Kontos
adds what is needed for supporting a full desktop/ laptop experience, that
is more than 4 gb of ram, sata3, general purpose pcie lanes and more memory
bandwidth for the igpu.

each of those interfaces as hard macros costs around $50k to $100k to
license. also the power budget is... well... see below. the
licensing cost (and design NREs) for using greater than 4GB of RAM -
even if ARM *actually does it* - would be cost-prohibitive.

but the thing is, there's an example SoC that breaks the example that
you've given: the rk3288. the rk3288 easily out-performs recent
high-end intel atom systems, and can do 4GB of RAM, and is available
in a *lot* of very popular chromebooks.

Post by Bill Kontos
Most of the arm chips right now are stuck at 64 bit
ddr4 at most, and the ones we have access too ( being libre) have even less
bandwidth and are even more limited when it comes to ram.
Just an example, going from single channel to dual channel on an intel igpu
increases performance by 20-30%, and that's even on a gpu design much worse
than any powervr or mali gpu.

... with the disadvantage that it increases the power budget
(relatively) by an *enormous* amount.

* 32-bit DDR3L @ 800mhz uses around 300mW
* 32-bit DDR3L @ 1600mhz uses FOUR TIMES that amount - 1.2 watts.
* 64-bit DDR3L @ 1600mhz uses around 2.5 watts

that's just for the RAM ICs, excluding the driver power budget on the
SoC itself. a 128-bit channel would be in excess of FIVE watts at
1600mhz.

if you're used to working with SoCs that *don't even need a heat-sink*...

so now you're in to heat-sinks, fans, extra-careful thermal design:
now you're in to a $200k design, now you have to *justify* that... and
there's no chinese ODM that's going to bother when they can make much
more money selling tablets and phones than they can desktops and
laptops *with no OS*.

i realise that's a circular trap.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.uk

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Yea it's the chicken and the egg problem. I was thinking of devices like
the 12'' macbook with sholdered ram and pretty much every ultrabook with an
intel ulv that has dual channel ram sholdered or in sodimms. I guess the
thermal budget issue will become less of a thing when we get to ddr4l

http://www.indjst.org/index.php/indjst/article/download/94832/70105

36% less power consumption apparently... now all that's needed is to
*not* run them at the insane 2400mhz top rate which entirely defeats
the purpose of the exercise... :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[Bill Kontos]

Yea I guess 2400mhz ddr4l would consume about as much as 1600mhz ddr3l on
the same number of channels. But it probably would be of little benefit to
eoma68 anyway since the SoCs in use will probably reach the next bottleneck
well before 2400 mhz 128 bit ddr4 memory bandwidth gets saturated.

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Yea it's the chicken and the egg problem. I was thinking of devices like
the 12'' macbook with sholdered ram and pretty much every ultrabook with

an

Post by Bill Kontos
intel ulv that has dual channel ram sholdered or in sodimms. I guess the
thermal budget issue will become less of a thing when we get to ddr4l

http://www.indjst.org/index.php/indjst/article/download/94832/70105
36% less power consumption apparently... now all that's needed is to
*not* run them at the insane 2400mhz top rate which entirely defeats
the purpose of the exercise... :)
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Yea I guess 2400mhz ddr4l would consume about as much as 1600mhz ddr3l on
the same number of channels. But it probably would be of little benefit to
eoma68 anyway since the SoCs in use will probably reach the next bottleneck
well before 2400 mhz 128 bit ddr4 memory bandwidth gets saturated.

we did work out a system of "power negotiation with the chassis" for
the next revision of the EOMA68 standard: it becomes the
responsibility of the housing to get rid of heat, basically, when
power is permitted to go above 5.0 watts.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Se

[Bill Kontos]

How is that going to work and how will end users be able to know that they
can't plug a 5+ watt card on a incompatible housing ? Or do they negotiate
over some bit so the card knows if it can boost beyond 5 watts or not ?

On Wed, Mar 15, 2017 at 12:57 PM, Luke Kenneth Casson Leighton <

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Yea I guess 2400mhz ddr4l would consume about as much as 1600mhz ddr3l on
the same number of channels. But it probably would be of little benefit

to

Post by Bill Kontos
eoma68 anyway since the SoCs in use will probably reach the next

bottleneck

Post by Bill Kontos
well before 2400 mhz 128 bit ddr4 memory bandwidth gets saturated.

we did work out a system of "power negotiation with the chassis" for
the next revision of the EOMA68 standard: it becomes the
responsibility of the housing to get rid of heat, basically, when
power is permitted to go above 5.0 watts.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Bill Kontos]

Ok so basically this will allow type II cards( smaller) to fit into type
III housings and utilize higher clocks ? Also from my understanding the
type III card will be the physical form factor used for the EOMA 200
standard ?

On Wed, Mar 15, 2017 at 7:31 PM, Benson Mitchell <

Post by Bill Kontos
How is that going to work and how will end users be able to know that they
can't plug a 5+ watt card on a incompatible housing ?
In the current standard, any card needing more than 5W must be a Type III
(that's ~double thickness), and all Type III housings are both electrically
and thermally capable of 10W. High-power card doesn't physically fit in
low-power slots.
Or do they negotiate over some bit so the card knows if it can boost
beyond 5 watts or not ?
That's the idea with the upcoming revision -- by default, the limits still
apply (Type III cards 10W, Type I/II 5W), so you still can't make a Type II
card that needs 10W to run. But you can make a Type II card that meets the
5W limit by severe down-clocking; then a housing can offer CPU cards a
higher limit, allowing them to up-clock or use more cores.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Ok so basically this will allow type II cards( smaller) to fit into type III
housings

yyep.

and utilize higher clocks ?

or many more cores, or... whatever.

Also from my understanding the type III
card will be the physical form factor used for the EOMA 200 standard ?

absolutely not. EOMA200 is a completely separate standard,
absolutely nothing to do with EOMA68.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil

[Bill Kontos]

Oh ok so do you have any draft idea what kind of housing the eoma 68
standard will utilize ?

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Ok so basically this will allow type II cards( smaller) to fit into type

III

Post by Bill Kontos
housings

yyep.

Post by Bill Kontos
and utilize higher clocks ?

or many more cores, or... whatever.

Post by Bill Kontos
Also from my understanding the type III
card will be the physical form factor used for the EOMA 200 standard ?

absolutely not. EOMA200 is a completely separate standard,
absolutely nothing to do with EOMA68.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

Post by Bill Kontos
Oh ok so do you have any draft idea what kind of housing the eoma 68
standard will utilize ?

good question, easily answered (in perhaps a perplexing answer,
apologies) - anything that people wish to envisage. it's not down to
me (or the standard) to *restrict* people on what kind of housings are
created, in fact the total opposite is the case (hence why i am
creating reference designs). btw "Housing" has a special meaning in
EOMA68 terminology, where's that glossary, can anyone remember? :)

now i think about it, you *might* have used the word "housing"
without it being specifically in EOMA68 terminology - in which case
you *might* be referring to PCMCIA Type I, II and III sockets. it
*is* necessary to comply with the *PHYSICAL* sizes of the PCMCIA
sockets and *PHYSICAL* PCMCIA card dimensions.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Bill Kontos]

Yea that's what I meant, sorry my bad. My question is, what physical form
factor will the EOMA 200 cards have( that is, what will "house" the
electronics) ?

Post by Luke Kenneth Casson Leighton

Post by Bill Kontos
Oh ok so do you have any draft idea what kind of housing the eoma 68
standard will utilize ?

good question, easily answered (in perhaps a perplexing answer,
apologies) - anything that people wish to envisage. it's not down to
me (or the standard) to *restrict* people on what kind of housings are
created, in fact the total opposite is the case (hence why i am
creating reference designs). btw "Housing" has a special meaning in
EOMA68 terminology, where's that glossary, can anyone remember? :)
now i think about it, you *might* have used the word "housing"
without it being specifically in EOMA68 terminology - in which case
you *might* be referring to PCMCIA Type I, II and III sockets. it
*is* necessary to comply with the *PHYSICAL* sizes of the PCMCIA
sockets and *PHYSICAL* PCMCIA card dimensions.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
Yea that's what I meant, sorry my bad. My question is, what physical form
factor will the EOMA 200 cards have( that is, what will "house" the
electronics) ?

don't know yet - had a couple of attempts to define it but as it's
targetted at much higher-end SoCs (with much higher NREs) i left it
alone, intending to get back to it either when time permits *or a
sponsor comes forward*.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Bill Kontos
How is that going to work and how will end users be able to know that they
can't plug a 5+ watt card on a incompatible housing ? Or do they negotiate
over some bit so the card knows if it can boost beyond 5 watts or not ?

absolutely correct. a setting in the EOMA68 I2C EEPROM says "This
Housing Safely Supports <N> watts And Also Takes Direct Responsibility
For Removing Heat From The Card, Safely".

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta

[mdn]

Post by Paul Boddie

Post by Julie Marchant
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm
unity
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_
radeon_and_other/def5h1b/
It would be a good idea to encourage AMD to do this. Who knows? It could
lead us to an x86 EOMA computer card of some sort in the future. ;) Not
to mention, it would just be better for us overall to have AMD on our side.

"Unfortunately AMD is licensing Trustonic's PSP firmware. They do not have the
option to open source it."
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/defn8l1/
Of course, this is just one aspect of AMD's technologies, but similar
obstacles probably appear along each of the paths towards freedom for all the
different things their products provide. Even with all their GPU expertise,
they are unlikely to make the technologies transparent because every patent
troll and potential competitor might try and sue them over some detail or
other. That, unfortunately, is the pact of silence all the GPU vendors adhere
to, whether or not the explanation really has much merit.
It's interesting that this happens now. I was vaguely aware that AMD had just
launched their Ryzen line of products, and was also vaguely aware that they'd
been trying to get their Zen microarchitecture out. However, AMD have a
history of underwhelming the market in many ways, so it makes one wonder what
an appeal to the "community" is all about. One can be cynical and say that
companies only appeal to anyone if the market is too tough, and once they're
doing fine again, they forget about all their friends in the "community".
Still, their stock price has gone up sixfold over the last few months, so
maybe I'm not the one to second-guess them.

That's of because of hype building like always.
You should see all the inane comments that I see everywhere on forums
and image boards, it's like if they pay people to go on the said websites...
If a message if repeated enough times one the web you can see that it
will influence something outside of it.

Post by Paul Boddie
Paul
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/dett0cc/

behind the scenes i've asked /u/AMD_James if AMD would like to be part
of a collaboration to put a commercially-viable multi-core 64-bit
RISC-V processor together, with a view *later* to AMD copying the
trick that was used in the Loongson:
https://en.wikipedia.org/wiki/Loongson#Hardware-assisted_x86_emulation

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp

[Bill Kontos]

We don't need to have full utilization of PSP, just ignoring it at boot
sequence and not running it at all would be just fine.

Post by Julie Marchant
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_
creators_of_athlon_radeon_and_other/dett0cc/
behind the scenes i've asked /u/AMD_James if AMD would like to be part
of a collaboration to put a commercially-viable multi-core 64-bit
RISC-V processor together, with a view *later* to AMD copying the
https://en.wikipedia.org/wiki/Loongson#Hardware-assisted_x86_emulation
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Bill Kontos]

I've been looking into the communitie's reaction to that comment about the
PSP firmware, and it seems like people are all over the place in regards to
what they want. Some people want a well defined ABI so coreboot can work
with it, some people want a way to disable it so it doesn't even boot, some
want full cooperation with libreboot, which given the behavior of Leah Rowe
recently with the FSF I think it's safe to say that it's not going to
happen. Libreboot itself made an announcement here

https://libreboot.org/amd-libre/

asking for a full unconditional release of everything including releasing
the signed keys for loading firmware( that doesn't make any sense, if you
have a system that needs a signed key but the key is public what's the
point ?). The whole announcement looks very rushed out to me( e.g. amd
sales would go through the roof if they released the psp firmware, not
going to happen). So my point is, from all these things the most likely to
happen is amd releasing an ABI for it. It will give them the benefit of
some press coverage and nothing more( like what broadcomm did with "open
sourcing" drivers for the RPi 3 which was just the userland part while the
opengl implementation was still part of a huge binary blob, but they did
get the press coverage they wanted). So don't get your hopes too high on
this.

Post by Bill Kontos
We don't need to have full utilization of PSP, just ignoring it at boot
sequence and not running it at all would be just fine.
On Sun, Mar 12, 2017 at 1:17 PM, Luke Kenneth Casson Leighton <

Post by Julie Marchant
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea
tors_of_athlon_radeon_and_other/dett0cc/
behind the scenes i've asked /u/AMD_James if AMD would like to be part
of a collaboration to put a commercially-viable multi-core 64-bit
RISC-V processor together, with a view *later* to AMD copying the
https://en.wikipedia.org/wiki/Loongson#Hardware-assisted_x86_emulation
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

Post by Bill Kontos
asking for a full unconditional release of everything including releasing
the signed keys for loading firmware( that doesn't make any sense, if you
have a system that needs a signed key but the key is public what's the point
?).

exactly: the point is, they should never have added secret-key
firmware signing into the hardware in the first place. *that's* the
point.

Post by Bill Kontos
press coverage they wanted). So don't get your hopes too high on this.

yep. which is why i'm recommending they go "clean slate" and go with
RISC-V with x86 part-acceleration. i looked at the numbers from a
2015 paper on the FP implementation in rocket: it's a whopping 40%
more power-efficient for the same performance.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments t

[Bill Kontos]

One can argue of going the signed firmware route for security is a good or
a bad practice and I agree with you that the unbrickable design of the A20
is a better one, but that is irrelevant in the case of Ryzen chips: They
have already been taped out so we have to work with what we are given.
Going completely free with risc v would be cool but that is years away.

Post by Luke Kenneth Casson Leighton

Post by Bill Kontos
asking for a full unconditional release of everything including releasing
the signed keys for loading firmware( that doesn't make any sense, if you
have a system that needs a signed key but the key is public what's the

point

Post by Bill Kontos
?).

exactly: the point is, they should never have added secret-key
firmware signing into the hardware in the first place. *that's* the
point.

Post by Bill Kontos
press coverage they wanted). So don't get your hopes too high on this.

yep. which is why i'm recommending they go "clean slate" and go with
RISC-V with x86 part-acceleration. i looked at the numbers from a
2015 paper on the FP implementation in rocket: it's a whopping 40%
more power-efficient for the same performance.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Albert ARIBAUD]

Bonjour,

Le Sun, 12 Mar 2017 21:31:27 +0200

Post by Bill Kontos
One can argue of going the signed firmware route for security is a
good or a bad practice and I agree with you that the unbrickable
design of the A20 is a better one, but that is irrelevant in the case
of Ryzen chips: They have already been taped out so we have to work
with what we are given.

Which, some would argue, is the reason why they should have thought,
long before tapeout, of a (re)programmable key mechanism instead of a
ROMed or OTP one. It would have made it possible to write a secret key
in the device and be sure it won't be read back [1], while preventing
said device from being locked-out or bricked, because you can always
mass-erase it back to "no key" state. (that's what's done on Kinetis
SoCs for the whole internal flash, to give one example, although
they /do/ offer a way to lock the device completely if some manager
really wants that despite the repeated warnings from his tech people).

[1] Barring any cracking of the device's security, but that's a risk
for ROMmed keys too.

Amicalement,

[Luke Kenneth Casson Leighton]

ah! albert! did you get my email, am looking to invite you to help
with I2C EEPROM reading for the passthrough card (which has another
STM32F072...)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to a

[Albert ARIBAUD]

Hi Luke,

Le Mon, 13 Mar 2017 16:13:26 +0000

Post by Luke Kenneth Casson Leighton
ah! albert! did you get my email, am looking to invite you to help
with I2C EEPROM reading for the passthrough card (which has another
STM32F072...)

Yes -- sorry I did not answer this week-end. Of course I'd be happy to
help!

Post by Luke Kenneth Casson Leighton
l.

Amicalement,

[Mike Leimon]

Post by Bill Kontos
Ok so basically this will allow type II cards( smaller) to fit into type
III housings and utilize higher clocks ?

I think the idea is a bit better than that even. I think that by default
all Type II cards must adhere/support the 5W upper thermal limit. However, even
in a Type II slot the card may negotiate with a housing and if the housing
can support heat removal from the card to allow it to operate at a higher
(10W?) limit, then the card may then utilize a faster clock rate or
activate more cores (at that point).

Post by Bill Kontos
Also from my understanding the
type III card will be the physical form factor used for the EOMA 200
standard ?

No, I think this is a misunderstanding. I'm pretty sure that the EOMA-200
standard will have 202 pins Please see the following page for details:

http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-200

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Mike Leimon

Post by Bill Kontos
Ok so basically this will allow type II cards( smaller) to fit into type
III housings and utilize higher clocks ?

I think the idea is a bit better than that even. I think that by default
all Type II cards must adhere/support the 5W upper thermal limit. However, even
in a Type II slot the card may negotiate with a housing and if the housing
can support heat removal from the card to allow it to operate at a higher
(10W?) limit, then the card may then utilize a faster clock rate or
activate more cores (at that point).

ha, you said exactly what needed to be said (including below) - i
didn't need to reply _at all_ - thanks mike :)

Post by Mike Leimon

Post by Bill Kontos
Also from my understanding the
type III card will be the physical form factor used for the EOMA 200
standard ?

No, I think this is a misunderstanding. I'm pretty sure that the EOMA-200
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-200
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
S