Flávio Becker Posted June 29, 2018 Share Posted June 29, 2018 Hi, I've run armbianmonitor and this is the log: http://ix.io/1fpQ Link to comment Share on other sites More sharing options...
blackjam Posted July 1, 2018 Share Posted July 1, 2018 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 More sharing options...
Igor Posted July 4, 2018 Share Posted July 4, 2018 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 More sharing options...
makomk Posted July 10, 2018 Share Posted July 10, 2018 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 1 Link to comment Share on other sites More sharing options...
ag123 Posted September 20, 2018 Share Posted September 20, 2018 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 More sharing options...
Igor Posted September 21, 2018 Share Posted September 21, 2018 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 More sharing options...
ag123 Posted September 21, 2018 Share Posted September 21, 2018 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 More sharing options...
ag123 Posted September 21, 2018 Share Posted September 21, 2018 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 More sharing options...
Recommended Posts