Power & Source of Big Ideas

64-bit NanoPi M3 image

Moderators: chensy, FATechsupport

I am surprised. I bought a board with 64 - bit processor. I was looking for in the images linux ( debian ) in the minimum configuration with the 64 -bit kernel. And...nothing (!) ??
OK, there is a possibility of generating your own kernel . But ... where a jet version of 64 -bit ?? !!
...
...anyone here ?
Does not the link https://www.mediafire.com/folder/gg764iwvfm0mf/NanoPC-T3_Boardon the Wiki page work for you?:
@davef

Can you see anywhere 64-bit image?
Or show me where in the " Wiki Page " is - how to create 64-bit image?
I hope it is known to you that S5P6818 is a 64-bit CPU ?
I assumed that all the images at that page were suitable for the NanoPC-T3. Seems there are many download events. How can you tell whether or not they are 64 bit without trying to run them?

Does not the section "Make Your Own OS Image" help you to make your own 64bit images?
No comment.....
Read first ... then write something to talk sense to me ....
Ah, now I see "jet" must be some key word that I am not familiar with.
@FATechsupport

Nothing to say?
see below ....
Hi we don't have a 64-image yet. We wish we could release a 64-bit image in a couple of months. Samsung currently doesn't support a 64-bit image.
Hello,

I have just been in e-mail contact with an employee of Nexell/Zhongwei Semi. While they can only provide technical support to companies that have signed a NDA with them (such as FriendlyARM has), he was so kind as to provide some general information on the status of 64-bit support for S5P6818 from Nexell's point of view.

He said the following:
  • There will be a 64-bit based linux kernel on S5P6818 and the kernel version will be 3.18 or up. But when will it be released, we don't know exactly. It's under developing. The schedule is at the end of 2016 the 64-bit kernel will be released.
  • When this kernel is released, FriendlyARM will get it and then you can ask them for it.
This is great news, as it will open up the complete 64-bit world of ARMv8 aarch64 (arm64) for S5P6818! :D

So my follow-up questions now goes to FriendlyARM / @FATechsupport:
  1. Can you confirm that, once Nexell provides the 64-bit Linux kernel for S5P6818, you will also provide an adapted version with appropriate device drivers (both kernel source and binary distribution) of this 64-bit kernel that will run on NanoPi-M3/NanoPC-T3? ;)
  2. In the meantime, is there any chance to use the existing FriendlyARM toolchain based on gcc 4.9.3 (as described in the NanoPC-T3 product wiki) to rebuild the existing 3.4.y kernel on github in a way that uses armv8 on aarch32 (such as e.g. "--with-arch=armv8-a --with-tune=cortex-a53 --with-fpu=vfpv3 --with-float=hard")? :?:
Many thanks in advance for your kind help!
awl
Hi thank you for your attention.
Once we get this support we will arrange its development but we cannot say it for sure exactly we will be able to release it since it depends on various factors
As for the toolchain we will decide that after we get the new kernel
Many thanks for the quick reply! :)

Sorry - two follow-up questions to clarify:
Once we get this support we will arrange its development but we cannot say it for sure exactly we will be able to release it since it depends on various factors
Unfortunately, one very important word is missing here: Do you mean when or whether- i.e.

"we cannot say it for sure exactly when we will be able to release it since it depends on various factors" or
"we cannot say it for sure exactly whether we will be able to release it since it depends on various factors"?

Please confirm! ;)

And regarding the toolchain: My question was not about the toolchain to be used for the upcoming 64-bits kernel, but I rather wondered whether it might be possible to compile the existing 32-bits kernel (3.4.y) for arch=armv8-a tune=cortex-a53 (i.e. armv8 aarch32) instead of arch=armv7-a tune=cortex-a9 (which has been used for the current kernel)?

Thanks a million one more time!
awl
@FATechsupport:

Please confirm that you meant to say "when" (and not "whether") here:

awl29 wrote:
Do you mean when or whether- i.e.

"we cannot say it for sure exactly when we will be able to release it since it depends on various factors" or
"we cannot say it for sure exactly whether we will be able to release it since it depends on various factors"?
You need to make sure that 64-bit support for NanoPi-M3/NanoPC-T3 is only a question of time, but not a question of whether at all...

Many thanks!
Hello @FATechsupport,

would you please finally answer my question:

Did you mean you cannot confirm "when" or "whether" you will provide a 64-bit kernel for NanoPi-M3/NanoPC-T3 after Nexell's generic 64-bit kernel for S5P6818 has arrived at the end of this year?
While it is clear that "when", i.e. a concrete deadline, cannot be stated at this time, in case your message was that you cannot confirm "whether" (i.e. whether at all) you will provide a 64-bit kernel for your S5P6818-based SoCs next year would make me refrain from any substantial plans with these products.

So please clarify one more time - many thanks in advance! ;)

Best regards
awl
Final attempt for a friendly reminder to FriendlyARM / @FATechsupport:

Could you please be so kind as to clarify/confirm that providing a 64-bit kernel for NanoPi-M3/NanoPC-T3 (S5P6818) will only be a matter of "when" in 2017, i.e. the exact timeline for it is not yet fixed, and not a matter of "whether" at all you will provide the 64-bits kernel...

Wondering why this should be so difficult to confirm!? ;)

Many thanks!
awl
awl29 wrote:
Could you please be so kind as to clarify/confirm that providing a 64-bit kernel for NanoPi-M3/NanoPC-T3 (S5P6818) will only be a matter of "when" in 2017, i.e. the exact timeline for it is not yet fixed, and not a matter of "whether" at all you will provide the 64-bits kernel...l
Just out of curiosity, do you have any benchmark results showing whether the Cortex-A53 core is faster or slower in 64-bit mode? As I'm interested in using these boards for teaching numerical methods with a focus on high performance computing and parallel processing, it would be great to know how 64-bit mode compares to the 32-bit mode. My understanding is that the quad-issue quad-core NEON FPU unit is available and performs about the same in either mode, but there may be other considerations.
Hello,

ejolson wrote:
Just out of curiosity, do you have any benchmark results showing whether the Cortex-A53 core is faster or slower in 64-bit mode? As I'm interested in using these boards for teaching numerical methods with a focus on high performance computing and parallel processing, it would be great to know how 64-bit mode compares to the 32-bit mode. My understanding is that the quad-issue quad-core NEON FPU unit is available and performs about the same in either mode, but there may be other considerations.
while you may be right about the fact that there is no basic difference in how Cortex-A53 performs in 32-bit vs. 64-bit mode, the real issue is inherent support for the ARMv8-A architecture/instruction set in any 64-bit kernel and 64-bit userland apps (Linux distribution), while the instruction set for the existing 32-bits kernel 3.4.y as well as the Linux distributions available for S5P6818 is still armv7l (32-bit ARMv7 compatibility mode), so neither the current kernel nor userland code can leverage any of the new features of ARMv8 architecture (regardless whether in 32-bit or 64-bit mode).

Compared to the sysbench "cpu-max-prime" results shown here:
http://www.golem.de/news/banana-pi-m3-vs-lemaker-hikey-bastelrechner-mit-bumms-1603-119720-3.html
performance of my ARMv8 32-bit NanoPC-T3 pretty much resembles that of ARMv7 32-bit BananaPi M3 (Allwinner A83T SoC, octa-core ARM Cortex-A7 CPU up to 2.0GHz) - especially when taking the lower max CPU clock speed for the NanoPC-T3 compared to BPi-M3 into consideration:

sysbench --num-threads=1 --cpu-max-prime=10000 --test=cpu run
BananaPi M3: 159 sec. (single thread), 40 sec. (4 threads), 21 sec. (8 threads)
NanoPC-T3: 172 sec. (single thread), 43 sec. (4 threads), 21 sec. (8 threads)

Note that in the link given above, for Lemaker Hikey (Kirin 620 SoC with octa core ARM Cortex-A53 64-bit CPU up to 1.2GHz) the respective figures on a 64-bit kernel in ARMv8/aarch64 mode were significantly better:
Lemaker Hikey: 12 sec. (single thread), 3 sec. (4 threads), 2 sec. (8 threads)

So these are the impressive gains to be leveraged when the SoC really uses ARMv8 architecture/instruction set rather than ARMv7 compatibility mode.

I don't know (that's why I raised this question in my very first post in this thread) whether it would be feasible to recompile the existing kernel (and subsequently, userland code) in 32-bits ARMv8 (does that exist? which toolchain to use?) for the time being. To the best of my knowledge, the "natural" way to ARMv8 for other SoC vendors typically includes upgrading to a 64-bit kernel...

I hope this clarifies why I definitely think that it is highly important for FriendlyARM to provide real ARMv8 (and then, inherently 64-bit) support as soon as possible.

Best,
awl
awl29 wrote:
Compared to the sysbench "cpu-max-prime" results shown here:
http://www.golem.de/news/banana-pi-m3-vs-lemaker-hikey-bastelrechner-mit-bumms-1603-119720-3.html
performance of my ARMv8 32-bit NanoPC-T3 pretty much resembles that of ARMv7 32-bit BananaPi M3 (Allwinner A83T SoC, octa-core ARM Cortex-A7 CPU up to 2.0GHz) - especially when taking the lower max CPU clock speed for the NanoPC-T3 compared to BPi-M3 into consideration:

