WIP: Add initial support for FriendlyARM Nanopi R2S

[igorpecovnik]

Second network attached to USB3 port doesn't come up. Needs further inspection @armbian/boards-rockchip

Weird / unneded FA patches included but they are most likely not needed since it also boots with Rock64 image, where 2nd net driver gets up ...

Closes AR-168

[piter75]

You beat me to it! 👍
I have it booting with u-boot v2020.01 but I temporarily used rk3399 family to achieve it ;p

most likely not needed since it also boots with Rock64 image, where 2nd net driver gets up

That's because USB3 PHY driver for RK3328 was already added to rockchip64-current by @Tonymac32.

Second network attached to USB3 port doesn't come up.

"usbdrd_dwc3" needs to be set in "host" mode - now it's "otg".

[igorpecovnik]

You beat me to it! +1

:)

I have it booting with u-boot v2020.01 but I temporarily used rk3399 family to achieve it ;p

DoD:

• move to 2020.01
• serial console on mUSB?
• patches cleanup
• adding to DEV branch too, while legacy 4.4 we don't need to mess with

Anything else?

You can pick some, otherwise I will beat you up :)

[piter75]

move to 2020.01

I would extract it to separate PR even though your current solution steals half of RAM in between DDR loader and u-boot :) I have 1GiB with u-boot v2020.01.
Now that I have at least one RK3328 board I can get back to moving rockchip64 to v2020.01

serial console on mUSB?

on microUSB? I may be wrong but I think it will be mostly used to power up the board so I think we can do it in later as a cherry on top ;)

while legacy 4.4 we don't need to mess with

I was pleasantly surprised to see FA base their BSP on v5.4.

I would definitely add this commit to patches. Without it kernel console is flood with some phase change logs from mmc0 and block read/write errors.

With this I think we can merge it and refine with following PRs from there.

The other issue I have found in both your and my builds is eth0 (rl8211e) instability. Trying to transmit a few times with iperf3 should reveal it - either lower than expected speeds or connection reset by peer.
I did not find the culprit yet - it works reliably with FA image though.

[igorpecovnik]

on microUSB? I may be wrong but I think it will be mostly used to power up the board so I think we can do it in later as a cherry on top ;)

Yes, gadget_serial. Most of those small boards (Neo, Zero, ...) have console enabled by default. In case you power the board via computer, serial console pops up automatically ... its convenient feature.

I was pleasantly surprised to see FA base their BSP on v5.4.

Indeed. Why is that DDR timings in the kernel?

I would definitely add this commit to patches. Without it kernel console is flood with some phase change logs from mmc0 and block read/write errors.

OK, missed that.

The other issue I have found in both your and my builds is eth0 (rl8211e) instability. Trying to transmit a few times with iperf3 should reveal it - either lower than expected speeds or connection reset by peer.
I did not find the culprit yet - it works reliably with FA image though.

Didn't get this far. I'll try to narrow it down when possible.

[igorpecovnik]

I made few more tests, kernel randomly doesn't find boot device ... with that patch or without.

I will stop here. Have to focus on remaining bugs for the release.

The other issue I have found in both your and my builds is eth0 (rl8211e) instability.

To me it happens on both devices.

[piter75]

Yes, gadget_serial ... its convenient feature.

I am convinced ;-) Never thought about it that way.

Indeed. Why is that DDR timings in the kernel?

This is a little shiny gem :) As far as I understand rk3328 boots with DDR4 RAM clocked to 333MHz and is probably supposed to be reclocked as needed later. In mainline there is no support for that and that's why issues like #1744 are reported for Renegade.

This friendlyarm/kernel-rockchip@fcd9629 and few others add support for rk3328-dmc in mainline and RAM can be reclocked up to 1056MHz which makes it really fast again.
These are my sbc-bench results with the said patches: http://ix.io/2bme

I thought about bringing it in a separate PR with some more testing from Tony.

I made few more tests, kernel randomly doesn't find boot device

I don't remember having any issues with that. Even without the patch it booted, much slower but it did boot eventually.

The other issue I have found in both your and my builds is eth0 (rl8211e) instability.

To me it happens on both devices.

I did test it on rl8153b device only a few times so I it was not exhaustive.
They must have done some tweaking which we did not find yet... ;-)

[piter75]

I was able to move it a bit further and added:

• rk3328 memory DMC driver
• USB serial gadget (copied relevant kernel configs from sunxi64) - verified for working with macOS as a client
• SD phase fix

As a next step I plan to test again and try to fix network performance issues.

[igorpecovnik]

Great!

Further changes will probably be small in term of code. Perhaps we merge this in? Anyway board is a WIP target and it should not break anything.

[piter75]

The only thing I am worried a bit in this branch is the SD phase fix as it applies to all rk3328 boards.

@igorpecovnik could you possibly build an image for Rock64 (I suppose you own one) and verify if it boots before we merge it?

[igorpecovnik]

could you possibly build an image for Rock64 (I suppose you own one) and verify if it boots before we merge it?

Verified on V2 and V3

[igorpecovnik]

As a next step I plan to test again and try to fix network performance issues.

Network manager bug. It would probably be best to add:

auto eth0
	iface eth0 inet dhcp
auto lan0
	iface eth0 inet dhcp

to /etc/network/interfaces and we are done. Further network config is anyway users task.

But I have found another nasty bug. Reboot = linux doesn't find rootfs, while powercycle have no troubles.

[piter75]

As a next step I plan to test again and try to fix network performance issues.

I verified once again tonight and I see no performance issues with both interfaces - steady 941mbps in both directions on both.
I did not have to modify /etc/network/interfaces.

Reboot = linux doesn't find rootfs, while powercycle have no troubles.

Does it log something regarding the sdmmc?
I rebooted lots of times today and had no single issue with it.

[igorpecovnik]

I rebooted lots of times today and had no single issue with it.

Oh? Strange. I have tried 10+ times to reproduce to show you the log ... and I can't. Now, that's even stranger :) And network is also working as expected. With Network manager.

http://ix.io/2dUC

Remaining strange thing is that journal is filling /var/log