Jump to content

Igor

Administrators
  • Posts

    13936
  • Joined

  • Last visited

Everything posted by Igor

  1. Bug closed with a workaround - text on download pages is good enough. I would propose to open a task for its integration and integrate when possible, with normal priority.
  2. Yes. We have decided to move away from dirty proprietary stock boot loader to most recent boot loader ... where not all troubles has been ironed out / quirks ported from factory firmware. I would assume only with (some?) eMMC. Perhaps @chewittknows something about this? Reverting changes and forgetting about better security that comes with common / open / mainline represent some serious work / decisions and its questionable - you gain something, you loose something. We could go back, but not sure if that is the right way.
  3. Yes, that is perfect way. Just add those few lines to the download pages. Forum is kind of a black hole for this. Yes, this can wait for next release. If there will be a lot troubles in general, we might also come out with some bugfix release earlier. So far things looks good so this scenario is less likely to happen.
  4. All images has been tested and they works. Just follow instructions: https://www.armbian.com/radxa-zero/ Others https://armbian.atlassian.net/browse/AR-1148 @minnixtxThanks!
  5. In order to have such functionality in open source, where anyone can integrate code from another, this will be a lot harder. For example - our user / you covers us only 0.5% of costs of this project https://docs.armbian.com/User-Guide_FAQ/ Manjaro on ARM is a lot smaller project and basically only builds mainline kernel for you. Official builds - they are patching stock kernel, where such functions might be glued together in some proprietary way, with blobs. Linux distributions usually don't go that way since that would mean support can be tied to one (and those very similar) hardware only. What you are asking for is expensive to develop and I am not aware if there are any usable common ways. https://en.wikipedia.org/wiki/Mozilla_Foundation has 1000+ volunteers and around 100 full-time staff and yearly revenue of 500+ million dollars. If they can't provide this functionality OOB within their budget, few people certainly can't. This problem is also not Radxa specific. They integrate SoCs and sell it. We are focused into a build framework, so you can use this HW for something. For full potential, you need to look into different price range.
  6. Our CI seems to need further improvements - this error should be detected in automated way. Anyway, thanks for report! Images has been replaced and this particular build was manually tested. (download will be slow for around 24h)
  7. I have build images again and they work - both NICs are up. Replacing them soon. Replaced.
  8. Did it really switch to 22.05 branch. I heard there are issues with this functionality and you need to manually switch before running the script. Good. We'll deal with this asap.
  9. Check if you see anything suspicious here: https://github.com/armbian/build/commits/v22.05 Some commits were merged at last moment, including EDGE upgrade on Rockchip since EDGE is not production ready kernel and was moved to 5.18 so in case it doesn't work in EDGE, this is not the biggest problem, but it has to work well in current. Lets sum bugs in Jira and resolve this when possible. I already open a few minor ones.
  10. Strange that bullseye works, but focal not. And RC images were alright, right?
  11. That is certainly not the reason. All hardware is released with some old private / BSP / Android / presentation kernel. It always takes years to get to the mainline. Some HW never came there and never all functions gets there. This is just how this world function and Armbian is also mitigating this problem to the best possible degree. Otherwise you would be destined to much lower quality / usability and have it much later. Welcome!
  12. Yes. You didn't read my answer. I said that "if it won't work properly, its on you to debug". I suspected this will happen since we are not paying attention to making FAT boot support This exists in the system with one reason only - in case some hardware can't be boot from ext4 directly, we use this and adopt boot scripts to meet this scenario. And this is your job - to adopt boot scripts - what boot log tells you?
  13. Yes, those has to be fat32. Strange. Otherwise instructions on download pages are working - but with most recent images only.
  14. With correct / default parameters, all kernels for zero2 builds. I also fixed booting problem https://github.com/armbian/build/pull/3825
  15. Alternative - checkout to branch 22.05, add your changes and send me u-boot packages that affect your boards.
  16. Today I am making last RC build to check for troubles, Saturday, as planned, making a release ... in case there will be no major troubles. Bugs / last improvement are still going to be merged.
  17. Yeah, this way, just into some other folder: https://github.com/armbian/scripts/blob/master/.github/workflows/pack-debian.yml#L230-L241 You need to move repository under /armbian in order that key works.
  18. It doesn't have someone https://forum.armbian.com/staffapplications/application/8-single-board-computer-maintainer/ to take care of issues in order to get a better status: https://docs.armbian.com/User-Guide_Board-Support-Rules/
  19. This problem was fixed but hasn't been released yet. Once it will be, there won't be any need for searching and switching to older kernels, where this function was still working.
  20. Wait for release or build from sources.
  21. https://github.com/armbian/build/tree/master/config/boards Add BOOTFS_TYPE="fat" to the end of the board config file. Perhaps it works if added as a parameter. But this is internal switch - if it won't work properly, its on you to debug.
  22. Today's RC build (images has just been updated) is first, finally, after two weeks of constant struggle (bugs in CI, bugs in build process, bugs in hardware) that was done almost without errors. Just a few images has to be re-done. Thank you all for helping fighting bugs! Those need attention before release: https://armbian.atlassian.net/browse/AR-1197 https://armbian.atlassian.net/browse/AR-1196 https://armbian.atlassian.net/browse/AR-1198 If possible: https://armbian.atlassian.net/browse/AR-1186 https://armbian.atlassian.net/browse/AR-1186 https://armbian.atlassian.net/browse/AR-1176 https://armbian.atlassian.net/browse/AR-1158 I have manually (some via automation) tested: VIM1, VIM2, VIM3, Opi Zero plus2, Jetson Nano, Orangepi One, Orangepi Win, XU4, C4, C2, Cubox, Clearfog pro, Rockpi E, Nanoi pi M4, Opi Zero, Udoo quad, x86 UEFI
  23. If its a bug, we have to fix it. Probably you need to set .ignore_changes ? Actions scripts are using this principle, so I didn't even notice there is something wrong.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines