RSS Bot

Description #5114 The uboot targets are declared twice, which is strange. And no need to build uboot.dtb. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Build for rockpro64 success: https://paste.next.armbian.com/okogutizaw Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Update odroidxu4-current kernel to 5.4.242 How Has This Been Tested? [x] Reboot of my Odroid HC1 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description These patches fix an issue present on newer Kernels (6.1+, no idea if older kernels are affected as well), where the thermal sensors are unavailable (/sys/class/thermal is empty). By applying these patches, thermal sensors are available to use. The problem seems to be related by how Linux thermal driver drivers/thermal/thermal_of.c handles thermal zones without trips defined - if it doesn't exist, throw an error. I'm not Linux expert, but it looks like 6.1 brought some thermal driver refactoring, which might have caused this behavior. Before the patches, with logging verbosity set to 7, there's also an error present in boot log related to the sensor's init process: https://paste.armbian.com/awikixucez ... [ 1.255888] thermal_sys: Failed to find 'trips' node [ 1.255901] thermal_sys: Failed to find trip points for thermal-sensor id=0 [ 1.255916] sun8i-thermal 5070400.thermal-sensor: Failed to register sensor 0 (-EINVAL) [ 1.255925] sun8i-thermal: probe of 5070400.thermal-sensor failed with error -22 ... With the patches applied, the errors are no longer present: (sunxi-6.1 log): https://paste.armbian.com/jomezorune (sunxi-6.2 log): https://paste.armbian.com/kutozasuji Changes Added one trip to each thermal zone with missing trips (GPU, DDR & VE). Added critical trip point, set to 110C, corresponding to the recommended Tj max, as per H616 documentation (found here: https://linux-sunxi.org/H616) For completeness, added new critical trip point for CPU thermal zone, similar to trips mentioned above How Has This Been Tested? Both kernel versions have been compiled before and after applying patches and tested like this: Check if the board boots up Proceed with minimal initial setup Be logged in as root Check if sensors are available by using the following command: ls /sys/class/thermal/ Expected result: there are 4 directories present in the output Actual result (before patch): output is empty Check if sensors provide meaningful temperatures by using the following commands: cat /sys/class/thermal/thermal_zone0/temp cat /sys/class/thermal/thermal_zone1/temp cat /sys/class/thermal/thermal_zone2/temp cat /sys/class/thermal/thermal_zone3/temp Expected results: each sensor readout outputs sensible temperature (in my case, ~50 C) Actual result (before patch): no output, commands fail Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Cologone Chip GateMate A1 is an FPGA with 20,480 logic elements best suited for lower-power applications and programmable with an open-source toolchain based on nMigen, Yosys, and other open-source tools. The A1 FPGA also comes with 1,280 Kbit block SRAM, four PLLs, a quad SPI interface up to 100 MHz, a 5Gbps SerDes interface, and the company offers an evaluation board to get started with development. GateMate A1 specifications: CPE Architecture 20,480 programmable elements (CPE) for combinatorial and sequential logic 40,960 Latches / Flip-Flops within programmable elements CPE consists of LUT-tree with 8 inputs Each CPE is configurable as a 2-bit full-adder or 2×2-bit multipliers Features 4x programmable PLLs quad SPI interface up to 100 MHz 1,280 Kbit dual-ported block RAM with variable data widths in 32 x 40 Kbit RAM cells Multipliers with arbitrary size implementable in CPE array Multiple clocking schemas All 162 GPIOs are configurable as single-ended [...] The post Cologone GateMate A1 FPGA chip with 20,480 LE is programmable with an open-source toolchain appeared first on CNX Software - Embedded Systems News. View the full article

Description Extension to include fake vcgencmd to non Raspberry Pi builds to allow the Android app Raspi Check to control Armbian boards out of the box. See also https://github.com/armbian/build/pull/5100 and https://github.com/armbian/build/pull/5095 How Has This Been Tested? Build for Raspberry Pi (not installing the fake vcgencmd, bur failed for another reason on SHA-1) and non-Raspberry Pi boards (installing it) Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description This will fix chrony https://forum.armbian.com/topic/28142-visionfive-2-chrony-doesnt-run-kernel-missing-seccomp Jira reference number [AR-9999] How Has This Been Tested? Not tested View the full article

NVK, an open-source Vulkan driver for NVIDIA hardware that is part of Mesa, now supports the Vulkan extension VK_KHR_multiview. View the full article

AAEON EPIC-ADS7-PUC is an embedded system based on an up to 12th Gen Intel Core i7-12700E Alder Lake-S processor and designed for robotics, automation, and healthcare imaging applications. The embedded computer supports up to 32GB DDR5 and two SATA III storage devices, offers three 4K video outputs via HDMI and DisplayPort connectors, one 2.5GbE and three Gigabit Ethernet ports, along with Intel TCC support, up to six USB 3.2 Gen 2 ports, two RS232/422/4485 COM ports, and some SKUs support Intel Time Coordinated Computing (TCC) for real-time control. Key Features: SoC – Intel Core Alder Lake-S processor, up to the 12-core (8P+4E) Core i7-12700E processor clocked at up to 4.8 GHz with Intel UHD Graphics 770; TDP: 65W Chipset – Intel 600 Series Desktop Chipset (R680E/Q670E/H610E) System Memory – Up to 32GB DDR5 4800 via 2x SODIMM socket (16GB max each) Storage – 2x SATA 3 with +5V onboard SATA [...] The post EPIC-ADS7-PUC Alder Lake-S embedded system is made for robotics, automation, healthcare imaging appeared first on CNX Software - Embedded Systems News. View the full article

HealthyPi 5 is an open-source sensor platform for biosignal acquisition based on Raspberry Pi RP2040 microcontroller and ESP32-C3 WiFi & BLE module used to capture vitals such as electrocardiogram (ECG), respiration, photoplethysmography (PPG), oxygen saturation (SpO₂), and body-temperature data. It is a complete redesign of the HealthyPi v4 Raspberry Pi HAT with many of the same features. While the HealthyPi 5 also follows the Raspberry Pi HAT form factor and can be connected to a Raspberry Pi SBC to analyze the data, it can also be used as a standalone device with the processing handled by the RP2040 dual-core Cortex-M0+ microcontroller and connectivity through an ESP32-C3 wireless module, and data visualized on a 3.5-inch SPI display or a smartphone over WiFi or Bluetooth. HealthyPi 5 specifications: MCU – Raspberry Pi RP2040 dual-core Arm Cortex-M0+ microcontroller @ 133 MHz with 264 KB SRAM Wireless Module – ESP32-C3 RISC-V module with 2.4 [...] The post HealthyPi 5 WiFi & BLE biosignal-acquisition sensor platform captures body temperature, ECG, PPG, SpO₂, and other vitals (Crowdfunding) appeared first on CNX Software - Embedded Systems News. View the full article

more of rpardini's GHA & pipeline stuff (early May/23) pipeline: cli: add proper gha- prefix to CLI commands that have something to do with GitHub Actions (thus gha-matrix now, and the new gha-template) stop at the correct places for inventory and targets non-GHA-specific commands handle gha-template first (and return), since it does not really depend on any info/targets/etc batcat the output for show-off pipeline: add output-gha-workflow-template.py utility, for rendering GHA workflow YAML templates with chunks python-tools: add Jinja2. Incredible how we made it this far without it. output-gha-workflow-template: a double-templater, first runs jinja with a custom syntax, then "moar magic" to be useful for GHA pipeline: targets-compositor: whole target can be enabled: no to quickly disable it (as if it wasn't there) pipeline: output-gha-matrix: directly GHA-output images-chunk-json-2, images-chunk-not-empty-2, images-chunk-size-2 and artifacts-xxx with no fake entry as alternative to the full output, this allows us to skip chunkjobs when they're empty, and hopefully makes GHA-JSON-parsing 10x faster pipeline: output-gha-matrix: new input.pipeline.gha.runners in the targets.yaml for mapping GHA's runs_on based on name and arch artifact kernel/uboot: add ARCH to artifact_input_variables; used for (maybe) mapping to runner tags in JSON pipeline View the full article

Description See: https://github.com/armbian/build/pull/5096#issuecomment-1523211702 Leave example. It should not be needed anymore since we re-pack those packages https://github.com/armbian/scripts/pull/44/files Jira reference number AR-1671 View the full article

When Rockchip first introduced the Rockchip RK3399 processor with a PCIe interface people initially hoped they could connect graphics card, but those hopes were quickly squashed due to a 32MB addressing limit. However, the PCIe implementation on the newer Rockchip RK3588 processor does not have such a limitation, and last November, Radxa teased a demo with an AMD Radeon Pro WX 5100 PCIe graphics card connected to the Rock 5B SBC running the glxgears demo on the Radeon GPU. I couldn’t find any instructions to reproduce this setup, but this got Jasbir interested, and he tried to do a test of his own with the Radxa Rock 5B connected to an AMD Radeon R7 520 (XFX R7 250 low-profile) through an “M.2 Key M Extender Cable to PCIE x16 Graphics Card Riser Adapter” ($14 plus taxes on Aliexpress) and powered by an LR1007 120W 12VDC ATX board. The experiment was [...] The post AMD Radeon PCIe graphics card tested with a Rockchip RK3588 SBC (Radxa Rock 5B) appeared first on CNX Software - Embedded Systems News. View the full article

OpenEarable is an open-source hardware earable, sometimes also called hearable, that fits around your ear and is based on the same u-blox NINA-B306 module found in the Arduino Nano 33 BLE Sense board. Besides the Nordic Semi nRF52840 Arm Cortex-M4-based Bluetooth LE module, the design also features a speaker and ultrasonic microphone, a 6-axis IMU and a pressure sensor, as well as the circuitry for the battery, two LEDs, and a push button. OpenEarable specifications: Wireless module – U-blox NINA-B306 module powered by a Nordic Semi nRF52840 Arm Cortex-M4F microcontroller @ 64MHz with 1MB Flash, 256KB RAM, Bluetooth 5.0 LE connectivity Audio – Built-in speaker and ultrasonic microphone (Knowles SPH0641LU4H-1) Sensors STMicro LPS22HBTR pressure and temperature sensor STMicro LSM6DSRTR 6-axis IMU with accelerometer and gyroscope USB – Micro USB port for power and programming Debugging – Solder pads for SWD interface Misc – Push button, charging LED, one programmable PWM [...] The post OpenEarable open-source hardware earable platform leverages Arduino Nano 33 BLE Sense ecosystem appeared first on CNX Software - Embedded Systems News. View the full article

Yesterday, I wrote about the BBT Pi V1.2 Allwinner H616 SBC designed for 3D printers, but also mentioned I had received the Pad 7 from BIGTREETECH which is a software-compatible, but more complete solution with a 7-inch display and an Allwinner H616-powered CB1 system-on-module compatible with the Raspberry Pi CM4. The BIGTREETECH Pad 7 should be more convenient to use with its integrated 7-inch touchscreen display, and if you ever decided you didn’t need it to control your 3D printer anymore, it could always be used as a small Linux computer running Raspberry Pi OS or another operating system. BIGTREETECH Pad 7 specifications: Supported modules BIGTREETECH CB1 v2.2 (included in the kit) – Allwinner H616 quad-core Cortex-A53 CPU with Mali-G31 MP2 GPU, 1GB RAM, 802.11 b/g/n WiFi 4 Raspberry Pi CM4 module with Broadcom BCM2711 quad-core Cortex-A72 CPU with VideoCore IV GPU, 1 to 8GB RAM, 0 to 32GB eMMC [...] The post BIGTREETECH Pad 7 7-inch 3D printer control display runs Klipper on Allwinner H616 SoM or Raspberry Pi CM4 appeared first on CNX Software - Embedded Systems News. View the full article

