https://arace.tech/products/radxa-orion-o6?variant=43770715275444

Anyone else have more informations?

_________________
retired

@AmigaBlitter

The ARM Cortex-A720 is based on the ARM Cortex-A78, with a 10 percent improvement.
https://en.wikipedia.org/wiki/ARM_Cortex-A720


CD8180 / P1 SoC's CPU ARM Immortalis G720 MC10
https://sbcwiki.com/docs/soc-manufactures/cix/cd8180-p1/

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@AmigaBlitter

Quote:

AmigaBlitter wrote: https://arace.tech/products/radxa-orion-o6?variant=43770715275444

Very nice board. A sign of things to come.

_________________
All the way, with 68k

@agami

*shrug*

ARM boards much more powerful in standard PC formats exist for a while.

Maybe or maybe not at that price point, but I just don't see where the use case for this is between rPi like devices (some of them pretty powerful) and AMD APUs on MiniITX boards.

Heck giving it's soldered RAM one might just as well go with an M4(Pro) MacMini.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@AmigaBlitter

I have it on my desk, but waiting for EFI updates before I continue with my experiments.

@AmigaBlitter

yet another boring arm board
for pc I have windows ((TM) since 2001)
as long as aros don't reach at least win xp level it is not interesting
szulc hammer agami karlos and other trolls should hard work on aros to get it to xp level

@ppcamiga1

And why should they? Just because people challenge you and question your "rants" doesn't make them a troll.

I don't think you are in a position to be making "demands" of people considering you don't appear to have the intellectual capacity to understand how EMU68 works.

_________________
Live Long and keep Amigaing!

A1200, Power Tower, TF1260 128MB RAM, 68060 Rev 6, OS3.9 BB2, HD-Floppy, Mediator TX+ PCI, Voodoo 3 3000, Soundblaster 4.1, TV Card, Spider USB, 100MBit Ethernet, 16GB CF HD, 52xCDRom.

@AmigaBlitter

Interesting. But the ITX form factor suggests it is targeted at the desktop environment.
I think they can achieve a substantial market share, with enough performance for the casual and average user.

I am personally more interested in the smaller boards, e.g. Raspberry or Raspi Zero form factor.
I use them quite a lot for my hobby projects instead of microcontrollers, the price is about the same - and they are cheap.
Quote:

Anyone else have more informations?

Not really, but I would wait a bit.
While the hardware of companies like Radxa or Shenzhen Xunlong (Orange Pi) is quite good, the software support is often lacking. Both in OS distribution supporting it in general, and driver quality and extend. This is at least my experience.

@AmigaBlitter

And in addition, after the fact :
https://www.youtube.com/watch?v=OMnCqmM-WKo&ab_channel=JeffGeerling

@codis

Quote:

And in addition, after the fact : https://www.youtube.com/watch?v=OMnCqmM-WKo&ab_channel=JeffGeerling

Looks like that board needs some work yet. The Geekbench single core should be around twice the RPi score.

_________________
Whyzzat?

@ppcamiga1

No one was asking you for your opinion. And even if you copy and paste the same garbage you post every time, not a single person of those you address cares what you demand them (and me) to do. You are just a meaningless troll without skills other then copy and paste the same text all the time.

Hammer Quote:

The ARM Cortex-A720 is based on the ARM Cortex-A78, with a 10 percent improvement. https://en.wikipedia.org/wiki/ARM_Cortex-A720

The ARM Cortex-A720 has a claimed 10% performed improvement using the same area as a Cortex-A78. Since this is a high performance OoO core, SoCs are more likely to tune Cortex-A720 cores for performance which use a much larger area. I expect even the 4x Cortex-A720 mid performance cores in the Orion O6 CD8180 SoC to use more transistors than RPi 5 Cortex-A78 cores (area varies by process size which is why I switched to transistors for core sizes). I expect the 4x big Cortex-A720 cores are up to 30% better performance than a RPi 5 Cortex-A78 core and the 4x medium Cortex-A720 cores to be closer to a Cortex-A78 in performance. A smaller fab process and LPDDR5 memory upgrade should boost the performance over a RPi 5 further. With the better integrated ARM GPU and a reasonable price, this board will likely steal RPi 5 sales at the high end. There are some downsides though. Chinese hardware producers often have inferior software support and there are some claims of rushed motherboard development in 2 months.

https://www.tomshardware.com/pc-components/motherboards/worlds-first-open-source-armv9-motherboard-surfaces-radxa-orion-o6s-pricing-starts-at-usd200-for-the-8gb-ram-model Quote:

Interestingly, the trio of companies behind the Orion O6 says this 'motherboard' was quickly developed. They started working on the project on July 30 this year. It powered up for the first time on September 29, and now it is said to be ready for mass production. We see all storage configurations of the Orion O6 listed for sale on AliExpress, with delivery slated for 20-40 days from now. The 8GB RAM model starts at $200. It is $240 for 16GB and $300 for 32GB, up to $450 for the 64GB SBC.

The "Radxa Orion O6-World's first Open Source ARM V9 Motherboard" claim may be deceptive. A motherboard is hardware so this sounds like open source hardware but it only applies to the "motherboard" if their claims are true which would be nice. The ARM SoC is closed source with ARM being oppressive in some ways which could limit GPU documentation. RPi is likely receiving pressure from ARM to switch to using ARM GPUs as well even though they have resisted changing GPUs so far despite ARM invested in RPi. RPi has had to fabless develop MCUs with Cortex-R cores at the low end to provide small footprint hardware (and included RISC-V cores to hedge their bets) to get around ARM deprecating 64-bit support where most of their business started. Speaking of 64-bit support, the OoO Cortex-A720 and in-order Cortex-A520 cores dropped 32-bit support and likely most big endian support with it. Michalsc should be able to confirm soon.

RPi's business was built on very low cost embedded and hobbyist hardware. The SoC cost was a small fraction of the SBC cost which is no longer true with the RPi 5 where the SoC+memory cost likely leaves little margin and budget and used x86-64 SBCs allow for minimal ability to scale up (the Orion O6 SoC is likely to be large and expensive using tens of billions of transistors like x86-64 hardware but with no x86-64 software library to fall back on). It was ARM Thumb ISAs which allowed RPi to exist since the 68k market was blocked first by Motorola management and then by the Amiga industrial complex.

https://smist08.wordpress.com/2022/02/04/raspberry-pi-os-goes-64-bit/ Quote:

How Does it Run? First off, even though it will run on a Raspberry Pi 3 or even a Raspberry Pi Zero 2, I wouldn’t recommend it. A 64-bit operating system uses more memory than the corresponding 32-bit version and 1 Gig of RAM isn’t enough. To use this, you really need a Raspberry Pi 4 with at least 4 Gig of RAM. On my Raspberry Pi 4 with 8 Gig of RAM, it is noticeably peppier than the 32-bit version, especially when browsing with Chromium. ... Why Move to 64-Bit? The Raspberry Pi OS has been around for a while in 32-bits, the advantage is that it runs on all Raspberry Pi’s no matter how old and it runs in compact memory footprints of 512 MB or 1 Gig. It runs a vast library of open source software and has provided a great platform for millions of students and DIY’ers. However, most of the rest of the world including mainstream Linux, Windows, MacOS, Android and iOS have all been 64-bit for some time. So let’s look at some reasons to move to 64-bits. 1. Memory addressing simplifies, making life simpler for Linux. 2. In 64-bit mode, each ARM CPU has twice as many general purpose registers (32 vs 16) allowing programs to keep more variables in registers, saving loading and storing things to and from memory. 3. All new compiler optimizations are targeting the ARM 64-bit instructions set, not much work is being done on the 32-bit code generators. 4. The CPU registers are now 64-bits, so if you are doing lots of long integer arithmetic, it will now be done in one clock cycle rather than taking several under 32-bits. All that being said, there are a couple of disadvantages, namely 64-bit tends to take more memory due to: 1. If integers are 64-bit, rather than 32-bit then it takes twice as much memory to hold each one. 2. Normal ARM instructions are 32-bits in size when running in either 32-bit or 64-bit mode. However in 32-bit mode there is a special “thumb� mode where each instruction is only 16-bits in size. Using these can greatly reduce memory footprint and the GCC compiler supports producing these as an option.

This is Stephen Smith's Blog who wrote “Programming with 64-Bit ARM Assembly Language� so he supports 64-bit ARM but says it needs 4GiB of memory, at least for Linux. He also recognizes that ARM "Thumb mode" that was licensed from Hitachi and copied from SuperH which was an inferior copy from the 68k made the original 256MiB, 512MiB and 1MiB RPi hardware possible. Now ARM is shoving much larger footprint 64-bit ARM64/AArch64 down users throats while dropping compatibility again in typical RISC fashion. They espouse the performance advantage as there is one on higher end ARM hardware.

https://www.sevarg.net/2021/12/18/raspberry-pi-32-bit-vs-64-bit/

The RPi 3 with 1GiB memory and in-order Cortex-A53 cores performed better with a 32-bit Raspbian/RPi OS in benchmarks where some benchmarks crashed with the memory consumed by a 64-bit OS. A RPi 4 with 4GiB of memory had better performance with a 64-bit Raspbian/RPi OS in benchmarks. There are some claims of ARM 64-bit having better performance with small footprint hardware in limited cases and the performance gain for memory trade off probably seems acceptable although this does match up with the benchmark results above even though the RPi Zero 2 W uses the same Cortex-A53 cores as the RPi 3.

https://www.reddit.com/r/raspberry_pi/comments/smv9h3/raspberry_pi_os_32bit_vs_64bit_performance_review/
tinkerterrapin Quote:

In one of my projects 64 bit mode runs about 35% faster and takes 45% more memory. Tested on the same Zero 2 W with fresh Raspberry Pi OS 32/64bit installs.

There is no doubt that a 64-bit RPi OS needs much more memory but lets examine the performance difference closer. AArch64 more than doubled the GP integer registers from the original 32-bit ARM ISA and quadruples the registers in Thumb modes (the FPU and SIMD support and registers increased as well). The x86 ISA was similarly performance handicapped with less than 8 GP registers and much of the x86-64 performance improvements came from using more registers and executing fewer instructions as a result much of which was offset by the performance loss of larger code and pointers. A paper called "Performance Characterization of SPEC CPU2006 Integer Benchmarks on x86-64 Architecture" only showed a 7% performance gain on average for 64-bit over 32-bit in SPEC CPU2006 and a 0.46% performance gain for 64-bit in SPEC CPU2000 at the cost of 25.1% increased memory used for SPEC CPU2006.

Performance Characterization of SPEC CPU2006 Integer Benchmarks on x86-64 Architecture
https://ece.northeastern.edu/groups/nucar/publications/SWC06.pdf Quote:

We have observed that for the SPEC CPU2006 integer benchmarks, 64-bit mode offers a sizable performance advantage over 32-bit mode (7% on average). However, the advantages vary from benchmark to benchmark, and for a handful of programs, 64-bit mode is significantly slower than 32-bit mode (in this subset of benchmarks, performance is reduced by more than 16% when running in 64-bit mode.) We further analyze 5 benchmarks that exhibit significant differences in performance between these two modes. For this set of CPU2006 integer programs, we present a range of performance characteristics that illustrate the impact of moving to a 64-bit environment. Our results and analysis can be used by performance engineers and developers to better understand how to exploit the capabilities of the x86-64 architecture.

Higher spec x86-64 hardware and improved compiler support has likely increased the performance gain for 64-bit much like AArch64 has done. The newer x86-64 and AArch64 ISAs are big improvements but compared to how handicapped the earlier ISAs were in performance. This can be demonstrated with the modernized 32-bit x32 ABI that uses the same hardware resources as x86-64.

https://en.wikipedia.org/wiki/X32_ABI Quote:

