aboutsummaryrefslogtreecommitdiff
path: root/target/linux/armsr/base-files/etc
Commit message (Collapse)AuthorAge
* treewide: simplify kernel version number comparisonsShiji Yang2025-07-14
| | | | | | | | | Directly call the function "get_linux_version()" to get the integer kernel version number. Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/19172 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* armsr: use console=tty1 to make console more readily availableMark Mentovai2024-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Like x86, armsr is frequently virtualized, and is used for development and debugging. Kernel messages should be more readily apparent by default. This can be achieved by adding console=tty1 to the kernel command line, enabling the console on a (possibly virtual) display and keyboard, in addition to a serial port. This also enables failsafe on tty1. Failsafe mode operates on consoles known by the kernel, without regard to /etc/inittab. armsr's /etc/inittab is also updated to specify tty1 instead of tty0. tty1 is technically more correct: tty1 is the first virtual console, where tty0 reflects the current active virtual console (which is likely to be tty1). This configuration matches x86, which is another target commonly used for virtualization, development, and debugging in the same way. x86's kernel command line had specified console=tty0, although console=tty1 is more correct for the reasons given above. This also brings x86's kernel command line console= into agreement with its /etc/inittab, which already used tty1. Signed-off-by: Mark Mentovai <mark@mentovai.com> Link: https://github.com/openwrt/openwrt/pull/16213 Signed-off-by: Robert Marko <robimarko@gmail.com>
* kernel: armsr: Renesas: RZ: Ethernet module and ttySC0John Vincent2024-06-17
| | | | | | | | Ethernet module enable for Renesas RZ platform inittab fix for ttySC0 Fixes: #15284 Signed-off-by: John Vincent <john.vincent.xa@bp.renesas.com>
* base-files: armsr: add script to migrate GPIO switches on Ten64 boardMathew McBride2024-05-07
| | | | | | | | | | | | | | Due to a change in kernel 6.2, the GPIO numbers on certain architectures (including arm64) have changed. This script will update any defined GPIO switches to the new numbering. See https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042448.html for more information. In the future, the GPIO switch mechanism will likely be replaced with something using libgpiod. Signed-off-by: Mathew McBride <matt@traverse.com.au>
* base-files: armsr: number Ten64 GPIOs according to kernel versionMathew McBride2024-05-07
| | | | | | | | | | | | | | | | A change in kernel 6.2[1] caused the base numbers of GPIOs to change significantly on some architectures like aarch64. We have to number our GPIOs accordingly. Ideally the board.d scripts should look through sysfs to find the basenum (like cat "/sys/devices/platform/soc/2000000.i2c/ i2c-0/0-0076/gpio/gpiochip640/base"), but the problem is that this occurs before modules are loaded, meaning I2C and other runtime devices may be missing. Signed-off-by: Mathew McBride <matt@traverse.com.au> [1] https://lore.kernel.org/lkml/cover.1662116601.git.christophe.leroy@csgroup.eu/T/
* x86,armsr: interpolate GRUB_SERIAL into /etc/inittabPhilip Prindeville2023-11-19
| | | | | | | | | Some platforms have their console on other ports than ttyS0, so allow the developer to tailor this on bespoke platform images. Fixes issue #13401. Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
* armsr: rename from armvirtMathew McBride2023-06-10
Now that the armvirt target supports real hardware, not just VMs, thanks to the addition of EFI, rename it to something more appropriate. 'armsr' (Arm SystemReady) was chosen after the name of the Arm standards program. The 32 and 64 bit targets have also been renamed armv7 and armv8 respectively, to allow future profiles where required (such as armv9). See https://developer.arm.com/documentation/102858/0100/Introduction for more information. Signed-off-by: Mathew McBride <matt@traverse.com.au>