fish/immortalwrt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6ced31c320
immortalwrt/target/linux/lantiq/base-files/lib/upgrade/platform.sh

28 lines
412 B
Bash
Raw Normal View History

lantiq: add v3.10 patches Signed-off-by: John Crispin <blogic@openwrt.org> SVN-Revision: 38031
2013-09-18 05:46:10 +08:00
PART_NAME=firmware
lantiq: append metadata to images Signed-off-by: Felix Fietkau <nbd@nbd.name>
2016-11-17 18:41:08 +08:00
REQUIRE_IMAGE_METADATA=1
adds new lantiq kernel. once the codebase is fully tested and know to be working on all the devices previously supported by ifxmips, we will drop ifxmips support. SVN-Revision: 24526
2010-12-13 06:57:16 +08:00
platform_check_image() {
lantiq: remove device specific sysupgrade image checks Replaced by image metadata Signed-off-by: Felix Fietkau <nbd@nbd.name>
2016-11-21 03:07:18 +08:00
return 0
adds new lantiq kernel. once the codebase is fully tested and know to be working on all the devices previously supported by ifxmips, we will drop ifxmips support. SVN-Revision: 24526
2010-12-13 06:57:16 +08:00
}
treewide: move nand_do_upgrade call to platform_do_upgrade Calling nand_do_upgrade() from platform_pre_upgrade() was deprecated with 30f61a34b4cf ("base-files: always use staged sysupgrade"). Update the platform upgrade code to use platform_do_upgrade() for NAND images as well. Signed-off-by: Mathias Kresin <dev@kresin.me>
2017-12-19 03:32:18 +08:00
platform_do_upgrade() {
lantiq: remove lantiq_board_name, use the generic function instead Signed-off-by: Felix Fietkau <nbd@nbd.name>
2017-03-17 23:21:30 +08:00
local board=$(board_name)
lantiq: add platform_pre_upgrade for sysupgrade As explained in recent sysupgrade/nand.sh commits, current NAND sysupgrade is a bit misleading because of nand_do_platform_check behavior. It leaves a special mark in /tmp/sysupgrade-nand-path triggering some diffent code path in nand_upgrade_stage1. The plan is to have the check function only check the image and nothing else. Then platform code (platform_pre_upgrade) should trigger NAND specific upgrade path. This is what this patch implements. Please note that because of current nand_upgrade_stage1 implementation this patch doesn't change any behaior yet. It only prepares lantiq target for changing nand_do_platform_check (it will be possible after preparing all other targets as well). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> SVN-Revision: 46939
2015-09-15 14:13:07 +08:00
case "$board" in
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
2017-06-10 01:28:36 +08:00
avm,fritz3370-rev2-hynix|\
avm,fritz3370-rev2-micron|\
lantiq: add support for AVM FRITZ!Box 7362 SL Hardware: - SoC: Lantiq VRX288 - RAM: Winbond W971GG6JB 1 Gb (128 MiB) - Flash: - SPI: 8 Mb (1 MiB) for bootloader and tffs - NAND: 1 Gb (128 MiB) for OS - xDSL: Lantiq VRX208 - WLAN: Atheros AR9381 - DECT: Dialog Semiconductors SC14441 Everything except FXS/DECT works (no drivers for AVM's FXS implementation with SC14441). Installation via FTP: 1. Use scripts/flashing/eva_ramboot.py to send initramfs-kernel.bin to the device when powering on. Standard AVM procedures with finding the correct IP address and the right moment to open FTP apply here (approx. 4 seconds on 7362SL). IMPORTANT: set lzma compression in ramdisk options, bootloader stalls when receiving uncompressed images. 2. Transfer sysupgrade.bin image with scp to /tmp directory and run sysupgrade 3. First boot might take a bit longer if linux_fs_start was set to 1, in that case the device will reboot twice, first time it will fail to load second kernel (overwritten by ubifs), set linux_fs_start to 0 and reboot. OpenWrt uses the entire NAND flash. Kernel uses 4 MiB and rootfs uses the rest of 124 MiB, overwriting everything related to FRITZ!OS - both OS images, config and answering machine/media server data. To return to FRITZ!OS, use AVM's recovery image. Signed-off-by: Danijel Tudek <danijel.tudek@gmail.com>
2019-02-13 01:11:09 +08:00
avm,fritz7362sl|\
lantiq: add support for AVM FRITZ!Box 7412 Hardware: SoC: Lantiq VRX 220 CPU Cores: 2x MIPS 34Kc at 500 MHz RAM: 128 MiB 250 MHz Storage: 128 MiB NAND flash Ethernet: built-in Fast Ethernet switch, only port 2 is used Wireless: Atheros AR9287-BL1A b/g/n with 2 pcb antennas Modem: built-in A/VDSL2 modem DECT: Dialog SC14441 LEDs: 1 two-color, 4 one-color Buttons: 2 FXS: 1 port via TAE or RJ12 connector Everything except FXS/DECT works (no drivers for AVM's FXS implementation with SC14441). Installation: Use the eva_ramboot.py script to load an initramfs image on the device. Run it a few seconds after turning the device on. $ scripts/flashing eva_ramboot 192.168.178.1 bin/targets/lantiq/xrx200/openwrt-lantiq-xrx200-avm_fritz7412-initramfs-kernel.bin If it fails to find the device try the ip address 169.254.120.1. (Firmware updates or the recovery tool apparently change it.) IMPORTANT: set lzma compression in ramdisk options, bootloader stalls when receiving uncompressed images. The device will load it in ram and boot it. You can reach it under the openwrt default ip address 192.168.1.1. Check if the key linux_fs_start is not set to 1 in tffs: $ fritz_tffs_nand -d /dev/mtd1 -n linux_fs_start If it is set to 1, the bootloader will select the wrong set of partitions. Restart the box and install an FritzOS upgrade or do a recovery. Afterwards start again at step 1. Run sysupgrade to persistently install OpenWRT. Signed-off-by: Valentin Spreckels <Valentin.Spreckels@Informatik.Uni-Oldenburg.de> Signed-off-by: Andy Binder <AndyBinder@gmx.de>
2019-01-25 01:00:25 +08:00
avm,fritz7412|\
lantiq: complete AVM FRITZ!Box 3370 support Rename the image and use a compatible string which indicates that only hardware revision 2 and higher is supported. It allows to use the wireless LED, as HWRev 1 uses GPIO#39 for the wireless LED and starting with HWRev 2 GPIO#35 is used for the wireless LED and GPIO#39 for IFX_GPIO_MODULE_EXTPHY_MDIO. The HWREV can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV HWSubRevision Within the same HW revision 5 of the Fritz!Box 3370 different NAND flash chips are used. Usually it isn't a big deal but depending on the used NAND flash chip, the ECC calculation is done different (and incompatible of course). Boards with a Micron MT29F1G08ABADA NAND flash chip are using the NAND chip to calculate the ECC (on-die). Boards with a Hynix HY27UF081G2M NAND flash chip are doing the ECC calculation in software. Supporting both with a single DTS isn't possible. It might be possible to add a patch selecting the ECC mode dynamicaly based on the found NAND flash chip. But such a patch has no chance to get accepted upstream and most likely need to be touched with every kernel update. Instead two images are created. One for Micron NAND flash chip and one for Hynix NAND flash chip. So far no pattern is known to identify the used flash chip without opening the box. Add the power off GPIO. At least EVA version 2186 sets/keeps the GPIO as input, which will cause a reboot 30sec after power on. For boards with EVA version 2186 the installation is tricky as it has to be finished within the 30sec time frame. The EVA version can be checked by connecting to the fritzbox right after power on via ftp: ftp> quote GETENV urlader-version The ath9k eeprom/caldata is at a different and offset and stored in reverse order (from the last byte to the beginning) on the flash. Reverse the bits to bring the data into the format expected by the ath9k driver. Since the ath9k eeprom is stored in reverse order on flash, we can not use the mac address from the on flash eeprom. Get the MAC address from the tffs instead. Within the same HW revision 5 of the Fritz!Box 3370 both version of the vr9 SoC are used. During preparation of kernel 4.14 support, all devicetree source files were changed to load the vr9 v1.1 and vr9 v1.2 gphy firmware, which fixed the embedded phys for boards using the version 1.2 of the vr9 SoC. While at it, add a trigger to make use of the LAN LED. Setup the build-in switch and add a hint for LuCI two show the ports in order matching the labels on the case Add support for the second USB port and provide the volatage GPIOs. Use GPIO#21 as PCIe reset pin. The lan led is connected to GPIO#38. Name the rootfs partition ubi and remove the mtd/rootfs related kernel bootargs to use the OpenWrt autoprobing based on the partition name. Enable sysupgrade support to allow an upgrade from a running system. Since sysupgrade wasn't supported till now, drop image build code which was added to allow a sysupgrade from earlier OpenWrt versions. Build images that allow an (initial) installation via EVA bootloader. To install OpenWrt via Eva bootloader, within the first seconds after power on a ftp connection need to be established to the FRITZ!Box at 192.168.178.1 and the the following ftp commands need to be run: ftp> quote USER adam2 ftp> quote PASS adam2 ftp> binary ftp> debug ftp> passive ftp> quote SETENV linux_fs_start 0 ftp> quote MEDIA FLSH ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-kernel.bin mtd1 ftp> put /path/to/openwrt-lantiq-xrx200-FRITZ3370-eva-filesystem.bin mtd0 Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
2017-06-10 01:28:36 +08:00
bt,homehub-v2b|\
bt,homehub-v3a|\
bt,homehub-v5a|\
zyxel,p-2812hnu-f1|\
zyxel,p-2812hnu-f3)
lantiq: add platform_pre_upgrade for sysupgrade As explained in recent sysupgrade/nand.sh commits, current NAND sysupgrade is a bit misleading because of nand_do_platform_check behavior. It leaves a special mark in /tmp/sysupgrade-nand-path triggering some diffent code path in nand_upgrade_stage1. The plan is to have the check function only check the image and nothing else. Then platform code (platform_pre_upgrade) should trigger NAND specific upgrade path. This is what this patch implements. Please note that because of current nand_upgrade_stage1 implementation this patch doesn't change any behaior yet. It only prepares lantiq target for changing nand_do_platform_check (it will be possible after preparing all other targets as well). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> SVN-Revision: 46939
2015-09-15 14:13:07 +08:00
nand_do_upgrade $1
;;
treewide: move nand_do_upgrade call to platform_do_upgrade Calling nand_do_upgrade() from platform_pre_upgrade() was deprecated with 30f61a34b4cf ("base-files: always use staged sysupgrade"). Update the platform upgrade code to use platform_do_upgrade() for NAND images as well. Signed-off-by: Mathias Kresin <dev@kresin.me>
2017-12-19 03:32:18 +08:00
*)
treewide: sysupgrade: don't use $ARGV in platform_do_upgrade() stage2 passes image path to platform_do_upgrade() as an argument so it can be simply accessed using $1 Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2019-07-15 01:03:19 +08:00
default_do_upgrade "$1"
treewide: move nand_do_upgrade call to platform_do_upgrade Calling nand_do_upgrade() from platform_pre_upgrade() was deprecated with 30f61a34b4cf ("base-files: always use staged sysupgrade"). Update the platform upgrade code to use platform_do_upgrade() for NAND images as well. Signed-off-by: Mathias Kresin <dev@kresin.me>
2017-12-19 03:32:18 +08:00
;;
lantiq: add platform_pre_upgrade for sysupgrade As explained in recent sysupgrade/nand.sh commits, current NAND sysupgrade is a bit misleading because of nand_do_platform_check behavior. It leaves a special mark in /tmp/sysupgrade-nand-path triggering some diffent code path in nand_upgrade_stage1. The plan is to have the check function only check the image and nothing else. Then platform code (platform_pre_upgrade) should trigger NAND specific upgrade path. This is what this patch implements. Please note that because of current nand_upgrade_stage1 implementation this patch doesn't change any behaior yet. It only prepares lantiq target for changing nand_do_platform_check (it will be possible after preparing all other targets as well). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> SVN-Revision: 46939
2015-09-15 14:13:07 +08:00
esac
}
Reference in New Issue Copy Permalink