aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/mvebu/cortexa9
Commit message (Collapse)AuthorAgeFilesLines
* treewide: remove "+" sign for increment with macaddr_addAdrian Schmutzler2021-06-051-2/+2
| | | | | | | | | | | | Many people appear to use an unneeded "+" prefix for the increment when calculating a MAC address with macaddr_add. Since this is not required and used inconsistently [*], just remove it. [*] As a funny side-fact, copy-pasting has led to almost all hotplug.d files using the "+", while nearly all of the 02_network files are not using it. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: venom resize kernel to 6MBTad Davanzo2021-03-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | venom has a 3MB kernel partition as specified by the DTS. 3MB is not sufficient for building with many kernel modules or newer kernel versions. venom uboot however as set from factory will load up to 6MB. This can be observed by looking a uboot log: NAND read: device 0 offset 0x900000, size 0x600000 6291456 bytes read: OK and from uboot environment variables: $ fw_printenv | grep "priKernSize"; priKernSize=0x0600000 Resize the root partitions from 120MB to 117MB to let kernel expand into it another 3MB. And set kernel target size to 6MB. Lastly set the kernel-size-migration compatibility version on venom to prevent sysupgrading without first reinstalling from a factory image. Signed-off-by: Tad Davanzo <tad@spotco.us>
* mvebu: mamba resize kernel to 4MBTad Davanzo2021-03-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | mamba has a 3MB kernel partition as specified by the DTS. 3MB is not sufficient for building with many kernel modules or newer kernel versions. mamba uboot however as set from factory will load up to 4MB. This can be observed by looking a uboot log: NAND read: device 0 offset 0xa00000, size 0x400000 4194304 bytes read: OK and from uboot environment variables: $ fw_printenv | grep "pri_kern_size"; pri_kern_size=0x400000 Resize the root partitions from 37MB to 36MB to let kernel expand into it another 1MB. And set kernel target size to 4MB. Lastly add a compatibility version message: kernel-size-migration. And set it on mamba to prevent sysupgrading without first reinstalling from a factory image. Signed-off-by: Tad Davanzo <tad@spotco.us>
* treewide: remove execute bit and shebang from board.d filesAdrian Schmutzler2021-03-063-3/+0
| | | | | | | | | | | | | | | | So far, board.d files were having execute bit set and contained a shebang. However, they are just sourced in board_detect, with an apparantly unnecessary check for execute permission beforehand. Replace this check by one for existance and make the board.d files "normal" files, as would be expected in /etc anyway. Note: This removes an apparantly unused '#!/bin/sh /etc/rc.common' in target/linux/bcm47xx/base-files/etc/board.d/01_network Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* target: use SPDX license identifiers on MakefilesAdrian Schmutzler2021-02-101-4/+1
| | | | | | Use SPDX license tags to allow machines to check licenses. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: sysupgrade: use v function for writing logsTomasz Maciej Nowak2020-12-011-1/+1
| | | | | | Sync with x86 target changes. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* mvebu: fixup Turris Omnia U-Boot environmentKlaus Kudielka2020-11-271-0/+44
| | | | | | | | | | | | | | Fixup dfa357a3de "mvebu: base-files: Update Turris Omnia U-Boot environment" which should have included this file as well. By rebasing the initial patch this file somehow disappeared. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia) [explain fixup in commit message] Signed-off-by: Paul Spooren <mail@aparcar.org>
* mvebu: base-files: move additional files to subtargetsTomasz Maciej Nowak2020-11-252-0/+69
| | | | | | | Both of these scripts are only relevant to cortexa9, therefore move them there. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* mvebu: Correct regulatory country of WRT3200ACMKabuli Chana2020-10-111-1/+1
| | | | | | | | | | correct oversight on setting regulatory country and mac address of wireless configuration change method of retrieving mac address The MAC address for eth0 is rad out of the devinfo partition in some other initial configuration script already. Signed-off-by: Kabuli Chana <newtownBuild@gmail.com>
* mvebu: add wrt3200acm to 03_wireless CCKabuli Chana2020-10-111-0/+1
| | | | | | | | | correct device CC oversight Set the initial wifi configuration like for the other similar Linksys devices. Signed-off-by: Kabuli Chana <newtownBuild@gmail.com>
* treewide: revert sysupgrade adjustments for early DSA-adoptersAdrian Schmutzler2020-09-081-21/+0
| | | | | | | | | | | | | | | | | The uci-default mechanism to update the compat-version was only meant for early DSA-adopters, which should have updated by now. Remove this workaround again in order to prevent the intended experiences for all the other people. This reverts: a9703db72030 ("mvebu: fix sysupgrade experience for early DSA-adopters") 86c89bf5e8f5 ("kirkwood: fix sysupgrade experience for early DSA-adopters") Partially reverted: 1eac573b5304 ("ramips: mt7621: implement compatibility version for DSA migration") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: fix sysupgrade experience for early DSA-adoptersAdrian Schmutzler2020-08-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conceptually, the compat-version during sysupgrade is meant to describe the config. Therefore, if somebody starts with a device on 19.07 and swconfig, and that person does a forceful upgrade into a DSA-based firmware without wiping his/her config, then the local compat-version should stay at 1.0 according to the config present (and not get updated). However, this poses a problem for those people that early-adopted DSA in master, as they already have adjusted their config for DSA, but it still is "1.0" as far as sysupgrade is concerned. This can be healed by a simple uci set system.@system[0].compat_version="1.1" uci commit system But this needs to be applied _after_ the upgrade (as the "old" fwtool on the old installation does not know about compat_version) and it requires access via SSH (i.e. no pure GUI solution is available for this group of people, apart from wiping their config _again_ for no technical reason). Despite, the situation will not become obvious to those just upgrading via GUI, they will just have the experience of a "broken upgrade". This is a conflict which cannot be resolved by achieving both goals, we have to decide to either keep the strict concept or improve the situation for early adopters. In this patch, we address the issue by providing a uci-defaults script that will raise the compat_version for _all_ people upgrading into a 1.1 image, no matter whether they have reset config or not. The idea is to implement this as a _temporary_ solution, so early adopters can upgrade into the new mechanism without issues, and after a few weeks/months we could remove the uci-defaults script again. If we e.g. remove the script just before 20.xx.0-rc1, early adopters should have moved on by then, and existing stable users would still get the intended experience. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: fix alphabetic sorting in 02_networkAdrian Schmutzler2020-07-311-6/+6
| | | | | | This has been overlooked when removing solidrun,clearfog-a1 entry. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: increase compat version for SolidRun ClearFog BaseAdrian Schmutzler2020-07-311-0/+1
| | | | | | | | | | | | | When changing the Pro variant to DSA, the ethernet interface rename script was dropped by all devices to keep them in sync: be309bfd7445 ("mvebu: drop 06_set_iface_mac preinit script") Therefore, network config will be broken after upgrade for the Base variant as well. Increase the compat version and provide a message to signal that to the users. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: implement compatibility version for DSA migrationAdrian Schmutzler2020-07-311-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | This implements the newly introduced compat-version to prevent upgrade between swconfig and DSA for mvebu. Just define a compat version with minor increment and an appropriate message for both image (in Makefile) and device (in base-files). Having taken care of sysupgrade, we can put back the SUPPORTED_DEVICES that have been removed in previous patches to prevent broken config. Attention: All users that already updated to the DSA versions in master will receive the same incompatibility warning since their devices are still "1.0" as far as fwtool can tell. Those, and only those, can bypass the upgrade check by using force (-F) without having to reset config again. In addition, the new version string needs to be put into uci config manually, so the new fwtool knows that it actually deals with a "1.1": uci set "system.@system[-1].compat_version=1.1" uci commit system Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: add Kobol Helios 4 deviceAlberto Bursi2020-07-172-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Helios 4 is a NAS from Kobol that is powered by an Armada 38x MicroSOM from Solidrun, similarly to Clearfog. This device has: -Armada 38x CPU (dual core ARMv7 1.6 Ghz) -2 GB of ECC RAM -Gigabit ethernet (Marvell) -2x USB 3.0 ports -4x Sata 3.0 ports -i2c header (J9 |>GND|SDA|SCL|VCC) -2x 3-pin fan headers with PWM -micro-usb port is a TTL/UART to USB converter connected to TTL -MicroSD card slot -System, 4xSata and 1xUSB LEDs NOT WORKING: fan control Fan Control requires a kernel patch that is available in the Armbian project (the "default firmware" of this device) and named mvebu-gpio-remove-hardcoded -timer-assignment This patch isn't acceptable by OpenWrt, it should be upstreamed. I also have that patch in my own local OpenWrt builds, in case you want a more clean and less confusing patch for upstreaming. To install, write the disk image on a micro SD card with dd or win32 disk imager, insert the card in the slot. Check that the dip switch battery for boot selection is as follows Switch 1 and 2 down/off, switches 3, 4, 5 up/on. Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
* mvebu: remove non-existant board name solidrun,clearfog-a1Adrian Schmutzler2020-06-281-1/+0
| | | | | | | | | | | | | | In 02_network, the board name solidrun,clearfog-a1 is used in a case, but it does not seem to be used/exist anywhere else in OpenWrt. The valid strings are: - solidrun,clearfog-pro-a1 - solidrun,clearfog-base-a1 Fixes: 12795ec9f16b ("mvebu: split interface configuration for clearfog pro and base") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: fix default EU regdomain for Linksys WRT AC devicesJose Olivera2020-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | The mwlwifi driver sets the default country code for EU (fi- rmware region code 0x30) certified devices to FR (France), not DE (Germany). Whilst this is a trivial fix, novice users may not know how mwlwifi negatively reacts to a non-matching country code and may leave the setting alone. Especially si- nce it is under the advanced settings section in LuCI. Relevant mwlwifi driver code: https://github.com/kaloz/mwlwifi/commit/0a550312ddb5a9e00e8d602d5571598f25a78158 The mwlwifi driver readme states "Please don't change country code and let mwlwifi set it for you." However, OpenWrt's current behaviour does not adhere to this with its default, 'just flashed from factory' setting for EU devices. Signed-off-by: Jose Olivera <oliverajeo@gmail.com> [rebase, extend commit message] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* treewide: drop shebang from non-executable target filesAdrian Schmutzler2020-06-162-2/+0
| | | | | | | | | | | | | | This drops the shebang from all target files for /lib and /etc/uci-defaults folders, as these are sourced and the shebang is useless. While at it, fix the executable flag on a few of these files. This does not touch ar71xx, as this target is just used for backporting now and applying cosmetic changes would just complicate things. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: rename Linksys devices based on their common namesPaul Spooren2020-06-057-44/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linksys devices in mvebu target feature a mixed naming, where parts are based on the official product name (device node, image; e.g. WRT3200ACM) and parts are based on the internal code name (DTS file name, compatible, LED labels; e.g. rango). This inconsistent naming has been perceived as quite confusing. A recent attempt by Paul Spooren to harmonize this naming in kernel has been declined there. However, for us it still makes sense to apply at least a part of these changes locally. Primarily, this patch changes the compatible in DTS and thus the board name used in various scripts to have them in line with the device, model and image names. Due to the recent switch from swconfig to DSA, this allows us to drop SUPPORTED_DEVICES and thus prevent seamless upgrade between these incompatible setups. However, this does not include the LED label rename from Paul's initial patch: I don't think it's worth keeping the enormous diff locally for this case, as we can implement this much easier in 01_leds if we have to live with the inconsistency anyway. Signed-off-by: Paul Spooren <mail@aparcar.org> [rebase, extend to all devices, drop DT LED changes] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: drop 06_set_iface_mac preinit scriptDENG Qingfang2020-06-031-50/+0
| | | | | | | | MAC address is set in board.d script Interface swapping is not needed anymore as switching to DSA breaks previous configuration anyway Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mvebu: use ucidef to set up MAC addressDENG Qingfang2020-06-031-38/+75
| | | | | | Use ucidef to set up MAC address instead of preinit script Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mvebu: update default config for DSADENG Qingfang2020-06-032-11/+5
| | | | | | | | Update network/LED configuration for DSA driver. sysupgrade from images prior to this commit with config preserved will break the ethernet. Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mvebu: add support for Buffalo LinkStation LS421DEDaniel González Cabanelas2020-04-132-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370 Hardware: SoC: Marvell Armada 88F6707-A1 CPU: Cortex-A9 1200 MHz, 1 core Flash: SPI-NOR 1 MiB, NAND 512 MiB RAM: DDR3 512 MiB Ethernet: 1x 10/100/1000 Mbps USB: 1x 2.0, 1x 3.0 SATA: 2x 3.0 Gbps LEDs/Input : 5x / 2x (1x button, 1x slide-switch) RTC: Ricoh RS5C372A, I2C, no battery Flash instruction (UART+TFTP): 1. Downgrade the OEM firmware to 1.34 version (BUFFALO_BOOTVER=0.13) 2. Remove any hard drive from inside the bays. 3. Boot the Openwrt initramfs image using the U-Boot serial console: tftpboot 0x1200000 buffalo_ls421de-initramfs-kernel.bin bootm 0x1200000 4. Flash the sysupgrade image using the Openwrt console: sysupgrade -n buffalo_ls421de-squashfs-sysupgrade.bin 5. Wait until it finish, the device will reboot with Openwrt installed on the NAND flash. Note: - Device shuting down doesn't work, even if the power slide switch is used. We must first, via MDIO, set the unused LED2 at the ethernet phy0 to off state. Reboot works ok. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
* mvebu: cortexa9: correct cpu subtypeTomasz Maciej Nowak2020-03-281-1/+1
| | | | | | | | | | | | | | | Armada 370 processors have only 16 double-precision registers. The change introduced by 8dcc1087602e ("toolchain: ARM: Fix toolchain compilation for gcc 8.x") switched accidentally the toolchain for mvebu cortexa9 subtarget to cpu type with 32 double-precision registers. This stems from gcc defaults which assume "vfpv3-d32" if only "vfpv3" as mfpu is specified. That change resulted in unusable image, in which kernel will kill userspace as soon as it causing "Illegal instruction". Ref: https://forum.openwrt.org/t/gcc-was-broken-on-mvebu-armada-370-device-after-commit-on-2019-03-25/43272 Fixes: 8dcc1087602e ("toolchain: ARM: Fix toolchain compilation for gcc 8.x") Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
* mvebu: split base-files across subtargetsAdrian Schmutzler2020-01-219-0/+433
| | | | | | | | | | | | | For the mvebu target in particular, there is a lot of files in base-files that are only relevant for one subtarget. Improve overview and reduce size per subtarget by moving/splitting base-files depending on the subtarget they belong to. While at it, consolidate 01_leds by using the model part of the board name as variable. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
* mvebu: move HARDEN_BRANCH_PREDICTOR to common configTomasz Maciej Nowak2019-01-271-1/+0
| | | | | | | | This symbol is enabled in all subtargets, move it to common kernel config. Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Acked-by: Rosen Penev <rosenp@gmail.com>
* kernel: bump 4.14 to 4.14.77Koen Vandeputte2018-10-191-0/+1
| | | | | | | | | | | | | | | Refreshed all patches. Altered patches: - 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch New symbol for arm targets: - HARDEN_BRANCH_PREDICTOR Compile-tested on: ar71xx, cns3xxx, imx6 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* mvebu: Add subtarget for Cortex A9 buildHauke Mehrtens2018-03-101-0/+14
This is in preparation for adding a subtarget for the Cortex A53 later. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 06:21:40 +0000