Jump to content

rpardini

Members
  • Posts

    132
  • Joined

  • Last visited

Everything posted by rpardini

  1. until

    I'm not sure I will be able to attend, but would like to remind everyone involved about https://github.com/armbian/documentation/pull/352
  2. Hey @Timo12357 this was identified before. Check https://github.com/armbian/build/pull/5766 Please check against beta/testing repo? Thanks
  3. Thanks for reporting this, should be fixed in https://github.com/armbian/build/pull/5914
  4. Some progress has been made, 6.6-rc5, new alsa-ucm-conf and firmware. Try the "Armbian Trixie - Gnome Desktop" image available at https://www.armbian.com/lenovo-x13s/ under "Other supported variants", that might work: filename is Armbian_23.8.6_Thinkpad-x13s_trixie_sc8280xp_6.6.0-rc5_gnome_desktop
  5. @c0rnelius graciously submitted GitHub PR to upgrade u-boot that effectively removed the patch in question from the equation for the Radxa Zero. While it was nice to "boot USB first", since it enabled a few interesting scenarios (boot non-Armbian EFI OSes in USB disk), it's not worth having it if normal Armbian operation is impacted. I've advocated for this usb-first style to be default around u-boot 2022, but we're now moving to board-specific support (and removing completely in the case of the Zero) for 2023+.
  6. Yeah that. Well, cpufrequtils and big.little clusters don't mix well as you probably noticed. cpufrequtils itself has been deprecated for well over a decade. Since cpufrequtils was being inflicted on otherwise perfectly working, DT-controlled boards, we've disabled it by default. Boards that are proven to require it can re-enable it directly on the board as you've already found out or in the Armbian board file via 'CPUFREQUTILS_ENABLE=true' All that said, the real, kernel-supported alternative, cpupower, requires kernel-tools build which is currently not provided by Armbian (nor is usbipd, perf, nor any other kernel userspace tool, due to the complexities of release-dependent building of parts of kernel which is normally userspace-agnostic).
  7. Sorry what are you talking about? Which board? Why you mention me here? 😉
  8. Please build with `SHARE_LOG=yes` and send us the URL so we can check. That's due to the pd-mapper and qrtr in userspace working. (Only for lunar, coming from ubuntu x13s ppa) Yep it has a hid bind loop that is work-arounded via some udev rules... it's strange. Mostly, yes. I'd say send your patches to steev, or add them to Armbian. Copy the x13s board file and change the DTB. If this works we can refactor/unify more later... Yeah take a look at the x13s board file, you'll find something really similar. I have not kept up to the rapid amount of changes after 6.3.y. I might try to update to 6.6, since that's gonna be LTS.
  9. rpardini

    Odroid M1

    Definitely pick the PR and build whatever userspace you need, there's not much that is userspace dependent (maybe mesa, but I've not tested desktop usage). I've tested on Bookworm, Jammy and Lunar, all work great. Also: UMS mode works absolutely great. Use an SD + recovery button to deinfest, after that you can stop u-boot with the serial console and for example run "pci enum; nvme scan; ums 0 nvme 0" and be able to flash to NVMe via UMS (usb otg) without any SD or eMMC. Also2: you can fix the MAC address stored in the u-boot env in SPI to match the board sticker if you want. Otherwise, MAC address is generated based on CPU serial number, which is stable, but does not match what's on the sticker. Dunno where HK stores the sticker value (maybe some fuse/OTP?)
  10. rpardini

    Odroid M1

    https://github.com/armbian/build/pull/5606 Testing image: https://github.com/rpardini/armbian-release/releases/download/23.08.18-rpardini-434/Armbian_23.08.18-rpardini-434_Odroidm1_bookworm_edge_6.5.0-rc6.img.xz #### `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works; bump kernel to 6.5-rcX - `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.4.y, update config, rebase patches to 6.4.10 - `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.5-rc6; manually fix RK808 breakage in .config; externalize overlays; use Makefile autopatcher; rebase patches - `odroidm1`/`edge` (`rk3568-odroid`): drop 6.3 and 6.4 patches - `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works - using Kwiboo's `rk3568-2023.10` branch with BINMAN-handled blobs - patches (defconfig unless indicated): - boot usb first (rockchip-common) - blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot - change usb_host0_xhci to otg (u-boot dtsi) - enable DM_GADGET, UMS 🔥 and RockUSB - **usage instructions**: - build & burn image to SD card - insert SD card into board - **hold the recovery (RCY) button** and power on the board - watch board boot - **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD - if you don't, you'll need to hold the recovery button every boot - optionally: use `armbian-install` to install OS to eMMC/NVMe/USB - power-off board - remove SD card (new u-boot always boots SD first!) - boot into your newly de-infested machine - boot order: USB, SD, MMC, NVME, SCSI - de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI: - Armbian UEFI-arm64 - Fedora 38 aarch64 - HASSOS for ODROID-M1 - Talos arm64 - others... - extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address - although it is based on cpuid#, doesn't match the HK sticker on the board - run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed - `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)
  11. Hey @Erica please try this experimental image: https://github.com/rpardini/armbian-release/releases/download/latest-images/Armbian_20230600_Khadas-vim3_bookworm_edge_6.4.0-rc5.img.xz Instructions, for any VIM3, in any state (middle button 3 times in 1 second tells the MCU to force the SoC to boot from SD/eMMC). -> Write oowow (https://dl.khadas.com/products/vim3/firmware/oowow/vim3-oowow-latest-sd.img.gz) to SD card. Insert SD card with oowow. -> Power on board, press the middle button 3 times + reset until it reboots into oowow. -> Use oowow to clear the SPI ("fast" method is enough) *and* the eMMC ("fast" method is enough). -> Use oowow to set "bootmode" to SPI. (This way it will try SPI, which is empty, then eMMC, which is also empty, then SD). -> Power off the board (important. MCU changes don't take effect unless you power it off completely). -> Write Armbian to SD card, insert the SD card with Armbian. -> Power on the board. Boot Armbian from SD. Use `armbian-install` after preparing the partitions on the target device (eMMC/NVMe/USB). Good luck.
  12. User on Discord reported problems using the -rt patches with the main branch on Amlogic edge. 1) RT patches are specific to certain linux versions, and the fact most of our families use say 6.2.y branch (and we can't easily override KERNELBRANCH= due to the tangle between board/boardfamily/family_common source order conundra). Would need to either hack at the meson64_common file to change it to to "tag:6.2" to use the 6.2.0 release, or use a hook in a config file to to the sam. Suggestion: add a FORCE_KERNELBRANCH param to work around this more easily for users without requiring a config file change. 2) RT patches add in a ./localversion-rt file, which is picked up by Kconfig and included in CONFIG_LOCALVERSION, which changes the paths of _everything_ from what Armbian expects. Say from "6.2.14-meson64" to "6.2.14-rt3-meson64". The kernel builds, but packaging gags. It's possible to remove the patch that adds that file so the version matches, but Armbian definitely should be able to handle this more gracefully, either by automatically removing "localversion-*" files, or by actually honoring them.
  13. Ahn, ok, that literally only affect the filename of the produced images, not the versions of packages or anything that is published to repo, which is what I was worried about.
  14. Sorry Igor I missed this during the call. This might... lead to problems, since we lose numerical sort comparison if we do this. Say "230501" and "230602" and "231000" and "240200" all sort correctly. But "23501" and "23602" and "231000" and "24200" are... broken.
  15. Yes, but keep in mind, if you wanna build the same package (say, htop) for _both_ bullseye _and_ jammy, you'll have possibly different build-dependencies (libraries etc), and different compilers, so you end up having to maintain one-package-per-distro which is what we're trying to avoid. Some kind of generator / patcher / manager is needed to account for the (usually very small) differences between releases. OBS has a bunch of tricks up its sleeve to do this.
  16. Also: if Launchpad PPAs supported Debian this discussion would not exist, so yeah, it's all about the tooling.
  17. Dunno how well it translates to Russian, but might be worth watching https://youtu.be/aSMw_hvBYnw OBS itself is already packaged in Debian: apt show obs-worker obs-server Yes, but consider that that process is one-per-release. So we'd need to maintain 6+ packages/branches which is beyond our capacity and makes no sense. So we have to go "beyond" source packaging. OBS has debtransform which can help with that. other option is git-buildpackage. there are others. Also _most_ of what we'd need is or has _already_ a Debian source package in one way or another (openzfs, mesa, etc, or even just "adopting" ubuntu/debian packages from upstream and changing small things), so the real question here is the workflow and the tooling.
  18. Another good option is the OpenSUSE original Open Build Service https://openbuildservice.org/, which has been adapted to work with Debian/Ubuntu by Collabora. https://en.opensuse.org/openSUSE:Build_Service_Debian_builds Same applies, but this goes out of its way to simplify building packages "for all releases and all arches" from a single source.
  19. http://mini-buildd.installiert.net/ would _more_ than fulfill our needs, and follows Debian standards. This takes *source* Debian packages, builds in chroots (cross-arch), and manages and deploys a repository. It would have to be _hosted_ somewhere. This would produce some "armbian-bookworm-extra" repository (per $RELEASE, of course) with what I think should be mostly userspace things (although zfs-dkms is a special case). The armbian/build managed repos would still exist, one global for all releases ("armbian-global", u-boot, kernels, ...) and then one per-release ("armbian-bookworm", with bsps, desktops, etc).
  20. rpardini

    Odroid M1

    Thanks for the report. For a minute I thought something more radical had happened, but it seems situation is mostly the same. In the end, it's about SPI -> NVMe boot, possibly with basic EFI support, that would shift the status quo. For now it seems "interested-enough" users can manage to make pboot boot the Armbian image and make it work decently well for most server/NAS/etc needs. We do have a few outstanding issues, like Eth MAC being random, any idea about that? (usually also at u-boot level, but I haven't looked into how HK does things)
  21. rpardini

    Odroid M1

    Hey @usual user -- where lie the patches for this? I'm interested 😉
  22. I'm happy with the current status of it, using HK's blobs / SPL / u-boot from factory SPI. I've added userspace tools to fiddle with u-boot env in SPI which makes it very usable. Kernel is pure mainline, someone contributed overlays (which work). @usual user has posted new stuff with mainline u-boot 23.0x -- if that ever gets nvme boot support I'll be investigating so we can make a full "de-petitboot-ified" build, including writing mainline u-boot to SPI. that's for later. @usual user will probably also know about RGA and other stuff....
  23. Hmm, not really. Separating the local cache only solves the problems involved in local caching, but the real hard part is solving for repo (apt repo, apt.armbian.com and beta variant). That simply can't be separated by folders, and usually only a single version of any given package is allowed in any single repo. Thus the `Version: ` field (which determines the .deb filename too) is the bottleneck here, and directory tricks won't work. But yeah, I very highly appreciate your try to detangle this stuff -- it is very, very hard. I am moving on with the prefixing implementation, and to hell with cache hit ratio, at least for now -- we've many things breaking cos an old version from repo is being considered "newer" than a just-built local .deb. (eg: installing armbian-config brings in sunxi-tools which causes an "upgrade" to linux-image-sunxi-edge which is actually older than just-built. it's insane.)
  24. Well this is a completely different subject, but yeah, valid. That probably/finally explains why media had double-patches to mkdebian/builddeb (which was already patched/replaced by Armbian before patches applied). I was trying to understand that, for months, and failed. Not a single comment explained it, as seems to be Oleg's policy. I will revisit it now that I know wth is going on and maybe it will make sense, but sincerely... Currently and before: - linux-image: has kernel, modules, and DTs (!), (in /usr/lib/<kernel_id>) -- as expected by standard Debian tooling (u-boot-menu, flash-kernel, etc). We had a long discussion about this, 2 years ago. Did we forget? (No, it was just Oleg said he agreed, but ignored it and patched his own stuff "secretly" sans any explanation or discussion). - linux-dtb: has DTs in /boot (as expected by "most" Armbian families, using u-boot and bootscripts, also the armbian-install, config, overlays, etc). Either way, we can definitely accommodate this "single pkg" need, but I'd like to do it in a way that is 1) comprehensible 2) usable by more families than just one 3) not a maintenance nightmare, eg, NOT double-patching. I don't think that is unreasonable. So if we could spell out what is the need, it would be easier... again: let's work together. we've 2 months to figure out stuff before release. I understand now that it seems that I just blindly changed the way `media` works and am crazy... might even be true, but, we can fix, and would already have fixed if more engineer talk and less drama. IMHO.
  25. Yes. I've remembered that adeepv/adeepn (Viacheslav) had something related: a privately hosted, pure-git kernel, to which we couldn't get HTTP access at all. In that case, including the base_version (eg v6.2.1) is not possible. Both for that case, and for this "HK's 5.4.y xu4 + incremental patches", we might introduce something like "KERNEL_SKIP_MAKEFILE_VERSION=yes" to be configured in family file (and _not_ FORCE_KERNEL_EXACT_VERSION_VIA_PATCHES like I mentioned before). Together with the "add $REVISION prefix to all artifact versions", we'd just not have the 6.2.1 version component, and instead just use the "S"HA1 of the commit (which is always available). This should also avoid the "forgot to update" misleading problem we've identified above. And it solves 2 problems...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines