hmartin

Members
  • Content Count

    63
  • Joined

  • Last visited

About hmartin

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

973 profile views
  1. I would recommend instead that you install the base OS to NAND using the provided script and then use a configuration management tool like Ansible or Puppet to get the node into the final state. Copying an image from one board to another is a bad idea for a few reasons: your SSH host keys will be the same your hostnames will be the same network configuration (if static) will need adjustment If you want to provision and manage many boards, a configuration management system like Ansible or Puppet is the best method. If this really doesn't work for you and you can only make a copy, then I would look into doing it at a filesystem level instead of a block level. rsync in archive mode (rsync -a) is a good tool for making filesystem level copies.
  2. Why do you think the patch is for 4.14? The patch has existed for many months, but Igor updated it recently. (I'm genuinely curious, not trying to start an argument. I don't see 4.14 mentioned in the commit message or anywhere else. The similar patch for sun8i-dev is for 4.10 according to the commit message) Well it is the Banana Pi M2 Ultra, it would be more surprising if the kernel wasn't outdated. Anyway, it seems I can build the packages successfully without the patch, so I'll just exclude it from the build process.
  3. Build environment is Ubuntu 16.04 in an lxc container. Trying to build kernel + u-boot, I am repeatedly getting the following error: patching file tools/include/tools/be_byteshift.h patching file tools/include/tools/le_byteshift.h CLEAN scripts/basic CLEAN scripts/dtc CLEAN scripts/kconfig CLEAN scripts/mod CLEAN scripts dpkg-deb: building package 'linux-firmware-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-firmware-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. gzip: /usr/share/doc//changelog.Debian.gz already exists; do you wish to overwrite (y or n)? y sh: 1: cannot create DEBIAN/md5sums: Directory nonexistent scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 2 Makefile:1343: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 dpkg-deb: building package 'linux-source-4.13.0-rc4-dev-sunxi' in '/home/ubuntu/armbian/.tmp/linux-source-dev-sunxi_5.34_all.deb'. dpkg-deb: error: failed to read archive '/home/ubuntu/armbian/output/debs/linux-image-dev-sunxi_5.34_armhf.deb': No such file or directory Looking at the root filesystem, I can see that something in the Armbian build process is actually overwriting /usr/share/doc/changelog.Debian.gz, which seems like it shouldn't be happening (e.g. files are supposed to be installed to a build directory): I've tried checking out armbian from github again, and the issue persists. Yes, I am building the kernel + u-boot for the Banana Pi M2 Ultra, which is unsupported (hence why I am posting here), but I cannot see anything in the configuration for this board that would be causing the above behaviour. Building the r40-v2 branch several months ago worked without issues. Since updating armbian to current, I am unable to package the r40-v2 or r40-v5 kernel. If I remove the patch packaging-4.x-DEV-with-postinstall-scripts.patch I am able to successfully build the packages: dpkg-deb: building package 'linux-firmware-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-firmware-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-deb: building package 'linux-headers-4.13.0-rc4-next-20170811-sunxi' in '../linux-headers-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.34_armhf.deb'. dpkg-deb: building package 'linux-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-genchanges: binary-only upload (no source code included) dpkg-deb: building package 'linux-source-4.13.0-rc4-dev-sunxi' in '/home/ubuntu/armbian/.tmp/linux-source-dev-sunxi_5.34_all.deb'. dpkg-deb: error: failed to read archive '/home/ubuntu/armbian/output/debs/linux-image-dev-sunxi_5.34_armhf.deb': No such file or directory [ o.k. ] Kernel build done [ @host ] [ o.k. ] Target directory [ /home/ubuntu/armbian/output/debs/ ] [ o.k. ] File name [ linux-image-dev-sunxi_5.34_armhf.deb ] [ o.k. ] Runtime [ 7 min ] @Igor I've looked at your modifications to the patch in commit 94bcf43 and I can't see anything obviously wrong, but it seems there is some regression in this patch which is causing packaging to fail now. Could you confirm that kernel packaging is working correctly for you on sunxi-dev with the latest patch version?
  4. Looks like the BananaPi M2 Ultra support is alive and well! (this is sarcasm) Mine was "working" until I decided to try mainline on it. Now I'm building Icesnowy's r40-v5 to see if there's been an progress. Please don't ask me for an Armbian image, support is nowhere near good enough to release even an alpha image.
  5. Glad I searched the forum. I'm trying to get 4.13-rc4 booting on the BPiM2U because apparently dwmac support is landing in 4.13. Unfortunately, it seems that we are still pretty far from mainline support for the R40, since trying to boot gets me this far: http://i.imgur.com/gLRPxpE.png I also found out that u-boot doesn't support USB, or Ethernet. So when I was missing the dtb (because 4.13 doesn't include one for the R40) the only way to recover was to boot from sdcard and copy the dtb. Thank goodness I still happened to have the armbian Banana Pi M2 Ultra image I made earlier on an sdcard. If not I would have just thrown it to the scrap. I think I'll wait until 4.13 is released before I start hacking Icesnowy patches on top. Exciting times ahead...
  6. In my opinion this is not limited to the Orange Pi Zero, and I am definitely not the only one to experience it. I know this is another Orange Pi Zero thread, but please see: Someone answered the question asked, but with an answer the user did not want to hear and did not accept. This in my opinion is a "garbage thread" candidate. It adds nothing, and attacks the person who answered the question. It would be great to trial, but I'm not confident it will stop people from just going back to the original thread and posting even more hostile responses because their previous reply was censored. Perhaps it's possible to have a moderation team who are separate from the developers? Anyway, I still say that it would be good to have a separation between "official" support of a limited # of boards, and "unofficial" support where stable/nightly releases are not provided and people can build and provide "unofficial" builds from git if they are willing to deal with users like the above. This method has worked well for the Android scene, and I don't see why it can't also work well for Armbian. Official boards can have forum sections dedicated to support threads. Unofficial boards have their own "unofficial" area. To avoid too much moderation work, only official area would be moderated. Unofficial area is more like "wild west"
  7. Just to update this thread: we now have kwboot working on Armada 38x boards. The trick to getting kwboot working was a patch which was never included in u-boot mainline: https://lists.denx.de/pipermail/u-boot/2015-August/226105.html If you apply this patch to u-boot tree and build it, you will get a kwboot binary that works for Armada 38x chips. The timing is still variable, so it will take multiple attempts to successfully kwboot, but it is definitely possible. I am quoting the post from Doozan: kwboot-x86_64.gz kwboot.patch
  8. Two things I want to bring up: "Trial period" is a great idea, and this is what I was getting at: During the "trial period" nightly/stable builds are not available. Anyone wanting to test out the board during the trial period has to build an image from git themselves. This prevents devs from being mobbed by people for support when there are still lingering issues. Forums suck for finding information, and no one ever uses the search feature. So, wiki software. MediaWiki is FOSS, but the syntax sucks. Confluence isn't FOSS, but it is free for Open Source projects, and they have a really excellent editor. I'm not affiliated with Atlassian in any way, I just think if you want a usable, low-friction wiki, Confluence would be a good choice. I realize since Confluence is not FOSS, this has some negative appeal in some corners. Also it's Java... We tried this already with the Orange Pi Zero. It just ended up pissing off everyone who was working on it (including me). No user seems willing to accept our explanations about performance and what is feasible. They think because the manufacturer says "WiFi" it will do the same things as their $1,200 laptop with dual-band 3x3 802.11ac. Why should I sit here and take shit from people who expect perfect WiFi from a $9 SBC and pay nothing toward Armbian? Especially after we calmly explain what isn't possible, they say "well I was thinking about giving you money, but since you can't make magic unicorns out of thin air, forget it" Seriously?! Seriously?!!! No. Please go away.
  9. I still have a problem with this. Because these devices are from China, and the manufacturer can change the board at any time. Maybe rev. 1 of the board was great, but they found a way to lower the cost (say, replace the WiFi module with a cheaper version, or replace EMMC with worse version) and rev. 2 is a pile of garbage. Just look at the OpenWrt/LEDE wiki if you want to get an idea of all the stupid things companies will do to lower cost and raise profit. Reduce memory size, reduce flash size, change chipsets entirely. I know this isn't very likely on these SBCs, because companies will just release a new version, but we have seen board revisions before (e.g. early Orange Pi Zero shipped without any SPI flash). Saying "Certified/Recommended for X" is a trap, because as soon as the company revises the board and breaks something, people will come here and complain, so you don't want to go there. I would go so far as to say if a manufacturer releases a new revision of the board which breaks the build, then we stop supporting the board. I would rather it go something like "Compatible with Orange Pi Zero Rev 1" or something which doesn't sound like a guarantee. Certified/Recommended to me says "it will work" instead of what Armbian should say, which is "it should work" As we've said previously, the Orange Pi Zero should not even have stable/nightly builds, given the hardware issues. This is an example of a board I would say is only available to build from git for those who are very willing to try. Edit: but this is getting pretty far from Rock64 topic... perhaps we can debate in another thread?
  10. The problem with these "certifications" is that then people expect everything to work perfectly. This simply isn't possible where someone can install any software with apt-get or compile it themselves. You'll say "Certified for Armbian" and then someone will say "but it doesn't work when I try to compile Firefox from source" which is obvious to anyone that there isn't enough memory, but you said "Certified for Armbian" so they assumed it could do anything. It's too difficult to say "Certified for X" and then expect the user to A. have reasonable expectations, and B. read the list of limitations (e.g. minor software/hardware issues). I don't see any problem for people to add support for boards via git. The best solution to avoid dealing with angry users is to not provide stable/nightly builds. If you force someone to compile Armbian from source to support a board, it raises the level of effort and technical knowledge required massively. People who know enough to compile Armbian for a board from git are the kind of people you want to come here. I disagree with having any private areas for board support. The reason is simple, it will keep out talented people who don't otherwise know about the hidden areas. I understand you want to avoid having users pile on with "+1" support for cheap shit, but there are easy ways to handle that. I think any discussion among developers about supporting a new board should be publicly visible, if not necessarily open for public comment. IMHO transparency is very important in open source. To have a closed section for making these decisions could potentially remove developers who want to support but are not part of any "inner circle" I would propose that the section is open for all users, but people who abuse it by starting threads full of "+1" are blocked from posting further. If this proves to be too difficult to maintain, then posting is restricted to developers. But my biggest concern is friction. It's hard enough to get developers, but if you make it harder for them to contribute, they simply won't come. Therefore we should be trying to make it as easy as possible for the next developers, who may not be known to us yet, to come and start developing for Armbian too. I still stand by my previous statements: Developer(s) commit to supporting a board. If the developer is no longer able to support the board, then someone else takes over. If the board is already "mature" and well supported, then perhaps no one is needed, but this would need to be considered for each board depending on the status. I go back to what I said earlier, I think Armbian should not build stable/nightly builds for "community supported" boards. Make it like the Android ROM scene: you provide the source for popular/well supported devices (e.g. Lineage OS "Official" devices), and other people are free to build their own image from source and post it here if they want (e.g. "Unofficial" builds). But make it more like XDA: there is a dev db listing the source/version/credits, and a big disclaimer that Armbian does not support these, WARRANTY VOID, etc. I think this would actually make more people contribute. Outside of the core devices, someone actually has to build the image themselves, post it here, and maybe provide support. If it gains enough traction, then Armbian could consider officially supporting it. I guess my point, and I don't make it very well, is this: make it easier for developers to contribute. Make it harder for users to download an image with half support. If someone cares enough to build an image from the source and post it here, then that shows some commitment from them. You don't necessarily have to stop supporting every board a vendor sends you. If you just love getting Armbian to boot on the latest hot garbage, then go for it. Why should we stop you? But leave these changes in git. Don't provide users with images they can easily flash.
  11. "If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support." Does this not address "in flight" ? If the board is added and builds are failing, or people are complaining that things are broken, and no developer is fixing it, then we drop support.
  12. I don't really think anyone disagrees with you. As I said in my previous post, this isn't a popularity contest of which boards are most popular (because that would probably end up being the cheapest, crappiest boards) but rather what Armbian developers are able to reasonably support. So here we are having the discussion. It seems like people are receiving dev samples for testing. If they decide to put in the effort to add support to Armbian, then the board will be supported. If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support.
  13. hmartin

    ROCK64

    @tkaiser nice start! Has pricing been announced? What about availability? Is there sufficient supply that users can buy it? (Or what is the expected release date) Any armbian developers committing to getting the board included into nightly releases? Any thoughts on an appropriate benchmark to test GbE and USB3? It would be great if we could standardize on something so people can use the test results to compare before purchasing.
  14. exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature). When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers. If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8
  15. Hi all, Over at Doozan we are having quite a time trying to get kwboot to work on the newer Armada 385 based boards. It works for the ClearFrog because there is a DIP switch to select UART boot. However on shipping products like the Zyxel NAS326 and the Western Digital EX2 Ultra/EX2100/EX4100 this is not an option. Does anyone else have any of the above products? Were you ever successful in getting it to load u-boot via uart?