Jump to content

Igor

Administrators
  • Posts

    13937
  • Joined

  • Last visited

Everything posted by Igor

  1. It is difficult to go back but staying on the same kernel branch. Which patches might not work properly. I could point you what to fix, but its pointless going that way. Lets try to stabilise M5 on K6.1 / latest (best working) u-boot. Which is the cause of this: SD card / eMMC initialisation is failing. This problem we are fighting with Amlogic for years.
  2. I can understand you have good intentions, so thank you, but do you really think you (and community at large) are supporting this project in any way or it is perhaps the other way around? https://liberapay.com/armbian If you report a bug in software that you have downloaded for free, developers (you don't support), maintainers (you don't support) and support staff (you don't support) just looses more of their precious time and more of their private money. Development and fixing of those things is hard and time consuming work. Vendors that sold you hardware together are also unable to provide you quality software with their small sales margin and competition. FYI.
  3. Event -> Video (with transcripts and comments) 1. Checking the progress of Armbian-next. most of open bugs has been fixed. How to help? users? continue to test various variants -> open a ticket developers? focus on cleaning rockchip64 / media patches, focus into config/ section -> moving family and board hacks into extensions 2. Armbian short description We are still not unified. Most sane idea is to better divide Armbian as OS for end users and Armbian as a build system for developers / integrator / business users and name those two more appropriate. We couldn't unite on a name to fit it all. 3. Mainlining of patches We generally agree and encourage this but we can deal with this gradually. Cleaning and squashing patches first, then move on. While doing this perhaps mark what could be good candidate to mainline so we don't press on people to proceed right on the spot.
  4. We provide / have minimal images for software deployment purposes, where "nothing" comes preinstalled. Standard CLI image provides more things including possibility to recompile kernel, build armbian image, drivers, ... This was since ever, only default headers install was included recently.
  5. To make it easier for installing drivers via DKMS is the only reason. But I guess its better to disable?
  6. Welcome to Armbian forums! I have to be honest with you. We have no interest - it just bring more expenses & stress to the people that work on project. If we provide images that doesn't fully work, and they never do, we are loosing money which is very troublesome when having no income. There were never any support budget for this hardware. Not a single cent. Vendor is unfriendly and not "community driven" as they advertise. Pine64 also rather supports commercial Linux projects that are focused in taking advantage of other FOSS projects. Including ours. Most of their ARM section was ported from Armbian, PostmarketOS ... We were officially not notified about any hardware changes even they recommend our work. If LTS does not boot, is IMO expected. The problem officially does not exits. Our images were made for hardware called "Pine64+": https://github.com/armbian/build/blob/master/config/boards/pine64.conf#L4 LTS (probably) needs different boot loader config / settings. Towboot is just a fork of the same thing, a different UI with not enough people / activity to be taken seriously. Primary reason is anyway unrelated to low level hardware support, but to boot different kernels / user lands with the same boot image. Something that is not very important for Armbian.
  7. Stable, weekly and CI builds https://www.armbian.com/orangepi-5/
  8. until
    This week meeting topics: 1. Checking the progress of Armbian-next 2. Armbian short description 3. Mainlining of patches General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers. @Contributor/Maintainer
  9. The reasons why we don't officially deal with this HW is lack of people / resources / time. We would like to hire few developers to offload, but nobody wants to finance consumer needs and competition. If few dollars is to much, you are welcome to use builds with random support status and fix problems on your own. This hardware is even in automated testing setup, but equipment for checking HDMI output is limited. Not even sure why we have this HW in test system.
  10. Giving us more work is pointless as we are years behind. Scope of desired changes from users side exceeds developers capacity for quite a lot. This is all what we can do in order to start moving this project (improving this application in all aspects, including UX) forward:
  11. This download function certainly needs to be addressed in some way. On a side note - with upgrading to NEXT, all external compilers are go away. We would like to keep those things in Jira (invite was sent to your email, feel free to tackle/improve info on any other issue)
  12. Doesn't boot with 3A images?
  13. Event -> Video (with transcripts and comments) 1. Merging NEXT (updated slides) We discussed progress made in past week (Jira Epic) and set limited expectations for following week due to holidays season. We will try to enable rootfs caching CI at first (which has to be compatible with master) and Docker image creation next (which probably isn't?) 2. Unifying boot process Most single board computers needs good overlay handling so moving them to complete generic image is likely / in short term not possible. We still can not count on DTBless or DT from u-boot only, well support from vendor SPI. If we want to move like everything to UEFI and keep things operation / loose no feature, its a lot of work. Sorting out u-boots and going extlinux way with support for multiple kernels (NEXT/CURRENT) might be the best mid-way. 3. When 6.2 and 6.1, current / edge Keeping and stabilising 6.1 at EDGE for few months, waiting that it will be tagged as LTS for sure. Keeping new things like 3588 / 3568 at their own kernel branches, CURRENT = 6.1, EDGE = 6.2 (at once) @rpardini @JetHomeDid I forget to mention something important?
  14. This weeks meeting topics: Merging NEXT Unifying boot process When 6.2 and 6.1, current / edge General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers.
  15. Recording
  16. Event | Recording This weeks meeting topics: Merging of next generation build framework Primary goal is to understand benefits it is bringing as we all will need to sacrifice some time in order to review it, then merge and fix remaining bug. Despite our current system produces images, we have many bugs and dirty workarounds that this upgrade is addressing. The future of rockchip64 family Main goal is to make it maintainable again. GitHub development and review process Main goal is to motivate people to take more responsibility for reviewing and merging. Define clear rules. Conclusions: Everyone interested should watch a recording (~1h) and place a comment below. Comments will be discussed here and / or at next meeting. Before we can do anything in real regarding merging NEXT, we need to clean patches but also address several things, starting with those: Making a tool / module for patch generation (@rpardini) Preparing guidelines for review and contribution (@giddy) Move repo management from the build system (@igor) How to help? Cleaning the patches! (helper is here) armbian-next_-_meeting_21.dec.2022.pdf
  17. Coordinating development of armbian-config refactoring: https://github.com/armbian/configng @joekhoobyar
  18. Donations are very rare so I am happy, but they don't give you any service. This is your free willing contribution to cover small % of things that we already fixed for you. Remember that you are not paying for software in any way. If you want that research is done you need to become at least a gold partner. For your 5$ I can't hire anyone to look into your problem. Especially not myself. Welcome to the custom hardware world. Trick that works with Allwinner devices, doesn't work with Amlogic ... just wait, perhaps someone knows, I don't.
  19. Workaround? yes (armbian-config, alternative kernels, choose previous one - 5.10.something), fix? With this, there is nothing we can do but wait like you that Hardkernel fix it.
  20. Current only working software for this HW is very old stuff anyway Vendors objectives are different than ours. They want to sell hardware and they want to have control over software. By doing on their own, they control it and they don't help their competitors. It this aspect it makes sense. But yes, I totally agree. Research has been done on the topic, we know many pros and cons and I think we do agree to some point. https://forum.armbian.com/topic/20847-the-boot-process-and-various-devices/ A good topic to discuss it next week - how to proceed from current stage? @ManoftheSea Too early? If preparation and transition is not done well, we also have a lottery. It is nice that you experiment with all this, I know others also did some. We found some issues and we need to make some decisions ...
  21. Not saying its good idea. This is all what was possible back then. Odoroids are still on boot.ini which is textual interpretation of boot.scr ... I agree that some old junk has to be remove. But this has to be done together and systematically or we made one step forward, two back. Upgrades / downgrades has to work. Install tools has to work. Build tools has to work and everything has to be checked twice. And again - what do we sacrifice?
  22. Aha, that I haven't try. So we would need to change priorities in the boot script or proceeding into some other method?
  23. I have successfully installed to SPI / NVME from official Armbian builds. Without any hacks, regular armbian-install.
  24. Keeping kernel bootsplash is getting out of control ... it was disabled while we anyway moved to plymouth. Check here: https://github.com/armbian/build/pulls?q=is%3Apr+plymouth+
  25. Armbian automated testings shows no problems with WiFi https://paste.armbian.com/yaqokonipe But this image is little further then released, made from latest sources (nightly). You can switch to the same firmware via armbian-config.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines