• Content Count

  • Joined

  • Last visited

1 Follower

About chwe

  • Rank
    Embedded member

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. chwe

    Banana PI BPI-W2

    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 everything needed is there.. I suggest we switch this part of the discussion to
  4. chwe

    Banana PI BPI-W2

    then.. I suggest you fix it.. cause the link you shared contains https... btw.. it affects us too for upgrades... see
  5. chwe

    Banana PI BPI-W2

    at least for me https doesn't work whereas: works... and actually, it would make sense to link to the repo itself...
  6. chwe

    testers wanted Next major upgrade v5.60

    well not really. for now, let's assume that rootfs stuff works and we only test for new kernels bootloaders. So for each kernel you need one test. Current work-flow could be: Burn Ubuntu/debian default, next or dev image to SD-Card switch to nightly in armbian-config (so that your board gets updates from instead of git clone cd testings ./ e.g. USB can be tested by attaching a USB stick and check dmesg, dvfs can be tested with stress -c4 and running armbianmonitor in a second console you should be prompted through all stuff you've to answer In case there're still open questions feel free to ask. you can also have multiple ssh sessions to the same board if you need more than one console (e.g. for dvfs tests). When possible please test connection over ethernet cable as well. I suggest that you do this on an SD-card without productive stuff in case something goes wrong and the update to nightly bricks your board just to avoid stress on your side in case it breaks.
  7. How do I do this? It would be great for debugging - to see what's actually going on. well.. just written minutes ago.. tested with current debian server from downloadpage (Armbian_5.59_Orangepizero_Debian_stretch_next_4.14.65) on an orangepizero.. Well, let's see if this helps first.. and then we might have a look into the other issues you face.
  8. Just a short one which we can link to in case we need it for debugging end-users board: Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later): install picocom (sudo apt-get install picocom) connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up: [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters connect to it via picocom (in this case 'picocom /dev/ttyACM0'): chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password: I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this). Currently boards with USB gadget mode: - nanopineoplus2 - nanopineocore2 - nanopineo2 - nanopim3 - nanopifire3 - bananapim2plus - orangepizeroplus - bananapim2zero
  9. nope it can be either accessed via USB-UART adapter (that's what those 3 pins near to RJ45 are for.. Or with armbian via USB gadget mode. yep hmm that sounds strange.. But with your previous armbian it worked properly on the same router via DHCP?
  10. chwe

    Daily (tech related) news diet

    Todays special: What could probably go wrong? (It's in german, sorry for that.. ) Random company decides that people may want a app which may help you to fill your yearly tax form (that's the latest point where I probably would be skeptical but well, seems that people want to share all their tax data with *random company*). To save money, they decide to outsource the development for such a app to an contractor from india, contractor horribly fails to develop the app which is based on an AWS Bucket with public read/write rights for more or less everyone (as far as I understand the text correctly).. *random security researcher* tells the company that they do wrong, they think it's more appropriate to just ignore him than to see if there's a real issue until media covers up the story. One of the databases he found stored all the user credentials in plain text and all data uploaded to the app could be seen by *random security researcher*.. Just WTF?!?? If you don't have the resources to develop such an app on your own just don't do it! There's absolutely no excuse to bring such a shitshow to your end-users.. At least you need in-house capabilities to review the garbage you bought from your contractor.. How can you think it's somehow okay that user credentials for an app storing tax data of them in plain text? If you don't even get this point right you shouldn't be allowed to offer such a service. And the best part of it, the app is called '' (tax59) because this app cost you 59CHF (~60$).. reminds me to this one: Edit: just for fun, from the website: 'free translation' So I guess 1 factor: the guy who wants to see you taxdata needs Internet access 2 factor: he probably needs java script activated to brows through AWS services 3 factor: he needs a free AWS account cause those open AWS Buckets are only open to people having such an AWS account Sorry for being sarcastic but that's the only way to deal with such news.. BTW: there is a java based tax app provided by the govt here in switzerland since years. You can load the form from the last year so that all your data is there and you just have to adjust it to the new year.. And it's not only Windows.. They provide an OS X and even a Linux version for it.. It's not that we've to submit those forms on tablets of stone...
  11. chwe

    NanoPC T4

    did you try And then a 'rkdeveloptool ef' might do it.. As far as I see this is plain c++ without any blobs so you could probably compile it on one of your arm boards as well.. chwe@chwe-acer:~$ rkdeveloptool ---------------------Tool Usage --------------------- Help: -h or --help Version: -v or --version ListDevice: ld DownloadBoot: db <Loader> UpgradeLoader: ul <Loader> ReadLBA: rl <BeginSec> <SectorLen> <File> WriteLBA: wl <BeginSec> <File> WriteLBA: wlx <PartitionName> <File> WriteGPT: gpt <gpt partition table> WriteParameter: prm <parameter> PrintPartition: ppt EraseFlash: ef TestDevice: td ResetDevice: rd [subcode] ReadFlashID: rid ReadFlashInfo: rfi ReadChipInfo: rci ReadCapability: rcb PackBootLoader: pack UnpackBootLoader: unpack <boot loader> TagSPL: tagspl <tag> <U-Boot SPL> -------------------------------------------------------
  12. okay some starters: Most boards don't have a PMIC which is capable of reporting the DC-In voltage. That's a fact and it's likely that this won't change. Those SoCs are mostly made for TV-Boxes, so the corresponding PMICs are developed with the assumption that the (TV-Box) boardmaker understands how proper powering works (e.g. barrelplug with a known good PSU), unfortunately SBC boardmakers decided that 'the RPi way of powering' (e.g. telling your customers that they can use their crappy phone charger with a crappy USB cable first before 'providing' a 'RPi approved' microUSB PSU which delivers 2.5A at 5.1V to overcome all those undervoltage situations). And that's why we're where we are.. having boards and dealing with undervoltage issues and trying again and again to convince people that undervoltage might be a reason why *random board* doesn't run as expected. If there would be a known 100% reliable way to detect undervoltage on each board we support, I'm sure @tkaiser would've implemented it the day he knows that it's working to save himself a bunch of time explaining again and again (and again) why *unexpected error* is likely related to underpowering. If the error would look exactly the same everytime, I'm sure such a script would also be shared, underpowering can have all sorts of funny errors and it's an error which can be avoided buy being not the scrooge trying to save 2-3 bucks by using random crap. If random OPi board has an barrel-plug, buy opis PSU my OPi PC+ works over a year 24/7 without issues (headless). If you plan to stick random crap via USB to it probably with turned on wifi as well and then mix it with some heavy tasks on the CPU, even the one provided by xunlong my f*ck up and quit. If you've an microUSB powered one (e.g. OPi Zero etc.) go for good microUSB cables (e.g. ~AWG20 for powerwires - you can even find sometimes such cables on aliexpress). I use 1m cables branded 'Fonken' with AWG21 powerlines and AWG28 for datalines together with a Ikea handycharger named 'KOPPLA' and never got fooled by them (doesn't mean that nobody ever will be fooled by this combination but at least headless OPis worked quite well). If you consider to stick random SSDs or HDDs on a microUSB powered SBC over USB powered by the board itself, please reconsider your plan or use Y cables and ask @TonyMac32 when his "mezzanine" board: will be available (he might need some testing not that he gets an article in the Register similar to team RPi ). Or build your own GPIO powered solution. Sometimes a simple Multimeter can help you to measure between GND and a random 5V pin on the pinheader to get a clue if the average voltage is okay.. Some of the shitty PSUs have low voltage spikes which aren't detected by an el Cheapo multimeter which makes debugging even harder. Some SoCs and their boards may be more sensitive to undervoltage than others. But the solution is simple don't save 2-3 bucks by going for the cheapest one you find... Btw. I assume that RPi's official PSU might also be considered as a 'good one' cause it was developed after team RPi realized that average phonechargers are to crappy to power their board reliable...
  13. Sure, I stepped down a littlebit with my BPi-R2 testings at the moment. There was/is a patchseries which should make it possible to define multiple CPU ports ( Unfortunately it never reached Linus tree and the patch doesn't apply at the moment. Maybe I'll have a look into it and see if this enhances the performance.
  14. well will hopefully be part of tool/work-flow to avoid frustration with updates.. so that the average user doesn't need freezing his system in productive use-cases.
  15. chwe

    OPi Prime report

    first != Armbian linux -sunxi was formed around kernel development for Allwinner SoCs whereas Armbian tries to build an usable Ubuntu/Debian on top of their work (and on top of other Kernels for other SoCs). There's contribution by armbian members to the Sunxi wiki (e.g. @tkaiser quite often and others probably too) but as armbian, that's community work! so you can also contribute in case you're not satisfied by the current state. unfortunately not.. or at least not for Allwinner H-series boards. The A series SoC have a PMIC with voltagecheck you don't need 5.000 V 4.999 will also do... A good powersupply will deliver around 5V under high load.. that's where a shitty powersupply may fail which ends in threads collected here: last one: may help to find informations needed. Summarizations have to be written, as long as everyone expects that 'someone else' will do it nobody does it..