From tona_kosmicznego_smiecia at interia.pl  Wed Nov  4 19:56:59 2020
From: tona_kosmicznego_smiecia at interia.pl (Jan Wielkiewicz)
Date: Wed, 4 Nov 2020 20:56:59 +0100
Subject: [Arm-netbook] Any progress?
In-Reply-To: <CAPweEDx506zBEZMN_8-vgZiMSNNQi5fQ5Ub_SMnUQwDnDkAApQ@mail.gmail.com>
References: <20200918014028.4c77a81a@interia.pl>
	<CAPweEDx506zBEZMN_8-vgZiMSNNQi5fQ5Ub_SMnUQwDnDkAApQ@mail.gmail.com>
Message-ID: <20201104205659.18d470e6@interia.pl>

Dnia 2020-09-18, o godz. 14:08:29
Luke Kenneth Casson Leighton <lkcl at lkcl.net> napisał(a):

> On Fri, Sep 18, 2020 at 12:41 AM Jan Wielkiewicz
> <tona_kosmicznego_smiecia at interia.pl> wrote:
> >
> > Hello Luke and others!
> 
> hi jan
> 
> > Are there any news about the cards?
> > We're slowly reaching the next estimated shipping date (30
> > September), so let us know if there's anything new (I know the
> > answer for the shipping date is the same as always).
> 
> i'm pinging mike to find out where he's at.  will let you know.
> 

Sooooo did you find out anything?
By the way, I just saw you're doing a code freeze of the processor. Do
you have any estimations of when the first products using the simple
version of the core may be available? I have some pocket money hungry
for crowdfunding.


Jan Wielkiewicz


From lkcl at lkcl.net  Wed Nov  4 20:31:34 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 4 Nov 2020 20:31:34 +0000
Subject: [Arm-netbook] Any progress?
In-Reply-To: <20201104205659.18d470e6@interia.pl>
References: <20200918014028.4c77a81a@interia.pl>
	<CAPweEDx506zBEZMN_8-vgZiMSNNQi5fQ5Ub_SMnUQwDnDkAApQ@mail.gmail.com>
	<20201104205659.18d470e6@interia.pl>
Message-ID: <CAPweEDxm4C5+6tX_ZFV+2j9WuUHa6yfjSEs_0wUVnYY9ce4hmA@mail.gmail.com>

On Wed, Nov 4, 2020 at 7:58 PM Jan Wielkiewicz
<tona_kosmicznego_smiecia at interia.pl> wrote:
>
> Dnia 2020-09-18, o godz. 14:08:29
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> napisał(a):
>
> > On Fri, Sep 18, 2020 at 12:41 AM Jan Wielkiewicz
> > <tona_kosmicznego_smiecia at interia.pl> wrote:
> > >
> > > Hello Luke and others!
> >
> > hi jan
> >
> > > Are there any news about the cards?
> > > We're slowly reaching the next estimated shipping date (30
> > > September), so let us know if there's anything new (I know the
> > > answer for the shipping date is the same as always).
> >
> > i'm pinging mike to find out where he's at.  will let you know.
> >
>
> Sooooo did you find out anything?

he had to move to a bigger factory, and will be carrying on the production.

> By the way, I just saw you're doing a code freeze of the processor. Do
> you have any estimations of when the first products using the simple
> version of the core may be available?

mmm...

> I have some pocket money hungry
> for crowdfunding.

right now they'll need to be big pockets, it's costing NLnet EUR
18,000 to do a few test ASICs (maybe 30, of which maybe 15 might
work).

we also need to be very careful in whom we give them to because we are
required to comply with the OPF's EULA.  if it's non-compliant with
the OpenPOWER Compliance Requirements, we can't sell it.  however...
there is a leeetle wiggle-room inasmuch as IBM and other entities
would have to show "material harm" caused by our test ASIC.

if we sold 100,000 such non-compliant test ASICs such that people
start doing upstream kernel development to cater for the mistakes,
that starts to piss people off who make literally billions of dollars
from the reputation going back 25 years of OpenPOWER ISA being
"unified, stable and reliable".

if however we sold... mmm... 1000 on the SPECIFIC condition that UNDER
NO CIRCUMSTANCES was this to be considered anything other than a test
ASIC, then *MAYBE* it would be ok.

l.


From paul at boddie.org.uk  Sat Nov 28 22:23:11 2020
From: paul at boddie.org.uk (Paul Boddie)
Date: Sat, 28 Nov 2020 23:23:11 +0100
Subject: [Arm-netbook] Somewhat off-topic updates about Ryzen, PolarFire,
	HiFive and Elbrus (was Re:  Current status)
In-Reply-To: <2034287.2zzArLbcde@jason>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason>
Message-ID: <2808268.lnS8WIl1fd@jason>

On Tuesday, 21 July 2020 23:36:28 CET Paul Boddie wrote:
> 
> So, upcoming AMD products could be decent, but I would be wary about
> stability for a while after their release. Following the Linux kernel bug
> tracker can be informative:
> 
> https://bugzilla.kernel.org/
> 
> Searching for "amdgpu" is probably what you want to do. For quite some time,
> people were having problems with the 3200G, and that made me worried about
> the 3400G, but it seems that even within product families there might be
> some parts that are better supported than others.

Since then, my Ryzen system has worked better than my work laptop that has an 
Intel Core 7 CPU with integrated graphics that aren't used because there is 
also an Nvidia video card which occasionally does some very weird display 
memory "picture interference" thing.