Description This is experimental support for DDR dynamic frequency changing for Allwinner H3. It based on: https://github.com/smaeul/u-boot/commits/patch/h3-dram-devfreq https://github.com/smaeul/linux/commits/wip/devfreq-a83t Discussion on linux-sunxi listing: https://lore.kernel.org/linux-sunxi/CAKAF0m_6C68ox5z-NX1D6rjREgiySmSdxcda-KRvyehZssD5OQ@mail.gmail.com/T/#t My fixes for H3 Due to H3 hardware bugs (see listing) it implemented by software "emulation" of MDFS: It uses a special helper in the u-boot PSCI code. This is needed, because changing DDR freq is possible only in the SRAM. Before freq changing all secondary CPU's put in the while(true) on PSCI handler (in SRAM). This is needed, because after DDR RAM enters self-refresh mode any RAM access leads to a complete freeze. We must suspend all execution on any secondary cores to prevent this. And, finally, call PSCI callback SUNXI_PSCI_DRAM_DVFS_REQ on CPU0 for changing frequency. Not great, but works. Similar way implemented in the original legacy sunxi kernels: https://github.com/Tina-Linux/tina-v83x-linux-4.9/blob/master/drivers/devfreq/dramfreq/sunxi-ddrfreq.c#L1373 But instead of PSCI in u-boot it uses a dirty hack by writing code from kernel to the SRAM. P.S.II'm not sure if this module should be enabled by default. Most of users want performance instead of power saving. Maybe better and safer to disable this in DT (by status = "disabled"). And who needs it can enable using DT overlay. How Has This Been Tested? Build and update kernel Build and update u-boot Run something like this: https://gist.github.com/Azq2/955b4ebaaa526243e3d4b111d9afa5c9 Tested: [x] h3 (orangepilite) Not tested: [ ] a33 (support added by this patches) [ ] a83t (support added by this patches) [ ] a64 [ ] h5 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Espressif Systems unveiled the ESP32-H2 Bluetooth 5.2 LE & 802.15.4 RISC-V microcontroller in August 2021, but the ESP32-H2-DevKitM-1 development board based on the ESP32-H2-MINI-1 module has only been selling on the official Espressif’s Aliexpress store for $9.90 for a few weeks. The ESP32-H2-DevKitM-1 development board allows the development of applications with Bluetooth 5.2 LE, Zigbee, Thread, and/or Matter connectivity, features two USB Type-C ports, Boot & Reset buttons, and RGB LED, and two rows of 15 pins exposing all I/Os from the ESP32-H2-MINI-1 module. ESP32-H2-DevKitM-1 specifications: Wireless module – ESP32-H2-MINI-1 MCU – Espressif Systems ESP32-H2 32-bit RISC-V microcontroller at up to 96 MHz with 320 KB SRAM, 128 KB ROM, 4 KB LP memory, Bluetooth 5.2 LE/Mesh and 802.15.4 (Zigbee/Thread/Matter) radios. Storage – 4MB flash storage (E1N4 on the photo above should mean 4MB, but there are also ESP32-H2-MINI-1 modules with 1MB and 2MB flash) PCB antenna Dimensions – 13.2×16.6×2.4 [...] The post ESP32-H2-DevKitM-1 ESP32-H2 development board launched for $10 appeared first on CNX Software - Embedded Systems News. View the full article

the return of the son of CREATE_PATCHES=yes et al kernel/uboot/atf: introduce kernel-patch, uboot-patch, atf-patch, uboot-config, kernel-config CLI commands; enhanced manual patching; block deprecated ways all interactive commands now don't build the artifact anymore; just patches/.configs are produced and then build ends user is required to put the produced patches in the right place and build again, for full consistency split ATF and U-BOOT manual patching process; use CLI command atf-patch to patch ATF, and uboot-patch to patch u-boot non-interactive artifact builds are now 100% sans-stdin introduce uboot-config CLI command; still experimental, only produces a defconfig and not a patch reworked userpatch_create() to be (hopefully) more useful: detects a previous patch and offers to apply it before continuing enters a loop showing the diff, and only proceeds when user indicates he's happy with the patch produces mbox-formatted patches via format-patch and standard Armbian parameters uses MAINTAINER and MAINTAINERMAIL instead of git configuration (so it works in containers) don't allow image builds with any patching or configuring at all (it has been deprecated with a warning for months already, and results are inconsistent) View the full article

