Jump to content

WE NEED !YOUR! HELP


Recommended Posts

No problems here with a Cubieboard 1 on latest Xenial.

 

But I'm unable to execute armbianmonitor -u

 

I have this error:

 

/var/log/armhwinfo.log has been uploaded to <html>
 <head>
  <title>500 Internal Server Error</title>
 </head>
 <body>
  <h1>500 Internal Server Error</h1>
  The server has either erred or is incapable of performing the requested operation.<br /><br />

 </body>
</html>

 

Link to comment
Share on other sites

On 7/1/2018 at 10:05 PM, blackjam said:

No problems here with a Cubieboard 1 on latest Xenial.


This board is not supported anymore and it is not receiving BSP updates. That's why you got that error. It's safe to ignore.

Link to comment
Share on other sites

  • Igor unpinned this topic

Upgraded my Orange Pi One to the beta and it mostly seems to work as before, with a couple of issues:

 

[    5.717969] x_tables: section 3 reloc 5 sym 'mutex_lock': relocation 10 out of range (0xbf80008c -> 0xc080faf9)
[    5.750496] systemd[1]: Failed to insert module 'ip_tables': Exec format error

Some module loading failure caused by the module being loaded too far from the kernel code, not sure why this has started happening for me after the upgrade.

 

Also, the lack of working device tree overlay parameters makes the pps-gpio overlay unusable on this board, since the overlay's default pin PD14 isn't an interrupt pin and so pps-gpio fails to find the interrupt it needs. The underlying code works fine, there's just no way to use it without compiling a custom device tree overlay that uses a different pin (I chose PG9).  I also couldn't find a way to get armbian-add-overlay to work; there wasn't any obvious way to install kernel headers that included the device tree compiler it needs.

 

armbianmonitor log: http://ix.io/1gKB

Link to comment
Share on other sites

i'm not too sure if this is relevant, in nightly builds in the recent armbian update 5.59.180919 on orange pi pc

switching from the next-sunxi kernel (4.14.70) to dev-sunxi kernel (4.8.18)

results in the following symptoms:

dvfs:

in 4.18.8 cpu seem to run only between 2 frequencies 648mhz, 1ghz

while in 4.14.70 it is able to run in a range of frequencies 480khz to 1.29ghz

 

i did a check between the dtb files (decompiling it using dtc -I dtb -O dts /boot/dtb/sun8i-h3-orangepi-pc.dtb)

it turns out 4.18.8 do not have the operating point definitions that is there in 4.14.70

however, the dtb in 4.18.8 has some new definitions for csi (this may be good news for those wanting to try out the camera in the mainline kernel)

various other definitions also varies between 4.14.70 vs 4.18.8

edit:

found one of the answers: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/src/arm/sun8i-h3.dtsi?id=1dd2785450c025d11523a6108921355ce1524f01

 

hdmi-audio:

in 4.18.8, i couldn't select hdmi-audio in pulseaudio volume control (on x11 desktop)

while in 4.14.70 this is possible and i'm able to play a video with sound via hdmi audio

 

i've not yet figured out the root cause of the 'missing' hdmi audio issue.

 

my guess is 4.14.70 could be considered stable and 4.18.8 still considered development/experimental

armbianmonitor -u for

4.14.70 https://pastebin.com/3NLDHaFs

4.18.8 https://pastebin.com/BXpx5qXh

 

Link to comment
Share on other sites

4 hours ago, ag123 said:

my guess is 4.14.70 could be considered stable and 4.18.8 still considered development/experimental


4.14.y is more or less maintaining only while 4.18.y is WIP and will remain in that stage for months. Next LTS is 4.19.y anyway.

 

4 hours ago, ag123 said:

in 4.18.8 cpu seem to run only between 2 frequencies 648mhz, 1ghz

while in 4.14.70 it is able to run in a range of frequencies 480khz to 1.29ghz


Probably there is no regulator support? 

Link to comment
Share on other sites

6 hours ago, Igor said:


4.14.y is more or less maintaining only while 4.18.y is WIP and will remain in that stage for months. Next LTS is 4.19.y anyway.

 