(I thought that might be the HDMI output playing up, having had to mess with 
Synopsys HDMI on the Ingenic JZ4780 and seeing the many weird things that have 
to be set up to enable the peripheral, but is probably some dodgy interaction 
between the binary firmware blobs and the baroque "Linux plus GNOME plus 
whatever is in-between" graphics stack.)

The only weird thing I have seen with the Ryzen 3400G is this kind of message 
(with dmesg prefixes removed):

Corrected error, no action required.
CPU:7 (17:18:1) MC3_STATUS[-|CE|MiscV|-|-|-|SyndV|-|-|-]: 0x9820000000000150
IPID: 0x000300b000000000, Syndrome: 0x000000002a000503
Decode Unit Ext. Error Code: 0, Micro-op cache tag parity error.
cache level: RESV, tx: INSN, mem-tx: IRD

I have no idea whether this is really bad or not.

[...]

> "A low-cost dev kit for Microchip's PolarFire SoC, a low-power FPGA
> integrated with a hardened quad core 64-bit RISC-V microprocessor
> subsystem"
> 
> https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit
> 
> That is from the Microsemi part of Microchip's business, however, meaning
> that it is another recent acquisition: Microchip presumably buying in new
> technology to remain competitive.

Since that campaign, they've started another:

"PolarBerry is a System-on-Module (SoM) SBC utilizing the Microchip PolarFire 
SoC, which integrates a low-power FPGA with a highly secure, four-application-
core, 64-bit, Linux-capable RISC-V subsystem."

https://www.crowdsupply.com/sundance-dsp/polarberry

They go on about how it has "defense-level security". And again, it relies on 
Microsemi's proprietary toolchain.

Meanwhile, this one slipped below the radar given that SiFive already 
crowdfunded a similar kind of board successfully a while back:

"Powered by the SiFive Freedom U740 RISC-V SoC and targeted for creating RISC-
V applications, the platform features 8 GB of 64-bit DDR4 memory operating at 
2400 MT/s, high-speed interconnects with PCIe Gen 3 x8 operating at 7.8 GB/s, 
Gigabit Ethernet, and USB 3.2 Gen 1."

https://www.crowdsupply.com/sifive/hifive-unmatched

However, I think this one might appeal to Luke a bit more:

"Elbrus is a mini-ITX security-oriented motherboard for mobile/embedded usage 
based on the MCST Elbrus-8CB 8-core @ 1.5 GHz VLIW CPU on ELBRUS 
architecture."

https://www.crowdsupply.com/sra-centr8/icepeakitx-elbrus-8cb

In case OpenPOWER isn't exciting enough.

Paul




From lkcl at lkcl.net  Sat Nov 28 23:20:22 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 28 Nov 2020 23:20:22 +0000
Subject: [Arm-netbook] Somewhat off-topic updates about Ryzen, PolarFire,
 HiFive and Elbrus (was Re: Current status)
In-Reply-To: <2808268.lnS8WIl1fd@jason>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason> <2808268.lnS8WIl1fd@jason>
Message-ID: <CAPweEDzzD7KCBGwk6RizG0gyFLbTPw5u3Ma73B0mLHHMYR5LeA@mail.gmail.com>

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

On Sat, Nov 28, 2020 at 10:23 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> On Tuesday, 21 July 2020 23:36:28 CET Paul Boddie wrote:
> >
> > So, upcoming AMD products could be decent, but I would be wary about
> > stability for a while after their release. Following the Linux kernel bug
> > tracker can be informative:
> >
> > https://bugzilla.kernel.org/
> >
> > Searching for "amdgpu" is probably what you want to do. For quite some time,
> > people were having problems with the 3200G, and that made me worried about
> > the 3400G, but it seems that even within product families there might be
> > some parts that are better supported than others.
>
> Since then, my Ryzen system has worked better than my work laptop that has an
> Intel Core 7 CPU with integrated graphics that aren't used because there is
> also an Nvidia video card which occasionally does some very weird display
> memory "picture interference" thing.
>
> (I thought that might be the HDMI output playing up, having had to mess with
> Synopsys HDMI on the Ingenic JZ4780 and seeing the many weird things that have
> to be set up to enable the peripheral, but is probably some dodgy interaction
> between the binary firmware blobs and the baroque "Linux plus GNOME plus
> whatever is in-between" graphics stack.)
>
> The only weird thing I have seen with the Ryzen 3400G is this kind of message
> (with dmesg prefixes removed):
>
> Corrected error, no action required.
> CPU:7 (17:18:1) MC3_STATUS[-|CE|MiscV|-|-|-|SyndV|-|-|-]: 0x9820000000000150
> IPID: 0x000300b000000000, Syndrome: 0x000000002a000503
> Decode Unit Ext. Error Code: 0, Micro-op cache tag parity error.
> cache level: RESV, tx: INSN, mem-tx: IRD

my gaming laptop (also i7) i bought 2-3 years ago now had immediate
problems which i "resolved" by cranking down the PCIe bus speed to
level "2".  this stopped devices disappearing off of the PCIe bus,
such as "the entire USB subsystem" or "the NVMe SSD".

i suspect that the Reference Design (supplied by intel to laptop
manufacturers) simply failed to provide sufficient power, and
consequently would cause devices to go unstable and drop off the PCIe
bus if they ran above a certain speed, draining a certain amount of
power.

here were the options i ended up using in grub.cfg:

 ro  apparmor=0 nouveau.blacklist=1
nvme_core.default_ps_max_latency_us=0 acpi_backlight=vendor
acpi_os_name="Windows 2015" acpi_osi=! noapic pcie_aspm=off
mem_sleep_default=deep

there may have been more.

l.


From lkcl at lkcl.net  Sat Nov 28 23:21:12 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 28 Nov 2020 23:21:12 +0000
Subject: [Arm-netbook] Somewhat off-topic updates about Ryzen, PolarFire,
 HiFive and Elbrus (was Re: Current status)
In-Reply-To: <CAPweEDzzD7KCBGwk6RizG0gyFLbTPw5u3Ma73B0mLHHMYR5LeA@mail.gmail.com>
References: <mailman.1.1595197284.6429.arm-netbook@lists.phcomp.co.uk>
	<20200720210214.79d4c075@Phenom-II-x6.niklas.com>
	<2034287.2zzArLbcde@jason> <2808268.lnS8WIl1fd@jason>
	<CAPweEDzzD7KCBGwk6RizG0gyFLbTPw5u3Ma73B0mLHHMYR5LeA@mail.gmail.com>
Message-ID: <CAPweEDzRrb3k=eCqVYtzGbEW5B89Zeo6ZUgHoG7tqqs01xnhDg@mail.gmail.com>

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="apparmor=0 nouveau.blacklist=1
nvme_core.default_ps_max_latency_us=0 acpi_backlight=vendor
acpi_os_name=\"Windows 2015\" acpi_osi=! noapic pcie_aspm=off
mem_sleep_default=deep"