TwoTrees TTC 450 is a CNC router machine for precision cutting with a working area of 460x460x80 mm. The machine can handle 2D and 3D, 3-axis X, Y, Z movement, features a 32-bit microcontroller, a touchscreen control display, and supports WiFi network connection. The TTC 450 can also read files on an SD card for offline operation, and workpieces can be made of a variety of materials such as wood, acrylic, Plastwood, carbon fiber sheet, aluminum, metal, and various engineering plastic materials. TTC 450 CNC router specifications Work Area – 450 x 450 X 80 mm Body Material – Metal frame & Aluminium 4080U Profile Drive System – Translation screw drive with double Y-axis system Mainboard – DLC32 V2.1 (ESP32-based as found in TwoTrees TS2 laser engraver) Stepper Driver – A4988 1.3A Stepper Motors – 17HS8401S, NEMA23 20mN.m Spindle – 74W, 8000RPM Max Speed – 800mm/Min Running Accuracy – +/-0.1mm [...] The post Review of TwoTrees TTC 450 CNC router machine with 80W and 500W spindles appeared first on CNX Software - Embedded Systems News. View the full article

Description OrangepiZero2 users who would like to test functional cpu-frequency-scaling 5.19.17 How Has This Been Tested? https://forum.armbian.com/topic/26290-h616-mainlining-effort/ [ ] Test A [ ] Test B Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

BIGTREETECH Pi v1.2, also known as the BBT Pi v1.2, is a Raspberry Pi-sized Allwinner H616 single board computer (SBC) specially designed for 3D printers with many of the same ports as the Raspberry Pi 3/4, but also features 12V-24V DC power input and connectors for the ADXL345 3-axis accelerometer, CAN Bus, and so on. The board is equipped with 1GB RAM, a microSD card slot to run the operating system (Debian 11 with Klipper), a 4K capable micro HDMI port, Fast Ethernet and WiFi 4 networking, four USB ports, and the usual 40-pin Raspberry Pi header. BTT Pi specifications: SoC – Allwinner H616 quad-core Arm Cortex-A53 @ 1.5GHz with Arm Mali G31 MP2 with support for OpenGL ES 3.2 System Memory – 1GB DDR3L SDRAM Storage – MicroSD card slot Video Output Micro HDMI 2.0a port up to 4Kp60 resolution SPI port for display Audio – 3.5mm audio jack [...] The post BIGTREETECH Pi v1.2 – A Raspberry Pi-sized Allwinner H616 SBC for 3D printers appeared first on CNX Software - Embedded Systems News. View the full article

more of rpardini's dirty laundry, very late April/'23 Remove legacy branches after trying, and failing, to ressurect them rockchip: completely remove legacy branch; fixes #5118 there's absolutely no point in trying to keep this alive, current/edge are good enough, legacy's abandoned for years and broken jetson-nano legacy: give up on this legacy and remove it; fixes #5117 jetson-nano legacy: try, and fail, to fix this legacy; (does NOT) fixes #5117 jetson-nano legacy: kernel config: CONFIG_SECTION_MISMATCH_WARN_ONLY=y jetson-nano legacy: add -mno-outline-atomics to fix linking jetson-nano legacy: add xxd host-dependency jetson-nano legacy: downgrade a lot of gcc errors to allow this legacy to build Fix (sucessfully) broken stuff rtl8822bs: fix: remove binaries (firmware?) being added to kernel driver source and breaking patching; related to #5117 kernel-make: introduce KERNEL_EXTRA_CFLAGS; fill it to add to what's passed to KCFLAGS; related to #5117 macchiatobin-doubleshot: fix u-boot/atf build: export SCP_BL2 had been wrongly converted to declare -g SCP_BL2 when it is in fact required; fixes #5116 rk3399-4.4: remove mbox-confusing long explanation from ancient patch in ancient kernel; possibly fixes #5119 driver_uwe5622_allwinner: only apply "pre-6.1" park-link patch if kernel >= 5 (eg: not for rockchip64-legacy); possibly fixes #5120 rockchip64_common: add explicit make target u-boot.dtb before u-boot.itb in the target map for SPI; fixes #5114 when BOOT_SUPPORT_SPI=yes (and not using the rkspi_loader) it seems the makefile target u-boot.itb does not correctly depend on the u-boot.dtb target, and works "by accident" on multicore machines, which are faster and build it fast enough in parallel. this adds u-boot.dtb to the target map, so make's hand is forced to do the right thing. artifact-uboot: fix: include UBOOT_TARGET_MAP in variables hash of version kernel-debs: postinst/etc: fix: unify is_boot_dev_vfat() function; make work during image build too via env var determinining if /boot is vfat is more complex than it looks; use a common function to unify across all scripts during image build, the kernel install is always done with a non-fat, non-mounted /boot use a special variable passed through the env so unified function can know ahead of time introduce extra_apt_envs param to chroot_sdcard_apt_get(); array with extra environment vars if vfat /boot: linux-update-symlinks is not called (Debian would just choke on this) don't even try to symlink Armbian stuff, move instead more/better logging board-side (unfortunately mixed in all the set -x debugs) View the full article

Damien George has recently announced the release of MicroPython 1.20 with support for the Raspberry Pi Pico W board., a new lightweight package manager called mip, a smaller footprint thanks to the use of compressed type structs, and many other changes. mip package manager The new mip package manager uses a custom protocol optimized for embedded systems to query and install packages, and intends to replace upip for installing packages from micropython-lib or any URL. Mip can be run directly on a device, as long as it has network connectivity, or via mpremote from a host computer. Damien explains all pure-Python drivers have been moved from the micropython repository to the micropython-lib repository as part of the change in order to make it easier to install the packages needed for a given project. MicroPython is getting smaller The MicroPython binary size has been reduced by many kilobytes for all ports [...] The post MicroPython 1.20 released with Raspberry Pi Pico W support, mip package manager, smaller footprint appeared first on CNX Software - Embedded Systems News. View the full article

Description Fix mistake due to patch copied as-is from rk322x family without properly checking it first :pensive: How Has This Been Tested? [x] Kernel deb packages compiled Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

🔥 JSON info pipeline: v18 After some months of development, here's our JSON pipeline. targets.yaml is looked for in userpatches, if not found the template in config/templates will be used. to run: ./compile.sh matrix This has not been tested outside of my work branch, so might fail in your environment, please report. View the full article

rpardini's dirty laundry, late April/'23 uefi/edge: bump to 6.3 bcm2711/grub: add busybox (for initrd grep/sed) so initramfs-growroot works again on Debian bcm2711: bomb early when RELEASE is set and not supported bcm2711/edge: bump to 6.3 (rpi4b, RPi Foundation Kernel) rockchip-rk3588/edge: bump to 6.3, drop 6.2 patches rk3568-odroid/edge: bump to 6.3 (odroidm1) virtual-qemu: move to eos (replaced by qemu-uboot-x86 and qemu-uboot-arm64) qemu-uboot-arm64/qemu-uboot-x86: split more x86/arm64 differences, add some docs, bump to u-boot 23.04 +update-patches; add arm64 bootscript extensions: introduce u-boot-menu extension, for use with extlinux this is using the default Debian/Ubuntu package, we probably should replace that with our own scripts kernel-debs: call linux-update-symlinks in postinst; expected of Debian-compatible kernels this handles /vmlinuz etc symlinks (doesn't know about uInitrd, etc) initramfs post-update 99-uboot: add verbose logging, no actual changes sun50iw9: don't inadvertently override pre-existing hook function name - fixes #5099 imx7d (EOS): codeaurora.org is no more, move to nxp-imx's repos for both kernel and u-boot grub: keep u-boot stuff if UEFI_GRUB=yes git-ref2info: many fixes for nonstandard repos; try a few different dereference and refs/ combinations in a certain order; remove codeaurora repo handling git-ref2info: when resolving SHA1's for 'xxx' tag or branch, try first refs/heads/xxx, then just 'xxx'; validate SHA1 with 40-char regexp this works-around Gerrit-style repositories that have a 'refs/for/xxx' ref that gets in the way case in point: https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03 (has both refs/heads/odroidc-v2011.03 and refs/for/odroidc-v2011.03) git-ref2info: when processing tags for a SHA1, try both dereference and non-dereferenced, in that order, to get a SHA1 this solves old problem reported in #4916: GitHub incorrectly processes dereference requests for tags that are not actually annotated case in point: https://github.com/ayufan-rock64/linux-kernel/releases/tag/4.4.202-1237-rockchip-ayufan codeaurora is no more, https://bye.codeaurora.org/ View the full article