Details Though the x32 ABI limits the program to a virtual address space of 4 GiB, it also decreases the memory footprint of the program by making pointers smaller. This can allow it to run faster by fitting more code and more data into cache. The best results during testing were with the 181.mcf SPEC CPU 2000 benchmark, in which the x32 ABI version was 40% faster than the x86-64 version. On average, x32 is 5–8% faster on the SPEC CPU integer benchmarks compared to x86-64. There is no speed advantage over x86-64 in the SPEC CPU floating-point benchmarks. There are also some application benchmarks that demonstrate the advantages of the x32 ABI.

https://sites.google.com/site/x32abi/ Quote:

Comparison Test machines: Fedora 17/x86-64 o kernel-3.3.7-3.0 o glibc-2.15-37.0 181.mcf from SPEC CPU 2000 (memory bound): Intel Core i7 o ~40% faster than x86-64. o ~2% slower than ia32. Intel Atom o ~40% faster than x86-64. o ~1% faster than ia32. 186.crafty from SPEC CPU 2000 (64bit integer): Intel Core i7 o ~3% faster than x86-64. o ~40% faster than ia32. Intel Atom o ~4% faster than x86-64. o ~26% faster than ia32.

At least on lower spec x86-64 hardware, 32-bit x32 has better performance than 64-bit x86-64 which has better performance than 32-bit x86/ia32. There was a similar attempt as x32 for ARM but it did not get as far and I am unaware of any benchmarks.

https://wiki.debian.org/Arm64ilp32Port Quote:

Arm64ilp32Port This port is arm64 with a 32-bit ABI instead of a 64bit ABI. It is exactly equivalent to x32 on x86. The instruction set is 64-bit armv8, but not using the default LP64 ABI (64-bit longs and pointers) but the ILP32 ABI (ints, longs and pointers are all 32bit, same as they are on armhf/armel). It gives exactly the same functionality as existing 32-bit ARM, but using the v8 instruction set. This is significant on arm cores that _only_ support v8, such as the Cavium ThunderX, where you also have software that is not 64-bit-safe. It is fairly experimental at the moment (2016-2018) and whilst there is upstream toolchain support, kernel and glibc support are being maintained in topic trees, not mainline whilst the world determines if this architecture gets sufficient usage for long-term support.

I expect a 32-bit Arm64ilp32Port would be higher performance than 64-bit AArch64 which is higher performance than Thumb(-2) on higher spec hardware. The ARM Thumb ISAs were created for low spec embedded hardware with very limited memory bandwidth where performance was better than the 32-bit original ARM ISA. The performance gain from small code offsets the performance loss from increased instructions executed, due to the poor copy of the 68k ISA. The 68k has similar code density to Thumb-2 but does not have Thumb handicap of increased instructions which can be 40% or more. The 68k ISA with 16 GP registers executes a similar number of instructions as a RISC ISA with 32 GP registers but has 40% plus better code density than classic RISC ISAs like PPC, MIPS and SPARC. PPC was completely replaced by ARM64/AArch64 because it has better code density and performance traits/metrics but the 68k remains viable for low end hardware with similar code density to Thumb(-2) and better performance traits/metrics, especially with ARM delegating Thumb cores to very low end Cortex-M MCUs. This basically means there are no standard low end cores for small footprint hardware from ARM. Small footprint is a pretty large category of 1-2GiB memory and below hardware.

ARM is neglecting their bread and butter embedded market believing they can scale up and compete with x86-64. This puts businesses like RPi in a difficult position as they had better margin on low end standard hardware and ARM is wanting them to scale up into more competitive 64-bit markets with lower margin. Much of this 64-bit transition for ARM has come from the 64-bit smartphone and tablet market where Apple led the way. Android requirements have been skyrocketing to new levels of bloat too.

https://www.gadgets360.com/mobiles/news/google-android-15-minimum-ram-storage-requirements-update-8168643 Quote:

Smartphones to Require at Least 6GB of RAM With Android 16 Android Authority spotted the updated minimum specifications for smartphones that ship with Android 15 and Google's apps and services. If manufacturers want to ship new smartphones with Android 15, they will need to include at least 32GB of built-in storage. Google previously increased the requirement from 8GB of inbuilt storage to 16GB, after the release of Android 13. Google has also specified that smartphone makers will need to allocate 75 percent of the built-in storage must be reserved for user data. Most entry-level smartphones today ship with 64GB (or more) inbuilt storage, and this has become a necessity due to the increasing size of applications. The minimum amount of RAM available on a smartphone running Android is now 4GB, which means that handsets with 3GB of RAM must run on Android Go, which is optimised for less capable handsets. Google will once again increase the minimum amount of RAM to 6GB when Android 16 comes out, so phones with 4GB of RAM will also need to use Android Go in the future. Phones shipping with Android 15 must be equipped with chips that support the Vulkan 1.3 (or newer) 3D graphics and compute API, according to Google. These handsets must also support emergency contact sharing with emergency services.

Android quickly replaced Windows CE/mobile because of the cost advantage of using free software.

https://en.wikipedia.org/wiki/Windows_Mobile#Market_share Quote:

In February 2009, Microsoft signed a deal with the third largest mobile phone maker, LG Electronics, to license Windows Mobile OS on 50 upcoming LG smartphone models. But in September 2009, Palm, Inc. announced it would drop Windows Mobile from its smartphone line-up. Gartner estimated that by the third quarter of 2009 Windows Mobile's share of worldwide smartphone sales was 7.9%. By August 2010, it was the least popular smartphone operating system, with a 5% share of the worldwide smartphone market (after Symbian, BlackBerry OS, Android and iOS). An October 2009 report in DigiTimes said that Acer would shift its focus from Windows Mobile to Google Android. The New York Times reported in 2009 that Windows Mobile "(was) foundering", as cellphone makers desert it in favor of Google's Android phone platform. It cited the difficulties in Microsoft's business model, which involves charging handset manufacturers up to $25 for each copy of Windows Mobile, while rival Google gives away Android for free. From late 2009 analysts and media reports began to express concerns about the future viability of the Windows Mobile platform, and whether Microsoft would keep supporting it into the future. Samsung announced in November 2009 that it would phase out the Windows Mobile platform, to concentrate on its own Bada operating system, Google's Android, and Microsoft's Windows Phone.

The cost advantage of using Android over Windows Mobile was $25 per device. The cost advantage of using 1GiB of memory with a 32-bit OS instead of 4GiB of memory with a 64-bit OS may be $15 and for 6GiB of memory may be $25 if memory was $5/GiB as RPi often charges. RPi likely pays less for memory than what they charge for it but I doubt it is the rule of thumb 3 times increase for hardware. Avoiding royalties like ARM charges gives a per device cost advantage over ARM using producers and potentially that much of a margin advantage. A 3%-5% higher margin is nothing to scoff at as grocery stores and refiners often operate and mass produce with that small of margin. I believe Eben Upton understands the low margin mass produced hardware market but ARM is not helping him by forcing him to scale up to more expensive hardware with less margin. In contrast, the Amiga industrial complex does not understand the need to produce competitive hardware at all or they could have brought the smaller footprint 68k Amiga with cost advantages to market before Eben.

Last edited by matthey on 01-Jun-2025 at 01:36 AM.
Last edited by matthey on 01-Jun-2025 at 01:35 AM.
Last edited by matthey on 01-Jun-2025 at 01:28 AM.

@matthey

And what’s the penalty of using 32bit OS when dealing with modern data, large files on large file systems on large storage devices, using large time stamps? Just saying, 32bit systems are becoming increasingly quirky to deal with.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

And what’s the penalty of using 32bit OS when dealing with modern data, large files on large file systems on large storage devices, using large time stamps? Just saying, 32bit systems are becoming increasingly quirky to deal with.

64-bit filesystems and timestamps are used in 32-bit OSs. The increased overhead of 64-bit operations in 32-bit is usually not bad with proper support considering the frequency of these operations. Consider how often the AmigaOS uses 64-bit filesystem and timestamp datatypes.

1. 64-bit add, sub and neg are the most frequent operations and they are in the order of double the cost but sometimes a little more (e.g. add+addx instructions)
2. 64-bit shift is more like 3-4 times the cost of a 32-bit shift on the 68k. Some other 32-bit ISAs are closer to double like x86 with an instruction to shift out of one 32-bit register into another.
3. 64-bit multiply requires 4x 32x32=64 multiplies and adding the partial sums so maybe 5-7 times the cost of a 64x64=64 that has 1-3 cycle throughput using a modern fab processes. The 68060 removed 32x32=64 as other architectures added 64-bit support even for embedded use as the 68k was not allowed to compete with PPC. However, 68060 instructions with 64-bit results should be added back.
4. 64-bit division is tricky. The divisor/denominator can be checked to see if it fits in 32-bits in which case a 64/32=64 can be used which may be cheaper than a 64/64=64 but a full 64/64=64 in most 32-bit ISAs would be many times more expensive. It would be possible to add a 64/64=64 instruction to a 32-bit ISA but the implementation is expensive which is also one of the reasons why the DIV and MUL instructions with 64-bit datatypes were dropped from the 68060. Some CPU designs share the integer and FPU DIV hardware where the FPU is standard and with a new FPU rounding mode, a FPU FDIV could perform a 64/64=64 with similar latency as an integer 64/64=64. This would only be possible with an extended precision FPU where the fractional part of a floating point number is 64-bit instead of double precision where it is 53-bit. I had 64-bit integer math in the FPU working in the 68k Amiga version of FFmpeg but it was not optimal with the current rounding mode support in the 68k FPU.

https://aminet.net/package/gfx/conv/ffmpeg-git7df9937-m68k Quote:

Thanks to Bernd Roesch for his bugfixed/improved ixemul/SDL libraries and Matt Hey for optimized 68060 asm routines.

The CISC 68060 is Spartan compared to Reduced Instruction Set Computers (RISC) like PPC which have more instructions and ARM64/AArch64 has many times more instructions. The 68000 only had 56 instructions.

https://en.wikipedia.org/wiki/Motorola_68000#Instruction_set Quote:

Instruction set The designers attempted to make the assembly language orthogonal. That is, instructions are divided into operations and address modes, and almost all address modes are available for almost all instructions. There are 56 instructions and a minimum instruction size of 16 bits. Many instructions and addressing modes are longer to include more address or mode bits.

I asked the Google AI "How many instructions does AArch64 have?"

Google AI Quote:

AI Overview AArch64, the 64-bit version of the ARM architecture, has a large number of instructions, likely exceeding 1300, including basic instructions, SIMD, floating-point, and SVE extensions. The base instruction set alone, as documented in the A64 Base Instructions manual, contains 354 instructions. SIMD and floating-point instructions add another 404, and SVE (Scalable Vector Extension) instructions add 508, according to a Reddit user. The total can be more than 1300 when including all variants and extensions. Here's a breakdown of the key components: o A64 Base Instructions: 354 instructions. o SIMD and FP Instructions: 404 instructions. o SVE Instructions: 508 instructions. o Total (estimated): Over 1300 instructions when considering all variants and extensions, according to a Reddit user.

The info is mostly based on ARMv8 and the "reduced instruction set" computer RISC ISA has increased for ARMv9. A fixed length 32-bit encoding is used like PPC so when they run out of encoding space they can make it a 32-bit VLE like POWER, without 16-bit instructions to improve code density. At least it is not a "complex instruction set" computer CISC ISA though.

I asked Google "Do reduced instruction set computers have reduced instruction sets compared to complex instruction set computers?"

Google AI Quote:

AI Overview Yes, reduced instruction set computers (RISC) are designed to have a smaller, highly optimized set of instructions compared to complex instruction set computers (CISC). This means RISC processors have fewer instructions, but each instruction is designed to execute quickly and efficiently, leading to faster overall performance.

It brought up the following pic too.


https://www.microcontrollertips.com/risc-vs-cisc-architectures-one-better/

At least Google AI is putting a little disclaimer at the bottom, "AI responses may include mistakes." It would be shorter if they just said "AI lies."

Last edited by matthey on 01-Jun-2025 at 12:32 PM.
Last edited by matthey on 01-Jun-2025 at 12:17 PM.

@matthey

Quote:

Speaking of 64-bit support, the OoO Cortex-A720 and in-order Cortex-A520 cores dropped 32-bit support and likely most big endian support with it. Michalsc should be able to confirm soon.

I can only confirm that BigEndian mode is still a thing on ARM v9, and I confirm that the CPU of Orion O6 does support big endian mode.

michalsc Quote:

I can only confirm that BigEndian mode is still a thing on ARM v9, and I confirm that the CPU of Orion O6 does support big endian mode.

Interesting and good for Emu68 as it uses the 64-bit AArch64 ISA. Are the 32-bit ARM ISAs gone?

The 32-bit support was supposedly still available in early ARMv9 cores. See the charts at the bottom of the following Wiki pages.

https://en.wikipedia.org/wiki/ARM_Cortex-A720
https://en.wikipedia.org/wiki/ARM_Cortex-A520

The Cortex-A710 was the last OoO core to support 32-bit and ARMv9. The Cortex-A510 was the last in-order core to support 32-bit and ARMv9.

Last edited by matthey on 01-Jun-2025 at 12:46 PM.

@matthey

Dunno about 32-bit ISA. The last bits and pieces of it in Emu68 have been removed some time ago already.

@codis

Really interesting.

It have HW ray tracing and good NPU:

4x Cortex®-A720 (Big cores) up to 2.8GHz
4x Cortex®‑A720 (Medium cores) up to 2.4GHz
4x Cortex®‑A520 (LITTLE cores) 1.8GHz
RAM LPDDR5 RAM
- 128bit memory bus
- 5500MT/s transfer speed
- Configurations: 4GB / 8GB / 16GB / 32GB / 64GB
GPU Arm® Immortalis™ G720 MC10
- Hardware Ray‑Tracing enabled
- Vulkan® 1.3
- OpenGL® ES 3.2
- OpenCL® 3.0
VPU - 8K@60fps decoder AV1, H.265, H.264, VP9, VP8, H.263, MPEG‑4, MPEG‑2
- 8K@30fps encoder H.265, H.264, VP9, VP8
NPU Neural Processing Unit (NPU)
- Computing Power: 30 TOPs
- Precision Support: INT4 / INT8 / INT16 / FP16 / TF32

good the price for 64 GB of ram too.

_________________
retired

@AmigaBlitter

Quote:

good the price for 64 GB of ram too.

But you saw the last-minute addendum at the very end, regarding the price hike due to tariff regulations ? Just saying ...

On a related note - one can easily get refurbished PC's and notebooks for less than a third or a quarter of the original price here in Europe (AT, DE). I have a few of them, including for my wife. Most large organisations don't buy IT hardware anymore, but rent them from specialized companies (often spin-offs of hardware manufacturers like Dell or HP). After the 3 to 5 year leasing period, this systems are written off, and sold to electronics distributors who refurbish and resell them. And since I use basically only Linux on all those machines, performance or hardware support is never an issue.
Long story short - I can get a very decent refurbished system for the same price.

AmigaBlitter Quote:

It have HW ray tracing and good NPU:

The "HW ray tracing and good NPU" use many transistors and are not necessary.

Quote:

The H100 GPU is manufactured on a 'custom version' of TSMC’s 4N process, with 80 billion transistors - 68 percent more than the prior-generation 7nm A100 GPU. It is the first GPU to support PCIe Gen5 and the first to utilize HBM3, enabling 3TB/s of memory bandwidth. The new GPU provides up to 30 teraflops of peak standard IEEE FP64 performance, 60 teraflops of peak FP64 tensor core performance, and 60 teraflops of peak FP32 performance.

