Trisquel forum thread here:
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-commu...
And this is the Reddit thread where it happened:
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_r...
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.
oo that's a great idea, good find, julie. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Mar 10, 2017 at 4:08 PM, Julie Marchant onpon4@riseup.net wrote:
Trisquel forum thread here:
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-commu...
And this is the Reddit thread where it happened:
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_r...
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
Protect your emails with GnuPG: https://emailselfdefense.fsf.org
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Friday 10. March 2017 17.08.47 Julie Marchant wrote:
Trisquel forum thread here:
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm unity
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.
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_r...
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
On Fri, Mar 10, 2017 at 5:19 PM, Paul Boddie paul@boddie.org.uk wrote:
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.
On March 10, 2017 10:34:55 AM PST, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
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/
On Mon, Mar 13, 2017 at 4:51 PM, Eric Duhamel ericxdu23@gmail.com wrote:
On March 10, 2017 10:34:55 AM PST, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
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.
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.
On Fri, Mar 10, 2017 at 06:34:55PM +0000, Luke Kenneth Casson Leighton wrote:
On Fri, Mar 10, 2017 at 5:19 PM, Paul Boddie paul@boddie.org.uk wrote:
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
On Monday 13. March 2017 18.13.37 Hendrik Boom wrote:
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
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
On Mon, Mar 13, 2017 at 5:13 PM, Hendrik Boom hendrik@topoi.pooq.com wrote:
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.
Is the situation different now?
yes.
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.
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.
On Tue, Mar 14, 2017 at 8:39 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
On Mon, Mar 13, 2017 at 5:13 PM, Hendrik Boom hendrik@topoi.pooq.com wrote:
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.
Is the situation different now?
yes.
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Tue, Mar 14, 2017 at 10:55 AM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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.
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 On Tue, Mar 14, 2017 at 10:55 AM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Mar 14, 2017 at 12:00 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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.
On Tue, Mar 14, 2017 at 2:28 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Mar 14, 2017 at 12:00 PM, Bill Kontos vkontogpls@gmail.com wrote:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 9:00 AM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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 < lkcl@lkcl.net> wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 9:00 AM, Bill Kontos vkontogpls@gmail.com wrote:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mar 15, 2017 11:42 AM, "Bill Kontos" vkontogpls@gmail.com wrote:
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.
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 < benson.mitchell+arm-netbook@gmail.com> wrote:
On Mar 15, 2017 11:42 AM, "Bill Kontos" vkontogpls@gmail.com wrote:
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.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 6:18 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
Oh ok so do you have any draft idea what kind of housing the eoma 68 standard will utilize ?
On Wed, Mar 15, 2017 at 9:34 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 6:18 PM, Bill Kontos vkontogpls@gmail.com wrote:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, Mar 15, 2017 at 7:45 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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) ?
On Wed, Mar 15, 2017 at 9:51 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
On Wed, Mar 15, 2017 at 7:45 PM, Bill Kontos vkontogpls@gmail.com wrote:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 8:31 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Mar 15, 2017 at 3:40 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
Le 10/03/2017 18:19, Paul Boddie a écrit :
On Friday 10. March 2017 17.08.47 Julie Marchant wrote:
Trisquel forum thread here:
https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm unity
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.
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_r...
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.
Paul
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_r...
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.
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 <lkcl@lkcl.net
wrote:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
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.
On Sun, Mar 12, 2017 at 4:43 PM, Bill Kontos vkontogpls@gmail.com wrote:
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 < lkcl@lkcl.net> wrote:
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 trick that was used in the Loongson: https://en.wikipedia.org/wiki/Loongson#Hardware-assisted_x86_emulation
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Mar 12, 2017 at 3:46 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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.
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.
On Sun, Mar 12, 2017 at 8:23 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
On Sun, Mar 12, 2017 at 3:46 PM, Bill Kontos vkontogpls@gmail.com wrote:
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.
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Bonjour,
Le Sun, 12 Mar 2017 21:31:27 +0200 Bill Kontos vkontogpls@gmail.com a écrit:
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,
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.
Hi Luke,
Le Mon, 13 Mar 2017 16:13:26 +0000 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
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!
l.
Amicalement,
arm-netbook@lists.phcomp.co.uk
-
Albert ARIBAUD -
Benson Mitchell -
Bill Kontos -
Eric Duhamel -
Hendrik Boom -
Julie Marchant -
Luke Kenneth Casson Leighton -
mdn -
Paul Boddie