Skip to content
Snippets Groups Projects
  1. Aug 22, 2021
    • Stijn Tintel's avatar
      base-files: add option to make /var persistent · 57807f50
      Stijn Tintel authored
      
      In OpenWrt, /var is symlinked to /tmp by default. This is done to reduce
      the amount of writes to the flash chip, which often have not the
      greatest durability. As a result, things like DHCP or UPnP lease files,
      are not persistent across reboots.
      
      Since OpenWrt can run on devices with more durable storage, it makes
      sense to have an option for a persistent /var. Add an option to make
      /var persistent. When enabled, /var will no longer be symlinked to /tmp,
      but /var/run will be symlink to /tmp/run, as it should contains only
      files that should not be kept during reboot. The option is off by
      default, to maintain the current behaviour.
      
      Signed-off-by: default avatarStijn Tintel <stijn@linux-ipv6.be>
      57807f50
  2. Jun 20, 2021
  3. Jun 19, 2021
  4. Feb 28, 2021
  5. Feb 25, 2021
  6. Feb 24, 2021
    • Daniel Golle's avatar
      image: allow building FIT and uImage with ramdisk · 330bd380
      Daniel Golle authored
      
      Instead of embedding the initrd cpio archive into the kernel, allow
      for having an external ramdisk added to the FIT or uImage.
      This is useful to overcome kernel size limitations present in many
      stock bootloaders, as the ramdisk is then loaded seperately and doesn't
      add to the kernel size. Hence we can have larger ramdisks to host ie.
      installers with all binaries to flash included (or a web-based
      firmware selector).
      In terms of performance and total size the differences are neglectible.
      
      Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      330bd380
  7. Feb 16, 2021
  8. Feb 05, 2021
  9. Sep 02, 2020
    • Adrian Schmutzler's avatar
      rb532: drop target · 94198e2a
      Adrian Schmutzler authored
      This target is still on kernel 4.14, and recent attempts to move it to
      kernel 5.4 have not led to success. The device tester reported that it
      wouldn't boot with the following messages:
      
      From sysupgrade:
      
        Press any key within 4 seconds to enter setup....
        loading kernel from nand... OK
        setting up elf image... OK
        jumping to kernel code
      
      At this point the system hangs.
      
      From CompactFlash:
      
        Press any key within 4 seconds to enter setup....
        Booting CF
        Loading kernel... done
        setting up elf image... kernel out of range kernel loading failed
      
      The tester reported that the same was observed with current master
      (kernel 4.14) as well. This looks like some kernel size restriction.
      
      Since this target is quite old and only supports one device, and since
      nobody else seemed interested in working on this for quite some time,
      I decided to not put further work into analyzing the problem and drop
      this together with the other 4.14-only targets.
      
      Patchwork series:
      https://patchwork.ozlabs.org/project/openwrt/list/?series=197066&state=*
      
      
      
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      94198e2a
  10. Aug 30, 2020
  11. Jun 15, 2020
    • Christopher Hill's avatar
      ath79: add support for MikroTik RouterBOARD 493G (rb4xx series) · b7a8a545
      Christopher Hill authored
      This patch adds support for the MikroTik RouterBOARD RB493G, ported
      from the ar71xx target.
      
      See https://routerboard.com/RB493G
      
       for details
      
      Specification:
      - SoC Qualcomm Atheros AR7161
      - RAM: 256 MiB
      - Storage: 128MiB NAND
      - Ethernet: 9x 1000/100/10 Mbps
      - USB 1x 2.0 / 1.0 type A
      - PCIe: 3x Mini slot
      - MicroSD slot
      
      Working:
      - Board/system detection
      - Ethernet
      - SPI
      - NAND
      - LEDs
      - USB
      - Sysupgrade
      
      Enabled (but untested due to lack of hardware):
      - PCIe - ath79_pci_irq struct has the slot/pin/IRQ mappings if needed
      
      Installation methods:
      - tftp boot initramfs image, scp then flash via "sysupgrade -n"
      - nand boot existing OpenWrt, scp then flash via "sysupgrade -n"
      
      Notes:
      - initramfs image will not work if uncompressed image size over ~8.5Mb
      - The "rb4xx" drivers have been enabled
      
      Signed-off-by: default avatarChristopher Hill <ch6574@gmail.com>
      b7a8a545
  12. Mar 31, 2020
    • 李国's avatar
      x86: generate EFI platform bootable images · a6b7c3e6
      李国 authored
      
      Add EFI platform bootable images for x86 platforms. These images can
      also boot from legacy BIOS platform.
      
      EFI System Partition need to be fat12/fat16/fat32 (not need to load
      filesystem drivers), so the first partition of EFI images are not ext4
      filesystem any more.
      
      GPT partition table has an alternate partition table, we did not
      generate it. This may cause problems when use these images as qemu disk
      (kernel can not find rootfs), we pad enough sectors will be ok.
      
      Signed-off-by: default avatar李国 <uxgood.org@gmail.com>
      [part_magic_* refactoring, removed genisoimage checks]
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      a6b7c3e6
  13. Mar 21, 2020
    • Paul Spooren's avatar
      x86: switch image generation to new code · cb007a7b
      Paul Spooren authored
      
      This commit introduces few related changes which need to be done in
      single commit to keep images buildable between git revisions. In result
      it retains all previous image creation possibilities with slight name
      change of generated images. Brief summary of the commit:
      
      * Split up image generation recipe to smaller chunks to make it more
        generic and reusable.
      
      * Make iso images x86 specific and drop their definition as root
        filesystem.
      
      * Convert image creation process to generic code specified in image.mk.
      
      * Make geode subtarget inherit features from the main target instead of
        redefining them.
      
      * For subtargets create device definitions with basic packages set.
      
      Signed-off-by: default avatarTomasz Maciej Nowak <tomek_n@o2.pl>
      [rebased]
      Signed-off-by: default avatarPaul Spooren <mail@aparcar.org>
      cb007a7b
  14. Feb 14, 2020
    • Adrian Schmutzler's avatar
      brcm2708: rename target to bcm27xx · 7d7aa2fd
      Adrian Schmutzler authored
      
      This change makes the names of Broadcom targets consistent by using
      the common notation based on SoC/CPU ID (which is used internally
      anyway), bcmXXXX instead of brcmXXXX.
      This is even used for target TITLE in make menuconfig already,
      only the short target name used brcm so far.
      
      Despite, since subtargets range from bcm2708 to bcm2711, it seems
      appropriate to use bcm27xx instead of bcm2708 (again, as already done
      for BOARDNAME).
      
      This also renames the packages brcm2708-userland and brcm2708-gpu-fw.
      
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      Acked-by: default avatarÁlvaro Fernández Rojas <noltari@gmail.com>
      7d7aa2fd
  15. Sep 21, 2019
  16. Jul 14, 2019
  17. Jun 25, 2019
    • Petr Štetiar's avatar
      build: enable gzipped images for armvirt and malta · 9c8e0b0e
      Petr Štetiar authored
      
      As we're now going to pad all images by default to 128MiB let's enable
      compression of the images for armvirt and malta in order to save some
      space and bandwidth.
      
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      9c8e0b0e
    • Petr Štetiar's avatar
      build: make TARGET_ROOTFS_PARTSIZE 128MiB by default · 469ba337
      Petr Štetiar authored
      
      As we're now going to pad all images by default, lets decrease the
      default rootfs partition size from 256MiB to 128MiB in order to save
      some space.
      
      I'm keeping it above 100MiB in order to keep current behavior, where
      overlay filesystem is using F2FS.
      
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      469ba337
    • Petr Štetiar's avatar
      build: remove TARGET_IMAGES_PAD option · d03ef97c
      Petr Štetiar authored
      
      It's being used only in x86 target to produce combined images, where
      it's mandatory to have padded images in order to produce working
      squashfs combined images usable in QEMU.
      
      Currently we're producing unusable x86 combined squashfs images
      (18.06.1, 18.06.2 and snapshots) as we don't enable TARGET_IMAGES_PAD,
      thus providing very small space for the overlay filesystem, leading to
      the following with OpenWrt 18.06.1 r7258-5eb055306f images on x86 QEMU:
      
       root@(none):/# mount | egrep 'root|overlay'
        /dev/root on /rom type squashfs
        /dev/loop0 on /overlay type ext4
        overlayfs:/overlay on / type overlay
      
       root@(none):/# df -h | egrep 'root|overlay|Size'
        Filesystem                Size      Used Available Use% Mounted on
        /dev/root                 2.5M      2.5M         0 100% /rom
        /dev/loop0              113.0K      8.0K     97.0K   8% /overlay
        overlayfs:/overlay      113.0K      8.0K     97.0K   8% /
      
      So we should rather ensure proper image padding in image generation code
      and we shouldn't rely on config options in order to generate usable
      images.
      
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      d03ef97c
  18. May 15, 2019
    • Stijn Segers's avatar
      lantiq/xrx200: enable initramfs images · 5cd49395
      Stijn Segers authored
      
      Commit eae6cac6 ("lantiq: add support for AVM FRITZ!Box 7362 SL"), but
      one needs an initramfs image to flash OpenWrt from stock firmware (as
      described in the commit log). This patch has the initramfs image built
      by default.
      
      Thanks to blogic (for pointing to the FEATURES declaration in the target
      Makefiles) and Musashino on the forum for suggesting
      config/Config-images.in needed editing too. While at it, reorder the
      TARGET_INITRAMFS_COMPRESSION_LZMA declarations alphabetically.
      
      This patch will result in initramfs images for all lantiq subtargets
      that have the ramdisk flag set. I tested on the falcon and ase
      subtargets, which lack that flag, to confirm they don't produce any
      initramfs images with this patch - which they do not.
      
      Given the limited scope of the lantiq (sub)target(s), blogic indicated
      this should be OK.
      
      Signed-off-by: default avatarStijn Segers <foss@volatilesystems.org>
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      [fixed the wrong reference to eae6cac6 commit]
      5cd49395
  19. Apr 06, 2019
  20. Feb 17, 2019
  21. Jan 31, 2019
  22. Jan 24, 2019
    • Christian Lamparter's avatar
      brcm2708: boot-part feature integration · 1aa00f9d
      Christian Lamparter authored
      
      This patch adds the boot-part feature which enables the brcm2708
      target move from the custom boot partition size config option to
      the generic CONFIG_TARGET_KERNEL_PARTSIZE.
      
      Note:
      For people using custom images: Just like with
      CONFIG_TARGET_ROOTFS_PARTSIZE changing the value
      can cause sysupgrade to repartition the device!
      Make sure to have a backup in this case.
      
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      1aa00f9d
  23. Jan 01, 2019
  24. Sep 29, 2018
  25. Sep 03, 2018
  26. Jul 30, 2018
  27. Jul 12, 2018
  28. Jan 13, 2018
    • Koen Vandeputte's avatar
      config: support new symbol intro'd in kernel 4.12 · fce35bce
      Koen Vandeputte authored
      
      Symbol CONFIG_INITRAMFS_FORCE allows to ignore the value passed by the
      bootloader.
      
      By default, all symbols containing INITRAMFS are wiped from the final
      config and then re-added conditionally.
      
      Add support for this symbol, as the build will stop otherwise
      questioning the user about this option:
      
      * Restart config...
      *
      *
      * General setup
      *
      Cross-compiler tool prefix (CROSS_COMPILE) []
      Compile also drivers which will not load (COMPILE_TEST) [N/y/?] n
      
      ...
      
      Initial RAM filesystem and RAM disk (initramfs/initrd) support
      (BLK_DEV_INITRD) [Y/n/?] y
      Initramfs source file(s) (INITRAMFS_SOURCE) []
      Ignore the initramfs passed by the bootloader (INITRAMFS_FORCE)
      [N/y/?] (NEW)
      
      Signed-off-by: default avatarKoen Vandeputte <koen.vandeputte@ncentric.com>
      fce35bce
  29. Oct 13, 2017
  30. Jul 06, 2017
  31. Apr 03, 2017
  32. Feb 17, 2017
  33. Dec 15, 2016
    • Felix Fietkau's avatar
      x86: revert default root size back to 256 MB · 4cc1f1ac
      Felix Fietkau authored
      
      2 GB is overkill and was only added to allow unlimited ext4 resizing,
      which is a pretty rare use case. 256 MB allows resizing up to 256 GB,
      which should be good enough for almost all users.
      
      A lot of this is mostly irrelevant anyway, since you can just use
      squashfs + ext4 overlay.
      
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      4cc1f1ac
  34. Nov 24, 2016
  35. Nov 09, 2016
  36. Oct 27, 2016
    • Jo-Philipp Wich's avatar
      config: ext4: increase x86 rootfs size to 2GB to support online resize2fs · dc6cc040
      Jo-Philipp Wich authored
      
      The current default rootfs size of 256MB in conjunction with 4K blocks
      produces an ext4 filesystem which lacks the appropriate amount of backup GDT
      entries to support online-resizing.
      
      For x86 targets, increase the default rootfs size to 2048MB which allows
      online resizing the filesystem to up to 2TB which is the current theoretical
      maximum for LEDE, due to missing GPT support on the root block device.
      
      Note that the filesystem artefact will not occupy 2GB on the build system as
      the make_ext4fs utility uses sparse files to generate the filesystem images,
      so the actual disk usage is much lower. Furthermore the filesystem images
      are gzip compressed, shrinking them to only a few megabytes on the download
      server.
      
      Signed-off-by: default avatarJo-Philipp Wich <jo@mein.io>
      Acked-by: default avatarMichael Heimpold <mhei@heimpold.de>
      dc6cc040
    • Jo-Philipp Wich's avatar
      config: ext4: drop option to set maximum number of inodes · d1ae4c49
      Jo-Philipp Wich authored
      
      There is very little practical use to limit the number of available inodes on
      an ext4 filesystem and the make_ext4fs utility is able to calculate useful
      defaults by itself.
      
      Drop the option to make resulting ext4 filesystems more flexible by default.
      
      Signed-off-by: default avatarJo-Philipp Wich <jo@mein.io>
      Acked-by: default avatarMichael Heimpold <mhei@heimpold.de>
      d1ae4c49
  37. Sep 08, 2016
Loading