Probably there is no regulator support? 

 

if i read this message

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/src/arm/sun8i-h3.dtsi?id=1dd2785450c025d11523a6108921355ce1524f01

Quote

ARM: dts: sun8i: h3: add operating-points-v2 table for CPU
The CPU on Allwinner H3 can do dynamic frequency scaling.
 

Add a DVFS table based on the one shipped with Allwinner's H3 SDK. The voltage-frequency relationship seems to be conservative, and Armbian has another DVFS table which uses lower voltage at a certain frequency. However, the official one is chosen for safety.

Frequencies higher than 1008MHz are temporarily dropped in the table, as they may lead to over voltage on boards without proper regulator settings or over temperature on boards with proper regulator settings. They will be added back once regulator settings are ready and thermal sensor driver is merged.

 

In order to satisfy all different regulators (SY8106A which is 50mV per level, SY8113B which have two states: 1.1V and 1.3V, and some board with non-tweakable regulators), all the OPPs are defined with a range which has the target value as the minimum allowed value, and 1.3V (the highest VDD-CPUX voltage suggested by the datasheet) as the maximum allowed value. It's proven to work well with a board with SY8113B.

it would not be correct to mark 4.18.8 as having no DVFS, but that this is WIP. Hence, we may anticipate further updates to this such as adding the 'missing' frequency bands. in this sense 4.18.8 use a 'safe' range of operating points between 648mhz and 1ghz (but not beyond) (for now).

 

Orange pi one may run at lower temperatures, and some users may like that as they may be able to do away with the hassle of adding a heat sink. But users used to the performance orange pi pc, pi one etc would too soon discover that the higher frequencies of 1.2 ghz isn't used giving a minor loss of performance.

 

Hdmi sound

Hdmi sound is 'missing' in 4.18.8 but it is there in 4.14.70.

I've not figured this out yet, it would be good if someone help to find out what cause it to be 'lost' and perhaps document it in a post here. e.g. is the problem in the dts for the boards? after it is 'discovered' i think patches could even be submitted to upstream in mainline (i.e. the kernel dts sources itself). But if anyone use the 4.18.8 kernel and wants the hdmi audio, they could then apply a patch e.g. against the dts source, recompile it and replace the dtb in /boot/dtb

I've marked hdmi as 'yes' for orangepipc in 4.18.8 as basically video works, but I'd think some users would consider it a defect and wants hdmi audio added back

Link to comment
Share on other sites

it seem the hdmi sound issue is related to this patch

https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-add-HDMI-sound-nodes-DT.patch

the main thing is the status = 'disabled' entries, i'm not too sure if there are other related kernel configs which may matter

Spoiler

 
+    sound_hdmi: sound {
+        compatible = "simple-audio-card";
+        simple-audio-card,format = "i2s";
+        simple-audio-card,name = "allwinner,hdmi";
+        simple-audio-card,mclk-fs = <256>;
+        status = "disabled";
+
+        simple-audio-card,codec {
+            sound-dai = <&hdmi>;
+        };
+
+        simple-audio-card,cpu {
+            sound-dai = <&i2s2>;
+        };
+    };
 
...
+        i2s2: i2s@1c22800 {
+            #sound-dai-cells = <0>;
+            compatible = "allwinner,sun8i-h3-i2s";
+            reg = <0x01c22800 0x400>;
+            interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&ccu CLK_BUS_I2S2>, <&ccu CLK_I2S2>;
+            clock-names = "apb", "mod";
+            dmas = <&dma 27>;
+            resets = <&ccu RST_BUS_I2S2>;
+            dma-names = "tx";
+            status = "disabled";
+        };
+
+

 

unfortunately i tried decompiling the dtb in /boot/dtb/sun8i-h3-orangepi-pc.dtb changing them to status = "okay" in my copy and replacing the dtb but thus far i did not manage to find the additional hdmi sound device after reboot. hence, this is not conclusive. it seemed there is also a mixer1 section that is missing in the decompiled dts

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines