• Content Count

  • Joined

  • Last visited


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. chwe

    RockPi 4b 'board bring up'

    didn't saw any progress in the last days.. So not sure that they really prepare a PR. In case yes.. they should sync first with the current stage..
  2. chwe

    Baudrate supported by RK3399

    no.. It could probably set to 115200 in DT. but then it had to be changed in u-boot as well.. and to keep stuff in a proper order.. for all RK3399 boards.. Is it worth to write a whole patchseries just for such a change.. I thought about it but I'm not sure..
  3. chwe

    Armbian support for BeagleBone Black

    I think official support for the BBB is still unlikely. I think the basics for letting it boot with 'Armbian' (e.g. adding the new boardfamily, and some random linux config for it and the boardconfig file) could be done within a weekend. But improve it over time.. test and fix stuff, search for patches which aren't mainlined but do help a lot integrate (test again) and maintain them is the hard work which takes a lot of time. If people are interested in bringing up the beagle bone on armbian I (we) can for sure give you some guidance how things work here.. e.g. go through those threads may help: and after deep sea for sure it would be fun to see Armbian in space as well (we then would need a new extreme where our images on *random SBC* do serious work - someone plans to fly to mars? ).. IMO supporting a board only for one project may be not worth for Armbian as project - but helping such a project to get Armbian flying on their board might be. I would agree that the beagles might be relevant when it comes to 'serious projects' where failure of random hardware components have a big impact. Still believe that TI understands the difference between a industrial grade component and an industrial grade SBC. In terms of long time availability I would assume that beagles are also better than most boards (you can still buy the beagleboard xM - I think mine is now something like 10 years old..).
  4. chwe

    RockPi 4b 'board bring up'

    Talking about config-default.conf and a bit of my workflow (others might do it different and I do boardbring up, kernel-patching by accident not by training - I normally do in science not in computes stuff ) for patching today: actually the first line describes everything you need here... just read the docs and you'll get most of the things well described. For simplicity we use the menu which opens by starting the script with sudo ./ without any additional flags (docs explain also how to do it with flags but that not really needed, it's just faster than searching your board in the menu. LIB_TAG becomes important cause it defines on which branch you build images (e.g. normally you do it on master when you just want to build the newest image for your board with armbians settings - as a developer who doesn't commit directly into armbians master, the workflow differs a bit and other branches than master become more important). I assume that you've a GitHub account and already forked the project online. If you look at my masters tree ( it's mostly a few commits behind armbians masters tree (depends when I last synced my master with armbians - github explains perfectly how to sync a fork and how to add another remote) but it's never commits ahead of armbians master I do want to have the same git history in master as armbian has it just makes things simpler (git merge will always works without issues ).. On my current buildmachine I cloned directly my fork for building and not armbians. In case you have cloned the original and you don't want to loose all your stuff in cache (e.g. compilers which just need a bunch of time) you'll have to delete the remotes and set origin to your fork (google will help you on this one) and upstream to (or dealing everytime with the proper commands when push stuff online - if you're not a git-ninja just set origin to your fork and upstream to armbians). Example: chwe@chwe-HP:~/armbian/build$ git remote -v origin (fetch) origin (push) upstream (fetch) upstream (push) First make sure that (at least) your local master branch is synced with armbians (due to set origin to your fork, this doesn't happen automatically during build! it will only sync it with your fork which is quite sure some commits behind armbians): check on which branch you are. We will do all the development in features branches not in master! So you might be on a different one from your last build: chwe@chwe-HP:~/armbian/build$ git branch * master mt7623 r2_gmac in this case everything is fine but it happened quite often in the beginnings that I was on one of my features branches which then ended in a mess (I've some features branches which have a lot of changes compared to armbians master)... if you're on a features branch make sure you've a clean working tree before you switch. git status can help you here to ensure your tree is clean. Example for a clean one: chwe@chwe-HP:~/armbian/build$ git status On branch mt7623 Your branch is up to date with 'origin/mt7623'. nothing to commit, working tree clean or a dirty one: chwe@chwe-HP:~/armbian/build$ git status On branch mt7623 Your branch is up to date with 'origin/mt7623'. Untracked files: (use "git add <file>..." to include in what will be committed) some_random_fancy_shit_i_did_in_my_features_branch.txt nothing added to commit but untracked files present (use "git add" to track) (either with git stash or git add -A && git commit see git manuals what might be appropriate here - I prefer often to commit stuff if it's (partly) working and stash only when I'm quite sure I'll switch back to the features branch soon, commit messages can help you sometimes if you don't remember the rational behind a changes you did a few weeks back on features which need a bit more time to develop ISP1 driver on rk3288 was a feature I tried over weeks and failed more than once - btw. got never merged into master for good reasons). If the tree is clean switch to master with git checkout master! now we sync our master with armbians master (and push it online to our fork as well, example in spoiler): git fetch upstream git merge upstream/master git push if you visit your fork online this should be visible: This branch is even with armbian:master. Let's create a features branch for our funny new feature locally and on remote (git checkout -b branchname && git push -u origin rockpi_tutorial): chwe@chwe-HP:~/armbian/build$ git checkout -b rockpi_tutorial Switched to a new branch 'rockpi_tutorial' chwe@chwe-HP:~/armbian/build$ git push -u origin rockpi_tutorial Username for '': chwe17 Password for '': Total 0 (delta 0), reused 0 (delta 0) remote: remote: Create a pull request for 'rockpi_tutorial' on GitHub by visiting: remote: remote: To * [new branch] rockpi_tutorial -> rockpi_tutorial Branch 'rockpi_tutorial' set up to track remote branch 'rockpi_tutorial' from 'origin'. now config-default.conf and especially LIB_TAG becomes important. We tell the build-script now that by default we want to build images on our new features branch. So change LIB_TAG="master" to LIB_TAG="rockpi_tutorial" with your favorite editor. Cause we go to create a patch, change it to yes as well CREATE_PATCHES="yes". In the next days I'll have a look if there's an easy but meaningful example of patching something for RockPi including the pull request to bring it back to armbian. I'm quite confident we'll find something in the device tree to fix... The reason I work with features branches is quite simple.. In case my random ponny feature doesn't make it in the pull request (maybe the change isn't that smart or it breaks something I didn't consider) and therefore doesn't get merged into armbians masters I simply can delete my branch or let it collect dust but I don't have to do anything in my masters branch (e.g. 'rewrite' the git history to have it even with armbians for my next features branch which is hopefully better than the one which didn't make it - it's just painful to clean up a messed up masters to get it back to the githistory of armbians - believe me, I did it more than once when I wasn't that familiar with git - as said in the starter, we all didn't start as git-kernel-u-boot-userspace ninjas ). On a features branch this doesn't happen. delete it or let it collect dust once you don't need it anymore.
  5. chwe

    RockPi 4b 'board bring up'

    so today we're talking a little bit about the buildscript (likely that those posts will be splitted out into it's own thread to build up a miniseries of tutorials)... I just talk about basics of it. To be honest, I don't know every part of it fully but for detailed questions there are people here which can answer specific parts. For the simplicity we assume that the SoC on the board is a supported one (rk3399 is). A basic overview with tree -L 2 to get a overview: cache: to avoid downloading the sources again and again every time you build an image and saving you time to build images, armbians build-script caches sources (e.g. rootfs, kernel sources, u-boot sources, atf, compilers - out of tree sources can't always be compiled with the newest compiler versions so we also have some older ones) config: basic configuration files for your board, the kernel and sources we use. config --> board: an armbian specific boardconfig file, for the RockPi 4b it looks like the follwowing: # RK3399 hexa core 2G/4GB SoC GBe eMMC USB3 WiFi BOARD_NAME="RockPi-4B" BOARDFAMILY="rockchip64" BOOTCONFIG="rockpi4b-rk3399_defconfig" # MODULES="" MODULES_NEXT="" # KERNEL_TARGET="default,dev" CLI_TARGET="stretch,bionic:default" DESKTOP_TARGET="stretch,bionic:default" CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" BOARDFAMILY tells you which sources it uses (later more on that). BOOTCONFIG telly you which xxx_defconfig file in u-boot will be used (maybe something for an u-boot plumber tutorial follow up) Modules is only needed if you've to install special modules to enhance functionality (something for a more detailed tutorial). KERNEL_TARGET (will be explained in sources), CLI_TARGET (which flavors of Armbian you can build (here we provide only ubuntu bionic and debian stretch for some older kernels we've to provide xenial as well cause they're not able to work properly with stretch or bionic). DESKTOP_TARGET - same as CLI but with a DESKTOP (e.g. we don't provide DESKTOP images for boards without HDMI etc.). CLI_BETA_TARGET not of interest yet. config --> kernel (the .config file you normally get with make ARCH=arm xxx_defconfig if you compile kernels on your own - our configs differ often from defconfigs provided by kernels often to enhance functionality) config --> sources as you can see, the RockPi4b is part of the rockchip64 family therefore ( for a beginner, most of this configs here can be ignored cause it needs some knowledge to deal with but a few interesting parts will be explained. It basically describes you which sources we use for ArmTrustedFirmware (part of all(most?) ARM64 boards during boot. U-boot (before the kernel fires up) and which kernel sources will be used for default (often a BSP Kernel), next (mostly a vanilla kernel) and dev (mostly a kernel close to mainline - for rockchip64 for example this is a kernel based on 4.20). some tweaks needed to build an image (e.g. different SoCs expect the u-boot binary on a clear defined place inside the SD-Card for example here: dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none >/dev/null 2>&1 ) tweaks which are needed to boot up the board (e.g. rockchip needs a few binaries and it depends on which rockchip SoC, (sometimes also ramspecific) you use to boot up a board - rockchip64 is for rk3328 and rk3399 and they use different binaries) some family_tweaks here to enable debug console etc. (boardspecific tweaks are also here with some if statements to keep those changes separated from the others). To do changes here or to create such a file from plain (for a new boardfamily) you might need some more experience but it's worth to have a look at it (especially to check which sources we use). The rest of config is currently not that important. config-default.conf (shows up after you build an image for the first time): this file will be important but since this post here gets anyways too long I try to explain it in the next days (it deserves to have it's own day) lib: the build-script is not only one big bash-script it's splittened into different ones. In the beginnings you (hopefully) don't need to change something in them but cause the script isn't everywhere 100% clean (we've to be pragmatic here + different people have different opinions how stuff should be solved) it's worth to try to understand how random part of the script work (needs knowledge in bash and definitively not learned within a few hours - you need some background this grows over time) output: that's where your kernel config (if you decide for Show a kernel configuration menu before compilation - would also need it's own post), debs (debian packages built during compilation, e.g. needed for sending kernelupgrades via apt upgrade), debug (also something for a further tutorial - you'll have a lot of fun with this folder during development ) images (the finally compiled images if nothing fails) patch (will be explained in the follow up, but that's most of the work devs do here.. - e.g. if we fix something inside a kernel or u-boot etc. a patch is automatically generated this is then moved to the appropriate patch folder and part of the buildscript) packages: blobs we've to deliver (e.g. to boot up a board), bsp (board support package - I also call non vanilla kernels bsp kernels, it has similarities but it's not the same - some boards need special configurations, e.g the bananapi r2 which has 5x GbE has here some configuration files to bring up all it's interfaces), tools (never worked with, ask someone else ) extras-buildpkgs for packages we deliver to get the enhanced functionality ( also not needed to understand fully in the beginnings - wouldn't call myself an expert on this part.. ) patch: if you generate a patch for kernel or u-boot and you want that others can use it as well place it here in the right folder, create a pull request to armbian and we'll get it. The structure is 'relatively' simple splitted into kernel, u-boot and atf (you won't patch atf soon.. ) for the kernel then splitted into boardfamily-branch (default, next & dev - for the rockpi this means rockchip64-default and rockchip64-dev is of interest). For u-boot it's mostly u-boot-boardfamily (sometimes we have two branches for u-boot, e.g. the time we switch from a out of tree u-boot to upstream or we need different u-boot sources. not that often here u-boot-rockchip64-dev is of interest for the RockPi) userpatch: the same than patches but for stuff you don't submit back to our tree (e.g. you can place your patch there if for whatever reasons it's not accepted by armbian - e.g. if it breaks other boards) now you got an brief overview how much you'll have to learn until you understand it fully and in the next days I might partly explain how to use it.. If you can't wait reading more.. there you go:;tab=comments#comment-65998 have fun.
  6. seems to be 'very simple' patches for upstream u-boot are there, and recent kernels as well (maybe it could be worth to compare them with upstream).. So building images built by armbians buildscript doesn't look that hard. Getting them officially into our build-script on the other hand will be harder (we try to reduce workload - there must be good reasons for a new soc family).
  7. chwe

    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 ( 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. ( 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.
  8. chwe

    RockPi 4b 'board bring up'

    you can start with testing: maybe not yet for the RockPi 4b but for other boards you have? google is a good helper which I quite often use. If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step. You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.
  9. chwe

    Spelling error in Armbian Docs

    yes and there are good reasons for it. Linus salary is also partly paid by Microsoft... it's never too late.. for sure you'll find something else to contribute.
  10. chwe

    Spelling error in Armbian Docs

    And here's the link how to contribute.. fork docs: fix it send PR and it gets soon also updated on
  11. chwe

    Orange Pi PC - A disaster ?

    well some people (including me) may disagree on this one, but that's a different story and it depends a bit on use-case. I've an OPi PC + (difference 8gb eMMC and onboard wifi) and it runs now since roughly a year in headless without any issues. So the PC isn't a disaster but your combination might be one. A few things to consider: proper powering quality SD-Card don't use crappy USB-Wifi If you describe your wifi dongle as crappy then it might be crappy. There are cheap wifi dongles with proper Linux support, just check if yours is one of them (I don't have it in mind and I wont check it for you). Make sure your board is properly powered and that you don't use a crappy sd-card just don't it. For 3.4 kernel we've it might be worth to try it when combined with DVI -> HDMI adapters.. But displays on SBCs is not my world so I can't give much advise here.. and a last one: we've a nice getting started guide to prepare your image.. I hope you followed it:
  12. chwe

    Daily (tech related) news diet

    well we have what you would call a militia parliament.. It's not always that they understand stuff better.. But hey.. data is the new oil.. we might need a few exxon valdez'es or deep water horizons to figure out how this new oil is handled safely.. some other bad jokes.. we don't understand it fully yet but let's build up a cartel (that's some years ago for the real oil)... wherever the pipeline goes.. someone is upset once it's in the environment it needs years until it disappears.. seems that this 'dataset' also contains information of their kids (account-names etc.), maybe this helps them a bit to understand the issue better... feeling like grandpa simpson
  13. chwe

    Helios4 Support

    just answer with yes.. sorry, I had to comment on this when I unlocked the post.. I don't know the helios well but one of my boards has all LEDs disabled so that nobody gets upset by blinking lights.. I wouldn't recommend it cause those LEDs actually make sense but well it's a working solution.. (and NO there isn't a spycam on it )
  14. chwe

    Daily (tech related) news diet

    German politicians may realize that collecting too much data can bite them back... (German) (English) Besides politicians (from most parties except the one which sits on the right side of the Bundestag) also journalists and a few comedians were targeted. Welcome to #Neuland! They might realize that data collection isn't always the best option.. Just a few weeks back Germany's 'Digital State Minister' claimed that privacy in health care data blocks the country from 'being on top in digitization'.. ( well, hopefully all her friends in the party which have a leaked phone numbers tell her that privacy isn't such a bad thing.. (I've no idea if her number was leaked as well, but it might help her to understand how much privacy is worth)...
  15. chwe

    picocom login on MacOS

    there was a nice little how to in the odroid forum for minicom:;t=841 I think it's more or less the same for picocom as well (they don't differ that much) and I don't have a mac anymore to test stuff... Keep in mind there are a lot of fake FTDIs on the market (some of them work without issues for example mine. - it's a proved fake, some tend to be more problematic).. btw. once you figured it properly out you might add it to this thread here? always nice to have tutorials enhanced.