<feed xmlns='http://www.w3.org/2005/Atom'>
<title>staging/hauke/package/boot, branch v21.02.2</title>
<subtitle>Hauke Mehrtens staging tree</subtitle>
<id>https://git.openwrt.org/openwrt/staging/hauke/atom?h=v21.02.2</id>
<link rel='self' href='https://git.openwrt.org/openwrt/staging/hauke/atom?h=v21.02.2'/>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/'/>
<updated>2022-01-03T13:28:13Z</updated>
<entry>
<title>arm-trusted-firmware-bcm63xx: add ATF for Broadcom devices</title>
<updated>2022-01-03T13:28:13Z</updated>
<author>
<name>Rafał Miłecki</name>
</author>
<published>2021-12-17T10:40:54Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=18b10db2f1945e9af4fcd5476fef808c15623cc5'/>
<id>urn:sha1:18b10db2f1945e9af4fcd5476fef808c15623cc5</id>
<content type='text'>
Right now it includes bcm4908 variant only that is required by BCM4908
family devices with U-Boot.

Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
(cherry picked from commit f18288e26715f8cdef6c6d62a196dfd4ade8265e)
</content>
</entry>
<entry>
<title>uboot-lantiq: danube: fix hanging lzma kernel uncompression #2</title>
<updated>2021-11-27T22:00:31Z</updated>
<author>
<name>Mathias Kresin</name>
</author>
<published>2021-11-27T20:43:40Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=36848e2c29ef7be477db875491fd96f2efa08645'/>
<id>urn:sha1:36848e2c29ef7be477db875491fd96f2efa08645</id>
<content type='text'>
Follow up to commit c744798cad6a13436f2ba9dd3a280cb16d315c85. Managed to
hit the very same issue again while playing with the NOR SPL builds.

Signed-off-by: Mathias Kresin &lt;dev@kresin.me&gt;
</content>
</entry>
<entry>
<title>uboot-lantiq: danube: fix hanging lzma kernel uncompression</title>
<updated>2021-11-14T19:24:45Z</updated>
<author>
<name>Mathias Kresin</name>
</author>
<published>2021-11-05T09:41:26Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=c744798cad6a13436f2ba9dd3a280cb16d315c85'/>
<id>urn:sha1:c744798cad6a13436f2ba9dd3a280cb16d315c85</id>
<content type='text'>
At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
assembly of LzmaProps_Decode. While the decission made by the compiler
looks perfect fine, it triggers some obscure hang on lantiq danube-s
v1.5 with MX29LV640EB NOR flash chips.

Only if the offset 1 is used, the hang can be observed. Using any other
offset works fine:

  lwl s0,0(a1) - s0 == 0x6d000080
  lwl s0,1(a1) - hangs
  lwl s0,2(a1) - s0 == 0x0080xxxx
  lwl s0,3(a1) - s0 == 0x80xxxxxx

It isn't clear whether it is a limitation of the flash chip, the EBU or
something else.

Force 8bit reads to prevent gcc optimizing the read with lwr/lwl
instructions.

Signed-off-by: Mathias Kresin &lt;dev@kresin.me&gt;
</content>
</entry>
<entry>
<title>uboot-lantiq: fix sha1.h header clash when system libmd installed</title>
<updated>2021-10-02T15:41:59Z</updated>
<author>
<name>Alan Swanson</name>
</author>
<published>2021-10-01T15:46:32Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=76d90a5eaf3b7fc5bb1a1b8626db0e4e2487e876'/>
<id>urn:sha1:76d90a5eaf3b7fc5bb1a1b8626db0e4e2487e876</id>
<content type='text'>
Backport of u-boot commit "includes: move openssl headers to include/u-boot"
https://github.com/u-boot/u-boot/commit/2b9912e6a7df7b1f60beb7942bd0e6fa5f9d0167

Fixes: FS#3955
Signed-off-by: Alan Swanson &lt;reiver@improbability.net&gt;
(cherry picked from commit 8db641049292035604f0e1fb788608fdea879eca)
</content>
</entry>
<entry>
<title>uboot-layerscape: fix dtc compilation on host gcc 10</title>
<updated>2021-08-28T13:48:08Z</updated>
<author>
<name>Hauke Mehrtens</name>
</author>
<published>2021-08-08T22:03:43Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=f78017006b6ad1f91d411eb003870bfc33a895e0'/>
<id>urn:sha1:f78017006b6ad1f91d411eb003870bfc33a895e0</id>
<content type='text'>
Backport a patch from upstream U-Boot to fix the compile with host GCC 10.

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
(cherry picked from commit 8d143784cb8fafccdbcdc0bd5d1aa47d3d676f70)
</content>
</entry>
<entry>
<title>uboot-at91: fix dtc compilation on host gcc 10</title>
<updated>2021-08-28T13:48:08Z</updated>
<author>
<name>Hauke Mehrtens</name>
</author>
<published>2021-08-20T22:07:54Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=8f039acee462bdda6928b98b2838b99e4723bb29'/>
<id>urn:sha1:8f039acee462bdda6928b98b2838b99e4723bb29</id>
<content type='text'>
Backport a patch from upstream U-Boot to fix the compile with host GCC 10.

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
(cherry picked from commit a1034afba8ea8bec48e2528fdae0fb74a6757e53)
</content>
</entry>
<entry>
<title>ramips: add support for Linksys EA8100 v1</title>
<updated>2021-06-10T15:09:35Z</updated>
<author>
<name>Tee Hao Wei</name>
</author>
<published>2021-05-17T19:46:36Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=97df795b78dc572ea2ec105ccbf8af27cc4b4d8e'/>
<id>urn:sha1:97df795b78dc572ea2ec105ccbf8af27cc4b4d8e</id>
<content type='text'>
Specifications:
- SoC: MT7621AT
- RAM: 256MB
- Flash: 128MB NAND
- Ethernet: 5 Gigabit ports
- WiFi: 2.4G/5G MT7615N
- USB: 1 USB 3.0, 1 USB 2.0

This device is very similar to the EA7300 v1/v2 and EA7500 v2.

Installation:

Upload the generated factory image through the factory web interface.

(following part taken from EA7300 v2 commit message:)

This might fail due to the A/B nature of this device. When flashing, OEM
firmware writes over the non-booted partition. If booted from 'A',
flashing over 'B' won't work. To get around this, you should flash the
OEM image over itself. This will then boot the router from 'B' and
allow you to flash OpenWRT without problems.

Reverting to factory firmware:

Hard-reset the router three times to force it to boot from 'B.' This is
where the stock firmware resides. To remove any traces of OpenWRT from
your router simply flash the OEM image at this point.

With thanks to Leon Poon (@LeonPoon) for the initial bringup.

Signed-off-by: Tee Hao Wei &lt;angelsl@in04.sg&gt;
[add missing entry in 10_fix_wifi_mac]
Signed-off-by: Adrian Schmutzler &lt;freifunk@adrianschmutzler.de&gt;
(cherry picked from commit b232680f847f4ea8d058849a51dedebb8e398a01)
</content>
</entry>
<entry>
<title>ramips: add support for Amped Wireless ALLY router and extender</title>
<updated>2021-06-10T15:09:35Z</updated>
<author>
<name>Jonathan Sturges</name>
</author>
<published>2021-06-05T12:17:42Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=5e6837cf8fa4366fa44f902303b981c15570557e'/>
<id>urn:sha1:5e6837cf8fa4366fa44f902303b981c15570557e</id>
<content type='text'>
Amped Wireless ALLY is a whole-home WiFi kit, with a router (model
ALLY-R1900K) and an Extender (model ALLY-00X19K).  Both are devices are
11ac and based on MediaTek MT7621AT and MT7615N chips.  The units are
nearly identical, except the Extender lacks a USB port and has a single
Ethernet port.

Specification:
- SoC: MediaTek MT7621AT (2C/4T) @ 880MHz
- RAM: 128MB DDR3 (Nanya NT5CC64M16GP-DI)
- FLASH: 128MB NAND (Winbond W29N01GVSIAA)
- WiFi: 2.4/5 GHz 4T4R
  - 2.4GHz MediaTek MT7615N bgn
  - 5GHz MediaTek MT7615N nac
- Switch: SoC integrated Gigabit Switch
- USB: 1x USB3 (Router only)
- BTN: Reset, WPS
- LED: single RGB
- UART:  through-hole on PCB.
   J1: pin1 (square pad, towards rear)=3.3V, pin2=RX,
   pin3=GND, pin4=TX.  Settings: 57600/8N1.

Note regarding dual system partitions
-------------------------------------

The vendor firmware and boot loader use a dual partition scheme.  The boot
partition is decided by the bootImage U-boot environment variable: 0 for
the 1st partition, 1 for the 2nd.

OpenWrt does not support this scheme and will always use the first OS
partition.  It will set bootImage to 0 during installation, making sure
the first partition is selected by the boot loader.

Also, because we can't be sure which partition is active to begin with, a
2-step flash process is used.  We first flash an initramfs image, then
follow with a regular sysupgrade.

Installation:

Router (ALLY-R1900K)
1) Install the flashable initramfs image via the OEM web-interface.
  (Alternatively, you can use the TFTP recovery method below.)
  You can use WiFi or Ethernet.
  The direct URL is:  http://192.168.3.1/07_06_00_firmware.html
  a. No login is needed, and you'll be in their setup wizard.
  b. You might get a warning about not being connected to the Internet.
  c. Towards the bottom of the page will be a section entitled "Or
  Manually Upgrade Firmware from a File:" where you can manually choose
  and upload a firmware file.
  d: Click "Choose File", select the OpenWRT "initramfs" image and click
  "Upload."
2) The Router will flash the OpenWrt initramfs image and reboot.  After
  booting, LuCI will be available on 192.168.1.1.
3) Log into LuCI as root; there is no password.
4) Optional (but recommended) is to backup the OEM firmware before
  continuing; see process below.
5) Complete the Installation by flashing a full OpenWRT image.  Note:
  you may use the sysupgrade command line tool in lieu of the UI if
  you prefer.
  a.  Choose System -&gt; Backup/Flash Firmware.
  b.  Click "Flash Image..." under "Flash new firmware image"
  c.  Click "Browse..." and then select the sysupgrade file.
  d.  Click Upload to upload the sysupgrade file.
  e.  Important:  uncheck "Keep settings and retain the current
      configuration" for this initial installation.
  f.  Click "Continue" to flash the firmware.
  g.  The device will reboot and OpenWRT is installed.

Extender (ALLY-00X19K)
1) This device requires a TFTP recovery procedure to do an initial load
  of OpenWRT.  Start by configuring a computer as a TFTP client:
  a. Install a TFTP client (server not necessary)
  b. Configure an Ethernet interface to 192.168.1.x/24; don't use .1 or .6
  c. Connect the Ethernet to the sole Ethernet port on the X19K.
2) Put the ALLY Extender in TFTP recovery mode.
  a. Do this by pressing and holding the reset button on the bottom while
  connecting the power.
  b. As soon as the LED lights up green (roughly 2-3 seconds), release
  the button.
3) Start the TFTP transfer of the Initramfs image from your setup machine.
For example, from Linux:
tftp -v -m binary 192.168.1.6 69 -c put initramfs.bin
4) The Extender will flash the OpenWrt initramfs image and reboot.  After
booting, LuCI will be available on 192.168.1.1.
5) Log into LuCI as root; there is no password.
6) Optional (but recommended) is to backup the OEM firmware before
  continuing; see process below.
7) Complete the Installation by flashing a full OpenWRT image.  Note: you
may use the sysupgrade command line tool in lieu of the UI if you prefer.
  a.  Choose System -&gt; Backup/Flash Firmware.
  b.  Click "Flash Image..." under "Flash new firmware image"
  c.  Click "Browse..." and then select the sysupgrade file.
  d.  Click Upload to upload the sysupgrade file.
  e.  Important:  uncheck "Keep settings and retain the current
      configuration" for this initial installation.
  f.  Click "Continue" to flash the firmware.
  g.  The device will reboot and OpenWRT is installed.

Backup the OEM Firmware:
-----------------------

There isn't any downloadable firmware for the ALLY devices on the Amped
Wireless web site. Reverting back to the OEM firmware is not possible
unless we have a backup of the original OEM firmware.

The OEM firmware may be stored on either /dev/mtd3 ("firmware") or
/dev/mtd6 ("oem").  We can't be sure which was overwritten with the
initramfs image, so backup both partitions to be safe.

  1) Once logged into LuCI, navigate to System -&gt; Backup/Flash Firmware.
  2) Under "Save mtdblock contents," first select "firmware" and click
  "Save mtdblock" to download the image.
  3) Repeat the process, but select "oem" from the pull-down menu.

Revert to the OEM Firmware:
--------------------------
* U-boot TFTP:
  Follow the TFTP recovery steps for the Extender, and use the
  backup image.

* OpenWrt "Flash Firmware" interface:
  Upload the backup image and select "Force update"
  before continuing.

Signed-off-by: Jonathan Sturges &lt;jsturges@redhat.com&gt;

(cherry picked from commit 6d23e474ad9d0eba935696c66db4fb6e2037bb72)
</content>
</entry>
<entry>
<title>ramips: add support for JCG Q20</title>
<updated>2021-06-10T15:09:35Z</updated>
<author>
<name>Chukun Pan</name>
</author>
<published>2021-05-16T12:10:05Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=9fa5b3afc90b1dc2a69f90897f39a4e593b42b11'/>
<id>urn:sha1:9fa5b3afc90b1dc2a69f90897f39a4e593b42b11</id>
<content type='text'>
JCG Q20 is an AX 1800M router.

Hardware specs:
  SoC: MediaTek MT7621AT
  Flash: Winbond W29N01HV 128 MiB
  RAM: Winbond W632GU6NB-11 256 MiB
  WiFi: MT7915 2.4/5 GHz 2T2R
  Ethernet: 10/100/1000 Mbps x3
  LED: Status (red / blue)
  Button: Reset, WPS
  Power: DC 12V,1A

Flash instructions:
  Upload factory.bin in stock firmware's upgrade page,
  do not preserve settings.

MAC addresses map:
  0x00004 *:3e wlan2g/wlan5g
  0x3fff4 *:3c lan/label
  0x3fffa *:3c wan

Signed-off-by: Chukun Pan &lt;amadeus@jmu.edu.cn&gt;
(cherry picked from commit 57cb387cfeee2a07902a2f1383ca471ef47265f3)
</content>
</entry>
<entry>
<title>ramips: mt7621: Add support for ZyXEL NR7101</title>
<updated>2021-06-10T15:09:35Z</updated>
<author>
<name>Bjørn Mork</name>
</author>
<published>2021-04-19T11:00:56Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=8c986d2ab96a29f11dbf6ff259a6e4712037ed3b'/>
<id>urn:sha1:8c986d2ab96a29f11dbf6ff259a6e4712037ed3b</id>
<content type='text'>
The ZyXEL NR7101 is an 802.3at PoE powered 5G outdoor (IP68) CPE
with integrated directional 5G/LTE antennas.

Specifications:

 - SoC: MediaTek MT7621AT
 - RAM: 256 MB
 - Flash: 128 MB MB NAND (MX30LF1G18AC)
 - WiFi: MediaTek MT7603E
 - Switch: 1 LAN port (Gigabiti)
 - 5G/LTE: Quectel RG502Q-EA connected by USB3 to SoC
 - SIM: 2 micro-SIM slots under transparent cover
 - Buttons: Reset, WLAN under same cover
 - LEDs: Multicolour green/red/yellow under same cover (visible)
 - Power: 802.3at PoE via LAN port

The device is built as an outdoor ethernet to 5G/LTE bridge or
router. The Wifi interface is intended for installation and/or
temporary management purposes only.

UART Serial:

57600N1
Located on populated 5 pin header J5:

 [o] GND
 [ ] key - no pin
 [o] RX
 [o] TX
 [o] 3.3V Vcc

Remove the SIM/button/LED cover, the WLAN button and 12 screws
holding the back plate and antenna cover together. The GPS antenna
is fixed to the cover, so be careful with the cable.  Remove 4
screws fixing the antenna board to the main board, again being
careful with the cables.

A bluetooth TTL adapter is recommended for permanent console
access, to keep the router water and dustproof. The 3.3V pin is
able to power such an adapter.

MAC addresses:

OpenWrt OEM   Address          Found as
lan     eth2  08:26:97:*:*:BC  Factory 0xe000 (hex), label
wlan0   ra0   08:26:97:*:*:BD  Factory 0x4 (hex)
wwan0   usb0  random

WARNING!!

ISP managed firmware might at any time update itself to a version
where all known workarounds have been disabled.  Never boot an ISP
managed firmware with a SIM in any of the slots if you intend to use
the router with OpenWrt. The bootloader lock can only be disabled with
root access to running firmware. The flash chip is physically
inaccessible without soldering.

Installation from OEM web GUI:

- Log in as "supervisor" on https://172.17.1.1/
- Upload OpenWrt initramfs-recovery.bin image on the
  Maintenance -&gt; Firmware page
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- (optional) Copy OpenWrt to the recovery partition. See below
- Sysupgrade to the OpenWrt sysupgrade image and reboot

Installation from OEM ssh:

- Log in as "root" on 172.17.1.1 port 22022
- scp OpenWrt initramfs-recovery.bin image to 172.17.1.1:/tmp
- Prepare bootloader config by running:
    nvram setro uboot DebugFlag 0x1
    nvram setro uboot CheckBypass 0
    nvram commit
- Run "mtd_write -w write initramfs-recovery.bin Kernel" and reboot
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- (optional) Copy OpenWrt to the recovery partition. See below
- Sysupgrade to the OpenWrt sysupgrade image and reboot

Copying OpenWrt to the recovery partition:

- Verify that you are running a working OpenWrt recovery image
  from flash
- ssh to root@192.168.1.1 and run:
    fw_setenv CheckBypass 0
    mtd -r erase Kernel2
- Wait while the bootloader mirrors Image1 to Image2

NOTE: This should only be done after successfully booting the OpenWrt
  recovery image from the primary partition during installation.  Do
  not do this after having sysupgraded OpenWrt!  Reinstalling the
  recovery image on normal upgrades is not required or recommended.

Installation from Z-Loader:

- Halt boot by pressing Escape on console
- Set up a tftp server to serve the OpenWrt initramfs-recovery.bin
  image at 10.10.10.3
- Type "ATNR 1,initramfs-recovery.bin" at the "ZLB&gt;" prompt
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- Sysupgrade to the OpenWrt sysupgrade image

NOTE: ATNR will write the recovery image to both primary and recovery
  partitions in one go.

Booting from RAM:

- Halt boot by pressing Escape on console
- Type "ATGU" at the "ZLB&gt;" prompt to enter the U-Boot menu
- Press "4" to select "4: Entr boot command line interface."
- Set up a tftp server to serve the OpenWrt initramfs-recovery.bin
  image at 10.10.10.3
- Load it using "tftpboot 0x88000000 initramfs-recovery.bin"
- Boot with "bootm  0x8800017C" to skip the 380 (0x17C) bytes ZyXEL
  header

This method can also be used to RAM boot OEM firmware. The warning
regarding OEM applies!  Never boot an unknown OEM firmware, or any OEM
firmware with a SIM in any slot.

NOTE: U-Boot configuration is incomplete (on some devices?). You may
  have to configure a working mac address before running tftp using
   "setenv eth0addr &lt;mac&gt;"

Unlocking the bootloader:

If you are unebale to halt boot, then the bootloader is locked.

The OEM firmware locks the bootloader on every boot by setting
DebugFlag to 0.  Setting it to 1 is therefore only temporary
when OEM firmware is installed.

- Run "nvram setro uboot DebugFlag 0x1; nvram commit" in OEM firmware
- Run "fw_setenv DebugFlag 0x1" in OpenWrt

  NOTE:
    OpenWrt does this automatically on first boot if necessary

  NOTE2:
    Setting the flag to 0x1 avoids the reset to 0 in known OEM
    versions, but this might change.

  WARNING:
    Writing anything to flash while the bootloader is locked is
    considered extremely risky. Errors might cause a permanent
    brick!

Enabling management access from LAN:

Temporary workaround to allow installing OpenWrt if OEM firmware
has disabled LAN management:

- Connect to console
- Log in as "root"
- Run "iptables -I INPUT -i br0 -j ACCEPT"

Notes on the OEM/bootloader dual partition scheme

The dual partition scheme on this device uses Image2 as a recovery
image only. The device will always boot from Image1, but the
bootloader might copy Image2 to Image1 under specific conditions. This
scheme prevents repurposing of the space occupied by Image2 in any
useful way.

Validation of primary and recovery images is controlled by the
variables CheckBypass, Image1Stable, and Image1Try.

The bootloader sets CheckBypass to 0 and reboots if Image1 fails
validation.

If CheckBypass is 0 and Image1 is invalid then Image2 is copied to
Image1.

If CheckBypass is 0 and Image2 is invalid, then Image1 is copied to
Image2.

If CheckBypass is 1 then all tests are skipped and Image1 is booted
unconditionally.  CheckBypass is set to 1 after each successful
validation of Image1.

Image1Try is incremented if Image1Stable is 0, and Image2 is copied to
Image1 if Image1Try is 3 or larger.  But the bootloader only tests
Image1Try if CheckBypass is 0, which is impossible unless the booted
image sets it to 0 before failing.

The system is therefore not resilient against runtime errors like
failure to mount the rootfs, unless the kernel image sets CheckBypass
to 0 before failing. This is not yet implemented in OpenWrt.

Setting Image1Stable to 1 prevents the bootloader from updating
Image1Try on every boot, saving unnecessary writes to the environment
partition.

Keeping an OpenWrt initramfs recovery as Image2 is recommended
primarily to avoid unwanted OEM firmware boots on failure. Ref the
warning above. It enables console-less recovery in case of some
failures to boot from Image1.

Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Tested-by: Bjørn Mork &lt;bjorn@mork.no&gt;
(cherry picked from commit 2449a632084b29632605e5a79ce5d73028eb15dd)
</content>
</entry>
</feed>
