Do not put the apex images into the kernel build directory as this directory
might get removed after kernel updates while the apex packages InstallDev
recipe is not getting re-executed because it is still considered current,
leading to image build failures later on due to missing images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Do not put the u-boot images into the kernel build directory as this directory
might get removed after kernel updates while the u-boot packages InstallDev
recipe is not getting re-executed because it is still considered current,
leading to image build failures later on due to missing images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Do not put the u-boot images into the kernel build directory as this directory
might get removed after kernel updates while the u-boot packages InstallDev
recipe is not getting re-executed because it is still considered current,
leading to image build failures later on due to missing images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Do not put the u-boot images into the kernel build directory as this directory
might get removed after kernel updates while the u-boot packages InstallDev
recipe is not getting re-executed because it is still considered current,
leading to image build failures later on due to missing images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Do not put the u-boot and ucode images into the kernel build directory as this
directory might get removed after kernel updates while the u-boot packages
InstallDev recipe is not getting re-executed because it is still considered
current, leading to image build failures later on due to missing images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Do not put the u-boot images into the kernel build directory as this directory
might get removed after kernel updates while the u-boot packages InstallDev
recipe is not getting re-executed because it is still considered current,
leading to image build failures later on due to missing u-boot images.
To ensure that built bootloader images persist over kernel version updates in
the buildroot, put them into the new STAGING_DIR_IMAGE directory.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Bump kernel to 4.4.44. Compile-tested on ar71xx, ramips/mt7621 and x86/64.
.44 has been run-tested on the 17.01 branch here on ar71xx and mt7621.
Signed-off-by: Stijn Segers <francesco.borromini@inventati.org>
The following changes enables GPIO sysfs as well as the LEDS_GPIO option
within the kernel. This is required to enable LEDs over a GPIO
interface.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
The GPL licensed source code of Belkin contains an ASIC based "Green
Feature". This change adds support for this Green Feature that can be
activated with an DTS option or swconfig.
Signed-off-by: Tobias Wolf <github-NTEO@vplace.de>
Before this change only port 4 of F5D8235 V1 worked at 1000Mpbs.
Comparing the current driver with the GPL_BELKIN_F5D8235-4_v1000
v1.01.24 sources showed that additional steps are required to set-up
the rlt8366s switch correctly.
Signed-off-by: Tobias Wolf <github-NTEO@vplace.de>
This change provides the possibility to define per-device initvals in
the DTS file for a rlt8366s switch.
Signed-off-by: Tobias Wolf <github-NTEO@vplace.de>
ramips/rt288x WLI-TX4-AG300N was missing support for its 100Mbit switch which
should be included by default.
Signed-off-by: Yo Abe <abe.geel@gmail.com>
[Jo-Philipp Wich: picked from OpenWrt PR#359, rewrap commit msg, fix Sob]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
On some EX2700 devices, the MAC address from the eeprom data differs
from the actual MAC address. Fix that, and cleanup the DTS file
while we're at it.
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
This commit adds 4 patches, one per kernel version that was used for
picking updates. This adds support for few new PHYs.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
TP-Link Archer C59v1 is a dual-band AC1350 router, based on Qualcomm/Atheros
QCA9561+QCA9886.
Specification:
- 775/650/258 MHz (CPU/DDR/AHB)
- 128 MB of RAM (DDR2)
- 16 MB of FLASH (SPI NOR)
- 3T3R 2.4 GHz
- 2T2R 5 GHz
- 5x 10/100 Mbps Ethernet
- USB 2.0 port
- 8x LED (controled by 74HC595), 3x button
- UART header on PCB
TP-Link Archer C60v1 is a dual-band AC1350 router, based on Qualcomm/Atheros
QCA9561+QCA9886.
Specification:
- 775/650/258 MHz (CPU/DDR/AHB)
- 64 MB of RAM (DDR2)
- 8 MB of FLASH (SPI NOR)
- 3T3R 2.4 GHz
- 2T2R 5 GHz
- 5x 10/100 Mbps Ethernet
- 7x LED, 2x button
- UART header on PCB
Currently not working:
- Port LAN1 on C59, LAN4 on C60
- WiFi 5GHz (missing ath10k firmware for QCA9886 chip)
- Update from oficial web interface ( tplink-saveloader not support "product-info")
Flash instruction:
1. Set PC to fixed ip address 192.168.0.66
2. Download lede-ar71xx-generic-archer-cXX-v1-squashfs-factory.bin
and rename it to tp_recovery.bin
3. Start a tftp server with the file tp_recovery.bin in its root directory
4. Turn off the router
5. Press and hold Reset button
6. Turn on router with the reset button pressed and wait ~15 seconds
7. Release the reset button and after a short time
the firmware should be transferred from the tftp server
8. Wait ~30 second to complete recovery.
Flash instruction under U-Boot, using UART:
1. tftp 0x81000000 lede-ar71xx-...-sysupgrade.bin
2. erase 0x9f020000 +$filesize
3. cp.b $fileaddr 0x9f020000 $filesize
4. reset
Signed-off-by: Henryk Heisig <hyniu@o2.pl>
[Jo-Philipp Wich: remove duplicate ATH79_MACH_ARCHER_C59/C60_V1 entries]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This device has 2 TRX partitions (main one and failsafe one) and Linux
may not detect them properly failing to run userspace.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Even when the disk uses 4k blocks, the partition table still uses units
of 512 byte sectors. Always use ibs=512 for the offsets
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The ZyXEL NSA310 device is a Kirkwood based NAS:
- SoC: Marvell 88F6702 1200Mhz
- SDRAM memory: 256MB DDR2 400Mhz
- Gigabit ethernet: Realtek (over pcie)
- Flash memory: 128MB
- 1 Power button
- 1 Power LED (blue)
- 5 Status LED (green/red)
- 1 Copy/Sync button
- 1 Reset button
- 2 SATA II port (1 internal and 1 external)
- 2 USB 2.0 ports (1 front and 1 back)
- Smart fan
The stock u-boot cannot read ubi so it should be replaced with the
LEDE/OpenWRT's u-boot or with a u-boot from here
https://github.com/mibodhi/u-boot-kirkwood
This device's boot ROM supports "kwboot" tool
(in mainline u-boot, built automatically if CONFIG_KIRKWOOD is declared)
that sends an uboot image to the board over serial connection, it is very easy to unbrick.
The stock bootloader can use usb and read from FAT filesystems,
so the installation process is simple, place the uboot file on a USB flashdrive
formatted as FAT (here it is "openwrt-kirkwood-nsa310.bin", then connect TTL
to the board and write the following commands in the bootloader console:
usb reset
fatload usb 0 0x1000000 openwrt-kirkwood-nsa310.bin
nand write 0x1000000 0x00000 0x100000
reset
Now you are rebooting in the new u-boot, write this in its console to install the firmware:
usb reset
fatload usb 0 0x2000000 lede-kirkwood-nsa310b-squashfs-factory.bin
nand erase.part ubi
nand write 0x2000000 ubi 0x600000
If your firmware file is bigger than 6 MiBs you should write its size in hex
instead of 0x600000 above, or remove that number entirely (it will take a while in this case).
If you are using another uboot that can read ubi, set mtdparts like this
mtdparts=mtdparts=orion_nand:0x00c0000(uboot),0x80000(uboot_env),0x7ec0000(ubi)
And set your bootcmd to be like this
bootcmd=run setenv bootargs; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000
Then you can install the firmware as described above.
After you installed (or configured) the u-boot for booting the firmware,
write the device's mac address in the ethaddr u-boot env.
The MAC address is usually on a sticker under the device (one of the two codes is the serial),
it should begin with "107BEF" as it is assigned to ZyXEL.
write in the u-boot console (use your MAC address instead of the example)
setenv ethaddr 10:7B:EF:00:00:00
saveenv
to save the mac address in the u-boot.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
Instead of referencing u-boot packages from device profiles and having a
-all metapackage, make the u-boot packages hidden (they don't install to
bin/ anyway), and name the files in KERNEL_BUILD_DIR appropriately
Signed-off-by: Felix Fietkau <nbd@nbd.name>
According to some reports, -march=pentium-mmx is a better choice for
older Geode CPUs than -march=geode anyway.
Bump the minimum architecture of the legacy target from i486 to
pentium-mmx. Anything older is not worth supporting anyway.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The le64 and be64 subtargets do not share a package architecture with
any other targets, so they are pretty wasteful for a development-only
target.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
While rt288x only has a MIPS 4KEc processor, it implements the MIPS32r2
architecture just like the 24Kc, so the instruction set should be 100%
compatible.
Switching it to 24kc allows it to share the package architecture with a
lot of other targets instead of creating a special case, saving
buildbot resources.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
