ODROID-N2L SBC is a smaller and cheaper version of the ODROID-N2+ single board computer powered by an Amlogic S922X hexa-core Cortex-A73/A53 processor and offered with 2GB or 4GB single-chip LPDDR4X memory.
While the ODROID-N2+ is the most popular board from Hardkernel, it’s also fairly larger than most hobbyist SBCs on the market, and following requests from customers, the company designed the ODROID-N2L with a compact form factor that is smaller than Raspberry Pi Model B SBCs and sold at a lower price at the cost of missing some of the features of its big brother.
ODROID-N2L specifications:
- SoC – Amlogic S922X hexa-core big.LITTLE processor with 4x Arm Cortex A73 cores @ up to 2,208/2,400 MHz, 2x Arm Cortex A53 cores @ 1,908/2,016GHz, Arm Mali-G52 GPU @ 846MHz; 12nm manufacturing process
- System Memory – 2GB or 4GB LPDDR4 @ 3216 MT/s
- Storage – eMMC flash module socket up to 128GB, microSD card slot up to UHS-I SDR104
- Video & Audio Output
- HDMI 2.0 port up to 4K @ 60 Hz with HDR, CEC, EDID
- MIPI DSI connector (marked as “F” below and listed as TBD, so it’s unclear whether it works right now)
- Connectivity – Optional WiFi or Ethernet RJ45 adapter
- USB – 1x USB 3.0 host port, 1x USB 2.0 host port
- Expansions
- 40-pin GPIO header with 2x I2C, UART, SPI, 2x ADC, 25x GPIO, 5V, 3.3V, 1.8V, and GND signals
- Note: 3.3V I/Os, except for ADC @ 1.8V max
- Misc – 2x system LEDs, 2-pin header for optional fan
- Debugging – 4-pin UART white connector (H) for serial console
- Power Supply – 7.5V to 16V DC via 5.5/2.1mm power barrel jack
- Power consumption
- Power off: 0.2 Watt
- Idle: 1.5 Watt
- CPU stress (passive heatsink): 5.4W @ 2.208/1,908 MHz; 5.8W when overclocked to 2,400/2,016 MHz
- CPU stress (active cooling): 6.1W @ @ 2.208/1,908 MHz; 6.4W when overclocked
- Dimensions – 69 x 56mm; Thickness: 22mm with fan heatsink, 32mm with tall heatsink (ODROID-N2+: 100 x 91 x 18.75mm)
- Weight – 50 grams with fan heatsink; 68 grams with tall heatsink (ODROID-N2+ is 200 grams with its large heatsink)
The biggest downside that I see is the complete lack of network connectivity as Ethernet, WiFi, or/and Bluetooth can only be added to the board through (USB) adapters. One of the tricks to make the board smaller was to replace the DDR4 RAM chips with a single LPDDR4 chip that also lowers power consumption and improves performance thanks to a 20% higher DRAM interface clock frequency. It shows in benchmarks as the ODROID-N2L is slightly faster than the ODROID-N2.
That’s around 10 to 20% faster system performance, and Hardkernel says graphics performance also improved by 10% in glmark2-es2 benchmark.
Power consumption is lower because of the LPDDR4X and the removal of some features.
Hardkernel provides Android 32-bit and 64-bit images as well as Ubuntu 22.04.01 minimal and MATE desktop images for the board. Note that images for the ODROID-N2+ will NOT boot on the ODROID-N2L because of the DRAM changes. Some work-in-progress documentation and the OS images can be found in the wiki.
ODROID-N2L SBC can be purchased for $59 with 2GB RAM and $69 with 4GB RAM. Those ship with a fan by default and the optional tall blue heatsink for fanless operation adds $4.90. You’ll find the boards and accessories on the Hardkernel store.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
> It shows in benchmarks as the ODROID-N2L is slightly faster than the ODROID-N2
Or to be more precise: two irrelevant BS benchmarks from 4 decades ago (like Dhrystone) that have zero relationship to anything running on today’s computers and that are highly susceptible to compiler optimizations/flags show higher scores when built with more recent compiler versions and most probably different compiler flags (N2L scores generated on Ubuntu Jammy with GCC 12.2 vs. N2+ scores generated 2.5 years ago on Focal with GCC 9.3).
Why not post something constructive, like, say, what sort of a benchmark would you suggest instead and why?
Which benchmarks I prefer and why is explained here. 🙂
And a score for one of those benchmarks not susceptible to compiler version, optimizations and flags is already listed by Hardkernel: the shown ‘7-zip MIPS’ are identical and that’s what is to be expected in general since those use cases that benefit from a little higher memory bandwidth are scarce.
BTW: measured ‘in the wild’ with kernel 5.15 the N2+ scores ~9800 7-zip MIPS and not just ~9360 as shown here (maybe they used 4.9).
some want real world benchmarks without defining what demand is “user’s average needs”, e.g. difficult like “browse faster”(?), instead of “browse more meaningful”
nice price device, for having a chance being part of a community to communicate pleasure and ‘needs’ on the products (one can’t compare companies like Apple and Hardkernel through their devices and marketing strategies, wrong(?), What do You expect?)
(different purposes, e.g. higher memory bandwidth could support gpu bandwidth with appropriate software&drivers levels(?))
> some want real world benchmarks
Where’s the point in benchmarking this thing at all? It’s the same SoC, it’s the same CPU clockspeeds, it’s 20% higher clocked RAM which results in ~10% higher memory bandwidth. The best any task could benefit from this is also a 10% increase in performance (likely only improving video at higher bitrates or higher fps with 2D/3D acceleration).
> Where’s the point in benchmarking this thing at all?
for whomever?
it’s a SoC on a (pcb) system (and one 4GB LPDDR4 2x16bit compared to four DDR4 2x2x16bit, Ubuntu 22.04, for ~$69 (or ~$79), network components are ~48(-128)pins for tranceiver and 14-16pins for RJ45 socket for xGMII, HDMI2.0 ~(19&case)pins, USB3.x 9-24pins)
Thanks for the comment. Chugging through video is one of those cases where I wouldn’t mind a bit of boost.
But i might as well farm video decode/encode out to a used android phone viewed with scrcpy.
I’m not convinced any ARM newer than the Vim3 Pro meets my minimum standards for electronic hygiene.
And asides the missing need to provide benchmark scores Hardkernel’s benchmark methodology and conclusions are BS.
Dhrystone is from 1984 and has been critized already back then that the whole tests fit inside the caches of the CPUs of that time!
When in 2022 on a CPU with magnitudes larger caches this irrelevant Dhrystone generates 17% better scores it’s obvious that this is 100% unrelated to faster DRAM bandwidth since no RAM access involved at all.
Any chance you’ll add Stockfish (chess program) in the future as bench?
It’s hard on integer (and heavily SIMD optimized these days, including AVX2 and AVX512) and scales.
x86 benches are generally easy to find, but not a lot of people test it with ARM machines.
Compiling is as simple as it gets.
https://github.com/official-stockfish/Stockfish/blob/master/src/Makefile
> Any chance you’ll add Stockfish in the future as bench?
Most probably not since it takes an insane amount of time ‘verifying’ a benchmark (susceptible to compiler version, optimizations and flags or not as such able to compare scores made in different years or not) and the benchmark should represent a somewhat broader use case (other than doing computer chess). Is there any?
As you’ve already noticed with the Rock 5B it serves well as a stresstest too. Besides that, it’s probably about as useless as a CPU miner.
It’s also a fairly popular benching tool, so you can always quickly compare results.
> it serves well as a stresstest too. Besides that, it’s probably about as useless as a CPU miner.
Yeah, as a load generator / stability tester it seems better suited, so stockfish could be a replacement for cpuminer. OTOH I use cpuminer to demonstrate how GCC version matters and this is a really important lesson for those users blindly trusting into numbers w/o switching on their brain for a second.
> It’s also a fairly popular benching tool, so you can always quickly compare results.
I doubt these comparisons are helpful since stockfish’s engine is improved constantly and as such the same hardware will generate increasing scores over the years so just as Hardkernel demonstrated with that outdated Dhrystone/Whetstone BS it is a mistake with ‘constantly improving’ software to compare results from different years.
That’s fair, though the previous versions on Openbench are static. There are also some continuous lists like on ipmanchess.
Stockfish 1.4.x on Openbench will always remain SF15.
On a sidenote, if you use “bench 128 \$NUM_CPU_CORES 24 default depth nnue” you might be able to stress the CPU even further as it disabled the “legacy” eval and only use the NN eval.
>as such the same hardware will generate increasing scores
(I get the point) but nps can also decrease if a bigger net tests better. Point remains because it makes comparisons between versions shoddy at best.
> Stockfish 1.4.x on Openbench will always remain SF15.
Maybe but I won’t rely on Phoronix anyway (this silly mode taking hours for simple tests for absolutely no reason) and it still takes efforts to identify what this stockfish benchmark is actually doing and which boundary conditions affect scores: https://github.com/ThomasKaiser/sbc-bench/issues/55#issuecomment-1309375720
> (this silly mode taking hours for simple tests for absolutely no reason)
Phoronix really takes hours?! Thought it wouldn’t take much longer than just compiling it myself which is why I linked it in the first place (besides the populated list)
> Phoronix really takes hours?!
See https://openbenchmarking.org/result/2211099-NE-2211093NE82
The real benchmark execution takes just a few minutes but Michael Larabel’s decisions (repeating a task over and over again until standard deviation ‘fits’ even if it will never ‘fit’) end up with those benchmarks taking forever at least on SBC. It’s ‘fire and forget’ at its best (worst ofc).
Congratulations! You found a way to freeze my Rock 5B by simply doing an early test in lazy mode:
phoronix-test-suite benchmark pts/stockfish-1.4.0
Consumption is at 12W (that’s massive compared to cpuminer and 7-zip) and switching to most recent boot BLOBs made it even worse.
I’ll investigate further! 🙂
Wow, this I want to hear about.
> Wow, this I want to hear about.
https://github.com/ThomasKaiser/sbc-bench/issues/55
verified only for ‘ARMv8 Cortex-A55′ (?)
With ‘verifying a benchmark’ I was talking about identifying what a specific benchmark is actually doing, which use case it (tries to) represent, whether its scores change with compiler version or not, whether memory bandwidth and/or latency affect the scores or everything happens inside CPU caches and so on.
7-ZIP MIPS is one of the few scores that do not vary with compiler version, libs and distro for example.
on “freeze [] Rock5B”
dynamIQ (bigLittle) cores A76 or A55 (integrated L2 cache) differences being a reason?
(openbenchmarking.org/test/pts/stockfish)
Tested CPU Architectures[…]
ARMv8 64-bit
arm64
Apple M1, Apple M1 Ultra, Apple M2
ARMv8 64-bit
aarch64
ARMv8 Cortex-A55 4-Core, ARMv8 Cortex-A72 4-Core, ARMv8 Neoverse-N1, Ampere ARMv8 Neoverse-N1 256-Core, Apple M1, Apple M2
https://github.com/ThomasKaiser/sbc-bench/issues/55#issuecomment-1309943551
interesting, what’s the stockfish reply to sbc-bench?
> Any chance you’ll add Stockfish (chess program) in the future as bench?
About to finish stockfish support as a stress tester. Results for ‘sbc-bench -s’ look like this now: http://ix.io/4fJQ
Currently thinking about how to collect valid results (the Rock 5B numbers above for example are BS since both throttling occured and due to the reliability issue with DRAM at 2112 MHz the score doesn’t represent RK3588 capabilities anyway).
Complete BS as all synthetic benches are what they are and none really emulate the complex apps and users patterns they run apart from the apps and user patterns.
As benches they are a perfectly good comparison as any other and just because TK does sbs-bench doesn’t suddenly mean all else is BS.
Indeed. Raspberry Pis are very popular and many find them efficient even though there have been arguments that they share the USB bandwidth and use legacy instruction set distros (32-bit ARM 6). None of this really matters in real life.
USB-bandwidth very much does matter. It doesn’t matter to everyone, but e.g. if you need to use both Ethernet and a USB HDD simultaneously on Rpi3 or earlier, both the Ethernet- and USB HDD-speeds will suffer and that definitely can be a problem for some users.
Making sweeping generalizations like that because it doesn’t matter for your personal usecases is ignorant.
Perhaps you should discover SPEC (@ spec.org).
@tkaiser is right, Drystone and Whetstone are long outdated.
Also, they should have used STREAM instead of mbw.
And, of course, compiler versions and compilation options matter a lot.
Maybe you should tell that to the kernel devs.
https://www.spinics.net/lists/devicetree/msg377945.html
All a benchmark is, is a intensive task for comparison and if you have a load of historical benchmarks the only way is to use the same benchmark recreating the same environ as best you can.
That is it as a benchmark is purely that comparison if you are testing for specific architecture features then pick those.
That TK is currently pushing his sbc-bench which would be really good apart from the toxicity that all else and everything is BS whilst all is needed is a benchmark fit for a short article for approx comparison really negates a lot of the great work and info he provides.
It was fit for purpose and if someone ones to provide more in depth benchmark info then do so.
[if it comes to garbage, don’t forget the surroundings]
benchmarks need continuity (and maybe a number for error correction on deviation errors), without comparison it’s [somewhat] useless information
The HK store says it has a 4 lane MIPI *DSI* (TBD), not CSI.
No network… another board for retro gaming?
As written here https://forum.odroid.com/viewtopic.php?f=176&p=358891
“over 70% of our sales come from B2B customers”
means selling to ordinary users is just small part of business.
It must be true for most SBC vendors.
It certainly is for the RPF. They said as much in a recent statement–how they’re focusing on supplying their partners over end user sales. This is nothing unique to HK. HK at least doesn’t pretend to be trying to support education as a primary goal.
Agree. At least they are more honest in this regards
Probably as with Raspberry thier commercial arm has been prioritised 100% whilst for a year retail has had near no stock.
No network = irrelevant for most usecases
That would be me. Without networking, I have no use for an SBC. I’d rather not have HDMI than Ethernet. But, everyone has different uses for these. I assume their big B2B customers wanted this and they’re just making it available to everyone just in case it works for us as well.
You can get a WiFi/BLE dongle for a couple of bucks.
some tell 10Mbps (duplex?) possible on SPI bus (GPIO?) or other optional adapter(?)
e.g. 7 wires I/O from 40pin compatible header
No proper casing that can support fanless operation for this version of N2 series?
If it wasn’t for the $35 shipping (which still waiting for a reply as if that is taxes included then guess not as bad) this was an instant buy.
I love the format and its a perfect ‘model-a’ layout that can still fit a relatively large common format heatsink on board.
The g52 MP6 is a really interesting GPU but hey Radxa this is what a Rock5a should look like as heard off another the NPU on the amlogic boards is very short of support.
Faster Single rank for embedded as why on space constrained boards do we often have 2x slow DDR chips whilst likely we are only increasing bandwidth?
I have never seen any PC benches that bench faster single rank vs slower double as it always seems to be like vs like as yeah double rank is better.
I am looking at the oDroid and now wondering why on embedded do we not just have faster single rank as a norm?
Maybe supply-chain problems drive this substitution?