pfeerick
-
Posts
148 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by pfeerick
-
-
There are just too many people who still don't read instructions (hey, stop lookin' at me!) so the only option is to break if they didn't read the 3 foot tall flaming print saying "BUILD SYSTEM REQUIREMENTS" and "if you don't have this system, use a virtual machine setup, like the vagrant one we provide for you". If they still want to disregard the instructions, they'll have to edit the build script themselves.
-
I've been away from my rock/pine/orangepi stuff for a while whilst life, the end the uni term, and complaining against the latest political brainwave of our government... but time is clearing up again, and I can start following the forums and documentation and stuff. My 2 cents is I agree with the general view expressed by @tkaiser... I don't like deleting stuff unless it is duplicated, with a polite note to the OP to bring their attention to the forum rules. What I would do in the case of those who have not done their due diligence and are asking for support, or who are not doing what is asked, is to either just put on the broken record approach, or to simply ignore them. And I agree with the general idea of the FAQs... but that also sounds a bit like the getting started documentation... so I'm not sure that is actually needed.... other than a bloody big arrow pointing at the documentation page... so that even a blind person couldn't miss it! :-P
-
Indeed... antennas do matter... you can boost the range 2x or more easily by changing from the standard 'wire' type (as the most basic antenna is nothing more than a wire of the an appropriate length so that it resonates at the correct frequency), to parabolic dish or yagi type. The straight wire type that you would find in most router 'rubber ducky' antenna is omnidirectional, whereas the parabolic dish or yagi type are directional - hence the increase in transmit/receive range - because the signal is focused.
I'd also be curious since Igor is doing that setup how much of an impact the proximity of all those wifi transceivers to one another has on their signal... do some of them - especially the ones with high gain antenna instead of PCB antenna - knock the signal strength and throughput of some of the others out? There is such a thing as being too close - known in the RF world as over-saturation or swamping... where the signal is so overwhelmingly strong that it makes the other side go deaf, and hence packets start to get dropped due to said deafness. In other words, closer is NOT always better!
-
What Igor said. From what I've seen mentioned, it sounds like in this case "newer != better" :-( I have two V1.1 Orange Pi Zeros that I purchased 2-3 months ago via their aliexpress page, and (after testing that both worked!) I have had one running 24x7 since I got it, open air without a case, plugged into ethernet running node-red and some other bits. I turned everything down power-wise and down-clocked it using the h3consumption script, and haven't had any issues with it, and it runs nice and cool. It does have a heatsink on it, but it certainly doesn't *need* it, but it helps keep it cool and let it throttle up for longer when needed.
-
Try the below - as you probably need the PHP7 packages. Or as Igor said... as he posted whilst I was typing
sudo apt install php7.0-cli php7.0-xml php7.0-mbstring -
I haven't tried a mainline kernel with USB recently, but I see that for the A64 that USB is still a Work In Progress (WIP) on the mainlining status matrix, so perhaps it's still a bit iffy. I'll try and give a recent mainline image an try tonight and let you know my results...
-
3 hours ago, thedon said:
Does not work for me; it is definitely ILI9341; ili9341 is printed on the board also; I just get a white screen; no errors on the modprobes; just that nothing goes to the screen;
ILI9341 being printed on the board unfortunately sometimes means absolutely nothing nowadays, with Chinese manufacturers re purposing boards and substituting chips. I bought a 3.5" LCD Arduino shield about six months ago, intending to use it with a STM32 project, and had to give up, as it most certainly didn't have the ili9488 chip that it claimed to have... either that or is was faulty, as nothing useful for identifying it was reported by the Arduino equivalent of lcd_id.
Please run the lcd_id app as directed by nopnop2002 (pinout is on the github page). Once you've ascertained that the LCD driver chip is a ILIL9341 (and/or is working), then you can start working towards getting it working.
-
@trohn_javolta What you'd need is re USB-Serial is basically this. If you're in the US, and prefer Adafruit, grab the serial to TTL cable they sell, but otherwise, something like the one I linked should work. There will be some pins on the board somewhere (not familiar with that particular board) that you plug three of the wires in to be able to interact with the board via a serial console (so no display, keyboard, etc needed on the board itself).
-
When I do github stuff that I intend to push back 'upstream', I do it in my own fork, and as a new branch, so that when you do a pull request, you simply specify that branch as what you're wanting to push back into the original project (rather than a single commit). It also means that if you have more commits you want to submit as part of that update request, you can continue to push them on that branch.
The github docs on forking repos and doing pull request may be of interest, as most of that is explained there... I end up searching for something there every so often... either trying to work out something new, or just grab the steps for something I'm doing again
-
This change is not Armbian related, but a systemd/udev change, to fix a perceived issue with machines that have multiple ethernet interfaces. Because the eth0, eth1 etc naming was not bould to a specific device, if for some reason they were detected in a different sequence at boot, eth0 would not be the eth0 from a previous boot. So the powers that be adopted the 'predicable naming system' which is tied to the hardware address of the device, which shouldn't change. You can read more about that here.
They suggest three options to revert to the older behaviour:
Quote-
You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy:
ln -s /dev/null /etc/systemd/network/99-default.link - You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.
- You pass the net.ifnames=0 on the kernel command line
(https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/)
A fourth option they didn't mention is to make a udev rule that links the predictable name to the un-predictable ones to the predictable, but that is a bit harder. It looks like the easiest uption is to mask the udev link rule.
-
You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy:
-
I'm not familiar with using this type of LCD on linux, but it sounds like your LCD is a parallel type connection (D0-D7 + others) rather than a SPI type connection (MOSI, MOSI, CLK, CS/SS), so won't work with these instructions. And the LED pin will be the pin that that controls the LED backlight for the display.
-
Hm... interesting..... al-la-facebook reactions!
This should make things... interesting! 
-
4 hours ago, tkaiser said:
But zero priority of course since you're the only Armbian user around having a power button soldered (or connected to EXP header)
Oh, well thanks a lot!
I guessed that might be the reason it hadn't been spotted til' now... this is the first time I've hit this particular issue across all the longsleep, ayufan and even previous armbian images... so either I haven't been holding my tongue right, or it's a new 'feature'
1 hour ago, zador.blood.stained said:Obviously comparing the behavior to other releases would be good to see if it depends on u-boot DT (or maybe it's a "feature", not a bug).
Yeah, I'm going to roll back through the earlier images I have saved, and see where it was introduced, as I don't don't think I had this problem with earlier images. And are you mad? Mentioning AllWinner and "fix things" in the one sentence? Madness... sheer madness!
-
I'm guessing it wasn't intentional that the current legacy Armbian_5.30_Pine64_Ubuntu_xenial_default_3.10.105 image for the pine64 wouldn't work without the battery?
Because the "Warning: Low battery power, shutting down to recharge" line (10th line from the end) is an absolute corker (or should I say showstopper?) when there is no battery connected to the pine64! It fell over on a 2G pine64 board that I was about to build up with Armbian.
SpoilerHELLO! BOOT0 is starting! boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f boot0 version : 4.0.0 set pll start set pll end rtc[0] value = 0x00000000 rtc[1] value = 0x00000000 rtc[2] value = 0x00000000 rtc[3] value = 0x0000a101 rtc[4] value = 0x00000000 rtc[5] value = 0x00000000 DRAM driver version: V1.1 rsb_send_initseq: rsb clk 400Khz -> 3Mhz PMU: AXP81X ddr voltage = 1500 mv DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) DRAM clk = 672 MHz DRAM zq value: 003b3bbb DRAM single rank full DQ OK DRAM size = 2048 MB DRAM init ok dram size =2048 card boot number = 0, boot0 copy = 0 card no is 0 sdcard 0 line count 4 [mmc]: mmc driver ver 2015-05-08 20:06 [mmc]: sdc0 spd mode error, 2 [mmc]: Wrong media type 0x00000000 [mmc]: ***Try SD card 0*** [mmc]: HSSDR52/SDR25 4 bit [mmc]: 50000000 Hz [mmc]: 30528 MB [mmc]: ***SD/MMC 0 init OK!!!*** sdcard 0 init ok The size of uboot is 000e8000. sum=2a39a234 src_sum=2a39a234 Succeed in loading uboot from sdmmc flash. boot0: start load other image boot0: Loading BL3-1 Loading file 0 at address 0x40000000,size 0x0000a200 success boot0: Loading scp Loading file 2 at address 0x00040000,size 0x00019a00 success set arisc reset to de-assert state Ready to disable icache. Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):3cdc5c3 NOTICE: BL3-1: Built : 12:02:56, Jun 7 2017 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x4a000000 INFO: BL3-1: Next image spsr = 0x1d3 U-Boot 2014.07-g6f37e5c-dirty (Jun 13 2017 - 15:42:40) Allwinner Technology uboot commit : 6f37e5cf6a65b0b10455d12dbd631effabe765ec rsb: secure monitor exist [ 0.362]pmbus: ready [ 0.365][ARISC] :arisc initialize [ 0.696][ARISC] :arisc_dvfs_cfg_vf_table: support only one vf_table [SCP] :sunxi-arisc driver begin startup 2 [SCP] :arisc_para size:1a8 [SCP] :arisc version: [v0.1.76] [SCP] :sunxi-arisc driver v1.10 is starting [ 0.825][ARISC] :sunxi-arisc driver startup succeeded [ 0.859]PMU: AXP81X [ 0.861]PMU: AXP81X found bat_vol=1, ratio=0 [ 0.867]PMU: dcdc2 1100 [ 0.870]PMU: cpux 1008 Mhz,AXI=336 Mhz PLL6=600 Mhz,AHB1=200 Mhz, APB1=100Mhz AHB2=300Mhz MBus=400Mhz device_type = 3253, onoff=1 dcdc1_vol = 3300, onoff=1 dcdc2_vol = 1100, onoff=1 dcdc6_vol = 1100, onoff=1 aldo1_vol = 2800, onoff=0 aldo2_vol = 1800, onoff=1 aldo3_vol = 3000, onoff=1 dldo1_vol = 3300, onoff=0 dldo2_vol = 3300, onoff=0 dldo3_vol = 2800, onoff=0 dldo4_vol = 3300, onoff=1 eldo1_vol = 1800, onoff=1 eldo2_vol = 1800, onoff=0 eldo3_vol = 1800, onoff=0 fldo1_vol = 1200, onoff=0 fldo2_vol = 1100, onoff=1 gpio0_vol = 3100, onoff=0 vbus not exist normal dc exist, limit to dc run key detect no key found no uart input DRAM: 2 GiB fdt addr: 0xb6ebcf00 Relocation Offset is: 75f0f000 In: serial Out: serial Err: serial gic: sec monitor mode [ 1.181]start drv_disp_init init_clocks: finish init_clocks. enable power vcc-hdmi-33, ret=0 drv_disp_init finish boot_disp.output_disp=0 boot_disp.output_type=3 boot_disp.output_mode=10 fetch script data boot_disp.auto_hpd fail disp0 device type(4) enable attched ok, mgr0<-->device1, type=4, mode=10 plugin [ 2.221]end workmode = 0,storage type = 1 [ 2.225]MMC: 0 [mmc]: mmc driver ver 2015-06-03 13:50:00 SUNXI SD/MMC: 0 [mmc]: start mmc_calibrate_delay_unit, don't access device... [mmc]: delay chain cal done, sample: 217(ps) [mmc]: media type 0x0 [mmc]: Wrong media type 0x0 [mmc]: ************Try SD card 0************ [mmc]: host caps: 0x27 [mmc]: MID 1b PSN a20a5776 [mmc]: PNM 00000 -- 0x30-30-30-30-30 [mmc]: PRV 1.0 [mmc]: MDT m-2 y-2016 [mmc]: speed mode : HSSDR52/SDR25 [mmc]: clock : 50000000 Hz [mmc]: bus_width : 4 bit [mmc]: user capacity : 30528 MB [mmc]: ************SD/MMC 0 init OK!!!************ [mmc]: erase_grp_size : 0x1WrBlk*0x200=0x200 Byte [mmc]: secure_feature : 0x0 [mmc]: secure_removal_type : 0x0 [ 2.411]sunxi flash init ok ** Unable to use mmc 0:1 for loading the env ** Using default environment --------fastboot partitions-------- mbr not exist base bootcmd=run mmcbootcmd bootcmd set setargs_mmc key 0 recovery key high 12, low 10 fastboot key high 6, low 4 no misc partition is found to be run cmd=run mmcbootcmd update dtb dram start update dtb dram end serial is: 040051900808080303ce check for ANX9807 get Pine64 model from DRAM size DRAM >512M Pine64 model: pine64-plus PowerBus = 2(0: not exist 1:vBus 2:acBus 3:vBus&acBus) Battery Voltage=1, Ratio=0 key trigger Warning: Low battery power, shutting down to recharge fetch script data boot_disp.output_full fail screen_id =0, screen_width =1920, screen_height =1080 frame buffer address 47400036 set next system normal drv_disp_exit [mmc]: MMC Device 2 not found [mmc]: mmc 2 not find, so not exit [ 7.056]power off set power off vol to default
After a little more prodding, it's related to powering on via the power button... the pine64 is correctly detecting 'no battery' if it is powered on via power insertion.
Spoiler--------fastboot partitions-------- mbr not exist base bootcmd=run mmcbootcmd bootcmd set setargs_mmc key 0 recovery key high 12, low 10 fastboot key high 6, low 4 no misc partition is found to be run cmd=run mmcbootcmd update dtb dram start update dtb dram end serial is: 040051900808080303ce check for ANX9807 get Pine64 model from DRAM size DRAM >512M Pine64 model: pine64-plus no battery exist sunxi bmp: unable to open file /boot/bootlogo.bmp [ 3.177]inter uboot shell autoboot in 3 seconds, Press s or <Esc><Esc> to abort
There was also a (trivial in comparison) service failure during the first boot... i'm not sure it went away due to a dist-upgrade or was simply a first boot gremlin:
Spoiler[ OK ] Started Daily apt activities. [ OK ] Reached target Timers. Starting Armbian filesystem resize service... [FAILED] Failed to start Set console font and keymap. See 'systemctl status console-setup.service' for details. [ OK ] Started Armbian filesystem resize service. [ OK ] Reached target Basic System. --- root@pine64:~# systemctl status console-setup.service ● console-setup.service - Set console font and keymap Loaded: loaded (/lib/systemd/system/console-setup.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2017-06-14 07:00:56 UTC; 1 months 16 days ago Docs: man:loadkeys(1) Main PID: 285 (code=exited, status=1/FAILURE) Jun 14 07:00:56 pine64 setupcon[285]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.7JYIFD: No such file Jun 14 07:00:56 pine64 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE Jun 14 07:00:56 pine64 systemd[1]: Failed to start Set console font and keymap. Jun 14 07:00:56 pine64 systemd[1]: console-setup.service: Unit entered failed state. Jun 14 07:00:56 pine64 systemd[1]: console-setup.service: Failed with result 'exit-code'. Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. -
Um... maybe tell us what your problems actually is? What did you do? Did you have wifi and ethernet running, and then unplug ethernet and this is the result of route -n?
-
I have seen links for FFC/FPC extenders before so they do exist. What board is this for, maybe I can find suitable link that way...
-
Locking thread... @giri@nwrk.biz has given the link in the previous post for where this discussion should happen.
-
Can the Raspberry 'manage it perfectly' on any pin, or just one? As IIRC, the rPi has one dedicated PWM capable pin, which should be stable... not sure about the oPi? I'm not saying there aren't library, hardware and configuration differences that could be causing the problem, just that I know that is one possible reason for this variance.
-
I'll shush for a while so we get some other voices here in the conversion, but let me be the first to say Thomas, you're a brain damaged retard for hoping (in my opinion against all hope) that somebody might listen and actually do something about it. But no, they insist on making excuses, and saying that they're doing a good job. And you know what I think we should do... boycott all the way until they learn the error of their evil ways.
I don't think you missed any discussions on the forum, as I didn't see anything either, but who am I to argue with the boss. But then again... unsupported WIP, and new toys...
-
1 hour ago, tkaiser said:
These people are not stupid, just somewhat different compared to a dev and BTW the majority of people on this planet.
The latter group are those we try to address. How should this work?
That's my perspective on this, and why I said some stuff needs to be built into Armbian. The viewpoint of the non-devs is simple... it should operate just like their old VCR. Like the original ones that just had play, fast forward, rewind, stop, and eject buttons. Not like the ones that had a million and one buttons, and could do everything from chroma editing to transition effects to audio redubbing. And needed a small encyclopedia to drive them. These are are the normal people, which is why they need stuff to be written in plain English and digestible format, with pictures and even videos where practical.
-
15 hours ago, Igor said:
Added yet another link - directly to "Getting started". @pfeerick I hope words are not too harsh ?
No complaints here from the peanut gallery!
1 hour ago, TonyMac32 said:I think the idea of the quiz is more harmful than the quiz itself. "Who are these guys to put barriers in the way?" etc. In general it comes across as unfriendly, snobbish, unwelcoming.
Agreed. Now, if we make it so it's a quiz like 1) have you read the documentation yet 2) no, really, HAVE YOU READ THE DOCUMENTATION? 3) are you using a good microSD card (read here if you're not sure what to answer) 4) is your power supply setup a good one? (read if here if you're not sure what to answer) 5) is this an official armbian image and 6) you consent to being locked in a room with tkaiser for an hour if you are found to not have answered any of the questions truthfully and correctly (ok, maybe not that last question/condition) and they have to answer that before their first post to into the technical support section, I might be for it... sort of
.
You might gather from how I'm not taking the questions too seriously I'm with Tony on that one... nice in principle, but I think it's too unfriendly and unwelcoming. But it doesn't mean it shouldn't be an option to be considered, I just don't see the need just yet. Lets see how we go with the other banners once we get the text nailed down, and go from there?
-
Oops! Well, can't please everyone. But it was better to have been done sooner than later, as if we left it for a month or so we're either be stuck with that thread as it was, or break a load more sites when it does get split.
Edit: Alasdair just updated the link
-
8 hours ago, TonyMac32 said:
I've had absolutely no issues with the forum, but now both you and tkaiser have mentioned it eating input. Browser of choice, perhaps?
It's just IPB being IPB... all the fluff and 'pretty' stuff it does sometimes comes back to bite you. Made the mistake of double-clicking the code block to edit, for some reason it then promptly decided I really wanted it to be sole contents of the post, and I had already hit save before I realised it was going to trash the post on me. I'll live.
It may not! 
Oh no, now you done it @chwe ! You should know better than to bring religion into the mix! :-O All I can say is.... here's the github page... see if you get a PR past the four disciples!
'
-
I don't think it's the change in thread title. If you look at the comment index number at the end, it is separated with a '-' in what you say is the link you've always used (which worked for me btw - it linked to your May 24 post), and the second uses a '=' (and didn't work for me) - did you get them swapped around by any chance (otherwise it's something on your end or Igor as changed something in the last hour)? Changing the separator alone made it work, and it redirects to the 'new' link (still using a '-' separator for the comment number).
5.35/5.36 bug / questions collection
in Advanced users - Development
Posted
Did the /etc/cron.d/armbian-updates permission issue get fixed (I'm guessing not... I just updated to 5.36 whilst I was writing this and it's back)? I was getting the insecure mode journal entries also on a just updated from 5.31 -> 5.35. Orange Pi Zero.
As with the earlier report, the permissions for /etc/cron.d/armbian-updates were:
And sudo chmod 644 /etc/cron.d/armbian-updates shut it up.
Dec 04 12:04:01 orangepizero-1 cron[521]: (*system*armbian-updates) RELOAD (/etc/cron.d/armbian-updates)Until then, unsurprisingly, the update count on the welcome banner was stuck at:
even though the system had just been updated and rebooted, and only actually had 1 update waiting.
btw, 5.36 still has a 'user-built' kernel :-P