chwe

  • Posts

    1432
  • Joined

  • Last visited

Reputation Activity

  1. Like
    chwe got a reaction from NicoD in Announcement : Odroid N2   
    just highlight thomas here, maybe he reads it..   @tkaiser
  2. Like
    chwe reacted to rooted in Announcement : Odroid N2   
    N2 results
     
    http://ix.io/1Brv
     
    Take these results with a grain of salt since i paid no mind to starting load average.
     
    Could someone give me a break down of the results compared to say a rk3399?
     
    I have never used this benchmark and have no idea if the results are as they should be.
  3. Like
    chwe got a reaction from NicoD in Daily (tech related) news diet   
    huh.. that wasn't addressed to you.. more to the politicians I quoted in my starter.. not that you get me wrong on this one..
     
    well, they might sold less discs.. Production cost for studio etc. are still here.. but the whole music industry was a way to late to get the money out.. Now spotify and apple music gets a large amount of it.. It's not that they didn't saw it.. Napster was a clear signal that they should find a way to deliver their content and make some money out of it..
     
    well that's a difficult crippled topic.. I worked in pharma for several years and currently doing pharma related research at university ergo govt. funded. Not everything there is govt. funded, pharma companies also spend a huge amount into research.. This might be a good one if you want to dive into this topic ( @martinayotte, didn't even know that your country has pharma... ): https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5848527/
    I'm not willing to nail down this fully, it's a way too much to consider to 'get the big picture'.. Pharma related research is unbelievable expensive.. Rule of thumb, if a device can be used for pharma related research it's roughly 10x the price you would expect.. The actual production costs of a drug is quite often only a small fraction of the price you pay for it.. The majority goes into other channels, including research, customer promotion and also a bigger amount into dividends - just look how much dividends a pharma-company pays yearly to its shareholders, you wouldn't expect it..
     
    Not cause I would prefer an open knowledge world everyone has to agree on my opinion.. People should be free to choose a closed environment if they want..
  4. Like
    chwe got a reaction from Igor in Improve 'Support over Forum' situation   
    It's not about censorship.. as you said you can look it up.. Normally you remember girls & guys being 'more often' here.. For me, text matters more than 'post count' or 'like count'.. (in fact the other two don't matter at all).  Remember this post here?
     
    It was his first one cause I remember that I unlocked it... You can have a lot of experience (even on armbian) without posting here.. just by reading.. *random number of likes* just shows that someone is maybe longer here or longer recognized doesn't mean s/he's more experienced.. Just spends more time here..
     
  5. Like
    chwe got a reaction from NicoD in Support of Raspberry Pi   
    well their official forum is quite entertaining..   I had some fun the last days when someone proposed that the next pi should have GbE and their mod explained that by 'electrical characteristics' doesn't really matter to me.. As usual those threads get closed.. and due to heavy bloating.. it's soon out of the first page and therefore nobody will see it anymore..
     
    I wouldn't fully agree on this one. There are some good people there.. Also people exactly knowing the RPis limitations.. Obviously their paid moderators/developers have to defend their product.. Hey it's part of their job, not always the way I prefer but understandable.. I think the reason you think it's full of trolls is cause they show up first when write something which doesn't end in 'those guys in Cambridge are superior compared to other SBC makers'... They have somehow a weird relationship with the VC4 but well, everybody is free to love whatever s/he wants.. The problem with the RPi is still the 32bit/64bit mixup.. If supported most of the 'nice' features wouldn't work due to 'only 32bit workable' yet..
    The potential amount of 'customers' would increase whereas chances that new devs will join cause of the RPi are rather low.. A decent dev could already add the RPi to Armbians buildscript, it would need some hacks here and there.. but it's not that much an issue to do it. Personally I don't see a reason to do it. For most use-cases there are simply better SBCs on market for a similar price.
     
    how dare you are---
    whereas the only supported RK3288 board is even more powerhungry and also powered by microUSB..
     
    well we shouldn't support boards based on the shittyness of support they have... I would prefer one based on 'interesting features'.. If a 'new RPi' is based on a interesting SoC with some nice features without threadX why not? But I don't think this will ever happen, they're just too much tied to broadcom..
     
     
  6. Like
    chwe got a reaction from Werner in Orangepi 3 h6 allwiner chip   
    3.10.65 on OPi 3? Armbian will never deal with the BSP kernel for H6 boards, you may ask in Xunlongs supportforum.
     
     
    it would be worth to have your buildscript and it's changes (as a fork) on your github as well, so that people interested in your work can see what you tried so far or even contribute to it.
  7. Like
    chwe got a reaction from NicoD in Orangepi 3 h6 allwiner chip   
    3.10.65 on OPi 3? Armbian will never deal with the BSP kernel for H6 boards, you may ask in Xunlongs supportforum.
     
     
    it would be worth to have your buildscript and it's changes (as a fork) on your github as well, so that people interested in your work can see what you tried so far or even contribute to it.
  8. Like
    chwe reacted to NicoD in PINE64@FOSDEM PineBook Pro, PinePhone, Pine H64, ...   
    Hi all.
    Last weekend PINE64 was on FOSDEM with many new products.
    The PineBook Pro with RK3399.
    The new designed PINE H64 with the H6, now with wifi on-board and a small form-factor. That one's comming out next week.
    The PinePhone. A prototype of the PinePhone with an A64 SoC and 2GB of RAM.
    The PineCam. A multi-funtional network camera.
    A new SNES case.
    Exciting times to come with all that.
    I've made a video about it all. You can see it here.
    Greetings, NicoD
     
  9. Like
    chwe got a reaction from Mario Schmidt in Banana Pi M2 Berry won't boot   
    nope.. it's csc only.. means no 'official support'
     
     
  10. Like
    chwe got a reaction from markbirss in Very Small Platforms - Rockchip 3308 and Allwinner V3s   
    didn't you call a challenge for the first one who gets armbian to run on a V3s some months ago?
     
    _ _ _ ____ _ _____ | | (_) ___| |__ ___ ___| _ \(_) |__ /___ _ __ ___ | | | |/ __| '_ \ / _ \/ _ \ |_) | | / // _ \ '__/ _ \ | |___| | (__| | | | __/ __/ __/| | / /| __/ | | (_) | |_____|_|\___|_| |_|\___|\___|_| |_| /____\___|_| \___/ Welcome to ARMBIAN 5.74 user-built Debian GNU/Linux 9 (stretch) 4.20.2-sunxi System load: 1.90 0.67 0.24 Up time: 1 min Memory usage: 58 % of 50MB Zram usage: 36 % of 25Mb IP: Usage of /: 4% of 29G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com Creating a new user account. Press <Ctrl-C> to abort Please provide a username (eg. your forename): got one on Christmas.. didn't have time to dig into it.. but well.. here you are.. Armbian booting from a LicheePiZero 
     
    Does it make sense? not really.. but hey.. who cares.. it boots.. in less than 30 seconds..
  11. Like
    chwe got a reaction from rooted in RockPi 4b 'board bring up'   
    As most of us were in the beginnings..
     
    I don't guarantee but I think it's not that easy to fry something with a wrong devicetree.. It's a way easier with connecting random crap to the pin-header.
     
    Since you want to get closer to group 1 let's give an example:
     
    That's the original DT for the RockPi4b (4.4.x kernel) spoiler cause it just messes up to show the whole one for everyone (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts):
     
    the first few lines after comment tell us which other DT files are included here e.g. (rk3399.dtsi):
    #include <dt-bindings/pwm/pwm.h> #include <dt-bindings/input/input.h> #include "rk3399.dtsi" #include "rk3399-linux.dtsi" #include "rk3399-opp.dtsi" basically just another 'layer' of describing hardware, since a lot of stuff is shared with all rk3399 based boards this stuff is usually described once there and the nodes are used again and again for every board.
     
    The nodes after it describe the hardware and how it is connected (also partly software e.g. there are multiple UARTs available, a node has to tell the kernel which one should be used to output the debug console).
     
    Now let's look at such a node:
    fiq_debugger: fiq-debugger { compatible = "rockchip,fiq-debugger"; rockchip,serial-id = <2>; rockchip,signal-irq = <182>; rockchip,wake-irq = <0>; rockchip,irq-mode-enable = <1>; /* If enable uart uses irq instead of fiq */ rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */ pinctrl-names = "default"; pinctrl-0 = <&uart2c_xfer>; }; the compatible part is the first one which is interesting cause it gives you some hints where you get further information. (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt)
    From there you get most of the information out what this node does and how it can be configured.. E.g. for the fiq node, it could be worth to set baudrate to 115200 cause this is the common baudrate for all SBCs (except rockchips which often favor higher baudrates for whatever reasons ). So obviously when you connect an USB-UART you've to set it to 1500000 not the default 115200 (keep in mind, if it's patched in the kernel, it should also be patched in u-boot, otherwise things get messy).
     
    That's just a short introduction and you've to read a lot of stuff until all this stuff makes sense. Maybe I write something about the buildsystem tomorrow.
  12. Like
    chwe got a reaction from Staars in Daily (tech related) news diet   
    well, I'm quite confident that they don't need 'our help' in those days to look stupid..
     
    In case someone asks it's mostly the Austrians and the Germans fault why we can observe greenhouse gases (Boltzmann & Planck). For those wanna lock smarter as they are...  A heretical explanation which 'works' is that every gas consisting more than two atoms is a greenhouse gas (e.g. the famous CO2). To be a greenhouse gas, a gas has to absorb near-IR radiation. If you dive now into quantum physics, only so called vibrational& vibrational-rotational transition which change the dipole moment of a molecule are allowed. If you compare now CO2 (greenhouse gas) and N2 (not a greenhouse gas):

    Carbon dioxide has two normal modes (2&3) which end in a change of the dipole moment (and one mode without such a change) whereas Nitrogen gas hasn't such a normal mode (only a symmetric stretch). But before we dive more into smart ass mode... I'm by no mean an expert in quantum mechanics I'm more like Dwayne Johnson in No pain no gain... Luckily, smarter people at Harvard rolled the topic better up that I could do it ever on myself from a quantum mechanical standpoint. Feel free to dive into it:
    http://acmg.seas.harvard.edu/people/faculty/djj/book/bookchap7.html
    They don't try to make up conclusions which their data doesn't cover.. They just try to explain it for people at least somehow able to understand quantum mechanics basically. Unfortunately there aren't as many 'scientific journalists' around the world to analyze and understand scientific papers to come to the right conclusion. In fact they mostly try to catch up some 'dramatic looking' sentences inside a publication to get some attention assuming that every sentence in a publication is so 'well-crafted' that it must be still valid if you change it a little bit. A *random expert* adds then some other dramatic sentences as well and there you get your 'it's the global warming, stupid'-article..  Small hint, not every scientific publication is on such a high level and it needs a lot of skills to break down such an article to make it understandable for the average joe and still being scientifically correct. Unfortunately it often ends in "reading A, thinking it means B and conclude C".. Maybe we could do better try to explain what our research tries to achieve in a manner that the 'average joe' also partly understands what we're doing... Not every detail, but at least partly..
  13. Like
    chwe reacted to Igor in New forum member, cannot reply to a post   
    We can only treat side effects of the cure we made. If you are dying from 3rd party disease or side effects and want help, you will certainly die since here are not enough doctors to cure. 
     
    I removed this obstacle, because we decided to deal with this problem differently. More efficient.
  14. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    Just a tiny update. Booting from SSD works as expected:
     
    It is not completely free of error messages, but it is quite okay'ish.
     
    I will try to update my first post in order to gather the most recent information there. 
  15. Like
    chwe reacted to martinayotte in BananaPi R2 (.csc mt7623 as new boardfamily)   
    So, I must be masochist since ALL by boards using old fashion /etc/network/interfaces ...
  16. Like
    chwe reacted to malvcr in BananaPi R2 (.csc mt7623 as new boardfamily)   
    This is a picture with an R2 located in a RACK assembly.
     

     
    The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server.  I am configuring a Moodle on the machine.
     
    As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID).  The disks power it is provided directly by the 430W power supply (not the R2 power connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees.
     
    It can be improved.  There are details, but in the future things will be better.  In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work).  The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes.  They are suspended on the board with metal posts.
     
    One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.
     
    At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology.
     
    --
     
    The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly).  I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module.  But I never was able to do this to work well with the 4 series kernels.  In fact, now Armbian comes loaded with the g_serial instead.  Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations.  By now, I am relying in the old friend RG45.
     
  17. Like
    chwe got a reaction from martinayotte in Daily (tech related) news diet   
    happens when you take a nap during your statistic courses.. seeing A, thinking about B and conclude C.. Unfortunately, it's not only he who should be blamed for it.. Quite a long time we tried to fit every storm, hot weather period, *random climatic phenomena* into this 'climate change thing'.. Not as surprisingly people don't believe it anymore.. The worst thing you can do to a field of science is to steal its trustworthiness.. And at least for a (growing) fraction of the population we must conclude that we achieved this since a few years now.. Well done...
  18. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    So, a few days later .....
     
    After spending several hours with my box including multiple head-banging on my desk, I found a surprisingly simple solution for an automated boot. But first some infos:
     
    1. Many of the RT1295-Boxes seem to have encrypted bootloaders (and kernel images) which makes it close to impossible to build new ones. One notable exception is (according to the firmware images) the Zidoo-line. If I understand correctly, it should be very dangerous to flash a Zidoo-box with another firmware (Lake, Beeling, Probox), because if the filenames containing words like "efuse" have a deeper meaning, then you can never again flash the Zidoo-Firmware. If someone knows more about this topic, I would be very interested to hear about.
     
    2. The GitHub-repo from BPI is bizarre, to say the least. They included a bunch of software to build encrypted firmware, which should not be needed for the BPI-W2. I could not get it to work, but maybe some others are able to do it. If someone can succeed, then point 1 shines in another light. At least you can build the dvrboot.bin and dvrboot.exe.bin yourself and I do not understand, why they (the bananapi-guys) describe cumbersome ways in their forum to download all that stuff from somewhere as a binary. I could not test these files on my Lake-1-box because of point 1, so it could be that they do not really work.
     
    3. In the end it was relatively simple. In the first u-boot, you can modify and (!!) save the bootcmd and (!!) you can pass multiple commands to it. You have to:
    env edit bootcmd then You will be asked for the new value and have to insert:
    sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr Please keep in mind that you have to use my "special" SD-card, where the kernel image and the dtb a written to the blocks 0x800 and 0xa440.
    That's it for the moment.
     
    If I find something new, I will update this thread. Feel free to ask.
  19. Like
    chwe reacted to noname in sun8i-corekeeper.sh error   
    I bought this board as soon as it appeared and immediately set up an Armbian. After that, I just updated the regular means.
  20. Like
    chwe got a reaction from lanefu in Improve 'Support over Forum' situation   
    well which project do you think?
    Let's look at a few which have some similarities.
    Retropi:
     
    Raspian:
    https://www.raspberrypi.org/forums/viewtopic.php?t=208814#p1291227
     
    OpenWRT:
    https://openwrt.org/bugs
     
    DietPi:
    mostly forum, a bit on GitHub
    ________________________________________________________________________________________-
    There's no project which is 100% similar, otherwise one of them would be obsolete.. A few of them scale bigger, some have a different focus. Some ideas:
    manual transfer: as soon as a experienced user/mod/maintainer realizes that the forum post is related to an issue he opens it, summarizes it and links to the related forum post. It's time consuming but we would keep track on all those bugs we spot through forum posts.
    As soon as we have an issue tracker outside forum or github, we've to train people once again to use it.. we've to maintain it.. and those not willing to register somewhere will still use the forum for that. The only idea which comes to my mind is either one on a well established platform so that the average user has it anyway (e.g. github) or mailing-list (I assume most people will still have a mailaccount ) but not sure if maintaining a mailing list would solve any problem - I would assume not.
     
    Maybe we can implement a bug Tag? once figured out that a thread is bug related mods/admins/devs could just add the bug tag to the related post/thread? Keeping an eye on threads with such a tag might be easier.. Still, the tag has to be removed once the bug is fixed, but it could be a starter.
     
  21. Like
    chwe got a reaction from Werner in Just a test   
    I think that was never the intention that 'armbian people' only answer to questions.. fist cause there are for sure other smart(er) people here and their contributions are highly appreciated.
    Personally I wouldn't participate in such an sub-forum. But I don't spend as much time in armbian when my 'dayjob' doesn't allow it. By paying for support people expect solutions, solutions aren't that easy. If *random hardware feature* doesn't work the pressure should be on the boardvendors side to fix it not on ours. For maintainers spending much more time to keep the project running (e.g. Igor) some sort of a salary might be mandatory and ways to make this possible isn't as easy but I don't think that such a payed supportforum is the way to go.
    how about a less radical approach. Just ignore topics which don't provide the needed information? Those really interested in getting their issue heard/solved may get it that there's information missing.
     
    challenge accepted. (we shouldn't lose our sense of humor even if it's a dark one )
     
    Besides that, I'm fine with stupid questions. Even in the field I'm good in (chemistry) I sometimes have stupid questions.. Happens.. but the way you react when you realize that you asked a stupid question makes the difference.. If you start to complain about support and and come up with "but the users are most important" I'll answer you with a polite form of "Go fu... *have sex with yourself*"... If you look at a forum from an SBC armbian doesn't support you'll see that moderators there have some sort of a scheme for questions they don't want to answer - always ends with: believe us we sold 20 millions boards we know what we're doing..
    We've to accept that there are people on forums which don't spend as much time on SBCs to get trivial issues solved on the other side, they've to accept that if they're not willing to invest time to fix things on their own/help us figuring out what's wrong, I'm not willing to waste my time with their issues.
     
     
    The first iteration of the new mandatory parts for opening a topic in technical support was a failure:
     
    the new version with:
    is at least not as harsh anymore.. but as @zador.blood.stained and @martinayotte showed  (https://forum.armbian.com/topic/9400-does-not-see-emmc-after-component-change/) here, there's still room for improvement. Maybe it needs some days/weeks/months until we have a solution which is "more or less" satisfying but I still think setting some pressure to people to provide armbianmonitor in their starter isn't a bad thing. Cause it is annoying to ask always for it and hope that he gets it after you asked for it 10 times..  (and it's also annoying to find different polite forms of the part from the "personal non rational rant" )
     
    For me this thread should be merged with "Improve 'Support over Forum' situation" - IMO it belongs to it. If nobody disagrees on that let's move it there.
  22. Like
    chwe got a reaction from NicoD in Just a test   
    I think that was never the intention that 'armbian people' only answer to questions.. fist cause there are for sure other smart(er) people here and their contributions are highly appreciated.
    Personally I wouldn't participate in such an sub-forum. But I don't spend as much time in armbian when my 'dayjob' doesn't allow it. By paying for support people expect solutions, solutions aren't that easy. If *random hardware feature* doesn't work the pressure should be on the boardvendors side to fix it not on ours. For maintainers spending much more time to keep the project running (e.g. Igor) some sort of a salary might be mandatory and ways to make this possible isn't as easy but I don't think that such a payed supportforum is the way to go.
    how about a less radical approach. Just ignore topics which don't provide the needed information? Those really interested in getting their issue heard/solved may get it that there's information missing.
     
    challenge accepted. (we shouldn't lose our sense of humor even if it's a dark one )
     
    Besides that, I'm fine with stupid questions. Even in the field I'm good in (chemistry) I sometimes have stupid questions.. Happens.. but the way you react when you realize that you asked a stupid question makes the difference.. If you start to complain about support and and come up with "but the users are most important" I'll answer you with a polite form of "Go fu... *have sex with yourself*"... If you look at a forum from an SBC armbian doesn't support you'll see that moderators there have some sort of a scheme for questions they don't want to answer - always ends with: believe us we sold 20 millions boards we know what we're doing..
    We've to accept that there are people on forums which don't spend as much time on SBCs to get trivial issues solved on the other side, they've to accept that if they're not willing to invest time to fix things on their own/help us figuring out what's wrong, I'm not willing to waste my time with their issues.
     
     
    The first iteration of the new mandatory parts for opening a topic in technical support was a failure:
     
    the new version with:
    is at least not as harsh anymore.. but as @zador.blood.stained and @martinayotte showed  (https://forum.armbian.com/topic/9400-does-not-see-emmc-after-component-change/) here, there's still room for improvement. Maybe it needs some days/weeks/months until we have a solution which is "more or less" satisfying but I still think setting some pressure to people to provide armbianmonitor in their starter isn't a bad thing. Cause it is annoying to ask always for it and hope that he gets it after you asked for it 10 times..  (and it's also annoying to find different polite forms of the part from the "personal non rational rant" )
     
    For me this thread should be merged with "Improve 'Support over Forum' situation" - IMO it belongs to it. If nobody disagrees on that let's move it there.
  23. Like
    chwe reacted to vtrandal in Possible to temporarily have armbian boot into headless mode?   
    This experience has motivated me to find where zramctl is being called during boot and replace it with a very large swapfile so my system (Orange Pi R1) does not run out of virtual memory.
    1. I have not yet found where/how zramctl is being used during boot/startup to create swap space. So I must learn about how the boot sequence is performed to find this information.
    2. I would like to search the filesystem for zramctl but searching on the target is slow and grep has segmentation faults. I want to search the filesystem on development host (where I compile Armbian).
     
    Those are my wishes from this experience. I will read the documentation to learn more and look for answers to these two questions in the forum.
     
    Thank you for making Armbian available. It is amazing. It is very good. I have no complaints. Only praise for Armbian and the people who make it available. Thank you.
  24. Like
    chwe got a reaction from JMCC in RockPi 4b 'board bring up'   
    As promised we prepare a little patch for our RockPi... Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:
    git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)
     
     
     
    It's not allays that much.. but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.
    https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284
    gpio-leds { compatible = "gpio-leds"; user-led1 { gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; user-led2 { gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; If we don't know what we can do with those we can look into documentation:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
    and from there:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt
     
    you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...
    so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes")
    CREATE_PATCHES="yes" # wait that you make changes to uboot a$ BUILD_ALL="no" # cycle through available boards and ma$ # set KERNEL_ONLY to "yes" or "no" to b$ BSPFREEZE="" # freeze armbian packages (u-boot, kern$ INSTALL_HEADERS="" # install kernel headers package LIB_TAG="rockpi_tutorial" # change to "branchname" to use$ CARD_DEVICE="/dev/mmcblk0" # device name /dev/sdx $ EXPERT="yes"  
    if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.
    ATF:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ] [ warn ] Press <Enter> after you are done [ waiting ] [ warn ] No changes found, skipping patch creation u-boot:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):
    as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:
    as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] /home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
    keep in mind.. we've to change it in the LED node and the pinctrl node..
     
    in build/output/patch we get two patches:
    u-boot-rockchip64-dev.patch:
    and for the kernel: (kernel-rockchip64-dev.patch)
    now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right..
    as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..
    hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..
    means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.
    U-boot:
    diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts index 5d73ce5..5574e9b 100644 --- a/arch/arm/dts/rk3399-rockpi4b.dts +++ b/arch/arm/dts/rk3399-rockpi4b.dts @@ -65,14 +65,9 @@ status = "okay"; compatible = "gpio-leds"; - power-led { - label = "power"; - gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - }; - - standby-led { - label = "standby"; - gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; }; }; Kernel:
    diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts index 7f10da2a8..1d4721dcc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts @@ -140,20 +140,15 @@ }; leds { + status = "okay"; compatible = "gpio-leds"; pinctrl-names = "default"; - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>; - - work-led { - label = "work"; - default-state = "on"; - gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; - }; + pinctrl-0 = <&status_led_gpio>; - diy-led { - label = "diy"; - default-state = "off"; - gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; }; @@ -643,12 +638,8 @@ }; leds { - work_led_gpio: work_led-gpio { - rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; - }; - - diy_led_gpio: diy_led-gpio { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + status_led_gpio: status_led_gpio { + rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>; }; }; Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:
    uboot:
    [ o.k. ] * [l][c] add-board-renegade.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch [ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch [ o.k. ] * [l][c] board-renegade-updates.patch [ o.k. ] * [l][c] enable-DT-overlays-support.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch and kernel:
    [ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch [ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-fusb30x-driver.patch [ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch [ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch [ o.k. ] * [l][c] fix-rockpro64-emmc.patch [ o.k. ] * [l][c] fix-spi1-flash-speed.patch [ o.k. ] * [l][c] general-add-overlay-compilation-support.patch [ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch [ o.k. ] * [l][c] general-packaging-4.17-dev.patch [ o.k. ] * [l][c] general-rockchip-overlays.patch [ o.k. ] * [l][c] nanopi4-dts.patch [ o.k. ] * [l][c] orangepi-rk3399-dts.patch [ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch [ o.k. ] * [l][c] renegade-enable-usb3.patch [ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch [ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch [ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch [ o.k. ] * [l][c] unlock-temperature.patch seems that everything is okay. So it's time to bring them back to armbian. Let's check our repo with git status:
    chwe@chwe-HP:~/armbian/build$ git status On branch rockpi_tutorial Your branch is up to date with 'origin/rockpi_tutorial'. Untracked files: (use "git add <file>..." to include in what will be committed) patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch nothing added to commit but untracked files present (use "git add" to track) there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push
    chwe@chwe-HP:~/armbian/build$ git push Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done. Total 9 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To https://github.com/chwe17/build.git a156fddf..bb63ed6d rockpi_tutorial -> rockpi_tutorial https://github.com/chwe17/build/tree/rockpi_tutorial
    our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:
    https://github.com/armbian/build/pull/1236
     
    You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it.
     
    Edit: this post was written 'on the fly'.. If something isn't clear, just let me know.. and I'll try to explain it better.
    Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer.
  25. Like
    chwe got a reaction from Dante4 in RockPi 4b 'board bring up'   
    As promised we prepare a little patch for our RockPi... Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:
    git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)
     
     
     
    It's not allays that much.. but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.
    https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284
    gpio-leds { compatible = "gpio-leds"; user-led1 { gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; user-led2 { gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; If we don't know what we can do with those we can look into documentation:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
    and from there:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt
     
    you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...
    so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes")
    CREATE_PATCHES="yes" # wait that you make changes to uboot a$ BUILD_ALL="no" # cycle through available boards and ma$ # set KERNEL_ONLY to "yes" or "no" to b$ BSPFREEZE="" # freeze armbian packages (u-boot, kern$ INSTALL_HEADERS="" # install kernel headers package LIB_TAG="rockpi_tutorial" # change to "branchname" to use$ CARD_DEVICE="/dev/mmcblk0" # device name /dev/sdx $ EXPERT="yes"  
    if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.
    ATF:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ] [ warn ] Press <Enter> after you are done [ waiting ] [ warn ] No changes found, skipping patch creation u-boot:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):
    as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:
    as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] /home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
    keep in mind.. we've to change it in the LED node and the pinctrl node..
     
    in build/output/patch we get two patches:
    u-boot-rockchip64-dev.patch:
    and for the kernel: (kernel-rockchip64-dev.patch)
    now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right..
    as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..
    hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..
    means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.
    U-boot:
    diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts index 5d73ce5..5574e9b 100644 --- a/arch/arm/dts/rk3399-rockpi4b.dts +++ b/arch/arm/dts/rk3399-rockpi4b.dts @@ -65,14 +65,9 @@ status = "okay"; compatible = "gpio-leds"; - power-led { - label = "power"; - gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - }; - - standby-led { - label = "standby"; - gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; }; }; Kernel:
    diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts index 7f10da2a8..1d4721dcc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts @@ -140,20 +140,15 @@ }; leds { + status = "okay"; compatible = "gpio-leds"; pinctrl-names = "default"; - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>; - - work-led { - label = "work"; - default-state = "on"; - gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; - }; + pinctrl-0 = <&status_led_gpio>; - diy-led { - label = "diy"; - default-state = "off"; - gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; }; @@ -643,12 +638,8 @@ }; leds { - work_led_gpio: work_led-gpio { - rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; - }; - - diy_led_gpio: diy_led-gpio { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + status_led_gpio: status_led_gpio { + rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>; }; }; Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:
    uboot:
    [ o.k. ] * [l][c] add-board-renegade.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch [ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch [ o.k. ] * [l][c] board-renegade-updates.patch [ o.k. ] * [l][c] enable-DT-overlays-support.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch and kernel:
    [ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch [ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-fusb30x-driver.patch [ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch [ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch [ o.k. ] * [l][c] fix-rockpro64-emmc.patch [ o.k. ] * [l][c] fix-spi1-flash-speed.patch [ o.k. ] * [l][c] general-add-overlay-compilation-support.patch [ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch [ o.k. ] * [l][c] general-packaging-4.17-dev.patch [ o.k. ] * [l][c] general-rockchip-overlays.patch [ o.k. ] * [l][c] nanopi4-dts.patch [ o.k. ] * [l][c] orangepi-rk3399-dts.patch [ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch [ o.k. ] * [l][c] renegade-enable-usb3.patch [ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch [ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch [ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch [ o.k. ] * [l][c] unlock-temperature.patch seems that everything is okay. So it's time to bring them back to armbian. Let's check our repo with git status:
    chwe@chwe-HP:~/armbian/build$ git status On branch rockpi_tutorial Your branch is up to date with 'origin/rockpi_tutorial'. Untracked files: (use "git add <file>..." to include in what will be committed) patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch nothing added to commit but untracked files present (use "git add" to track) there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push
    chwe@chwe-HP:~/armbian/build$ git push Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done. Total 9 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To https://github.com/chwe17/build.git a156fddf..bb63ed6d rockpi_tutorial -> rockpi_tutorial https://github.com/chwe17/build/tree/rockpi_tutorial
    our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:
    https://github.com/armbian/build/pull/1236
     
    You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it.
     
    Edit: this post was written 'on the fly'.. If something isn't clear, just let me know.. and I'll try to explain it better.
    Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer.