2021-02-10 13:52:34 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
|
2020-09-13 07:06:13 +00:00
|
|
|
include $(TOPDIR)/rules.mk
|
|
|
|
|
include $(INCLUDE_DIR)/image.mk
|
|
|
|
|
|
2023-01-04 13:53:54 +00:00
|
|
|
KERNEL_LOADADDR = 0x80100000
|
2020-09-13 07:06:13 +00:00
|
|
|
|
2022-12-21 22:26:08 +00:00
|
|
|
DEVICE_VARS += \
|
2022-10-08 12:46:51 +00:00
|
|
|
CAMEO_BOARD_MODEL \
|
2022-12-21 22:26:08 +00:00
|
|
|
CAMEO_BOARD_VERSION \
|
|
|
|
|
CAMEO_CUSTOMER_SIGNATURE \
|
|
|
|
|
CAMEO_KERNEL_PART \
|
2022-10-07 16:07:17 +00:00
|
|
|
CAMEO_KERNEL_PART_SIZE \
|
2022-12-21 22:26:08 +00:00
|
|
|
CAMEO_ROOTFS_PART \
|
|
|
|
|
H3C_DEVICE_ID \
|
|
|
|
|
H3C_PRODUCT_ID \
|
|
|
|
|
ZYXEL_VERS
|
2021-03-22 19:58:16 +00:00
|
|
|
|
realtek: build ZyXEL vendor firmware compatible initramfs
Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.
The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the listed versions, and that the version number is
larger than a model specific minimum value. The minimum
version varies between V1.00 and V2.60 for the currently
known GS1900 models. The number is not used anywhere else
to our knowlege, and has no direct relation to the version
info in the u-image header. We can therefore use an
arbitrary value larger than V2.60.
The stock firmware upgrade application will only load and
flash the part of the file specified in the u-image header,
regardless of file size. It can therefore not be used to
flash images with an appended rootfs. There is therefore no
need to include the trailer in other images than the
initramfs. This prevents accidentally bricking by attempts
to flash other images from the stock web UI.
Stock images support all models in the series, listing
all of them in the version trailer. OpenWrt provide model
specific images. We therefore only list the single supported
hardware identifier for each image. This eliminates the risk
of flashing the wrong OpenWrt image from stock web UI.
OpenWrt can be installed from stock firmware in two steps:
1) flash OpenWrt initramfs image from stock web gui
2) boot OpenWrt and sysupgrade to a squasfs image
The OpenWrt squashfs image depends on a static partition
map in the DTS. It can only be installed to the "firmware"
partition. This partition is labeled "RUNTIME1" in u-boot
and in stock firmware, and is referred to as "image 0" in
the stock flash management tool. The OpenWrt initramfs
can be installed and run from either partitions. But if
you want to keep stock irmware in the spare system partition,
then you must make sure stock firmware is installed to the
"RUNTIME2" partition referred to as "image 1" in the stock
web UI. And the initial OpenWrt initramfs must be flashed
to "RUNTIME1"/"image 0".
The stock flash management application supports direct
selection of both which partition to flash and which
partition to boot next. This allows software controlled
"dual-boot" between OpenWrt and stock firmware, without
using console access to u-boot. u-boot use the "bootpartition"
variable stored in the second u-boot environment to select
which of the two system partitions to boot. This variable
is set by the stock flash management application, by direct
user input. It can also be set in OpenWrt using e.g
fw_setsys bootpartition 1
to select "RUNTIME2"/"image 1" as default, assuming a
stock firmware version is installed in that partition.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-23 10:08:12 +00:00
|
|
|
define Build/zyxel-vers
|
|
|
|
|
( echo VERS;\
|
2021-06-24 21:04:08 +00:00
|
|
|
for hw in $(ZYXEL_VERS); do\
|
realtek: build ZyXEL vendor firmware compatible initramfs
Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.
The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the listed versions, and that the version number is
larger than a model specific minimum value. The minimum
version varies between V1.00 and V2.60 for the currently
known GS1900 models. The number is not used anywhere else
to our knowlege, and has no direct relation to the version
info in the u-image header. We can therefore use an
arbitrary value larger than V2.60.
The stock firmware upgrade application will only load and
flash the part of the file specified in the u-image header,
regardless of file size. It can therefore not be used to
flash images with an appended rootfs. There is therefore no
need to include the trailer in other images than the
initramfs. This prevents accidentally bricking by attempts
to flash other images from the stock web UI.
Stock images support all models in the series, listing
all of them in the version trailer. OpenWrt provide model
specific images. We therefore only list the single supported
hardware identifier for each image. This eliminates the risk
of flashing the wrong OpenWrt image from stock web UI.
OpenWrt can be installed from stock firmware in two steps:
1) flash OpenWrt initramfs image from stock web gui
2) boot OpenWrt and sysupgrade to a squasfs image
The OpenWrt squashfs image depends on a static partition
map in the DTS. It can only be installed to the "firmware"
partition. This partition is labeled "RUNTIME1" in u-boot
and in stock firmware, and is referred to as "image 0" in
the stock flash management tool. The OpenWrt initramfs
can be installed and run from either partitions. But if
you want to keep stock irmware in the spare system partition,
then you must make sure stock firmware is installed to the
"RUNTIME2" partition referred to as "image 1" in the stock
web UI. And the initial OpenWrt initramfs must be flashed
to "RUNTIME1"/"image 0".
The stock flash management application supports direct
selection of both which partition to flash and which
partition to boot next. This allows software controlled
"dual-boot" between OpenWrt and stock firmware, without
using console access to u-boot. u-boot use the "bootpartition"
variable stored in the second u-boot environment to select
which of the two system partitions to boot. This variable
is set by the stock flash management application, by direct
user input. It can also be set in OpenWrt using e.g
fw_setsys bootpartition 1
to select "RUNTIME2"/"image 1" as default, assuming a
stock firmware version is installed in that partition.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-23 10:08:12 +00:00
|
|
|
echo -n "V9.99($$hw.0) | ";\
|
|
|
|
|
date -d @$(SOURCE_DATE_EPOCH) +%m/%d/%Y;\
|
|
|
|
|
done ) >> $@
|
|
|
|
|
endef
|
|
|
|
|
|
2022-10-07 16:07:17 +00:00
|
|
|
define Build/cameo-tag
|
|
|
|
|
$(SCRIPT_DIR)/cameo-tag.py $@ $(CAMEO_KERNEL_PART_SIZE)
|
2022-07-05 06:46:59 +00:00
|
|
|
endef
|
|
|
|
|
|
2022-10-07 16:07:17 +00:00
|
|
|
define Build/cameo-version
|
2022-07-06 11:43:23 +00:00
|
|
|
echo -n "OpenWrt" >> $@
|
|
|
|
|
dd if=/dev/zero bs=25 count=1 >> $@
|
|
|
|
|
endef
|
|
|
|
|
|
2022-10-07 16:07:17 +00:00
|
|
|
define Build/cameo-headers
|
|
|
|
|
dd if=$@ bs=$(CAMEO_KERNEL_PART_SIZE) count=1 of=$@.kernel_part; \
|
|
|
|
|
dd if=$@ bs=$(CAMEO_KERNEL_PART_SIZE) skip=1 of=$@.rootfs_part; \
|
realtek: add DGS-1210-28 factory image
DGS-1210 switches support dual image, with each image composed of a
kernel and a rootfs partition. For image1, kernel and rootfs are in
sequence. The current OpenWrt image (written using a serial console),
uses those partitions together as the firmware partition, ignoring the
partition division. The current OEM u-boot fails to validate image1 but
it will only trigger firmware recovery if both image1 and image2 fail,
and it does not switch the boot image in case one of them fails the
check.
The OEM factory image is composed of concatenated blocks of data, each
one prefixed with a 0x40-byte cameo header. A normal OEM firmware will
have two of these blocks (kernel, rootfs). The OEM firmware only checks
the header before writing unconditionally the data (except the header)
to the correspoding partition.
The OpenWrt factory image mimics the OEM image by cutting the
kernel+rootfs firmware at the exact size of the OEM kernel partition
and packing it as "the kernel partition" and the rest of the kernel and
the rootfs as "the rootfs partition". It will only work if written to
image1 because image2 has a sysinfo partition between kernel2 and
rootfs2, cutting the kernel code in the middle.
Steps to install:
1) switch to image2 (containing an OEM image), using web or these CLI
commands:
- config firmware image_id 2 boot_up
- reboot
2) flash the factory_image1.bin to image1. OEM web (v6.30.016)
is crashing for any upload (ssh keys, firmware), even applying OEM
firmwares. These CLI commands can upload a new firmware to the other
image location (not used to boot):
- download firmware_fromTFTP <tftpserver> factory_image1.bin
- config firmware image_id 1 boot_up
- reboot
To debrick the device, you'll need serial access. If you want to
recover to an OpenWrt, you can replay the serial installation
instructions. For returning to the original firmware, press ESC during
the boot to trigger the emergency firmware recovery procedure. After
that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware.
The device documentation does describe that holding RESET for 12s
trigger the firmware recovery. However, the latest shipped U-Boot
"2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot
trigger that from a cold boot. In fact, any U-Boot procedure that relies
on the RESET button, like reset settings, will only work if started from
a running original firmware. That, in practice, cancels the benefit of
having two images and a firmware recovery procedure (if you are not
consider dual-booting OpenWrt).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
2022-06-23 20:50:03 +00:00
|
|
|
$(SCRIPT_DIR)/cameo-imghdr.py $@.kernel_part $@.kernel_part.hex \
|
2022-10-08 12:46:51 +00:00
|
|
|
"$(CAMEO_BOARD_MODEL)" os $(CAMEO_KERNEL_PART) \
|
realtek: add DGS-1210-28 factory image
DGS-1210 switches support dual image, with each image composed of a
kernel and a rootfs partition. For image1, kernel and rootfs are in
sequence. The current OpenWrt image (written using a serial console),
uses those partitions together as the firmware partition, ignoring the
partition division. The current OEM u-boot fails to validate image1 but
it will only trigger firmware recovery if both image1 and image2 fail,
and it does not switch the boot image in case one of them fails the
check.
The OEM factory image is composed of concatenated blocks of data, each
one prefixed with a 0x40-byte cameo header. A normal OEM firmware will
have two of these blocks (kernel, rootfs). The OEM firmware only checks
the header before writing unconditionally the data (except the header)
to the correspoding partition.
The OpenWrt factory image mimics the OEM image by cutting the
kernel+rootfs firmware at the exact size of the OEM kernel partition
and packing it as "the kernel partition" and the rest of the kernel and
the rootfs as "the rootfs partition". It will only work if written to
image1 because image2 has a sysinfo partition between kernel2 and
rootfs2, cutting the kernel code in the middle.
Steps to install:
1) switch to image2 (containing an OEM image), using web or these CLI
commands:
- config firmware image_id 2 boot_up
- reboot
2) flash the factory_image1.bin to image1. OEM web (v6.30.016)
is crashing for any upload (ssh keys, firmware), even applying OEM
firmwares. These CLI commands can upload a new firmware to the other
image location (not used to boot):
- download firmware_fromTFTP <tftpserver> factory_image1.bin
- config firmware image_id 1 boot_up
- reboot
To debrick the device, you'll need serial access. If you want to
recover to an OpenWrt, you can replay the serial installation
instructions. For returning to the original firmware, press ESC during
the boot to trigger the emergency firmware recovery procedure. After
that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware.
The device documentation does describe that holding RESET for 12s
trigger the firmware recovery. However, the latest shipped U-Boot
"2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot
trigger that from a cold boot. In fact, any U-Boot procedure that relies
on the RESET button, like reset settings, will only work if started from
a running original firmware. That, in practice, cancels the benefit of
having two images and a firmware recovery procedure (if you are not
consider dual-booting OpenWrt).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
2022-06-23 20:50:03 +00:00
|
|
|
$(CAMEO_CUSTOMER_SIGNATURE) \
|
|
|
|
|
$(CAMEO_BOARD_VERSION) \
|
|
|
|
|
$(KERNEL_LOADADDR); \
|
|
|
|
|
$(SCRIPT_DIR)/cameo-imghdr.py $@.rootfs_part $@.rootfs_part.hex \
|
2022-10-08 12:46:51 +00:00
|
|
|
"$(CAMEO_BOARD_MODEL)" squashfs $(CAMEO_ROOTFS_PART) \
|
realtek: add DGS-1210-28 factory image
DGS-1210 switches support dual image, with each image composed of a
kernel and a rootfs partition. For image1, kernel and rootfs are in
sequence. The current OpenWrt image (written using a serial console),
uses those partitions together as the firmware partition, ignoring the
partition division. The current OEM u-boot fails to validate image1 but
it will only trigger firmware recovery if both image1 and image2 fail,
and it does not switch the boot image in case one of them fails the
check.
The OEM factory image is composed of concatenated blocks of data, each
one prefixed with a 0x40-byte cameo header. A normal OEM firmware will
have two of these blocks (kernel, rootfs). The OEM firmware only checks
the header before writing unconditionally the data (except the header)
to the correspoding partition.
The OpenWrt factory image mimics the OEM image by cutting the
kernel+rootfs firmware at the exact size of the OEM kernel partition
and packing it as "the kernel partition" and the rest of the kernel and
the rootfs as "the rootfs partition". It will only work if written to
image1 because image2 has a sysinfo partition between kernel2 and
rootfs2, cutting the kernel code in the middle.
Steps to install:
1) switch to image2 (containing an OEM image), using web or these CLI
commands:
- config firmware image_id 2 boot_up
- reboot
2) flash the factory_image1.bin to image1. OEM web (v6.30.016)
is crashing for any upload (ssh keys, firmware), even applying OEM
firmwares. These CLI commands can upload a new firmware to the other
image location (not used to boot):
- download firmware_fromTFTP <tftpserver> factory_image1.bin
- config firmware image_id 1 boot_up
- reboot
To debrick the device, you'll need serial access. If you want to
recover to an OpenWrt, you can replay the serial installation
instructions. For returning to the original firmware, press ESC during
the boot to trigger the emergency firmware recovery procedure. After
that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware.
The device documentation does describe that holding RESET for 12s
trigger the firmware recovery. However, the latest shipped U-Boot
"2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot
trigger that from a cold boot. In fact, any U-Boot procedure that relies
on the RESET button, like reset settings, will only work if started from
a running original firmware. That, in practice, cancels the benefit of
having two images and a firmware recovery procedure (if you are not
consider dual-booting OpenWrt).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
2022-06-23 20:50:03 +00:00
|
|
|
$(CAMEO_CUSTOMER_SIGNATURE) \
|
|
|
|
|
$(CAMEO_BOARD_VERSION); \
|
|
|
|
|
cat $@.kernel_part.hex $@.rootfs_part.hex > $@
|
|
|
|
|
endef
|
|
|
|
|
|
2022-07-28 14:45:03 +00:00
|
|
|
define Build/7z
|
|
|
|
|
$(STAGING_DIR_HOST)/bin/7zr a $(@).new -t7z -m0=lzma $(@)
|
|
|
|
|
mv $@.new $@
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define Build/h3c-image
|
|
|
|
|
$(STAGING_DIR_HOST)/bin/mkh3cimg \
|
|
|
|
|
-i $(@) \
|
|
|
|
|
-o $(@).new \
|
|
|
|
|
-c 7z \
|
|
|
|
|
-p $(H3C_PRODUCT_ID) \
|
|
|
|
|
-d $(H3C_DEVICE_ID)
|
|
|
|
|
mv $@.new $@
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define Build/h3c-vfs
|
|
|
|
|
$(STAGING_DIR_HOST)/bin/mkh3cvfs \
|
|
|
|
|
-i $(@) \
|
|
|
|
|
-o $(@).new \
|
|
|
|
|
-f openwrt-kernel.bin
|
|
|
|
|
mv $@.new $@
|
|
|
|
|
endef
|
|
|
|
|
|
2020-09-13 07:06:13 +00:00
|
|
|
define Device/Default
|
|
|
|
|
PROFILES = Default
|
2022-12-21 22:26:08 +00:00
|
|
|
KERNEL := \
|
|
|
|
|
kernel-bin | \
|
|
|
|
|
append-dtb | \
|
2022-12-14 14:16:33 +00:00
|
|
|
libdeflate-gzip | \
|
2022-12-21 22:26:08 +00:00
|
|
|
uImage gzip
|
|
|
|
|
KERNEL_INITRAMFS := \
|
|
|
|
|
kernel-bin | \
|
|
|
|
|
append-dtb | \
|
2022-12-14 14:16:33 +00:00
|
|
|
libdeflate-gzip | \
|
2022-12-21 22:26:08 +00:00
|
|
|
uImage gzip
|
2024-09-01 18:36:38 +00:00
|
|
|
DEVICE_DTS_DIR := ../dts
|
2020-09-13 07:06:13 +00:00
|
|
|
DEVICE_DTS = $$(SOC)_$(1)
|
|
|
|
|
IMAGES := sysupgrade.bin
|
2022-12-21 22:26:08 +00:00
|
|
|
IMAGE/sysupgrade.bin := \
|
|
|
|
|
append-kernel | \
|
2022-12-28 20:46:48 +00:00
|
|
|
pad-to 64k | \
|
2022-12-21 22:26:08 +00:00
|
|
|
append-rootfs | \
|
|
|
|
|
pad-rootfs | \
|
2022-12-28 20:46:48 +00:00
|
|
|
check-size | \
|
|
|
|
|
append-metadata
|
2020-09-13 07:06:13 +00:00
|
|
|
endef
|
|
|
|
|
|
2021-12-29 18:39:26 +00:00
|
|
|
include $(SUBTARGET).mk
|
realtek: add ZyXEL GS1900-24HPv2 support
The ZyXEL GS1900-24HPv2 is a 24 port PoE switch with two SFP ports, similar to the other GS1900 switches.
Specifications
--------------
* Device: ZyXEL GS1900-24HPv2
* SoC: Realtek RTL8382M 500 MHz MIPS 4KEc
* Flash: 16 MiB
* RAM: W631GG8MB-12 128 MiB DDR3 SDRAM
(stock firmware is configured to use only 64 MiB)
* Ethernet: 24x 10/100/1000 Mbps, 2x SFP 100/1000 Mbps
* LEDs: 1 PWR LED (green, not configurable)
1 SYS LED (green, configurable)
24 ethernet port link/activity LEDs (green, SoC controlled)
24 ethernet port PoE status LEDs
2 SFP status/activity LEDs (green, SoC controlled)
* Buttons: 1 "RESTORE" button on front panel
1 "RESET" button on front panel
* Power 120-240V AC C13
* UART: 1 serial header (J41) with populated standard pin connector on
the left edge of the PCB, angled towards the side.
The casing has a rectangular cutout on the side that provides
external access to these pins.
Pinout (front to back):
+ GND
+ TX
+ RX
+ VCC
Serial connection parameters for both devices: 115200 8N1.
Installation
------------
OEM upgrade method:
(Possible on master once https://patchwork.ozlabs.org/project/openwrt/patch/20210624210408.19248-1-bjorn@mork.no/ is merged)
* Log in to OEM management web interface
* Navigate to Maintenance > Firmware > Management
* If "Active Image" has the first option selected, OpenWrt will need to be
flashed to the "Active" partition. If the second option is selected,
OpenWrt will need to be flashed to the "Backup" partition.
* Navigate to Maintenance > Firmware > Upload
* Upload the openwrt-realtek-generic-zyxel_gs1900-24hp-v2-initramfs-kernel.bin
file by your preferred method to the previously determined partition.
When prompted, select to boot from the newly flashed image, and reboot the switch.
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
> sysupgrade -n /tmp/openwrt-realtek-generic-zyxel_gs1900-24hp-v2-squashfs-sysupgrade.bin
it may be necessary to restart the network (/etc/init.d/network restart) on
the running initramfs image.
U-Boot TFTP method:
* Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10).
* Set up a TFTP server on your client and make it serve the initramfs image.
* Connect serial, power up the switch, interrupt U-boot by hitting the
space bar, and enable the network:
> rtk network on
* Since the GS1900-24HPv2 is a dual-partition device, you want to keep the OEM
firmware on the backup partition for the time being. OpenWrt can only boot
from the first partition anyway (hardcoded in the DTS). To make sure we are
manipulating the first partition, issue the following commands:
> setsys bootpartition 0
> savesys
* Download the image onto the device and boot from it:
> tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-24hp-v2-initramfs-kernel.bin
> bootm
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
> sysupgrade -n /tmp/openwrt-realtek-generic-zyxel_gs1900-24hp-v2-squashfs-sysupgrade.bin
it may be necessary to restart the network (/etc/init.d/network restart) on
the running initramfs image.
Signed-off-by: Soma Zambelly <zambelly.soma@gmail.com>
2021-08-24 21:46:08 +00:00
|
|
|
|
2020-09-13 07:06:13 +00:00
|
|
|
$(eval $(call BuildImage))
|