A 60 Teraflops GPU uses 80 billion transistors. A NPU may more efficiently use transistors and TOPs are a measure of simpler integer operations instead of floating point operations but a 30 TOPs NPU could use hundreds of millions if not billions of transistors. In comparison, a 68060 CPU uses 2,530,000 transistors, could be mass produced for less than $1 USD today and this Orion O6 board could maybe emulate a 68060@2GHz (we may soon find out as michalsc has a board). Personally, I would rather have a more powerful GPU that can improve GPU performance and perform AI work even though it may not be as efficient for some AI datatypes. The CPU SIMD units can also use most AI datatypes. I consider AI specific hardware to be wasteful considering the direction of AI is unknown and AI lies. HW ray tracing is not efficient compared to traditional 3D rendering but at least it has some clear benefits like for lighting and can be used sparingly where most effective.

AmigaBlitter Quote:

4x Cortex®-A720 (Big cores) up to 2.8GHz

The website changes and reads up to 2.6GHz currently.

https://www.jeffgeerling.com/blog/2025/radxa-orion-o6-brings-arm-midrange-pc Quote:

Bringup And anyone who's bought Radxa hardware early on knows this, but it bears mentioning: this board needs a little more time in the oven. Radxa has a docs site with a lot of helpful information. The board runs a lot of things well already. But if you already ordered one of these things, don't expect all the features on their website to run day-one. Some things, don't expect them to ever run. In fact, when I pre-ordered my 32 GB board, the website said there were 12 cores at up to 2.8 Gigahertz. As of today, the specs were updated to showing 12 cores, but 'up to 2.6 gigahertz'. And in reality, with the latest firmware, depending on how you're running the board, you might only get 8 cores. And only 2.4 or 2.5 gigahertz. But in positive news, the firmware that limits the board to 8 cores is SystemReady SR certified, meaning it has full UEFI support and can run Windows or Linux arm64 natively. That doesn't mean everything works out of the box though. If you want run Windows, there are still precious few drivers for Windows on Arm. And on Linux, depending on what version and what distro you install, you might or might not get support for features like the iGPU, or the 5 Gbps Ethernet. Each of the major distros I tested was lacking one feature or another. In a year or two, the Orion O6 will be in a better place. I probably spent a dozen hours just working on different driver issues to test everything. That's not something I'd want you to have to do, too.

This website has one of the best reviews on the Orion O6 and includes a CPU benchmark.



The single core CPU performance is ~45% higher than a RPi 5 but the Orion O6 big CPU cores are clocked about 8% higher.

Cortex-A76@2.4GHz (RPi 5)
Cortex-A720@2.6GHz (Orion O6)

The single core performance advantage of the Orion O6 is more like 34% at the same clock speed as the RPi 5. Disappointing is the power used from what some websites claim is a SoC TSMC 6nm chip fab process.



14W at idle is more than the RPi 5 "power virus" max of 12W. So much for peace and quiet with low power ARM. Maybe the Orion O6 comes with a power virus since it is from China. Trumps tariffs will fix the problem though.

https://www.jeffgeerling.com/blog/2025/radxa-orion-o6-brings-arm-midrange-pc Quote:

Welp. I went to re-order the board, and realized instead of paying around $330 plus $85 shipping, I'd have to pay around $330 plus $1,100 shipping, because of the tariffs that took effect this month!

The tariff markup is like the Amiga industrial complex tax/toll on Amiga hardware. The Orion O6 is still much higher performance than an X5000, A1222 or Mirari board even with the tariff resulting in similar prices to PPC Amiga hardware. It will never completely kill the absurdly priced PPC hardware in Amiga Neverland though. After all, there is already lower end x86-64 hardware than the Orion O6 that has similar performance, better discreet GPU support, a larger software library and maybe uses less power. No, Trevor likes the status quo where the Amiga market remains divided and niche even as real Amiga hardware dies and is replaced by virtual 68k Amigas.

Last edited by matthey on 01-Jun-2025 at 09:59 PM.
Last edited by matthey on 01-Jun-2025 at 09:26 PM.