From paul at boddie.org.uk  Tue May 12 22:06:52 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 12 May 2020 23:06:52 +0200
Subject: [Arm-netbook] MNT Reform Campaign
Message-ID: <2472461.A17itGjGyp@jeremy>

Hello,

It got mentioned about two-and-a-half years ago on this list, but the MNT 
Reform campaign has finally begun:

https://www.crowdsupply.com/mnt/reform

Of potential relevance to those following EOMA68-related efforts might be 
various resources that the MNT Reform effort has made available:

https://source.mntmn.com/MNT/reform

Things like the PCB layouts, microcontroller firmware and case designs are 
published, although people have previously noted that Autodesk Fusion isn't a 
particularly libre-friendly format for the case designs.

One could envisage adaptations of this for EOMA68-related purposes or 
something with similar objectives. Certainly, user-upgradeable functionality 
via an externally accessible PCMCIA-style slot (or similar, rather than the 
internal SO-DIMM slot) would surely be worthwhile exploring.

Paul


From lkcl at lkcl.net  Tue May 12 22:38:49 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 12 May 2020 22:38:49 +0100
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <2472461.A17itGjGyp@jeremy>
References: <2472461.A17itGjGyp@jeremy>
Message-ID: <CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>

On Tue, May 12, 2020 at 10:07 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> Hello,
>
> It got mentioned about two-and-a-half years ago on this list, but the MNT
> Reform campaign has finally begun:
>
> https://www.crowdsupply.com/mnt/reform

fantastic.  interestingly the libre-licensed iMX8 files could be used
to create an EOMA68-iMX8 Card.

however, the case parts - although "professional" - a large local
Corporation could conceivably manufacture and repair those, but an
end-user could not.

l.


From laserhawk64 at gmail.com  Wed May 13 00:20:37 2020
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Tue, 12 May 2020 19:20:37 -0400
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
References: <2472461.A17itGjGyp@jeremy>
	<CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
Message-ID: <CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>

Forgive me for asking, because I didn't quite pass the requisite fervency
test to be enrolled in the Joint OSHW-F|L|OSS Technical Militia ( :P ), but
remind me, please, of a couple things, if I may ask them...?

(1) Why are there none of these OSHW devices using existing x86-compatible
CPUs/SoCs?

(2a) Are there any meaningful barriers to creating an OSHW-compatible x86
CPU/SoC, independent of major chip houses (Intel, AMD) or established niche
players (VIA, etc)?

