Debian Builds for Orange Pi Win in the pipeline?

[xnyle]

Hi there,

 

I noticed there are up to date builds for Pine64 for Debian and also up to date ones for Ubuntu for the Orange Pi Win.

But none for Debian and Orange Pi Win, newest ones are from November probably with legacy kernel?

Is this just some kind of build script hiccup?

If not, do you have an idea about a timeframe for new Debian builds? (I'd rather not use Ubuntu if it's just a few days/weeks I'd have to wait for Debian.)

[Igor]

Nightly buildings are disabled since they are broken for A64 at this moment so it's pointless to make them. Use recommended builds at the download page. They are "recommended " for a reason.

 

We don't provide Debian Stretch with older kernel because it lacks needed functionality, while Debian Jessie ... is a bit old and it's better to use an Ubuntu-based image. In any case, there is not any of Ubuntu junk on them.

 

Stable kernel 4.y is months away.

[xnyle]

Thanks, my concern about ubuntu is (beside the junk) that there is no rolling release version like debian testing. So every 6 months I either have to reinstall everything, of face certain chaos when trying to upgrading ubuntu... At least that was the state of Ubuntu on ARM when I stopped using it a few years ago.

 

Anyway, seems I'm out of options here with that particular Orange board ;-)

[guidol]

On 1.2.2018 at 9:21 AM, Igor said:

We don't provide Debian Stretch with older kernel because it lacks needed functionality, while Debian Jessie ... is a bit old and it's better to use an Ubuntu-based image. In any case, there is not any of Ubuntu junk on them.

So there should no difference in functionality on a OPi One with mainline-kernel and debian stretch against the ubtuntu version? 

Because I do prefer pure debian against ubuntu. 

And whats the difference between debian and ubuntu, when armbian ubuntu hasnt the "ubuntu junk"? 

Isnt normally ubuntu build on debian (as a "fork")? 

 

[Igor]

 

1 hour ago, guidol said:

And whats the difference between debian and ubuntu

Ubuntu is Debian based, but the main difference is packages selection and their versions. Since we also define the package base, most of the packages are the same but they are certainly not the same version. This means certain application might not work out of the box and you need to solve dependencies on your own. This can be simple or a true nightmare. In this case, it's better to start with a proper base, whether Ubuntu or Debian. One good example is OMV - it does not work at all on Ubuntu - at least not out of the box. Stable version requires Debian Jessie, while current development is based on Stretch. For a board, which might be used as OMV (Helios4), we provide both, Jessie and Stretch and it's up to the user to decide which OMV version he will go for.

 

In the x86 world, a change between releases/distribution is usually also on a kernel branch, while here we don't have this luxury. We have to use what is available and since there is no better working kernel than 3.10.y for this board we simply can't provide Stretch. We could Jessie ... but since we provide a simple and easy to use build tools, this is not that urgent either.

[xnyle]

Just for clarification:

 

Is this build broken, or does it boot?

 

Debian_stretch_next_nightly.7z2017-11-05 10:07

 

All I need for that board is proper USB storage and Ethernet support.

 

They are "recommended " for a reason.

The reason is always derived from a biased point of view. If I don't need the parts that are not working, I don't really care.

[Igor]

2 hours ago, xnyle said:

Just for clarification:

 

Is this build broken, or does it boot?

 

Those "nightly" are automated builds, currently, on hold since we know its pointless to make them. Absolutely no idea if those old ones boot at all. They are made for developers and those who wanna try how far things are ...   

[xnyle]

Well it doesn't even boot, so had to use Ubuntu.

 

But something is not right, or this board is awsome performance-wise.

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=32 run

7 seconds? seriously? there has to be a hack somewhere?

RPI 3 needs 220 seconds.

[guidol]

19 minutes ago, xnyle said:

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=32 run

7 seconds? seriously? there has to be a hack somewhere?

RPI 3 needs 220 seconds.

Hmm that remind me of a test of the rock64 - where the rock64 is also much much faster in such a test:
take a look at minute 11:30
BTW: I like this YouTube Channel : "Explaining Computers" - much SBC-Tests

 

[Calaf]

1 hour ago, xnyle said:

Well it doesn't even boot,

As far as I remember, some paths were not correct (I don't remember which ones). You can see this by using a UART console. If you put the right files at the right place, it can boot flawlessly.

Unfortunately I deleted the image and I can't tell you what I changed.

It worked fine, except Bluetooth and several options like VLAN.  

[xnyle]

Thanks, but I guess "UART console" is a bit beyond my knowledge/equipment level. I'll stick with Ubuntu for the next months and then reinstall Debian.

[martinayotte]

On 2/2/2018 at 5:40 PM, xnyle said:

but I guess "UART console" is a bit beyond my knowledge/equipment level.

Incredible !

As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!

Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...

 

[xnyle]

I don't want to  play with it, i just use it.

 

I own a USB-TTL-Serial USB dongle, although without the wiki I wouldn't exactly have known what to do with it.

 

"Incredible" though is that you assume everyone always has as a workbench full of electronic equipment ready to go.

 

I'm happy there are kernel hackers out there who get those boards running, but I guess I'm not happy with their attitude towards "normal" users sometimes...

[Igor]

This is far from kernel hacking or any serious involvement in electronics - it is only a serial console, 3 wires connected to board and USB to your desktop computer. This basic (debug) tool is sometimes the only way to proceed on boards without HDMI and a network. "Normal" users do accept advice and we just try to help them the best way we know.

[tkaiser]

On 2.2.2018 at 8:00 PM, xnyle said:

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=32 run

7 seconds? seriously? there has to be a hack somewhere?

RPI 3 needs 220 seconds.

 

You have been fooled three times

1. the RPi uses the most crappy way to be powered (Micro USB), your board is undervolted (input voltage dropped below 4.63V) and therefore frequency capping happened. While you think you run a board capable of 1200 MHz the RPi 'firmware' decreased the CPU clockspeeds and you run at 600 MHz. If you replace your PSU and/or cable between PSU and board your RPi 3 will need 110 seconds when you repeat the test
2. the RPi 3 when used with an incapable distro (Raspbian or DietPi for example) can not show its full potential. The RPi 3 has an ARMv8 SoC but with those strange distros it has to run ARMv6 code. As soon as you switch to a better distro your RPi 3 will finish the same sysbench 'benchmark' in 7 seconds
3. sysbench is not a general purpose benchmark but a bad joke. It can not be used for any architecture comparisons since it's only a compiler benchmark and it's impossible to benchmark the hardware with it. Depending on which distro you use the 'performance' can vary by 15 times as you already observed. Sysbench is only used by clueless people or marketing guys

BTW: you're not alone. The majority of RPi 3 boards doing heavy stuff runs frequency capped (that's the nice thing with Raspberries. As soon as you would need the CPU power it clocks down to 600 MHz). Some more details: https://github.com/bamarni/pi64/issues/4

 

[xnyle]

1 hour ago, Igor said:

 "Normal" users do accept advice and we just try to help them the best way we know.

 

I'm not sure, if I give advise I usually don't start with "Incredible !".

 

Regarding sysbench, thanks, especially the raspberry power part. Up to now I thought I had a solid PSU.

[guidol]

10 hours ago, tkaiser said:

the RPi 3 when used with an incapable distro (Raspbian or DietPi for example) can not show its full potential. The RPi 3 has an ARMv8 SoC but with those strange distros it has to run ARMv6 code. As soon as you switch to a better distro your RPi 3 will finish the same sysbench 'benchmark' in 7 seconds

and whats the name of the better speedy ARMv8 distribution?

 

 

[tkaiser]

13 minutes ago, guidol said:

whats the name of the better speedy ARMv8 distribution?

 

I put a link in my post and why should this matter especially here? If you open your webbrowser, open google, then enter '64 bit dist' it will be already autocompleted to '64 bit distro for raspberry pi 3'. My post was about sysbench being unreliable crap and boards that are powered via Micro USB easily behaving like unreliable crap with users in front having not the slightest idea about the problem at all (that's why we shouldn't support such design fails).

 

Wrt 'sysbench': to get more details why this is such a lousy anti benchmark it's easy since this has been discussed in detail many times. This forum has two search functionalities. The internal (that as usual only produces misses and irrelevant hits) and 'Google site search' which works reasonably well even when queried just for 'sysbench'.

[guidol]

6 minutes ago, tkaiser said:

I put a link in my post and why should this matter especially here? If you open your webbrowser, open google, then enter '64 bit dist' it will be already autocompleted to '64 bit distro for raspberry pi 3'.

OK - after using google that the github link is about this 64bit os (bamarni).

but before using google I didnt know that OS-name and did see only your report about sysbench.

While using Google - the second 64bit OS for the RPi3 is Open Suse Leap 42.2

[tkaiser]

12 minutes ago, guidol said:

the second 64bit OS for the RPi3 is Open Suse Leap 42.2

 

No, there are a lot more but all of this doesn't really matter especially here in this forum. And the whole issue (people using this crappy tool called sysbench trying to benchmark hardware) is not even related to 32-bit vs. 64-bit but different compiler switches. Raspbian packages are built for the ARMv6 ISA so they can be executed on the horribly outdated single core RPis as well. Normal Debian/Ubuntu armhf packages are built for ARMv7 and you would need to switch to arm64 packages since only these packages are built with support for ARMv8 CPU cores (that's what's inside RPI 3 and 2 in the meantime).

 

So comparing an OPi Win running an arm64 Ubuntu or Debian distro with an RPi 3 running any recent Arch, Gentoo, Fedora, OpenSuSE or even an arm64 Armbian (see my link -- I did this) you will see sysbench numbers that are pretty close. Numbers between the different distros will vary since the distro packages are built with different compiler versions and switches. And this is all the lousy sysbench tool in 'cpu test' mode is able to report since this whole test is just calculating prime numbers inside the CPU caches (and as soon as an ARMv8 CPU is allowed to run ARMv8 code this gets magnitudes faster). I don't know of a single real-world use case that would correlate with this pseudo benchmark (except of course if your job is calculating prime numbers, then you can rely on sysbench and if you're running on a RPi 3 should better stay away from Raspbian, DietPi and the other ARMv6 dinosaurs)

 

But while sysbench is wrongly reporting an RPi 3 (or an OPi Win if you choose Xunlong's Raspbian images!) would be magnitudes slower than any of the recent ARMv8 boards with one specific workload the RPi 3 is really magnitudes slower (AES encryption -- think about VPN and disk encryption). Broadcom forgot to license ARMv8 crypto extensions so any other 64-bit (ARMv8) SBC is a better choice than RPi 3 if it's about AES (except ODROID-C2 and NanoPi K2 since their Amlogic S905 suffers from the same problem). See the numbers here: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 (OPi Win scores the same as Pinebook)

 

[martinayotte]

16 hours ago, xnyle said:

I'm not sure, if I give advise I usually don't start with "Incredible !".

It is incredible simply because googling the words "UART console" would have reveal tons of hints along with the link I've provided ...

 

[chwe]

On 4.2.2018 at 8:05 PM, xnyle said:

I don't want to  play with it, i just use it.

If you don't want to 'play with it', I suggest you go for the images which are labeled 'stable'. 

On 4.2.2018 at 8:05 PM, xnyle said:

I'm happy there are kernel hackers out there who get those boards running, but I guess I'm not happy with their attitude towards "normal" users sometimes...

I'm neither a 'kernel hacker'... But as a 'normal user' you should read the 'user manual', where the serial debug is described. Imagine you spend quite a lot of your spare time in bringing up such a device, you recommend the users a specific build and as a result the users complain about the attitude...

I agree that the tone in the whole Linux community is sometimes a bit harsh, it's well documented when Linus Torvalds 'rage out' on the mailing list...  But I understand that Devs are frustrated when they spend their spare-time, making recommendations what you should use and cause you're not happy with the provided images you complain about it. 

Is the situation perfect for your board? For sure not, but besides this board there are ~50 others SBCs to maintain, armbian depends on upstream, if a recent kernel, uboot or driver for *random feature* etc. is not ready, there's not much possible to improve this situation. 

Whereas in X86 world a lot of hardwaremakers show interest to bring their device up and running on Linux (for sure more than years ago), on 'ARM-world' this is slightly different, most of the SoCs used are made for Android use-cases. Software development for those chips is somehow 'fire and forget', means SoC maker isn't that much interested in maintaining it after it runs, every recent kernel for them is provided by those 'kernel hackers'. So, from my perspective there are four possibilities for you. You go for an older/better supported SoC (e.g. H3 where the support from the community is good or SoCs which are made for Linux and SoC maker cares about upstream),  you use the recommended Images, you accept the sometimes a bit harsh tone or you do your homework, means that you read as much as you can/need to solve images on your own. 

IMHO images besides 'stable' is for people who can live with problems, who have fun to solve problems and don't struggle with the basics. This step isn't an easy step but you have an active community here which tries the best to help you - sometimes they're a bit harsh, but in general they're helpful and try their best to help you.   

[xnyle]

Agreed to everything.

 

Thing is, I didn't complain about anything. I just asked if the build is working because I don't like Ubuntu. It isn't, I can't use it then, no problem. Someone gave a useful hint about debugging it, I basically said I don't want to do that because of knowledge (or better time) constraints, and THEN someone starts to rant for no reason. And it just goes on from there.

 

But Ok, happens if ppl read between the lines. I think we could close this topic as it went way off .. that topic.