• 0

Odroid N2+ / N2 Plus


NicoD
 Share

2 2

Question

Armbianmonitor:

Hi all. 
I've recently received the Odroid N2+. Since nobody else started a topic about it, I'll be the one. 
All works fine with Armbian since not much hardware changes have been made vs the N2. Except for the CPU frequency.

 

With the Odroid Ubuntu you can set it to 2.4Ghz for the big cores A73 as overclock (2208 stock)., and 2016Mhz for the A53 cores (1908  stock). 


With Armbian the max clocks are 2Ghz for all cores. Using Armbian Focal 4.9 legacy.
I tried setting the higher values in config.ini. Also tried with the "meson64_odroidn2_plus.dtb" file from the Odroid Ubuntu. Doesn't boot with that. (What do I know :D)

Other changes are the RTC battery that's now on the board. 
The heatsink has changed a little. But it's still more than sufficient to keep it cool even when overclocked. 


USB3 still rather s*cks on it. Slow and a lot of issues with 2.4Ghz dongles(wifi/keyboard...).
Too bad they didn't do anything about that. But that probably could have complicated compatibility with N2 images. 

Also feels a bit more sluggish than RK3399 on NVMe vs 128GB eMMC on the N2+.  That's what fast I/O does. I'll try on USB3-NVMe later.

Here some pictures. 1st pic the N2+ with its case open.
2nd picture the N2 left and the N2+ on the right.

DSCN6203.JPG.f766627dc0dcce9fbbb100793d06f4f8.JPGDSCN6207.JPG.4b5bda2e09c73a78971e4dd9fa4f9579.JPG
Cheers all.

Link to post
Share on other sites

Recommended Posts

  • 0

Hello,

 

i have the newest Armbian Image for N2+ from Feb 4 2021.

ive tried to set the CPU Frequency to 2400 Mhz and 2016 Mhz for the a53 cores.  But htop is showing the maximum frequncy of 2,21 Ghz and 1,8 Ghz. Ive set it in the boot ini. I dont know much about linux. Can someone provide me a way how i can set the frequcny to the overclocked 2400 Mhz and 2016Mhz. 

 

Thanks in advace. 

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0
5 hours ago, liose said:

Hello,

 

i have the newest Armbian Image for N2+ from Feb 4 2021.

ive tried to set the CPU Frequency to 2400 Mhz and 2016 Mhz for the a53 cores.  But htop is showing the maximum frequncy of 2,21 Ghz and 1,8 Ghz. Ive set it in the boot ini. I dont know much about linux. Can someone provide me a way how i can set the frequcny to the overclocked 2400 Mhz and 2016Mhz. 

 

Thanks in advace. 

 

Do you have N2+? If you don't, you can't overclock to N2+ values. Just to N2 overclocking values.

Link to post
Share on other sites

  • 0

This has to be set

 

# max cpu frequency in MHz unit
if test "${variant}" = "n2_plus"; then
        setenv fdtfile meson-g12b-odroid-n2-plus.dtb
        setenv max_freq_a73 "2400"
        setenv max_freq_a53 "2016"
else
        setenv fdtfile meson-g12b-odroid-n2.dtb
        setenv max_freq_a73 "1800"
        setenv max_freq_a53 "1896"
fi


... but I it looks like it doesn't work anymore. I found the problem. Will be fixed at next release.

 

Edit: Tested

Spoiler

  ___      _           _     _   _   _ ____       
 / _ \  __| |_ __ ___ (_) __| | | \ | |___ \  _   
| | | |/ _` | '__/ _ \| |/ _` | |  \| | __) || |_ 
| |_| | (_| | | | (_) | | (_| | | |\  |/ __/_   _|
 \___/ \__,_|_|  \___/|_|\__,_| |_| \_|_____||_|  
                                                  
Welcome to Armbian 21.02.0-trunk.100 Focal with Linux 5.10.15-meson64

No end-user support: untested automated build

System load:   22%           	Up time:       0 min		
Memory usage:  4% of 3.55G  	IP:            
CPU temp:      46°C           	Usage of /:    8% of 29G    	

Last login: Wed Feb 10 18:15:29 2021 from 10.0.10.8
root@odroidn2:~# cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.02 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.02 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:44.10%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:55.90%  (8)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.02 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.02 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:44.10%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:55.90%  (8)
analyzing CPU 2:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.40 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz, 2.11 GHz, 2.21 GHz, 2.30 GHz, 2.40 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:10.65%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:0.00%, 2.11 GHz:0.00%, 2.21 GHz:0.00%, 2.30 GHz:0.00%, 2.40 GHz:89.35%  (6)
analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.40 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz, 2.11 GHz, 2.21 GHz, 2.30 GHz, 2.40 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:10.65%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:0.00%, 2.11 GHz:0.00%, 2.21 GHz:0.00%, 2.30 GHz:0.00%, 2.40 GHz:89.35%  (6)
analyzing CPU 4:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.40 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz, 2.11 GHz, 2.21 GHz, 2.30 GHz, 2.40 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:10.65%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:0.00%, 2.11 GHz:0.00%, 2.21 GHz:0.00%, 2.30 GHz:0.00%, 2.40 GHz:89.35%  (6)
analyzing CPU 5:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 2.40 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz, 1.91 GHz, 2.02 GHz, 2.11 GHz, 2.21 GHz, 2.30 GHz, 2.40 GHz
  available cpufreq governors: conservative, powersave, ondemand, userspace, performance, schedutil
  current policy: frequency should be within 1000 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 667 MHz:0.00%, 1000 MHz:10.65%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:0.00%, 1.91 GHz:0.00%, 2.02 GHz:0.00%, 2.11 GHz:0.00%, 2.21 GHz:0.00%, 2.30 GHz:0.00%, 2.40 GHz:89.35%  (6)

 

 

Link to post
Share on other sites

  • 0

Hello forum,

I am new to Armbian. Selected it for my Odroid N2+ because I need high CPU performance for a virtual piano software and current Armbian Buster comes with 2.4 GHz.

I'd like to share my alsa settings for the analog stereo output of the N2+.

Could not find much info on the net, but at least I have analog sound now at the 3.5mm TRS-jack -- don't know really, why it works, but it does :)

Created a /etc/asound.conf with

pcm.!default {
        type plug
        slave {
        pcm "hw:0,1"
        }
}

(sets analog stereo device as default).

The alsamixer settings I made manually. The following is the output of the command amixer:

Simple mixer control 'ACODEC',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 222 [87%] [-12.33dB] [on]
  Front Right: Playback 222 [87%] [-12.33dB] [on]
Simple mixer control 'ACODEC Left DAC Sel',0
  Capabilities: enum
  Items: 'Left' 'Right'
  Item0: 'Left'
Simple mixer control 'ACODEC Mute Ramp',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'ACODEC Playback Channel Mode',0
  Capabilities: enum
  Items: 'Stereo' 'Mono'
  Item0: 'Stereo'
Simple mixer control 'ACODEC Ramp Rate',0
  Capabilities: enum
  Items: 'Fast' 'Slow'
  Item0: 'Fast'
Simple mixer control 'ACODEC Right DAC Sel',0
  Capabilities: enum
  Items: 'Right' 'Left'
  Item0: 'Right'
Simple mixer control 'ACODEC Unmute Ramp',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_A SINK 1 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 1'
Simple mixer control 'FRDDR_A SINK 2 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_A SINK 3 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_A SRC 1 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'FRDDR_A SRC 2 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_A SRC 3 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_B SINK 1 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 2'
Simple mixer control 'FRDDR_B SINK 2 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_B SINK 3 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_B SRC 1 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'FRDDR_B SRC 2 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_B SRC 3 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_C SINK 1 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 3'
Simple mixer control 'FRDDR_C SINK 2 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_C SINK 3 SEL',0
  Capabilities: enum
  Items: 'OUT 0' 'OUT 1' 'OUT 2' 'OUT 3' 'OUT 4' 'OUT 5' 'OUT 6' 'OUT 7'
  Item0: 'OUT 0'
Simple mixer control 'FRDDR_C SRC 1 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'FRDDR_C SRC 2 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'FRDDR_C SRC 3 EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'TDMIN_A SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7' 'IN 8' 'IN 9' 'IN 10' 'IN 11' 'IN 12' 'IN 13' 'IN 14' 'IN 15'
  Item0: 'IN 0'
Simple mixer control 'TDMIN_B SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7' 'IN 8' 'IN 9' 'IN 10' 'IN 11' 'IN 12' 'IN 13' 'IN 14' 'IN 15'
  Item0: 'IN 0'
Simple mixer control 'TDMIN_C SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7' 'IN 8' 'IN 9' 'IN 10' 'IN 11' 'IN 12' 'IN 13' 'IN 14' 'IN 15'
  Item0: 'IN 0'
Simple mixer control 'TDMIN_LB SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7' 'IN 8' 'IN 9' 'IN 10' 'IN 11' 'IN 12' 'IN 13' 'IN 14' 'IN 15'
  Item0: 'IN 0'
Simple mixer control 'TDMOUT_B Gain Enable',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'TDMOUT_B Lane 0',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_B Lane 1',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_B Lane 2',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_B Lane 3',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_B SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2'
  Item0: 'IN 0'
Simple mixer control 'TDMOUT_C Gain Enable',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'TDMOUT_C Lane 0',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_C Lane 1',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_C Lane 2',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_C Lane 3',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'TDMOUT_C SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2'
  Item0: 'IN 1'
Simple mixer control 'TOACODEC Lane Select',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 3
  Mono: 0 [0%]
Simple mixer control 'TOACODEC OUT EN',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'TOACODEC SRC',0
  Capabilities: enum
  Items: 'I2S A' 'I2S B' 'I2S C'
  Item0: 'I2S C'
Simple mixer control 'TODDR_A SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7'
  Item0: 'IN 0'
Simple mixer control 'TODDR_B SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7'
  Item0: 'IN 0'
Simple mixer control 'TODDR_C SRC SEL',0
  Capabilities: enum
  Items: 'IN 0' 'IN 1' 'IN 2' 'IN 3' 'IN 4' 'IN 5' 'IN 6' 'IN 7'
  Item0: 'IN 0'
Simple mixer control 'TOHDMITX',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'TOHDMITX I2S SRC',0
  Capabilities: enum
  Items: 'I2S A' 'I2S B' 'I2S C'
  Item0: 'I2S B'
Simple mixer control 'TOHDMITX SPDIF SRC',0
  Capabilities: enum
  Items: 'SPDIF A' 'SPDIF B'
  Item0: 'SPDIF A'

System: Armbian 21.02.4 Buster with Linux 5.10.27-meson64

Great project!
Thank you all!

Link to post
Share on other sites

  • 0

The Odroid N2+ has a serial port, that I would like to use for MIDI input. At the moment this is impossible, because MIDI requires 31250 baud, but Armbian - like the most other OS - supports only standard rates like 38400 baud.

On my Armbian Buster current it is /dev/ttyAML1 at pin 8 and 10 of the 40-pin J2. It has 9600 baud per default and I can exchange serial data with my Laptop (minicom, usb-to-serial, /dev/ttyUSB0). Fine to this point.

But how to change the baudrate to the 31250?
I found a nice hack for hardkernels legacy Ubuntu, where the meson_uart.c is patched that it works actually with 31250 baud when 38400 baud is selected.
Odroid N2 UART Custom Baud Rate for MIDI
Just for demonstration:

...
static void meson_uart_change_speed(struct uart_port *port, unsigned long baud)
{
    u32 val;
    struct meson_uart_port *mup = to_meson_port(port);
    struct platform_device *pdev = to_platform_device(port->dev);

    while (!(readl(port->membase + AML_UART_STATUS) & AML_UART_TX_EMPTY))
        cpu_relax();

#ifdef UART_TEST_DEBUG
    if (port->line != 0)
        baud = 115200;
#endif

    // this part is added.
    // trace_printk() is not neccesarry, it is just for debugging.
    trace_printk("Your baudrate: %ld\n", baud);
    if(baud == 38400)
    {
        baud = 31250;
        trace_printk("Change to %ld\n", baud);
    }

...

But I can't find similar code in my build of Armbian Buster current:
~/build/cache/sources/linux-mainline/linux-5.10.y/drivers/tty/serial/meson_uart.c
--> https://pastebin.com/raw/gEJt1reB

Will it be impossible to hack the meson_uart.c in Armbian, that it supports "baud = 31250"?

My serial/UART in dmesg:

[...]
[    0.943915] soc soc0: Amlogic Meson G12B (S922X) Revision 29:c (40:2) Detected
[...]
[    0.945359] VCC_3V3: supplied by VDDAO_3V3
[    0.945394] FLASH_1V8: supplied by VCC_3V3
[    0.945423] VCC_1V8: supplied by VCC_3V3
[    0.945450] VDDAO_1V8: supplied by VDDAO_3V3
[    0.945494] VDDCPU_A: supplied by regulator-dummy
[    0.945917] VDDCPU_B: supplied by regulator-dummy
[    0.946680] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.949136] Serial: AMBA driver
[    0.949436] ff803000.serial: ttyAML0 at MMIO 0xff803000 (irq = 25, base_baud = 1500000) is a meson_uart
[    0.949552] printk: console [ttyAML0] enabled
[    0.950111] ffd24000.serial: ttyAML1 at MMIO 0xffd24000 (irq = 33, base_baud = 1500000) is a meson_uart
[...]

It is Armbian 21.08.0-trunk Buster with Linux 5.10.32-meson64.

My C-programming is more than limited, sorry, but I can compile a linux kernel or Armbian image if needed. Serial MIDI-input with an Armbian powered N2+ would be a dream machine!

 

Kind regards

Link to post
Share on other sites

  • 0
1 hour ago, Odroidian said:

a serial port, that I would like to use for MIDI input.

I like what you are trying. 
I use a presonus USB audiobox on N2+ and it works great.
I know there are USB to MIDI converters. Not much difference between serial uart and usb. So I do think your idea could work. I'd use USB for ease of use. Good luck.

Link to post
Share on other sites

  • 0

Just from analogy ... could that work?

 

static void meson_uart_change_speed(struct uart_port *port, unsigned long baud)
{
	u32 val;

	while (!meson_uart_tx_empty(port))
		cpu_relax();

	/* Would this force 38400 to 31250 for MIDI? */
	if (baud == 38400) {
		baud = 31250;
	}

	if (port->uartclk == 24000000) {
		val = ((port->uartclk / 3) / baud) - 1;
		val |= AML_UART_BAUD_XTAL;
	} else {
		val = ((port->uartclk * 10 / (baud * 4) + 5) / 10) - 1;
	}
	val |= AML_UART_BAUD_USE;
	writel(val, port->membase + AML_UART_REG5);
}

 

Link to post
Share on other sites

  • 0

It works!

I tested the quick and dirty hack. Okay, not quick. I had to compile the  Buster minimal image two times, because my change was overwritten when ./compile.sh downloads the sources. The second time I waited until the download had finished and the kernel's menuconfig popped up. In this pause I edited meson_uart.c and removed meson_uart.o.

When I now set the UART to 38400 baud ...

stty -F /dev/ttyAML1 38400

... it actually outputs with 31250 baud, for example when I enter some characters with minicom running on the Odroid N2+:

 

tty-AML1forcedto31250baud.png

 

With the program ttymidi I am able to read the input (RX) of /dev/ttyAML1 and to connect it to ALSA. My virtual piano software is presenting a new MIDI input then (with the name "midi out").

ttymidi -s /dev/ttyAML1 -b 38400

Probably it is not necessary to compile the whole Armbian image, but I don't know so far how to compile and install the kernel only.

I guess I have to "freeze" my image now in some kind, so that my change is not overwritten by accident in the future.

Feel free to give me some advice what could have been done better.


PS: Now on minimal Armbian_21.08.0-trunk_Odroidn2_buster_current_5.10.32.img

Link to post
Share on other sites

  • 0

I receive "No end-user support: built from trunk" at MoTD even though I used a stable and recommended img: Armbian_21.05.4_Odroidn2_buster_current_5.10.43.img. Is that correct given it's a stable build?

 

Furthermore, I've received a kernel panick - not syncing: kernel stack overflow "Insufficient stack space to handle exception!".  Are the logs saved a place? Can't find it in journalctl. 

 

 

Link to post
Share on other sites

  • 0
6 hours ago, Z11ntal33r said:

I receive "No end-user support: built from trunk" at MoTD even though I used a stable and recommended img

Needs to be checked. https://armbian.atlassian.net/browse/AR-822?atlOrigin=eyJpIjoiZWQzYjJiZjM3NDEwNDY5Y2IxMzI2ZWRiZTRlZDRmYjciLCJwIjoiaiJ9

 

6 hours ago, Z11ntal33r said:

Furthermore, I've received a kernel panick - not syncing: kernel stack overflow "Insufficient stack space to handle exception!".  Are the logs saved a place? Can't find it in journalctl. 

To reduce wear on sdcard logs are written to a ramdisk and only synced periodically. To debug such things the best way is to put a serial console to it and log everything from there.

Link to post
Share on other sites

  • 0

As I didn't find a more suitable thread to ask my bit of questions about the odroid-n2+...:


 

1) When I use my Buster image with 5.6 Kernel from my Odroid-N2 and plug it into the Odroid-n2+, the result is that the device starts, but has no working Ethernet. When I try to ifconfig eth0 up it never finishes. Again: Can somebody advise me what to do about that?

 

2) Maybe not N2 specific, but I never had that on my Banana Pi or Odroid C2: When I make a backup of my 64GB MicroSD card using DD, Etcher cant write the image back: The MicroSD card is too small by a few MB. Even a new card of the same model is reported as too small. Can somebody explain this to me? How can I strip the image of empty space to get it writable onto the card?

 

Any help muchly appreciated!

Link to post
Share on other sites

  • 0
21 hours ago, Ruediger said:

1) When I use my Buster image with 5.6 Kernel from my Odroid-N2 and plug it into the Odroid-n2+, the result is that the device starts, but has no working Ethernet. When I try to ifconfig eth0 up it never finishes. Again: Can somebody advise me what to do about that?

Where did you find that image? Seems old.
These days there's a script that checks if it's the N2 or N2+ and then loads the correct devicetree.
But with old images (usually in config.txt) you had to manually select the correct device.
My advice would be to use a more recent image.
 

 

21 hours ago, Ruediger said:

2) Maybe not N2 specific, but I never had that on my Banana Pi or Odroid C2: When I make a backup of my 64GB MicroSD card using DD, Etcher cant write the image back: The MicroSD card is too small by a few MB. Even a new card of the same model is reported as too small. Can somebody explain this to me? How can I strip the image of empty space to get it writable onto the card?

You need to decrease the size of your sd partition to do this correct.
Safest way to do this is using another image on another sd/eMMC. Then use gparted to resize the partition so there's almost no free space. Then create the backup image.
Then set the patition size again to original.
The same when you burn the image to sd-card. Resize the partition with gparted.

Link to post
Share on other sites

  • 0
Am 8.3.2022 um 19:42 schrieb NicoD:

Where did you find that image? Seems old.
These days there's a script that checks if it's the N2 or N2+ and then loads the correct devicetree.
But with old images (usually in config.txt) you had to manually select the correct device.
My advice would be to use a more recent image.
 

 

You need to decrease the size of your sd partition to do this correct.
Safest way to do this is using another image on another sd/eMMC. Then use gparted to resize the partition so there's almost no free space. Then create the backup image.
Then set the patition size again to original.
The same when you burn the image to sd-card. Resize the partition with gparted.

 

 

Well, it is the operating image of my Odroid-N2 that I wanted to move to my Odroid-N2+

The problem is that there's 5 years of additional services and modifications in the system, and as I am no longer a student I do not have the time needed to analyse what I did and then trying to recreate it.

 

The DTD seems to have helped: I got ethernet working and was now able to update to

Linux odroid-n2 5.10.81-meson64 #21.08.6
 

So, operation on the same level as on the n2 is now possible again.

Updating the DTD however did not make it possible to select the 2.4GHz speed for the 4 big cores.

I modified that in the boot.ini file, but the system ignores that, even after a full update to Bullseye - which worked, debian typical, like a charm.

 

So my next question is:

Where does the system actually set the CPUs speed if not in the boot.ini file?

 

 

 

As for decreasing the partition sizes, this does not decrease the resulting image file size.

When I would make a backup of only the partition, that would help.

But a sole partition backup doesn't create a bootable sdcard.

I suspect the uboot header isn't part of the partition, but the drive.

Only when I make an image of the whole drive, can I  write the image back ( each time on a larger drive, I worked my way up from a 8GB card to 128BG by now ) and have a bootable system.

 

So far it didnt bother me, but the next size a 256GB card will get expensive and the read/write times start to get ridiculous.

 

Link to post
Share on other sites

  • 0
19 hours ago, Ruediger said:

Where does the system actually set the CPUs speed if not in the boot.ini file?

Should be something like this.
 

# max cpu frequency in MHz unit
if test "${variant}" = "n2_plus"; then
	setenv fdtfile meson-g12b-odroid-n2-plus.dtb
	setenv max_freq_a73 "2208"
	setenv max_freq_a53 "1908"
else
	setenv fdtfile meson-g12b-odroid-n2.dtb
	setenv max_freq_a73 "1800"
	setenv max_freq_a53 "1896"
fi


If you create an image, it only does the used disk space. Not the unused. So that's why I'm saying to decrease the partition size and then make the backup image. That is how Armbian images start. But there is a tool that expands the partition to full disk size at first boot.

And check a new image to see how everything is done to see if it's n2 or n2+. I'm not sure where the "${variant}" is declared.
I don't think that will be done on your image since older than that script.

Link to post
Share on other sites

  • 0
vor 1 Stunde schrieb NicoD:

Should be something like this.
 

# max cpu frequency in MHz unit
if test "${variant}" = "n2_plus"; then
	setenv fdtfile meson-g12b-odroid-n2-plus.dtb
	setenv max_freq_a73 "2208"
	setenv max_freq_a53 "1908"
else
	setenv fdtfile meson-g12b-odroid-n2.dtb
	setenv max_freq_a73 "1800"
	setenv max_freq_a53 "1896"
fi


If you create an image, it only does the used disk space. Not the unused. So that's why I'm saying to decrease the partition size and then make the backup image. That is how Armbian images start. But there is a tool that expands the partition to full disk size at first boot.

And check a new image to see how everything is done to see if it's n2 or n2+. I'm not sure where the "${variant}" is declared.
I don't think that will be done on your image since older than that script.

Well, as for the speed issue, I grabbed this:

# max cpu frequency for big core, A73 in MHz unit
# setenv max_freq_a73 "2004"  # 2.004 GHz
# setenv max_freq_a73 "1992"  # 1.992 GHz
# setenv max_freq_a73 "1908"  # 1.908 GHz
setenv max_freq_a73 "2400"  # 1.8 GHz, default value
# setenv max_freq_a73 "1704"  # 1.704 GHz

# max cpu frequency for little core, A53 in MHz unit
setenv max_freq_a53 "1992"  # 1.992 GHz
# setenv max_freq_a53 "1896"  # 1.896 GHz, default value
# setenv max_freq_a53 "1704"  # 1.704 GHz

 

from a current image, as in my own older image there were just slower speeds given. So, with the newer image I thought that would work, too.

However, the syste mstill runs at a mere 1908 MHz - both large and small cores.

 

As for the image sinze:

when I do

dd if=/dev/sdc  of=/media/backup/64gbmsd.img bs=1M

I cannot write /media/backup/64gbmsd.img back to /dev/sdc with etcher because the file is larger than the drive.

I have to use a larger microsd card to write it. The resulting card does boot without problems.

Shrinking the partitions doesn't affect this, as the partitions are a subset of the drive.

When I just do

dd if=/dev/sdc1  of=/media/backup/armbian.img bs=1M

the resulting img file is just 7.2GB in size, and can be written back with etcher, but the system doesn't boot from the resulting card.

 

What I need is the trick how the armbian images do not contain empty space. Enlarging them I can do easiyl later on, thats not a issue. But I need to get the image stripped of al lthe empty space.

And zipping or other compressions dont work because, on unpacking ,al lthe empty space is back and Etcher will need again a card larger than the one the image was made from - as described above.

 

Link to post
Share on other sites

  • 0
On 3/10/2022 at 11:25 PM, Ruediger said:

What I need is the trick how the armbian images do not contain empty space.

No "trick" is required, dd only the space occupied from the start of the raw device up to the end of the last partition. The "count=..." Parameter of dd is your friend. See "man dd" for reference.

Link to post
Share on other sites

  • 0
Am 12.3.2022 um 08:10 schrieb usual user:

No "trick" is required, dd only the space occupied from the start of the raw device up to the end of the last partition. The "count=..." Parameter of dd is your friend. See "man dd" for reference.

 

After realizing that I'm obviously very bad at understanding the way they count for DD, I got the image copied to a smaller card without the filesystem being corrupted or anything else.

I am now back on a 64GB Card instead of the last current 128GB card, so, yay!

I should be able to clean up the system and discard trash, and then I maybe even can get back to a 32GB card.

 

So: Thank you @usual userand @NicoD!

Now I still have a question left.

I compared the old boot.ini of my system and then copied the one from a current image into its place. The major change there was the addition of this sequence:

# Show what uboot default fdtfile is
echo "U-boot default fdtfile: ${fdtfile}"
echo "Current variant: ${variant}"

# there is a mismatch between u-boot and kernel in the n2-plus/n2_plus DTB filename.
# Also u-boot can't seem to decide between having, or not, 'amlogic/' in there.
if test "${variant}" = "n2_plus"; then
       setenv fdtfile "amlogic/meson-g12b-odroid-n2-plus.dtb"
       echo "For variant ${variant}, set default fdtfile: ${fdtfile}"
fi

if test "${variant}" = "n2-plus"; then
       setenv fdtfile "amlogic/meson-g12b-odroid-n2-plus.dtb"
       echo "For variant ${variant} (dash version, 2021.07 or up), set default fdtfile: ${fdtfile}"
fi


I am admittedly confused that boot.ini and boot.cmd contain and set pretty much similar settings.

I fixed the boot.cmd setting s to reflect what I found in the newer image ( a53 and a73 cores instead of references to a55 cores - I have no idea where that boot.cmd originated from ) and now hope that once the servers current business is finished and the next restart comes up, the N2+ will finally start running at its full 2.4GHz instead of a pesky 1.8GHz .

 

Should I maybe move al lfiles obviously from older images ( simply compared to a current one ) into a folder like "OLD" as to see if maybe interference with old copnfig files stops the device from running at full speed?
 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

2 2