(2b) I've heard noises of a homegrown sort of effort out of China, from a
company and fab house over there... could that CPU be considered as an
acceptable candidate for such an effirt, and if not, why...? (I assume not,
and because "China!", but I'm wide open here.)

From paul at boddie.org.uk  Wed May 13 20:52:34 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 13 May 2020 21:52:34 +0200
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>
References: <2472461.A17itGjGyp@jeremy>
	<CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
	<CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>
Message-ID: <4321123.d4ell7m0hL@jeremy>

On Tuesday 12. May 2020 19.20.37 Christopher Havel wrote:
> Forgive me for asking, because I didn't quite pass the requisite fervency
> test to be enrolled in the Joint OSHW-F|L|OSS Technical Militia ( :P ), but
> remind me, please, of a couple things, if I may ask them...?

I can try and provide some suggestions, but I'm sure Luke can give you plenty 
of additional insight.

> (1) Why are there none of these OSHW devices using existing x86-compatible
> CPUs/SoCs?

I can think of a few reasons, some mundane and some more important for open 
source hardware.

One mundane but practical reason might be that there is a degree of additional 
complexity in board design and assembly with x86(-64) products. Looking at 
recent AMD products where the socket support has been fairly stable, the 
actual CPUs seem to have large numbers of pins. If the CPUs are actually 
socketed, maybe the techniques involved are less demanding than having to 
mount the CPUs directly on the boards, but then I can still imagine that the 
engineering isn't going to be easy.

For lower-power products, things like the embedded Ryzen stuff uses a 
different socket type (FP5) to normal Ryzen (AM4) - even the GE variants of 
normal Ryzen - and for some products I get the impression that the "socket" is 
just an indicator of the footprint and not an actual socket where you would be 
able to swap out the CPUs, but I could be wrong. And this is just AMD: Intel 
seem to change "socket" types all the time which would make everything more 
complicated and demanding. It isn't a surprise that there are just a handful 
of major mainboard vendors presumably having deep relationships to AMD and 
Intel.

For open source hardware, it is also potentially interesting to make low-power 
products, and here the power consumption of x86(-64) seems rather high. At the 
lower end, Intel seem to offer Atom-branded and Pentium-branded products that 
consume a few watts and seem to be based on relatively modern 
microarchitectures, and they did try to make embedded CPUs based on earlier 
microarchitectures - Quark, I think it was - that didn't catch on.

There is also a strong temptation to drop the x86 legacy altogether when you 
are not strongly invested in it. My impression is that SoCs for other 
architectures provide a degree of freedom from that legacy at the cost of a 
lack of standardisation. But it also means that there is a certain potential 
to avoid the more recent undesirable aspects of BIOS-related technologies, 
although there are x86-64-based laptops being sold that supposedly address 
such issues (in certain regards) and that are promoted as being friendly to 
Free Software even if they are not actually open source hardware as well.

> (2a) Are there any meaningful barriers to creating an OSHW-compatible x86
> CPU/SoC, independent of major chip houses (Intel, AMD) or established niche
> players (VIA, etc)?

Yes: patents. VIA only got away with releasing x86-compatible products because 
of some ancient agreement, as far as I remember, and Intel has been rather 
aggressive in preventing new entrants getting into the market. The histories 
of various companies passing through the x86 market are quite interesting: 
Cyrix, NexGen, National Semiconductor, IBM, Transmeta, and so on. Many of the 
alternative x86 implementations seem to have ended up at AMD over the years.

> (2b) I've heard noises of a homegrown sort of effort out of China, from a
> company and fab house over there... could that CPU be considered as an
> acceptable candidate for such an effirt, and if not, why...? (I assume not,
> and because "China!", but I'm wide open here.)

I think I heard something of the sort, too. There is nothing to stop anyone 
from making their own x86(-64) implementation technically, and we must be at 
the stage where a fair amount of the x86 architecture is not patent 
encumbered. Then again, there are plenty of other architectures that are a lot 
more interesting and performant than old-style x86.

That brings us to another pertinent point about modern x86-64 CPUs: the 
performance presumably comes from the microarchitecture that is effectively 
internal and specific to each of the big players' products (things like Core 
and Zen). Seeking to compete with existing x86 products would involve a 
colossal amount of work replicating what they have managed to do with those 
microarchitecture efforts.

Well, those were just a few ideas, some more credible than others.

Paul


From lkcl at lkcl.net  Wed May 13 23:11:28 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 13 May 2020 23:11:28 +0100
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <4321123.d4ell7m0hL@jeremy>
References: <2472461.A17itGjGyp@jeremy>
	<CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
	<CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>
	<4321123.d4ell7m0hL@jeremy>
Message-ID: <CAPweEDxLReeFQ72nqJhNvZ_KAzSgDU7fDmqg9LFh6XnpmZYHtA@mail.gmail.com>

On Wed, May 13, 2020 at 8:53 PM Paul Boddie <paul at boddie.org.uk> wrote:

> That brings us to another pertinent point about modern x86-64 CPUs: the
> performance presumably comes from the microarchitecture that is effectively
> internal and specific to each of the big players' products (things like Core
> and Zen). Seeking to compete with existing x86 products would involve a
> colossal amount of work replicating what they have managed to do with those
> microarchitecture efforts.

billion-transistor efforts.  insane instruction opcode lengths.  40
years development
history, any of which you leave out, you can kiss compatibility goodbye.

nobody in their right mind is going to try to enter that market with
anything other
than a fractional subset plus software JIT emulation of the rest.

l.


From doark at mail.com  Thu May 14 01:42:54 2020
From: doark at mail.com (David Niklas)
Date: Wed, 13 May 2020 20:42:54 -0400
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <4321123.d4ell7m0hL@jeremy>
References: <2472461.A17itGjGyp@jeremy>
	<CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
	<CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>
	<4321123.d4ell7m0hL@jeremy>
Message-ID: <20200513204254.1376bd3c@Phenom-II-x6.niklas.com>

On Wed, 13 May 2020 21:52:34 +0200
Paul Boddie <paul at boddie.org.uk> wrote:
> On Tuesday 12. May 2020 19.20.37 Christopher Havel wrote:
<snip>
> > (1) Why are there none of these OSHW devices using existing
> > x86-compatible CPUs/SoCs?
<snip>
> > (2a) Are there any meaningful barriers to creating an OSHW-compatible
> > x86 CPU/SoC, independent of major chip houses (Intel, AMD) or
> > established niche players (VIA, etc)?
<snip>
> > (2b) I've heard noises of a homegrown sort of effort out of China,
> > from a company and fab house over there... could that CPU be
> > considered as an acceptable candidate for such an effirt, and if not,
> > why...? (I assume not, and because "China!", but I'm wide open
> > here.)
<snip>

