chwe

Moderators
  • Content Count

    1044
  • Joined

  • Last visited

2 Followers

About chwe

Profile Information

  • Location
    Switzerland

Recent Profile Visitors

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

  1. @frank-w as far as I understand the purpose for boards which have a SoC link to a DSA is that eth0 should be always up not? see here for config.. https://github.com/armbian/build/tree/master/packages/bsp/mt7623 e.g. everything related to wan/lan starts with 10. by default all interfaces are bridged and should get their IP by DHCP. It's not 100% satisfying but as long as people don't mess and use networkD, it should work. If people try to use archaic /etc/network and do insane stuff there.. well networkD might not play well as most services which end with s D... For the board bring up, it was IMO the best way to get it working. For configuration afterward.. well people have to understand network d good enough to configure it properly.. If they just purge part without understanding and reading this thread here.. Well you're on your own.. I won't support your mess. one of my concerns when I started the work on this board: and it seems to become true.. It is a board for experienced users or people willing to learn stuff.. @frank-w or @Igor can you please link this thread into the BPi forum? so that people read stuff (or at least have a chance to read) before they mess up their images. I think I was quite open during development/board bring up. Nobody cam up with better ideas how to solve stuff so I did it the way I think it's acceptable...
  2. shouldn't matter.. as long as you don't break u-boot.. it should always look for a bootscript on SD-Card first.. They have also such an firmware uploader tool similar to RockChip, so you should be able to unbrick it in case something goes really wrong.. Don't get me wrong, Franks work was and is still important to get this thingie working.. Without his wiki, or the proof that this board works good on mainline, this thread wouldn't even exist. It's just a 'maintenance cost calculating'... Even when I would leave Armbian, the current kernel/patch level would allow the other maintainers to still support the board assuming that mainline doesn't break stuff.. With an out of tree kernel such stuff gets complicated... What happens if Frank doesn't manage his kernelfork anymore? We would have a kernel where we had to apply all patches by hand to keep it in an good shape. Whereas with mainline, the things are just there. the switch only matters if you have a boot binary on SD & eMMC. So my switch is still on SD when I boot from eMMC (obviously with a removed SD-Card). I don't know what defaults the 1.1 board has. I don't have one so I can't test. Can you test it? Boot from SD-Card with an working image on eMMC and check where it goes? If you want to be sure that it boots from SD-Card just unlock boot0 and erase it with: echo 0 > /sys/block/mmcblk0boot0/force_ro dd if=/dev/null of=/dev/mmcblk0boot0 then it should go back to SD-Card... a great source for understanding stuff: https://wiki.archlinux.org/index.php/systemd-networkd without arch, I would be lost.. They have really user-friendly wikis.. Just to keep important information in the same thread:
  3. which Parts are too different? it’s mainline-Kernel, i’ve added features by merges, which you can also use to integrate in your Kernel… from the BPi forum here: http://forum.banana-pi.org/t/bpi-r2-new-image-armbian-with-kernel-4-19-y-2018-11-5-support-by-armbian/7193/17 I won't respond in the BPi Forum. My time is currently very limited and don't follow all forums related to the SBCs I use. Yes we could patch in all the nice stuff you did, or even use your kernel tree for the BPi R2. But either we rely on an out of tree kernel (yours) or we've to heavily patch mainline with all the patches you applied. The first could be an option but during development I decided to not go that way. The second would mean that we've to adjust this patches everytime they break during kernel bump to newer versions, something I'm not willing to to. Keep in mind, Armbian support for the R2 was quite a long time a one man show.. Nobody was interested in contribution therefore I could do whatever I thought would fit best.. Since my interest in HDMI is somehow non-existing at the moment.. I simply don't care if it works.. Similar to nand-sata install.. It wasn't of interest for me for a long time.. I recently thought let's give it a try and I 'wasted' the whole Sunday afternoon to get it working with a minimal adjustment to ensure it doesn't harm the >50 other boards Armbian supports (means for me - reading into how nand-sata-install basically works.. try a bunch of time to get it working, write a PR, just a side-note: without some hints I got back in may from Wolfgang and your wiki, this wouldn't ever happen. Collecting all the missing bits to get such stuff up is just painful thanks to both of you, things were a way easier... ). To keep my workload for the board in an acceptable range I tend to go for pure mainline. If mainline supports feature X, no problem to support it in Armbian (for the mt7623) as well. If mainline doesn't support it.. Well I wont spend much time trying to bring it up. Maintaining patches over time is time intensive.. @Igor and others do a lot of work for other SoCs to have features supported before they reach mainline.. For the R2 this wont happen. It's only one board in the MT7623 family.. So we (as Armbian) have to keep the support costs as low as possible, means everything which probably opens Pandora's box should be avoided. People tend to not understand that Mali != video acceleration. If HDMI and Mali is there people want KODI running.. I'm not willing to deal with questions like "why's KODI not working smooth on Armbian on the R2". Simply not. If people want KODI on it they should ask the KODI people. If people want HDMI on it, they should use your image or prepare a sane patch based on mainline for it. I won't do it. Similar for the onboard wifi.. I never touched it cause I personally didn't see an use-case for it. It just bloats more support questions in case this chip doesn't work reliable. We as Armbian don't have experience with the one soldered on this board. Igor packed it now but disabled it by default which is okay for me (at the moment), but in case support questions for it are overwhelming I'll take care that it gets wiped out from the buildscript cause I don't want to have a second XR819. The only chance I see to bring this board from csc to wip or fully supported in the future is to keep the maintenance costs as low as possible. So stick it to 'as clean as possible' vanilla LTS kernels which should not break and when time allows it I'll maintain a next branch with mainline (4.20 --> 5.0 etc.)... We try to reduce the workload for all the boards we support (see here: https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=63170 and follow ups). For a one board SoC I clearly prefer a mainline only approach to keep it maintainable. The main features are supported, and for the rest.. It's up to the user-base of this board to bring it up and test it. My 'job' is 'done' as soon as I can stick it to a proper upstream u-boot and the bootscript is fixed so that people can put their rootfs on something else than ext4 with nand-sata-install (which is currently broken for btrfs - at least when I tested it). The second gmac up would be a 'nice to have' a sane network config (everything under one bridge is probably not preferred by everyone) would be nice as well but not of high priority to me. I do in chemistry not computer science.. bringing up such stuff an testing it took me nuts and a bunch of reading/testing every-time.. For me this is definitively not a 'beginners SBC' so people using it with Armbian should either be experienced with such stuff so that they can fix things on their own or at least willing to learn (as I had to as well)... I wont write any step by step procedure do get things running for it.. If *joe random* needs such step by step procedures I suggest you go for a board which has a bigger community or use another Image where the creator is willing to give you such step-by-step procedures. My offer is a 'pure' vanilla kernel and an Armbian rootfs which supports most of the features provided for this board and thanks to Armbians buildscript you can create all needed updates on your own, so in the end you get a set of nice *.deb packages which allow to update your board(s) with dpkg -i *.deb and in case the board ever enters wip or supported you'll get those packages even on armbians apt server so that an apt update && apt upgrade will work. Kernel-support is quite mature but for whatever reason no other board-maker picked up the SoC. I think that's not a bad offer for a board which ended in a closed thread the first time it was discussed cause involved people were more focused on personal insults. Is it perfect? Indeed not.. It's no up to all users to make it better. You now get an Image which boots out of the box from SD-Card and also works on eMMC with a simple nand-sata-install call packed with a 'near to upstream' u-boot.. working armbianEnv.txt with working mPCI, USB and SATA and all blobs needed for it are prepacked with the Image. If you really need decent wifi, go for an mPCI based one (@Igor tested a few). If you need for whatever reason a display, IMO there are better boards for such use-cases. If you want to contribute: provide some real-world numbers what the network is capable to deliver. I simply don't have time and enough equipment to test it at the moment. Encrypted and not encrypted would be nice.. Or find a more sane approach for the overall network configuration: https://github.com/chwe17/build/tree/46665fc32f1ec0a4981a743fc259173c07383c04/packages/bsp/mt7623 there's your starting point..
  4. hmm I think networkmanager probably overwrites it then? simple approach: sudo nmtui -->edit connection -->edit --> IPv4 configuration --> show --> DNS servers add whatever you need there (you can have more than one.. so it will fall back to the second in case the first doesn't work) exit nmtui properly and then a systemctl restart NetworkManager should do it.. not even a reboot needed..
  5. I assume you work from a ubuntu 18.04 machine (no docker or whatsoever): in config-default.conf CREATE_PATCHES="yes" sudo ./compile.sh the menu asks you if you want to make changes to the kernelconfig --> yes as well it then prompts you to make changes in the sources.. then you put in your new module, check that it is present in the makefile as well and that kconfig fits. See gpiomem from rk as an example: https://github.com/armbian/build/blob/master/patch/kernel/rockchip-default/261_gpiomem_driver.patch if there are dependencies in kconfig, check if they're available... otherwise you've to patch them as well. e.g. here's an example with dependencies: https://github.com/armbian/build/blob/a979430e9b2b9b11f858d751bcb9b98be760ab3b/patch/kernel/sun8i-default/0011-gpu-drm-Add-Mali-DX910-SW-99002-r2p4-02rel1.patch#L42 after patching, the new drives should show up in menueconfig and you can just activate them... You don't have to mess with a config file.. a proper new one will be generated. Don't try to build config files manually as long as you're not really experienced.. chances are high that you get fooled.. --> we have a great script which does it properly.. In case you messed with the cached kernel besides a generate patch session.. In can be that the patch you'll generate isn't properly.. So just wipe out the kernel and start from a freshly downloaded one. The buildscript sometimes doesn't revert new files which didn't exist before.. add sources to clean level or just wipe out the mainline kernel.
  6. chwe

    Raspberry Camera V2.1

    officially there's only a v1 and a v2 https://www.raspberrypi.org/documentation/hardware/camera/ v1 with OV5647 and v2 with IMX219. both currently don't work with armbian you'll find more infos by using the search engine. buzzwords: camera tinkerboard, and ISP1 driver
  7. could actually be defined in: /etc/systemd/network/ https://github.com/armbian/build/blob/70bb483a3fc3e5d6a431c6e8d67e0dcb88330b28/config/sources/mt7623.conf#L59 all interfaces are handled by networkd. During the time I played with network I just looked for a way to bring all interfaces up. The current driver only allows to bring up eth0 (eth1 should be possible as well, but those patches never reached mainline - look through the thread here, you should find it). Feel free to play with it. Actually eth0 and eth1 should be connected to the DSA chip (but DSA networking is slightly different from normal networking so be prepared.. ). @frank-w ported it to 4.14 if I'm right but no idea if he ever ported it to >4.14 cause there were some bigger changes in network for the kernel. https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt e.g. this patch series would be needed (and firstly adjusted): https://lore.kernel.org/patchwork/patch/793309/
  8. it didn't work when I tried to have the rootfs on a btrfs partition.. I assume it needs some adjustments in the bootscript.. I'll have a look into it in the next days..
  9. to replicate: first install u-boot (entry 4) then install to emmc (entry 1). remove sd card cause per default it 'should' boot sd if it is present..
  10. after some pain, it finally works.. edit: with it.. I mean nand-sata-insall to eMMC Last login: Sun Nov 11 22:02:07 UTC 2018 on ttyS2 ____ ____ _ ____ ____ | __ ) __ _ _ __ __ _ _ __ __ _ | _ \(_) | _ \|___ \ | _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | __) | | |_) | (_| | | | | (_| | | | | (_| | | __/| | | _ < / __/ |____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_| |_| |_| \_\_____| Welcome to ARMBIAN 5.66 user-built Debian GNU/Linux 9 (stretch) 4.19.1-mt7623 System load: 0.76 0.18 0.06 Up time: 0 min Memory usage: 4 % of 2010MB IP: CPU temp: 39°C Usage of /: 14% of 7.1G [ 0 security updates available, 27 updates total: apt upgrade ] Last check: 2018-11-11 22:10 [ General system configuration (beta): armbian-config ] @Igor can you review and accept the PR.. @malvcr can you test if it works on your board too? Have fun with testing.
  11. looking through the diff at least kernelconfig needs some polishing... https://github.com/armbian/build/compare/master...paolosabatino:master adding @TonyMac32 here.. Maybe it can be partly set as modules?
  12. chwe

    Start a script when an interface is up

    https://wiki.archlinux.org/index.php/NetworkManager#Network_services_with_NetworkManager_dispatcher
  13. chwe

    Rock PI 4

    likely(http://wiki.radxa.com/Rockpi4/getting_started): as far as I know, all boards which work with upstream u-boot are DDR not LPDDR based... At least they implement PD properly.. Hopefully they deliver a proper heat-sink for it. Did you ever diff'd ayufans u-boot against upstream?
  14. chwe

    Daily (tech related) news diet

    https://areomagazine.com/2018/10/31/gender-controversy-comes-to-physics-a-response-to-the-statement-against-alessandro-strumia/ an interesting blog entry towards a controversial talk given by a High Energy Theory presented at a CERN workshop towards gender and its public response from a bunch of physicists, pointing out that they disagree on certain points of this talk. Without checking all linked references, for me it looks the anonymous response/summary in this blog entry seems to be 'well crafted'. It looks like he spent a lot of time to check the references from both sides. Such topics tend to be a 'hot topic' in those days. As a researcher it's a way less 'risky' to make controversial statement in physics or chemistry than to make one in gender related topics. One of the main arguments I see quite often in such 'public responses' are based on "He isn't an expert on *random topic* so he can't use the metrics used in his field to analyze a question in *random other topic* which does use different metrics...". A statement which I don't like. It implies that only experts on a field should make statements. This is somehow a technocratic point of view, which doesn't work well with my democratic point of view. As soon as we come to issues which don't only affect one field it becomes even harder. There aren't many experts for *random topic in science* and *random hot topic*. Should we only rely on the opinion of those few or should we allow others to be also part of the discussion. It's a fact that less women do in STEM and I think it's worth to investigate why this is so. But should we really smash down everyone which has a 'not mainstream'/controversial opinion or analysis of the topic? If it means that you've to fear, that your research career ends 'only' cause you gave a controversial talk, science will be boring in the future. Science is sometimes speculative, the knowledge isn't there from the beginnings, it grows over time. Quite often our model 'how things work' change over the time of a project. If we would know the answer before we start our experiments it wouldn't make sense to burn money to make those experiments. The goal is to prove or disprove your hypothesis. IMO disprove your own hypothesis is a way harder than find arguments to prove it. We are more confident to find evidence for our *unicorn hypothesis* than accept that it might be wrong. And sometimes, controversial inputs from other people also from other fields can help you to get a broader view. I remember a nice reaction (on paper) which I thought would fit really well in my research project. I wasted a bunch of time trying to get my unicorn working. The results were sometimes promising sometimes bad but never reliable. It was never clear (to me) why it doesn't work properly. During a coffee with someone 'out of chemistry' since years, he brought up an idea which I thought was boring, for sure not better than my unicorn and likely unreliable as well. Going back to the lab, reading a few papers and gave it a shot. Whereas my unicorn gave yields between 10-40% (not really reliable), the boring one over two steps gave yields between 80-85%. My unicorn was dead, but for the overall research topic, those 80-85% yield in this reaction made the difference between having enough material to answer a whole set of questions or having only one shot. If we want to understand if there's a systematic issue why there are less women in STEM and if there's a bias, we should investigate arguments/hypotheses which back ours, but also the one which who question ours. Tear down the arguments of the others but don't tear down the people behind them. Otherwise we might miss an important argument/idea cause they don't feel confident to share their opinions or findings in public anymore.
  15. chwe

    Daily (tech related) news diet

    https://boingboing.net/2018/11/03/balkanizing-the-balkanizers.html Elsevier sues Swedish ISP so that they've to block Sci-Hub. ISP blocks Sci-Hub and Elsevier... For those doing in science, Elsevier may be well known, for the others they are one of the world's major provider of scientific, technical, and medical information (wiki quote). Full access to their journals is unbelievable expensive, and mostly published by universities which get their funding (partly) from the govt. So, the research is payed by your taxes and and libraries/universities pay a lot of money to access them. The whole business model got some attention due to their high prices. That's were Sci-Hub came into the game, they offer a bunch of those articles for free (for sure not legal). Well, obviously Elsevier doesn't like to lose money (well, I assume most of the people wouldn't pay the 50$ fee for an 10 pages article if they don't get it from SciHub but that''s not my field, my university has free access to most of their publications - we pay for it). The problem is, to get attention for your research you've to publish it in high impact factor journals, some of Elseviers journals are such high impact factor publications so it might be interesting for your research career to publish them there, on the other hand this makes then your research inaccessible for the poor people which is IMO not fair. It's a balance between pushing your research career & make your research accessible for everyone. What's more important? Depends on the point of view.. A publication in a well respected journal may push your research career but on the other hand, your institution and others pay a lot of money to have such stuff accessible for their researcher and students (money which then doesn't go into research). Open access journals aren't that common in science, some offer that you pay for open access publication (you pay that others can read it for free - but mostly your research budget doesn't allow it or they are of questionable revenue --> just pay enough and we will publish whatever garbage you present to us). I hope this changes in the future. Cause the peer review process is mostly done by other researcher (to keep the journal happy, a prof. has to review x articles per year for free... if you don't do it you might be not able to publish in their journal anymore). Normally, you don't read printed journals anymore in those days (e.g. I've a small python crawler which looks for topics I'm interested and I download then PDFs to have a look into it). So a lot of the fees which might make sense in the past are questionable now but it didn't change much (well the fees get higher ). At least the Swedish ISP made a clear statement to Elsevier that they don't like their practice... Even if this means blocking websites, something I don't like either.. But it might get some attention that we've to rethink our way of making our research accessible for the public. IMO the taxpayers should be able to see how we spend their money (even when the majority of them doesn't understand what we do). On the other hand a proper peer review process is important to keep your publication on a high standard, otherwise it's not worth to read (there are a few publications I mostly avoid cause they're known to publish a lot of garbage, so even if there's a good one there, I probably miss it cause I don't trust the whole journal at all - I can't spend the whole day reading journals, sometimes I've to do some experiments as well ).