FriendlyELEC-Forum

Can you point me to forks that support NanoPi R2S?

Does NanoPi R2S require uboot?

because the R2S is supported by armbian you could use the armbian-build-system to generate u-boot and linux for the R2S:
https://docs.armbian.com/Developer-Guid ... eparation/

guidol wrote:
because the R2S is supported by armbian you could use the armbian-build-system to generate u-boot and linux for the R2S:
https://docs.armbian.com/Developer-Guid ... eparation/

I'd like to figure out the recipes. I tried to decode armbian before and failed. armbian is a complex beast.

crocket wrote:
armbian is a complex beast.

Things are far more complex Armbian kills great portion of that complexity and I agree it could be done more.

igorp wrote:

crocket wrote:
armbian is a complex beast.

Things are far more complex Armbian kills great portion of that complexity and I agree it could be done more.

I remember you from radxa forum.

I figured out that https://github.com/friendlyarm/sd-fuse_rk3328 is the recipe for nanopi r2s and nanopi neo3.

Is NanoPi R2s going to be soon supported by mainline linux and mainline u-boot?

crocket wrote:
Is NanoPi R2s going to be soon supported by mainline linux and mainline u-boot?

For that you will have to look elsewhere.

... Armbian runs improved mainline u-boot / kernel combo

igorp wrote:

crocket wrote:
Is NanoPi R2s going to be soon supported by mainline linux and mainline u-boot?

For that you will have to look elsewhere.

... Armbian runs improved mainline u-boot / kernel combo

1. I use either gentoo or artix linux.
2. Analyzing armbian is difficult.

Are you saying that NanoPi R2S is not going to get mainline support from linux and u-boot?

crocket wrote:
I use either gentoo or artix linux.

In ARM single board computers you have to forget about the "luxury" of distro hopping.

Analyzing armbian is difficult.

Analysing RAW material, the source of that, is more complicated. That's what I am trying to tell you. Difference between Gentoo and Armbian/Debian is nothing compare to this.

crocket wrote:
Are you saying that NanoPi R2S is not going to get mainline support from linux and u-boot?

No, but that takes time and when mainline support finally arrives, you will probably need to fix this and that on your own. That's how mainline support looks like. It stays in rough state. We have this know-how, generic distros doesn't have it.

To me, https://github.com/friendlyarm/sd-fuse_rk3328 seems more digestible than armbian. Armbian is a huge codebase.
Understanding a huge code base is more difficult than reading documents.
If I combine https://github.com/friendlyarm/sd-fuse_rk3328 with RK3328 documents on rockchip wiki, I will be able to reverse-engineer the steps.

Even Raspberry Pi 4 doesn't have perfect mainline support, so I know what you mean by mainline support.

Perhaps, are we being exploited as experiment subjects by ARM?
Using ARM SBCs feels like fighting an up-hill battle for ARM.

My money goes to a decent single board computer that doesn't require device trees.

crocket wrote:
To me, https://github.com/friendlyarm/sd-fuse_rk3328 seems more digestible than armbian. Armbian is a huge codebase.
Understanding a huge code base is more difficult than reading documents.

That code base is preparing things to compile u-boot. With Armbian you run ./compile "u-boot" and it prepares you environment and compiles u-boot. In any cases you didn't learn much unless you will be digging deeper into the u-boot. Armbian is a build tool, that saves you steps, time wasted for banal reasons that are subject of that wiki.

crocket wrote:
Perhaps, are we being exploited as experiment subjects by ARM?

ARM is about diversity, making custom computer for specific purpose. Don't compare this to x86 mainstream. Even Rpi is 1st proprietary video player by design, then something else ... a popular consumer / hobby all purpose device.

crocket wrote:
My money goes to a decent single board computer that doesn't require device trees.

Does'n exits

I think you are biased toward armbian. I want to figure out the exact steps without using third party tools.
I have been doing so on x86 computers. I don't want to be reliant on armbian to bootstrap another linux distribution.

I think single board computer manufacturers should provide build steps for linux and u-boot in addition to build scripts because build steps free users from specific distros and specific build tools.

Lots of people would want to use their preferred linux distributions.

Compared to the amount of efforts involved in documenting every little part of raspberry pi products, documenting build steps shouldn't be expensive. Build steps are short in my experiences.

https://wiki.odroid.com/odroid-c4/software is a good example of such documentation.

https://forum.radxa.com/t/is-rock-pi-x- ... -tree/4553 says Rock Pi X is an x86_64 single board computer that comes with UEFI and does not require device tree.

It will be interesting to explore x86 single board computers.

Is UEFI possible on ARM single board computers, too?

crocket wrote:
I think you are biased toward armbian. I want to figure out the exact steps without using third party tools

Yes I am biased, but I am showing you the fastest track to build and learn.

crocket wrote:
I have been doing so on x86 computers. I don't want to be reliant on armbian to bootstrap another linux distribution.

Armbian is a build system with huge knowledge base about ARM single board computers. Its Linux distribution is a demonstration, a side product of its capabilities.

You can find countless examples as such:
"Armbian are great, e.g. alpinelinux wiki uses Armbian build system in instructions to build alpinelinux for orangepi"

Clearly noticeable to me since you don't understand what I am trying to tell you. ARM single board computers are not simple x86 mainstream - each ARM family is basically new architecture. RPi with "1000x larger community backing" then other chips is only close to that, even its a strange proprietary device.

crocket wrote:
I think single board computer manufacturers should provide build steps for linux and u-boot in addition to build scripts because build steps free users from specific distros and specific build tools.

They do - they provide minimum required, but most Linux distributions are unable to pick from that, maintain that or bring to higher levels. The thing you are knowing as "various Linux distro" is the cheapest, the non-important part of the equation. Armbian, which uses Debian as a base, it could pick up Gentoo, Arch or whatever combination of scripting, DE, ... and would still stands out.

crocket wrote:
Lots of people would want to use their preferred linux distributions.

For that you need standards. In diverse world where most of the devices will never be able to allocate resources needed to join them?

Also Armbian directly or indirectly support many of them - since we do the base work, things x86 people takes as granted, but they nor you support the project base development https://docs.armbian.com/#what-is-armbian that invests in common good. Most of Linux distros only change wallpapers and brand. Most contribute little to nothing to the thinks you are looking for.

crocket wrote:
Compared to the amount of efforts involved in documenting every little part of raspberry pi products, documenting build steps shouldn't be expensive. Build steps are short in my experiences.

95% of Rpi documentation is made by community, created or copy / pasted. Rpi is closed device and they (community) had to reverse engineer first, then write documentation. Here, you at least don't need to do that.

crocket wrote:
https://wiki.odroid.com/odroid-c4/software is a good example of such documentation.

Better, agree. But not much further.

crocket wrote:
https://forum.radxa.com/t/is-rock-pi-x-going-to-require-device-tree/4553 says Rock Pi X is an x86_64 single board computer that comes with UEFI and does not require device tree. It will be interesting to explore x86 single board computers.

Got few around and no idea what to do with them. UEFI aka BIOS aka U-boot (aka low level programming) - if you are mentioning its not fully stable and since we don't cover UEFI nor x86, there is little to poke around that ATM.

crocket wrote:
Is UEFI possible on ARM single board computers, too?

Ofc, but bringing up is expensive. Someone has to make that UEFI for new hardware platform. Otherwise you have to work out with u-boot the dirty way or move up at least to Armbian to be less messy.

It took several years to develop UEFI for RPi (not sure if only by community) and that work can't be used for any other ARM board. https://www.cnx-software.com/2020/02/18 ... compliant/

If you throw "1 mio EUR" into our project per year, we will hire few people to start developing UEFI for boards you want to have it on. But there are many other companies that will provide the same. Just look around.

igorp wrote:
If you throw "1 mio EUR" into our project per year, we will hire few people to start developing UEFI for boards you want to have it on. But there are many other companies that will provide the same. Just look around.

I thought you were working for radxa. Are you now working for friendlyarm?

If I could spare a million euro per year, I would look into a standard open-source re-useable boot interface that every ARM single board computer can easily reuse.

I think it's time for standardization of the boot process on ARM platform.

For each company to reinvent the wheel is wasteful.

I see multiple angles of approach.

• Document generalized build steps, and put them where users can easily find. Make them easy to understand. (The cheapest)
  
  • It seems companies focus on supporting a few specific distros rather than documenting build steps well.
• x86 single board computers
• Work on standardization of the boot process on ARM platform (Long-term solution)
  
  • If you don't have to worry about device tree, you can easily install windows, mac os, linux, bsd, etc, ...
• Is UEFI reuseable on RISC-V single board computers?
• ...

crocket wrote:
If I could spare a million euro per year, I would look into a standard open-source re-useable boot interface that every ARM single board computer can easily reuse.

Even you have a million you can't purchase things that does not exists, right?

And if everything is working for you, you will not spent not even one cent Its free software, right?

crocket wrote:
I think it's time for standardization of the boot process on ARM platform.

Agree, but you seems to not understand the problem at all. If this would be cheap, it would be done many years ago.

Normally those devices software support is just good enough to cover single function.

crocket wrote:
UEFI reuseable on RISC-V single board computers?

UEFI on Rpi or whatever device is not reusable on any other device except a few cheap generic segments. And you need to maintain that code. To be able to maintain it, you have to understand how things works.

P.S.
I don't work for any of those companies.

I guess that leaves the choice of documenting build steps well.

It seems weird to me that manufacturers focus on supporting a few specific distros instead of documenting build steps well.

If you document build steps well, distributions will support your board and users will follow the steps.

Instead of focusing time and money on FriendlyWrt, I would focus on documenting build steps. SBC manufacturers should present index to well-documented build steps on their wiki pages.

crocket wrote:
If you document build steps well, distributions will support your board

Non-commercial distros that have big enough base already do the best they can while commercial, the majority, ... Canonical has a price list per hardware, also with Manjaro you can clearly see that they only support those who pay (look their twitter) ... and so on. Plus it has to be perfectly functional otherwise they don't "support".

FA is providing FriendlyWRT as a POC example of usage for this board. You have to promote what your hardware do best, what was it designed for. Remember those boards usually serve one/limited purpose(s). I don't see this as a waste. Its a concept, not a fully blown supported OS which costs magnitude more.

Ain't simple.

I don't want to rely on distribution support which is not scalable to all hardwares.
Users should be able to find and follow build steps. Right now, documentation is sketchy.

I prefer user-level DIY.

crocket wrote:
I don't want to rely on distribution support which is not scalable to all hardwares.

Armbian is a build system: https://github.com/armbian/build#compar ... -standards and on a hardware which it covers usually your best option. Somewhere your only. Others option will cost you more.

Armbian is 100% Debian compatible and Debian (and its derivatives) is by far most used operating system and that means fully scalable to any hardware out there.

crocket wrote:
Users should be able to find and follow build steps. Right now, documentation is sketchy.

Agree, but its free and you don't need to reverse engineer to make it work.

crocket wrote:
I prefer user-level DIY.

Then you will need to stick to Raspberry Pi.

I don't need to stick to Raspberry Pi.

I think reverse-engineering build steps for NanoPi R2S isn't going to be too much work for me.

But, it's going to be too much work for most people who don't even know about single board computers.

It's just a big enough hassle that makes me want to explore alternatives like Rock Pi X. It can be done, but I wouldn't do it if there are simpler ways.

I don't like Raspberry Pi much after experiencing strong censorship on official raspberry pi forum and the mindset behind Raspberry Pi support staff. Their attitude reminds me of corporations such as Red Hat that want to own people. Even if Raspberry Pi is very good, I wouldn't buy it unless I have no other options.

If you compare single board computers from other manufacturers with Raspberry Pi, your thread can be quickly closed on official raspberry pi forum by Raspberry Pi support team. They hate competition. I don't support corporations that are hostile to freedom of choice.

crocket wrote:
But, it's going to be too much work for most people who don't even know about single board computers.

It depends. SBC can be from purchasing chip and make a custom PCB around .... some purchases x86 ready to run device ... to do their stuff.

crocket wrote:
It's just a big enough hassle that makes me want to explore alternatives like Rock Pi X. It can be done, but I wouldn't do it if there are simpler ways.

Don't know what you plan to use it for but I would not call that as an alternative since its completely different device. By design and also architecture. Also rockpi X still need some fine tuning to run OS stable. Its not plug and play even it might look that way. (even my Ryzen 9 desktop has some troubles with Linux, but I am sure they will be soon gone)

crocket wrote:
I don't like Raspberry Pi much after experiencing strong censorship on official raspberry pi forum and the mindset behind Raspberry Pi support staff. Their attitude reminds me of corporations such as Red Hat that want to own people. Even if Raspberry Pi is very good, I wouldn't buy it unless I have no other options.

If you compare single board computers from other manufacturers with Raspberry Pi, your thread can be quickly closed on official raspberry pi forum by Raspberry Pi support team. They hate competition. I don't support corporations that are hostile to freedom of choice.

100% agree with this, but this is the only device where you plug and play and don't need to use much brain to operate with. They rely on (brainless by definition) consumers to sell stuff ...

You can plug a USB 3 gigabit ethernet adaptor into Rock Pi X or other single board computers with a USB 3 port.

NanoPi R2S just makes it physically more reliable and cleaner by not allowing users to detach the USB 3 ethernet adaptor.