The Chinese have a deal with Via which bought out Cyrix which had been in
a patent ware with Intel as they used hard-coded instructions whereas
Intel and AMD used micro-code to decode instructions.
https://www.youtube.com/watch?v=iWGAdoMz1c0

As to why there are no competitors in the X86 space, the amd64 64-bit
extensions are patented AFAIK. So you're limited to a 32 bit system.
That's not to mention MMX, SSE, AVX, and an assortment of other
instructions throughout the years.

Then there's the amount of design you have to do just for the
instruction set. Its hysterical how many instructions for moving data
there are.
https://www.youtube.com/watch?v=g9_FYRAfyqQ

Then you need something with high enough speed to match or exceed
the speed of the competition, without voiding any of their patents,
which is something they can't even achieve.

Then you need to create masks for the lithography for fabricating these
chips. Luke says a small opensource RISC-V CPU would cost millions to
create the masks for on an old node -- 32nm IIRC. 7nm costs double the
amount that 16nm costs for chip fabrication according to AMD which places
it in the hundreds of millions for the masks; and you need more for 7nm
then previous nodes.

You also have to have really good power usage, as 7nm is so small that you
have almost no space left for thermal conductivity. In fact, current AMD
offerings are thermally limited in the silicon. They could clock higher
and use more power but they'd blow through their thermal envelope.

Also, according to AMD, "extreme" measures must be taken to see to it that
clock speeds remain high instead of going lower then previous offerings.

You need to have enough transistors per mm2.

You need enough cores, memory channels, and PCIe 4.0 lanes.




In summery:

What you should be asking is, "Why are there no OSHW CPUs/GPUs for
purchase by consumers at all?"

In short, the Parallela board used a Xilinx (closed source HW and SW),
FPGA for their Epiphany CPU and said that they couldn't make it in
silicon due to lack of demand coupled with expense.
When people demand OSHW, they will get it. Until then, its going to be
based solely on the kindness of the companies and developers, like luke.
Gooooooo Luke!!!

Sincerely,
David


From laserhawk64 at gmail.com  Thu May 14 02:07:37 2020
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Wed, 13 May 2020 21:07:37 -0400
Subject: [Arm-netbook] MNT Reform Campaign
In-Reply-To: <20200513204254.1376bd3c@Phenom-II-x6.niklas.com>
References: <2472461.A17itGjGyp@jeremy>
	<CAPweEDwa0exJga2U8eTgDa-_NNya3Yd4TLox2Ms-gHB3mLnKWQ@mail.gmail.com>
	<CA+kEFNK5YQy8=CL4G7OCeH2qtmvEa-5A-i7W8DWpUupRZ9jUxA@mail.gmail.com>
	<4321123.d4ell7m0hL@jeremy>
	<20200513204254.1376bd3c@Phenom-II-x6.niklas.com>
Message-ID: <CA+kEFN+m8gYAJA=MxdusZ3+HMZg5qrtVFhFOzOrWS4QcMgs_fA@mail.gmail.com>

OK... how about something like a hybrid of what Transmeta and Google's
Android OS do, where you have an SoC on a board with its support stuff, and
it presents a standardized set of interfaces/specs/etc to the OS via a
firmware-level (?) VM sort of setup...?

Yes, I know how awful Transmeta CPUs were -- but not firsthand. Secondhand.
My local tech shop pal Jody has (had? Don't remember right now and I'm too
lazy to bug him) a Transmeta Crusoe based system at some point... said that
it made VIA chips look like a particularly high-end Core i9 Extreme Edition
overclocked and tuned to within an inch of catching fire (LOL -- my words,
not his). If you're not familiar with VIA... a 1GHz VIA Eden CPU as found
in a thin client I'm quite familiar with (the Wyse C-series aka Wyse Cx0
series... their model number scheme is really weird) is about on par with
my HP Mini 5102 netbook from 2010.

But, hey, maybe...? I dunno, you guys clearly know this stuff way better
than I do, so you tell me!

Off-topic #1 -- coincidentally, the HP Mini has a repair to it I'm quite
proud of... Jody gave it to me with a dented lid and a BIOS password.
Couldn't do much about the lid, but... SOIC-8 ROM holds the BIOS code.
Desoldered, plunked in my (then fairly new) TL866C "MiniPro" programmer I'd
gotten a few months prior for my birthday... boom! No more password. First
real SMD/SMT solder job I did.

Off-topic #2 -- more interesting, probably, to you guys would be how I came
to be so familiar with the Wyse C-series clients in the first place. Go
look up bug #91966 in the bug tracker for the "openchrome" Xwin driver ;)
warning, it's quite a long read... over 100 posts/comments... not kidding!

From crimier at yandex.ru  Tue May 19 00:42:50 2020
From: crimier at yandex.ru (=?utf-8?B?UGnEjXVnaW5zIEFyc2VuaWpz?=)
Date: Tue, 19 May 2020 02:42:50 +0300
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
Message-ID: <1010621589845316@mail.yandex.ru>

https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found

Note on the 'lsusb' thing: I personally like the 'dmesg -Hw &' command, it stays in the background and prints the dmesg info in realtime - in particular, letting you see detailed data about newly-connected devices.


From lkcl at lkcl.net  Tue May 19 01:05:52 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 19 May 2020 01:05:52 +0100
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <1010621589845316@mail.yandex.ru>
References: <1010621589845316@mail.yandex.ru>
Message-ID: <CAPweEDyz5jRUE=Wr843s=Mkh5PBBMszKRJdf2VQ-+aJLhBOZow@mail.gmail.com>

On Tue, May 19, 2020 at 12:43 AM Pičugins Arsenijs <crimier at yandex.ru> wrote:
>
> https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found
>
> Note on the 'lsusb' thing: I personally like the 'dmesg -Hw &' command, it stays in the background and prints the dmesg info in realtime - in particular, letting you see detailed data about newly-connected devices.

ah!  thank you :)

l.


From doark at mail.com  Wed May 20 03:31:06 2020
From: doark at mail.com (David Niklas)
Date: Tue, 19 May 2020 22:31:06 -0400
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <1010621589845316@mail.yandex.ru>
References: <1010621589845316@mail.yandex.ru>
Message-ID: <20200519223106.6c0dcf71@Phenom-II-x6.niklas.com>

https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found

Dear luke,
You didn't need email, you can use wall(1).

Hope it helps in the future.
David


From phil at hands.com  Wed May 20 09:01:46 2020
From: phil at hands.com (Philip Hands)
Date: Wed, 20 May 2020 10:01:46 +0200
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <20200519223106.6c0dcf71@Phenom-II-x6.niklas.com>
References: <1010621589845316@mail.yandex.ru>
	<20200519223106.6c0dcf71@Phenom-II-x6.niklas.com>
Message-ID: <87blmjt4ph.fsf@hands.com>

David Niklas <doark at mail.com> writes:

> https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found
>
> Dear luke,
> You didn't need email, you can use wall(1).

That dredges up memories of supporting users (via 1200 baud modem, thus
occupying the only land line) by communicating via write(1) in each
direction, which then lead to the memory of the joy of discovering
talk(1) as a better alternative.

Thanks for the moment of Proustian nostalgia.  :-)

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

From lkcl at lkcl.net  Wed May 20 12:32:07 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 20 May 2020 12:32:07 +0100
Subject: [Arm-netbook] EOMA68 Computing Devices Update: Command Not Found
In-Reply-To: <87blmjt4ph.fsf@hands.com>
References: <1010621589845316@mail.yandex.ru>
	<20200519223106.6c0dcf71@Phenom-II-x6.niklas.com>
	<87blmjt4ph.fsf@hands.com>
Message-ID: <CAPweEDzvrKau-dd2hOgGcJ5oMDegrykEWLwfRRY1x1AMyk85Zg@mail.gmail.com>

On Wed, May 20, 2020 at 9:02 AM Philip Hands <phil at hands.com> wrote:
>
> David Niklas <doark at mail.com> writes:
>
> > https://www.crowdsupply.com/eoma68/micro-desktop/updates/command-not-found
> >
> > Dear luke,
> > You didn't need email, you can use wall(1).
>
> That dredges up memories of supporting users (via 1200 baud modem, thus
> occupying the only land line) by communicating via write(1) in each
> direction, which then lead to the memory of the joy of discovering
> talk(1) as a better alternative.

ha, i remember that.  and trying to write a better alternative
(multi-user, tokenring style) as a way to learn c, except i didn't use
select and on trying to kill it, it left a zombie process running at
100% CPU on the SunOS 4.1.3 minicomputer.  as it was during the
inter-term break, i went to see one of the sysadmins in the Imperial
College Dept of Computing to sort it out.  he was later severely told
off for rebooting the machine.

> Thanks for the moment of Proustian nostalgia.  :-)

:)

l.