All Activity
This stream auto-updates
- Today
-
I have a 5.2V 2.5A supply that I use (same one I use for my RPi). I hard-booted without an HDMI cable attached, and current dropped by 10mA to 0.206mA with no devices plugged in (except for ethernet). I'll probably live with what I have for now, but getting down to .125 at idle would be really impressive.
- Yesterday
-
should we be explicitly setting CPUMIN/CPUMAX in all board configs?
5kft replied to 5kft's topic in Development
I like that idea! However as @tkaiser notes it'd probably be overkill for the number of people that would actually use it (i.e., just me) -
should we be explicitly setting CPUMIN/CPUMAX in all board configs?
5kft replied to 5kft's topic in Development
Yes, I think that you are right - LOL! OK, thank you very much! This is exactly the perspective I was looking for. I was originally planning on doing a simple sed line in rc.local to comment this out (followed by a service restart), but wanted to ask this question first just in case. One could argue that for some boards we keep CPUMIN/CPUMAX defined (as you note), and for others (thoroughly tested) they could be removed, but it is also wise to be as careful and conservative as possible when it comes to this, as we don't want to introduce instability or unintended side effects. Thanks again -
should we be explicitly setting CPUMIN/CPUMAX in all board configs?
chwe replied to 5kft's topic in Development
maybe a script in rc6.d (at reboot) together with an entry in armbian-config? most likely BSP gets updated with the kernelupdate right? So you'll reboot the board anyway. Not sure if someone ever wrote an startscript in rc6 and if this is sane.. :S -
should we be explicitly setting CPUMIN/CPUMAX in all board configs?
tkaiser replied to 5kft's topic in Development
Honestly: I think you're the only one doing this The reasons to specify these settings are as follows: CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough) CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary) I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon. -
What power supply are you using? ARe your numbers from a programmable DC power supply? Normally not having HDMI connected at boot will usually cause the pipeline to turn off. You can also see the schematics here: https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing
-
@Da Xue Do you have an example configuration of how to disable HDMI? Those are pretty sizeable gains compared to what I'm currently seeing. Also, I'm trying to figure out if overlays are supported for the DTB? I can rebuild the DTB, but it means I need to maintain it long term, and I'd rather not need to rebuild the DTB every time I update the kernel if I can avoid it.
-
should we be explicitly setting CPUMIN/CPUMAX in all board configs?
5kft posted a topic in Development
I'm curious as to why we explicitly specify CPUMIN and CPUMAX values in the Armbian board configs, for most/all boards... These values of course propagate their way into the MIN_SPEED and MAX_SPEED settings in the target /etc/default/cpufrequtils configuration file (e.g., see lib/makeboarddeb.sh). If these values aren't specified, then the cpufreq driver will base its speed ranges on what the underlying H/W supports (e.g., specified via the board DT(s)). So...if the underlying driver configuration provides the supported speed range, then we actually need to specify these values? I ask because I'm running my H5 boards with my overlays that increase the maximum clock rates to 1.3GHz/1.4GHz, and every time I do an Armbian nightly upgrade and the BSP package is upgraded, I have to re-edit /etc/default/cpufrequtils and remove the MAX_SPEED line (e.g., from the default of 816MHz). It seems like this should not be necessary as the DT already configures the correct/supported maximum speed... Would it make sense to remove some of these explicit configuration settings for boards that we know will operate correctly based on the DT configs (e.g., edit config/boards/...conf appropriately?) Anyway just a question/thought...thanks! -
Turning off HDMI will get you pretty big gains since the display output pipeline can be turned off. The lowest I've achieved using that basic tweak is to get it down to 125mA.
-
Thanks a lot! I finally fixed my eMMC problem. Booting into MASKROM and erasing flash by using Chinese Rockchip Tool let me install armbian again to eMMC. I had some problems identifying the device with the Rockchip utility. Switching from Win10 to old Win7 laptop fixed connection issues. Now trying to configure armbian as my new ‚all-in-one‘ livingroom device. Are there experiences with running Kodi on armbian?
-
Thanks a lot, wifi works well now with fw_bcm4339a0_ag.bin from github! In fact those files where in /lib/firmware/brcm/ (as asked by martinayotte) and not in /lib/firmware/ap6335/brcm/. I use the ones you told me to download, but I suppose that those in /lib/firmware/brcm/ should also work. You did something special to use this path?
-
Right ! I've more than 10 around : some FT232, some CH340, some PL2303 and some CP2102 ...
-
that's not a solution, that's a workaround.. and IMO a shitty one due to wifi for the OPi zero can be.... uncool If it would be my board, I would prefer to have this fixed befor wifi might quit in the future.. Just as a first one 'sudo armbianmonitor -u' can be helpful see comment at the download page: USB gadget mode can be something to test.. And as @martinayotte mentions everytime, and I second that: spending 1-2$ for an USB to UART adapter is it worth when working with SBCs.
-
Yes, you are missing the appropriate firmware files. My box has AP6330, which is manufactured by AmPak and is actually a combo of broadcom chips. In my case it has the BRCM4330 wifi chip and BCM40183 for bluetooth. In your case you have a hint by the brcmfmac driver telling you it is expecting brcmfmac4339-sdio binary file. Now the first thing to do is some tidying up. On your box edit the file /boot/armbianEnv.txt and change this line: extraargs=brcmfmac.alternative_fw_path=ap6330 cma=64M into this line: extraargs=brcmfmac.alternative_fw_path=ap6335 cma=64M This way we are telling the brcmfmac driver to find all its things into /lib/firmware/ap6335/brcm path. Now you can grab the necessary firmware files from this repository: https://github.com/rockchip-linux/rkwifibt/tree/master/firmware/broadcom/all In particular you will need to: download the firmware blob fw_bcm4339a0_ag.bin into /lib/firmware/ap6335/brcm/brcmfmac4339-sdio.bin (you may also try fw_bcm4339a0_ag_apsta.bin or fw_bcm4339a0_ag_p2p.bin) download the nvram configuration nvram_AP6335.txt into /lib/firmware/ap6335/brcm/brcmfmac4339-sdio.txt after a reboot (or modprobing the module) you should have done a step forward to get the wifi working. A last note: It is possible that you also get bluetooth. At the moment there is a systemd service (ap6330-bluetooth) that loads the bluetooth firmware binary used on the AP6330. In the lucky case the firmware is compatible you also get free bluetooth, but I don't guarantee anything on this.
-
Yes with many other brcmfac variants.
-
The main repository was updated to 5.60 at this moment.
-
How can I set the watchdog timeout of H2/H3 to 16 seconds ?
rufik replied to edupv's topic in Allwinner H2 & H3
How is your watchdog doing? Does it work reliable over the time? -
I retried above case again with orange pi zero using armbian bionic and stretch. The phenomenon happen on both image. Additional things that I found out is that : after first boot : armbianEnv.txte created, armbianEnv.txt still has original content after second boot: armbianEnv.txt content replaced with sshd_config
-
armbian creating armbianEnv.txte after first boot Hi, this is my first post in this forum, I don't know if this is the correct thread, but I just trying fresh Armbian 5.59 next on nanopim1, orangepi zero dan nanopiduo. After first boot, armbianEnv.txt content is replaced with these : # $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sb and armbianEnv.txte file is created with content from original armbianEnv.txt. I verify that armbianEnv.txte is not exist on sd card just after flashing. I tried with 4 Sandisk brand and I can replicate the phenomenon. Is this a bug ?
-
WiFi access point (hostapd) with kernel 4.18 and 4.19.
Igor replied to ap17's topic in Mainline kernel
https://docs.armbian.com/Process_Contribute/ -
repository and current stable image inconsistent
Igor replied to vjacheslav's topic in Common issues
There will be an update to 5.60 in a few hours. Then this will work OOB. -
well, I probably need a coffee first.. didn't get that much sleep tonight.. He should stated it that the repo us currently private and will be opened in the next x days. Would make things easier.. But well it's public now: Kernel: patchlevel 119 --> head is at 127 that's okay (or surprisingly high IMO) there's no much of a githistory for this kernel the dts are refracted hardly.. but overall DT stuff looks quite properly made.. (I didn't saw any License headers in all related dts files) U-boot v2015.07 (as expected.. SoC makers don't give a shit about recent u-boot versions but it should understand ext4) boardconfig may need some fixing in their current scripts u-boot uses the provided toolchain. The makefile may need some fixing and hopefully u-boot can be built with linaro gcc in the future.. off-topic but it's also not much of an issue to switch due to https://github.com/armbian/build/blob/71c777b3b67c4e76ddbf1866c1eae36bb0f6c955/lib/configuration.sh#L140 everything needed is there.. I suggest we switch this part of the discussion to https://github.com/armbian/build/pull/1117
-
Has anyone had the following error when using kernel 4.18 and 19? 1. Start hostapd (with or without dhcpd) 2. Try connecting via WiFi 3. Result... ---------------------------------------------- Aug 01 15:06:24 P2E vmunix: [ 5553.586947] ------------[ cut here ]------------ Aug 01 15:06:24 P2E vmunix: [ 5553.591573] kernel BUG at mm/slub.c:3902! Aug 01 15:06:24 P2E vmunix: [ 5553.595577] Internal error: Oops - BUG: 0 [#1] SMP ARM Aug 01 15:06:24 P2E vmunix: [ 5553.600707] Modules linked in: cpufreq_userspace realtek sy8106a_regulator evdev dwmac_sun8i mdio_mux stmmac_platform stmmac i2c_mv64xxx sun8i_ths ptp 8189fs sunxi_wdt cfg80211 rfkill cpufreq_dt gpio_keys thermal_sys uio_pdrv_genirq uio ip_tables x_tables Aug 01 15:06:24 P2E vmunix: [ 5553.623305] CPU: 2 PID: 668 Comm: RTW_CMD_THREAD Not tainted 4.19.0-rc1-H23.a1 #1 Aug 01 15:06:24 P2E vmunix: [ 5553.630775] Hardware name: Allwinner sun8i Family Aug 01 15:06:24 P2E vmunix: [ 5553.635481] PC is at kfree+0xfc/0x140 Aug 01 15:06:24 P2E vmunix: [ 5553.639233] LR is at nl80211_send_station+0xb10/0xc80 [cfg80211] Aug 01 15:06:24 P2E vmunix: [ 5553.645229] pc : [<c0135f04>] lr : [<bf09710c>] psr: 40000013 Aug 01 15:06:24 P2E vmunix: [ 5553.651483] sp : ed193dc8 ip : 00000008 fp : ecfaa030 Aug 01 15:06:24 P2E vmunix: [ 5553.656697] r10: ecfaa168 r9 : 00000000 r8 : ed193e50 Aug 01 15:06:24 P2E vmunix: [ 5553.661912] r7 : ed193de0 r6 : ecffd840 r5 : c082ae88 r4 : ecfaa014 Aug 01 15:06:24 P2E vmunix: [ 5553.668428] r3 : eee44b78 r2 : eee44b74 r1 : 00000024 r0 : c0135f40 Aug 01 15:06:24 P2E vmunix: [ 5553.674944] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Aug 01 15:06:24 P2E vmunix: [ 5553.682067] Control: 10c5387d Table: 6cda006a DAC: 00000051 Aug 01 15:06:24 P2E vmunix: [ 5553.687808] Process RTW_CMD_THREAD (pid: 668, stack limit = 0x68dce8d5) Aug 01 15:06:24 P2E vmunix: [ 5553.694410] Stack: (0xed193dc8 to 0xed194000) Aug 01 15:06:24 P2E vmunix: [ 5553.698763] 3dc0: 00000005 00000013 ecfaa014 c082ae88 00000012 ecfaa034 Aug 01 15:06:24 P2E vmunix: [ 5553.706929] 3de0: e598c000 e3a010c0 00000000 3085c00e 00000000 ee707800 00480020 ee7071a0 Aug 01 15:06:24 P2E vmunix: [ 5553.715094] 3e00: ed193e50 ecffd840 00000000 ed2efe8a f0db4108 bf09741c 00000000 ee707000 Aug 01 15:06:24 P2E vmunix: [ 5553.723260] 3e20: ee707800 ed2efe8a ed193e50 bf10b294 c082ae88 0000001c 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.731425] 3e40: f0db40f8 00080416 ed192000 bf11ac28 00000000 00000000 c082ae88 00060040 Aug 01 15:06:24 P2E vmunix: [ 5553.739590] 3e60: 00000002 01d40801 00000000 3085c00e 00000001 f0db3000 00000001 c082ae88 Aug 01 15:06:24 P2E vmunix: [ 5553.747754] 3e80: 00000007 bf0d79e0 00000001 bf13c8a4 ed192000 00000001 00210d00 00060040 Aug 01 15:06:24 P2E vmunix: [ 5553.755919] 3ea0: c082ae88 ed2f4180 ee472000 c082ae88 00000006 00000000 ed2efe9c 00000038 Aug 01 15:06:24 P2E vmunix: [ 5553.764084] 3ec0: 00000000 00000000 f0db4108 3085c00e f0e1d074 ee401d00 ed193ef8 00012785 Aug 01 15:06:24 P2E vmunix: [ 5553.772249] 3ee0: ed2efe80 f0db40f8 00080416 ed192000 f0db4108 c0135f40 00000001 bf0de80c Aug 01 15:06:24 P2E vmunix: [ 5553.780414] 3f00: f0db40f8 3085c00e f0e1d074 f0db3000 f0e1d074 00000054 ed2efe80 bf0de838 Aug 01 15:06:24 P2E vmunix: [ 5553.788579] 3f20: 00000058 ee5c7a00 f0db3000 bf173990 f0db40f8 bf0ed70c ecca40c0 f0db3000 Aug 01 15:06:24 P2E vmunix: [ 5553.796745] 3f40: f0db4118 f0db4000 f0db40f8 bf0ccbc4 ffffe000 bf0ed698 f0db4144 ee5c7a00 Aug 01 15:06:24 P2E vmunix: [ 5553.804910] 3f60: ffffe000 ed368b80 ece06980 00000000 ed192000 f0db3000 bf0cc8dc ed368b9c Aug 01 15:06:24 P2E vmunix: [ 5553.813075] 3f80: ed5cd864 c0045244 000000af ece06980 c0045124 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.821239] 3fa0: 00000000 00000000 00000000 c00090e8 00000000 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.829403] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.837569] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.845741] [<c0135f04>] (kfree) from [<3085c00e>] (0x3085c00e) Aug 01 15:06:24 P2E vmunix: [ 5553.851655] Code: 1a000003 e5923004 e3130001 1a000000 (e7f001f2) Aug 01 15:06:24 P2E vmunix: [ 5553.857742] ---[ end trace 964b2ab036abba84 ]--- ---------------------------------------------- I solved this problem and can share the result.
-
You don't get it. @Nora Lee edited her post above in the meantime. She posted just http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 directly below the http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 @Lion Wang already posted (you as moderator might see the edit history). So I thought it would be a nice joke to again post http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 (which is plain stupid of course since there's no information anyway in that forum post other than a link to the sources) but then decided to switch to https:// since the last time it already worked that great. Remember this? https://github.com/BPI-SINOVOIP/BPI-W2-bsp was a 404 yesterday but an hour ago Bananas delivered. Now they can show their superior performance again and make HTTPS work with their forum so they can again repair a broken link. BTW: Armbian is not affected: Accessing http://dl.armbian.com will redirect automagically to https://dl.armbian.com -- apt with HTTP only is not that much of an issue.
-
then.. I suggest you fix it.. cause the link you shared contains https... btw.. it affects us too for upgrades... see https://github.com/armbian/build/pull/1117
