hmartin

  • Content Count

    64
  • Joined

  • Last visited

About hmartin

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1518 profile views
  1. Hi, sorry if this is considered a necro bump. I just received the Orange Pi Zero Plus H5, as it was seemingly out of production earlier this year. I have tried building u-boot from mainline (using v2020.07 and v2020.04) and both fail with the following error (SPI or FEL booting): U-Boot SPL 2020.04-dirty (Sep 27 2020 - 20:11:48 +0000) DRAM: 512 MiB SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Since I have read about people flashing u-boot from Armbian, I thought I would try FEL booting the u-boot incl
  2. 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
  3. 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.
  4. 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 (
  5. 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.
  6. 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 earlie
  7. 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
  8. 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
  9. 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 rea
  10. 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, bec
  11. 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 o
  12. "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.
  13. 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
  14. 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.
  15. 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