arm64 support? When?

[Gene Heskett]

I can't find a stretch release for a rock64. Thats not an armhf, but an
arm64.

Cheers, Gene Heskett

[Paul Wise]

Post by Gene Heskett
I can't find a stretch release for a rock64.

The .dts for pine64 rock64 was added in Linux mainline in version
4.14, which is long after stretch, but there were stability fixes for
rock64 just 10 days ago (limiting the Ethernet to 100Mbit). If the
Linux kernel in stretch doesn't work with the rock64, you could try
the version from Debian backports.

[Gene Heskett]

Post by Paul Wise

Post by Gene Heskett
I can't find a stretch release for a rock64.

The .dts for pine64 rock64 was added in Linux mainline in version
4.14, which is long after stretch, but there were stability fixes for
rock64 just 10 days ago (limiting the Ethernet to 100Mbit). If the
Linux kernel in stretch doesn't work with the rock64, you could try
the version from Debian backports.

Why was that limited? Its a gigabit port now. It is running right now on
an ayufan build of Jessie. And I've a terabyte of spinning rust on its
usb3 port. I've built several realtime kernels on it so far, but not
tested since the Makefiles don't have a clue how to do an install on a
u-boot'er, and neither do I.

This is a pi killer for machine control, and once its all working I have
a home for a half dozen of them. ATM, spi, which I need, isn't working
at the speeds a broken hardware pi can do, I have one writing 32 bit
packets at 42 megabaud, and reading back the machines responses at 25
megabaud. But the pi has a pinhole path for other data i/o that throws
away keyboard and mouse events at an unacceptable rate. Its spi doesn't
suffer from that, working perfectly, so once the gcode is into its
memory, its works very well. Because of the keyboard/mouse interface
problems, getting it there however, can be a quite a chore.

Cheers, Gene Heskett

[Paul Wise]

Post by Gene Heskett
Why was that limited? Its a gigabit port now.

This is the commit that changed it:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc631943faba6fc3f755748091ada31798fb7d50

PS: here is how I found the commit:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git log -p -i --grep rock64
commit e1915c8195b38393005be9b74bfa6a3a367c83b3
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
commit f48f66a962a54c3d26d688c3df5441c9d1ba8730
...
And a second stopgap is limiting the speed of the gmac on the rk3328-rock64
to 100MBit. While the hardware can reach 1GBit, currently it is not stable.
Limiting it to 100MBit for the time being allows nfsroots to be used again
until the problem is identified.
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
...
commit bc631943faba6fc3f755748091ada31798fb7d50
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now

It looks like either the current kernel or the hardware has reliability
issues when the gmac is actually running at 1GBit. In my test-case
it is not able to boot on a nfsroot at this speed, as the system
will always lose the connection to the nfs-server during boot, before
reaching any login prompt and not recover from this.

So until this is solved, limit the speed to 100MBit as with this the
nfsroot survives stress tests like an apt-get upgrade without problems.
...
+ /* shows instability at 1GBit right now */
+ max-speed = <100>;

[Gene Heskett]

Post by Paul Wise

Post by Gene Heskett
Why was that limited? Its a gigabit port now.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/?id=bc631943faba6fc3f755748091ada31798fb7d50
$ git clone
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $
cd linux
$ git log -p -i --grep rock64
commit e1915c8195b38393005be9b74bfa6a3a367c83b3
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit
for now commit f48f66a962a54c3d26d688c3df5441c9d1ba8730
...
And a second stopgap is limiting the speed of the gmac on the
rk3328-rock64 to 100MBit. While the hardware can reach 1GBit,
currently it is not stable. Limiting it to 100MBit for the time being
allows nfsroots to be used again until the problem is identified.
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit
for now ...
commit bc631943faba6fc3f755748091ada31798fb7d50
...
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
It looks like either the current kernel or the hardware has
reliability issues when the gmac is actually running at 1GBit. In my
test-case it is not able to boot on a nfsroot at this speed, as the
system will always lose the connection to the nfs-server during boot,
before reaching any login prompt and not recover from this.
So until this is solved, limit the speed to 100MBit as with this
the nfsroot survives stress tests like an apt-get upgrade without
problems. ...
+ /* shows instability at 1GBit right now */
+ max-speed = <100>;

Which I think demo's why I haven't used any nfs shares, or cifs/samba for
that matter, in 3 or more years on any platform here at the coyote.den.

It never was "stable" for me.

While sshfs Just Works.

Cheers, Gene Heskett

[Gene Heskett]

Post by Gene Heskett
I can't find a stretch release for a rock64. Thats not an armhf, but
an arm64.

Is this relevant?
https://github.com/ayufan-rock64/linux-rootfs/releases

Yes, very. But his emphasis seems to be on media applications, which
means realtime kernels aren't very high on his list, and neither is
decent spi speeds. Questions that involve the u-boot process, asked on
their forum, have been uniformly ignored. So at the instant, its run
whats offered on his github pages by writing the image to a u-sd card.

Cheers, Gene Heskett