staging/neocturne/target/Config.in, branch main

loongarch64: new target

2024-05-04T06:14:16Z

Add target for Loongson LoongArch64-based boards. LoongArch is a new RISC ISA developed by Loongson. It's a bit like MIPS or RISC-V. LoongArch includes both 32-bit and 64-bit versions (LoongArch32/LoongArch64). Loongson 3A5000 and 3A6000 are the two existing CPUs of LoongArch64 and is used for PC products. It's BIOS supports ACPI and UEFI-only boot. These CPUs supports SMP and SMT. At present only LoongArch64 is supported by linux kernel. Toolchain requirement: binutils >= 2.40 gcc >= 13.1 For details, please check the following links: https://lwn.net/Articles/861951/ https://loongson.github.io/LoongArch-Documentation/README-EN.html Signed-off-by: Weijie Gao

generic: groundwork for RISC-V

2023-05-28T11:19:10Z

Add build infrastructure for RISC-V. Signed-off-by: Zoltan HERPAI

base-files: add eMMC sysupgrade support

2021-12-02T20:42:58Z

Adds generic support for sysupgrading on eMMC-based devices. Provide function emmc_do_upgrade and emmc_copy_config to be used in /lib/upgrade/platform.sh instead of redundantly implementing the same logic over and over again. Similar to generic sysupgrade on NAND, use environment variables CI_KERNPART, CI_ROOTPART and newly introduce CI_DATAPART to indicate GPT partition names to be used. On devices with more than one MMC block device, CI_ROOTDEV can be used to specify the MMC device for partition name lookups. Also allow to select block devices directly using EMMC_KERN_DEV, EMMC_ROOT_DEV and EMMC_DATA_DEV, as using GPT partition names is not always an option (e.g. when forced to use MBR). To easily handle writing kernel and rootfs make use of sysupgrade.tar format convention which is also already used for generic NAND support. Signed-off-by: Enrico Mioso Signed-off-by: Daniel Golle CC: Li Zhang CC: TruongSinh Tran-Nguyen

base-files: rename 'sdcard' to 'legacy-sdcard'

2021-08-16T11:22:17Z

While an image layout based on MBR and 'bootfs' partition may be easy to understand for users who are very used to the IBM PC and always have the option to access the SD card outside of the device (and hence don't really depend on other recovery methods or dual-boot), in my opinion it's a dead end for many desirable features on embedded systems, especially when managed remotely (and hence without an easy option to access the SD card using another device in case things go wrong, for example). Let me explain: * using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a single corruption of the bootfs can render the system into a state that it no longer boots at all. This makes dual-boot useless, or at least very tedious to setup with then 2 independent boot partitions to avoid the single point of failure on a "hot" block (the FAT index of the boot partition, written every time a file is changed in bootfs). And well: most targets even store the bootloader environment in a file in that very same FAT filesystem, hence it cannot be used to script a reliable dual-boot method (as loading the environment itself will already fail if the filesystem is corrupted). * loading the kernel uImage from bootfs and using rootfs inside an additional partition means the bootloader can only validate the kernel -- if rootfs is broken or corrupted, this can lead to a reboot loop, which is often a quite costly thing to happen in terms of hardware lifetime. * imitating MBR-boot behavior with a FAT-formatted bootfs partition (like IBM PC in the 80s and 90s) is just one of many choices on embedded targets. There are much better options with modern U-Boot (which is what we use and build from source for all targets booting off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623. Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix functions with 'legacy_sdcard_' instead of 'sdcard_'. Tested-by: Stijn Tintel Signed-off-by: Daniel Golle

base-files: add generic sdcard upgrade method

2021-08-06T22:34:40Z

Add a generic sdcard upgrade method instead of duplicating code in yet another target, and add a feature flag to only install this upgrade method in targets that set this flag. Copied from mvebu. Signed-off-by: Stijn Tintel

include/image*: add support for device-tree overlays

2021-03-17T17:45:34Z

Add new target feature 'dt-overlay' which makes DTC keep the symbol names in the generated dtb. Make sure additional DT overlay sources specified by the new device variable DEVICE_DTS_OVERLAY get compiled together with the main DTS (currently overlays got to be in the same folder). Let Build/fit pass the generated DT overlay blobs to mkits.sh. Signed-off-by: Daniel Golle

treewide: fix spelling 'seperate' -> 'separate'

2021-02-28T23:59:21Z

This popular spelling mistake was also introduced by myself lately. Fix it everywhere. Signed-off-by: Daniel Golle

image: allow building FIT and uImage with ramdisk

2021-02-24T01:35:20Z

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: Daniel Golle

build: define PWM_SUPPORT arch feature flag

2020-09-25T17:32:33Z

As the PWM has its own sub-system in the Linux kernel, I think it should be handled in the same way as GPIO, RTC, PCI... This patch introduces a specific feature flag "pwm" and the "leds-pwm" kernel module as the first customer. Signed-off-by: Christian Lamparter

build: define RTC_SUPPORT as a bool

2020-04-09T10:51:10Z

Currently, RTC_SUPPORT is defined as a tristate, with 'depends on m', which is supposed to only let it be set to 'm' or 'n'. However, scripts/target-metadata.pl will 'select' it, or setting it to 'y', which defeats it's 'depends on m' restriction. The users of the symbol are not expecting it to be necessarily 'm' either, so we can safely use it as bool. Newer versions of Linux 'conf' will issue a warning when it detects such unmet dependencies, and will set it to 'n' instead of 'y', as the current version does. In all cases, 'm' is never used. Signed-off-by: Eneas U de Queiroz