sysbench --num-threads=1 --cpu-max-prime=10000 --test=cpu run
BananaPi M3: 159 sec. (single thread), 40 sec. (4 threads), 21 sec. (8 threads)
NanoPC-T3: 172 sec. (single thread), 43 sec. (4 threads), 21 sec. (8 threads)

Note that in the link given above, for Lemaker Hikey (Kirin 620 SoC with octa core ARM Cortex-A53 64-bit CPU up to 1.2GHz) the respective figures on a 64-bit kernel in ARMv8/aarch64 mode were significantly better:
Lemaker Hikey: 12 sec. (single thread), 3 sec. (4 threads), 2 sec. (8 threads)
Very interesting. I looked at the code sysbench/tests/cpu/sb_cpu.c for the sysbench cpu test. It consists of a tight loop that repeatedly tests whether a 64-bit integer is divisible by another 64-bit integer. In 32-bit mode such a test is performed by a subroutine call __aeabi_uldivmod. In addition to this, a surprising amount of time is spent on a type conversion instruction vcvt.f64.s32 from integer to double at each iteration to check the loop bound. While the test counts the number of primes, it then throws that count away before returning, so a smart optimized could eliminate the loop entirely. However, it appears -O2 level optimization in gcc does not actually eliminate the loop. Recompiling the code with gcc version 5.2 results in a slight increase of

NanoPC-T3: 143.0189 sec. (single thread), 17.9151 sec. (8 threads)

It appears repeated 64-bit integer division and conversions of 64-bit integers to double is one case where running the ARMv8 in the 64-bit mode achieves significant gains over 32-bit mode. At the same time, how many people use unsigned long long variable types in their code? In particular, it is worth mentioning that by using unsigned long instead the speed of the T3 in 32-bit mode is about 15.969 sec. (single thread). An excerpt of the relevant code from sysbench follows:

Code: Select all

int cpu_execute_request(sb_request_t *r, int thread_id)
{
  unsigned long long c;
  unsigned long long l;
  double t;
  unsigned long long n=0;
  log_msg_t           msg;
  log_msg_oper_t      op_msg;
 
  (void)r; /* unused */
 
  /* Prepare log message */
  msg.type = LOG_MSG_TYPE_OPER;
  msg.data = &op_msg;
 
  /* So far we're using very simple test prime number tests in 64bit */
  LOG_EVENT_START(msg, thread_id);
 
  for(c=3; c < max_prime; c++)
  {
    t = sqrt((double)c);
    for(l = 2; l <= t; l++)
      if (c % l == 0)
        break;
    if (l > t )
      n++;
  }
 
  LOG_EVENT_STOP(msg, thread_id);
 
  return 0;
}
Hello again,

first of all, sorry for my late reply.

ejolson wrote:
It appears repeated 64-bit integer division and conversions of 64-bit integers to double is one case where running the ARMv8 in the 64-bit mode achieves significant gains over 32-bit mode. At the same time, how many people use unsigned long long variable types in their code?
Hmm - would it be possible that your view on this is a little bit C/C++-centric? From my experience, usage of the type "long" in Java (which is 64-bits in Java, as there is no "long long") by far is not such a rare thing as 64-bit integers might still be in C/C++ code... ;)

ejolson wrote:
In particular, it is worth mentioning that by using unsigned long instead the speed of the T3 in 32-bit mode is about 15.969 sec. (single thread).
ejolson wrote:
In addition to this, a surprising amount of time is spent on a type conversion instruction vcvt.f64.s32 from integer to double at each iteration to check the loop bound.
Both of these findings are indeed good news, as they show that indeed, at least for this particular benchmark, the huge performance difference can be fully attributed to the use of 64-bit arithmetic operations (which may or may not be possible for programmers to avoid depending on language and application scenario).

Do I get your message right that it is highly unlikely that other architectural differences between ARMv8 and ARMv7 (unrelated to 64-bit arithmetic operations) would make up for significant performance gains?

Anyway, many thanks for digging into this - you made me feel (even) better about my decision in favour of a NanoPi M3... ;)

Best,
awl
Hello again,

as we are now past Chinese New Year as well, I would like to get back to some statements that both Nexell and FriendlyARM have made in Aug/Sept of last year regarding support/availability of a 64-bit kernel for NanoPi-M3/NanoPC-T3:

awl29 wrote:
I have just been in e-mail contact with an employee of Nexell/Zhongwei Semi. While they can only provide technical support to companies that have signed a NDA with them (such as FriendlyARM has), he was so kind as to provide some general information on the status of 64-bit support for S5P6818 from Nexell's point of view.

He said the following:
  • There will be a 64-bit based linux kernel on S5P6818 and the kernel version will be 3.18 or up. But when will it be released, we don't know exactly. It's under developing. The schedule is at the end of 2016 the 64-bit kernel will be released.
  • When this kernel is released, FriendlyARM will get it and then you can ask them for it.
This is great news, as it will open up the complete 64-bit world of ARMv8 aarch64 (arm64) for S5P6818! :D
FATechsupport wrote:
Hi thank you for your attention.
Once we get this support we will arrange its development but we cannot say it for sure exactly we will be able to release it since it depends on various factors
As for the toolchain we will decide that after we get the new kernel
Can you please update us on the current status of the 64-bit activities:

  • Have you received the 64-bit kernel for S5P6818 SoC from Nexell/Zhongwei Semi in the meantime as they promised? If you haven't yet, then please inform your contacts at Nexell and ask them to provide it to you.
  • What is the status of your own activities regarding device driver support for this new kernel? How far away are we from a working 64-bit kernel for M3/T3, i.e. what tasks are still on your to-do list?
Many thanks for your help & best regards
awl
There is a 64-bit kernel 4.4 using the same CPU here: https://github.com/SamsungARTIK/linux-a ... /A710/v4.4
u-boot here: https://github.com/SamsungARTIK/u-boot- ... 0_os_2.0.0

As far as Nexell is concerned, job done! They have delivered the kernel.

Integrating that kernel to work with the hardware (other than the CPU) on NanoPi M3 is up to FriendlyARM.
Hello FriendlyARM / FATechSupport,

would you please be so kind as to provide an update on the status of your activities regarding the 64-bit kernel for NanoPi-M3 / NanoPC-T3?

Many thanks in advance!
awl
@Friendly ARM / @FATechSupport

Would you please be so kind and answer the questions above about the 64-bits kernel?

Thank you in advance.
awl
I'm also interested in the 64-bit images. It seems rather weird to advertise the board as 64-bit, when in fact there are no images supporting that.

I see xsacha posted links to github repository with 64-bit kernel/uboot a month ago - has anyone managed to get that working with nanopc-t3?
Repeating myself:
@Friendly ARM / @FATechSupport

Would you please be so kind and answer the questions above about the 64-bits kernel?

Thank you in advance.
awl
@Chensy, do you have any updates on development of 64-bit Debian/Ubuntu image for the M3. @FATechsupport does not seem to be active on th the forums for the last couple of months, and you are listed as an additional moderator. Thanks you for any info you can give!
So, not even a response after more than a month (and several months since the issue of 64-bit images was first brought up). At this point I'd say this is just a bait & switch - advertising a board as 64-bit, without providing any viable way to actually run it in 64-bit mode.

FWIW I do realize 64-bits won't give me much advantage on this board, but I need to do tests with 64-bit ARM, so this seemed like a nice board to do so. Should have bought pine64+ I guess - only 4 cores, but 2GB RAM and 64-bit images.
tomasv wrote:
FWIW I do realize 64-bits won't give me much advantage on this board, but I need to do tests with 64-bit ARM, so this seemed like a nice board to do so.


The geekbox runs a 64 bit kernel and can run both 32 and 64 bit user applications (with the appropriate libraries installed). I see a decent (40% or so) boost from 64 bit apps, but obviously it will vary from application to application. As well as the larger register size there are also twice the number of registers and the new instruction set to benefit from.

My use case is headless server for compilation and regression testing, so I don't need multimedia support. I'd be delighted to see (and test) a 64 bit OS on the M3. (While we're on wishful thinking, I'd also love a version with 2G ram and 16G eMMC! )
I still hope for FriendlyARM to deliver an official 64-bit kernel when they release the 2GB version of T3, but for the time being, here is an independent 64-bit kernel based on 4.11 for M3/T3 (S5P6818) and Debian installer build that works on M3 and T3:

https://github.com/rafaello7/debian-installer-nanopi-m3/releases
https://github.com/rafaello7/debian-installer-nanopi-m3
https://github.com/rafaello7/linux-nanopi-m3

All credits for this effort go to github user "rafaello7" - I'm just the messenger... ;)

Best regards,
awl

Who is online

In total there are 3 users online :: 0 registered, 0 hidden and 3 guests (based on users active over the past 5 minutes)
Most users ever online was 5185 on Wed Jan 22, 2020 1:44 pm

Users browsing this forum: No registered users and 3 guests