<feed xmlns='http://www.w3.org/2005/Atom'>
<title>staging/hauke/target, branch v21.02.3</title>
<subtitle>Hauke Mehrtens staging tree</subtitle>
<id>https://git.openwrt.org/openwrt/staging/hauke/atom?h=v21.02.3</id>
<link rel='self' href='https://git.openwrt.org/openwrt/staging/hauke/atom?h=v21.02.3'/>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/'/>
<updated>2022-04-16T12:59:34Z</updated>
<entry>
<title>ath79: Move TPLink WPA8630Pv2 to ath79-tiny target</title>
<updated>2022-04-16T12:59:34Z</updated>
<author>
<name>Joe Mullally</name>
</author>
<published>2021-08-30T21:35:05Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=1d4dea6d4f4d34914e4622809b8b4a7c2c35ab47'/>
<id>urn:sha1:1d4dea6d4f4d34914e4622809b8b4a7c2c35ab47</id>
<content type='text'>
These devices only have 6MiB available for firmware, which is not
enough for recent release images, so move these to the tiny target.

Note for users sysupgrading from the previous ath79-generic snapshot
images:

The tiny target kernel has a 4Kb flash erase block size instead
of the generic target's 64kb. This means the JFFS2 overlay partition
containing settings must be reformatted with the new block size or else
there will be data corruption.

To do this, backup your settings before upgrading, then during the
sysupgrade, de-select "Keep Settings". On the CLI, use "sysupgrade -n".

If you forget to do this and your system becomes unstable after
upgrading, you can do this to format the partition and recover:

* Reboot
* Press RESET when Power LED blinks during boot to enter Failsafe mode
* SSH to 192.168.1.1
* Run "firstboot" and reboot

Signed-off-by: Joe Mullally &lt;jwmullally@gmail.com&gt;
Tested-by: Robert Högberg &lt;robert.hogberg@gmail.com&gt;
Signed-off-by: Petr Štetiar &lt;ynezz@true.cz&gt; [commit message facelift]
(cherry picked from commit 44e1e5d)
Signed-off-by: Petr Štetiar &lt;ynezz@true.cz&gt;
</content>
</entry>
<entry>
<title>bcm27xx: add AMP2 to HifiBerry DAC+ / DAC+ Pro package</title>
<updated>2022-04-16T12:55:27Z</updated>
<author>
<name>Torsten Duwe</name>
</author>
<published>2021-09-22T08:52:51Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=41a97c207438903c309371ba695cea01ae78aba4'/>
<id>urn:sha1:41a97c207438903c309371ba695cea01ae78aba4</id>
<content type='text'>
According to the vendor [1] these HATs share the same DT overlay:
hifiberry-dacplus. The PCM512x-compatible control unit is attached to
I2C, so the additional snd-soc-pcm512x-i2c kernel module is required.
Also explicitly note the Amp2 support to reduce confusion for those
users.

[1] &lt;https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/&gt;
Signed-off-by: Torsten Duwe &lt;duwe@lst.de&gt;
(added bcm27xx tag, changed commit message)
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
(cherry picked from commit 7ea9936f7f32fd90af1a29775ac3b297d7775db7)
</content>
</entry>
<entry>
<title>ath79: add support for MikroTik RouterBOARD mAP lite</title>
<updated>2022-04-16T12:51:57Z</updated>
<author>
<name>Thibaut VARÈNE</name>
</author>
<published>2022-03-10T11:01:29Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=9a765554f409235ff6359d6eccb79187c2513de0'/>
<id>urn:sha1:9a765554f409235ff6359d6eccb79187c2513de0</id>
<content type='text'>
The MikroTik RouterBOARD mAPL-2nd (sold as mAP Lite) is a small
2.4 GHz 802.11b/g/n PoE-capable AP.

See https://mikrotik.com/product/RBmAPL-2nD for more info.

Specifications:
 - SoC: Qualcomm Atheros QCA9533
 - RAM: 64 MB
 - Storage: 16 MB NOR
 - Wireless: Atheros AR9531 (SoC) 802.11b/g/n 2x2:2, 1.5 dBi antenna
 - Ethernet: Atheros AR8229 (SoC), 1x 10/100 port, 802.3af/at PoE in
 - 4 user-controllable LEDs:
   · 1x power (green)
   · 1x user (green)
   · 1x lan (green)
   · 1x wlan (green)

Flashing:
 TFTP boot initramfs image and then perform sysupgrade. Follow common
 MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.

Note: following 781d4bfb397cdd12ee0151eb66c577f470e3377d
 The network setup avoids using the integrated switch and connects the
 single Ethernet port directly. This way, link speed (10/100 Mbps) is
 properly reported by eth0.

Signed-off-by: Thibaut VARÈNE &lt;hacks@slashdirt.org&gt;
(cherry picked from commit eb38af788180d624e5b37aa5db1fe3766b138dc8)
</content>
</entry>
<entry>
<title>ath79: add support for Yuncore A930</title>
<updated>2022-04-16T12:48:45Z</updated>
<author>
<name>Thibaut VARÈNE</name>
</author>
<published>2022-04-15T11:17:53Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=2cc9ee8000597fe132071ec3ba6bf0ac9404ac94'/>
<id>urn:sha1:2cc9ee8000597fe132071ec3ba6bf0ac9404ac94</id>
<content type='text'>
Specification:

- QCA9533 (650 MHz), 64 or 128MB RAM, 16MB SPI NOR
- 2x 10/100 Mbps Ethernet, with 802.3at PoE support (WAN)
- 2T2R 802.11b/g/n 2.4GHz

Flash instructions:

If your device comes with generic QSDK based firmware, you can login
over telnet (login: root, empty password, default IP: 192.168.188.253),
issue first (important!) 'fw_setenv' command and then perform regular
upgrade, using 'sysupgrade -n -F ...' (you can use 'wget' to download
image to the device, SSH server is not available):

  fw_setenv bootcmd "bootm 0x9f050000 || bootm 0x9fe80000"
  sysupgrade -n -F openwrt-...-yuncore_...-squashfs-sysupgrade.bin

In case your device runs firmware with YunCore custom GUI, you can use
U-Boot recovery mode:

1. Set a static IP 192.168.0.141/24 on PC and start TFTP server with
   'tftp' image renamed to 'upgrade.bin'
2. Power the device with reset button pressed and release it after 5-7
   seconds, recovery mode should start downloading image from server
   (unfortunately, there is no visible indication that recovery got
   enabled - in case of problems check TFTP server logs)

Signed-off-by: Clemens Hopfer &lt;openwrt@wireloss.net&gt;
Signed-off-by: Thibaut VARÈNE &lt;hacks@slashdirt.org&gt;
(cherry-picked from commit a05dcb07241aa83a4416b56201e31b4af8518981)
[switch to mtd-mac-address instead of nvmem-cells]
</content>
</entry>
<entry>
<title>ath79: add support for Yuncore XD3200</title>
<updated>2022-04-16T12:48:29Z</updated>
<author>
<name>Thibaut VARÈNE</name>
</author>
<published>2022-04-15T11:17:49Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=06874171d125f0a69d6fb8cfd12213b7913d317e'/>
<id>urn:sha1:06874171d125f0a69d6fb8cfd12213b7913d317e</id>
<content type='text'>
Specification:

- QCA9563 (775MHz), 128MB RAM, 16MB SPI NOR
- 2T2R 802.11b/g/n 2.4GHz
- 2T2R 802.11n/ac 5GHz
- 2x 10/100/1000 Mbps Ethernet, with 802.3at PoE support (WAN port)

LED for 5 GHz WLAN is currently not supported as it is connected directly
to the QCA9882 radio chip.

Flash instructions:

If your device comes with generic QSDK based firmware, you can login
over telnet (login: root, empty password, default IP: 192.168.188.253),
issue first (important!) 'fw_setenv' command and then perform regular
upgrade, using 'sysupgrade -n -F ...' (you can use 'wget' to download
image to the device, SSH server is not available):

  fw_setenv bootcmd "bootm 0x9f050000 || bootm 0x9fe80000"
  sysupgrade -n -F openwrt-...-yuncore_...-squashfs-sysupgrade.bin

In case your device runs firmware with YunCore custom GUI, you can use
U-Boot recovery mode:

1. Set a static IP 192.168.0.141/24 on PC and start TFTP server with
   'tftp' image renamed to 'upgrade.bin'
2. Power the device with reset button pressed and release it after 5-7
   seconds, recovery mode should start downloading image from server
   (unfortunately, there is no visible indication that recovery got
   enabled - in case of problems check TFTP server logs)

Signed-off-by: Thibaut VARÈNE &lt;hacks@slashdirt.org&gt;
(cherry-picked from commit c91df224f54fdd44c9c0487a8c91876f5d273164)
</content>
</entry>
<entry>
<title>ramips: fix reboot for remaining 32 MB boards</title>
<updated>2022-04-08T08:31:32Z</updated>
<author>
<name>Michael Pratt</name>
</author>
<published>2021-09-11T02:06:10Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=169c9e3a88b7d4521a797864540657ef33554663'/>
<id>urn:sha1:169c9e3a88b7d4521a797864540657ef33554663</id>
<content type='text'>
The following devices have a Winbond W25Q256FV flash chip,
which does not have the RESET pin enabled by default,
and otherwise would require setting a bit in a status register.

Before moving to Linux 5.4, we had the patch:
0053-mtd-spi-nor-add-w25q256-3b-mode-switch.patch
which kept specific flash chips with explicit 3-byte and 4-byte address modes
to stay in 3-byte address mode while idle (after an erase or write)
by using a custom flag SPI_NOR_4B_READ_OP that was part of the patch.

this was obsoleted by the patch:
481-mtd-spi-nor-rework-broken-flash-reset-support.patch
which uses the newer upstream flag SNOR_F_BROKEN_RESET
for devices with a flash chip that cannot be hardware reset with RESET pin
and therefore must be left in 3-byte address mode when idle.

The new patch requires that the DTS of affected devices
have the property "broken-flash-reset", which was not yet added for most of them.

This commit adds the property for remaining affected devices in ramips target,
specifically because of the flash chip model.

However, it is possible that there are other devices
where the flash chip uses an explicit 4-byte address mode
and the RESET pin is not connected to the SOC on the board,
and those DTS would also need this property.

Ref: 22d982ea0033 ("ramips: add support for switching between 3-byte and 4-byte addressing")
Ref: dfa521f12953 ("generic: spi-nor: rework broken-flash-reset")
Signed-off-by: Michael Pratt &lt;mcpratt@pm.me&gt;
[pepe2k@gmail.com: backported to 21.02]
Fixes: #9655, #9636, #9547
Signed-off-by: Piotr Dymacz &lt;pepe2k@gmail.com&gt;
(backported from commit 74516f4357d281f093f0daac01c4c5c239acc443)
</content>
</entry>
<entry>
<title>kernel: bump 5.4 to 5.4.188</title>
<updated>2022-04-07T18:42:34Z</updated>
<author>
<name>Hauke Mehrtens</name>
</author>
<published>2022-04-05T22:46:27Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=39bf2aee0ed840ff6bb4838bc0a42aaddc36a4d3'/>
<id>urn:sha1:39bf2aee0ed840ff6bb4838bc0a42aaddc36a4d3</id>
<content type='text'>
Added the new configuration options:
CONFIG_HARDEN_BRANCH_HISTORY=y
CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY=y

Manually adapted:
target/linux/generic/hack-5.4/220-gc_sections.patch

Compile-tested: lantiq/xrx200, armvirt/64
Run-tested: lantiq/xrx200, armvirt/64

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
</content>
</entry>
<entry>
<title>imagebuilder: fix broken image generation with external targets</title>
<updated>2022-04-05T20:06:41Z</updated>
<author>
<name>Petr Štetiar</name>
</author>
<published>2022-03-24T05:52:37Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=3008f1f441a41e162311cee1ccadfdaaec1581c1'/>
<id>urn:sha1:3008f1f441a41e162311cee1ccadfdaaec1581c1</id>
<content type='text'>
When using external targets there is a symlink being created for the
target under target/linux which then becomes dangling under Image
Builder. Fix it by dereferencing the possible symlink.

Tested on IB with external target, ipq40xx and mvebu.

Signed-off-by: Petr Štetiar &lt;ynezz@true.cz&gt;
(cherry picked from commit 621f39d1f438bf95dbae667c575926fa16a6d797)
(cherry picked from commit ec9af870f3278f75549836b469baefa260e2ed41)
</content>
</entry>
<entry>
<title>ath79: migrate Archer C5 5GHz radio device paths</title>
<updated>2022-03-31T16:07:57Z</updated>
<author>
<name>Jan-Niklas Burfeind</name>
</author>
<published>2022-03-28T16:07:59Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=ee62912b2db0018cd370f2c110e1391ee779cc6d'/>
<id>urn:sha1:ee62912b2db0018cd370f2c110e1391ee779cc6d</id>
<content type='text'>
When upgrading a TP-Link Archer C5 v1 from ar71xx to ath79,
the 5ghz radio stops working because the device path changed.

Same has been done for the Archer C7 before:

commit e19506f20618 ("ath79: migrate Archer C7 5GHz radio device paths")

Signed-off-by: Jan-Niklas Burfeind &lt;git@aiyionpri.me&gt;
(cherry picked from commit c6eb63d48f942f1e54737ed182776cf9a08de542)
</content>
</entry>
<entry>
<title>ath79: fix label MAC address for Ubiquiti UniFi AP Outdoor+</title>
<updated>2022-03-30T15:49:43Z</updated>
<author>
<name>Matthias Schiffer</name>
</author>
<published>2022-03-29T22:20:39Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/hauke/commit/?id=f6513143addb6585b5133f12523bfc3950ae7dbb'/>
<id>urn:sha1:f6513143addb6585b5133f12523bfc3950ae7dbb</id>
<content type='text'>
The label has the MAC address of eth0, not the WLAN PHY address. We can
merge the definition back into ar7241_ubnt_unifi.dtsi, as both DTS
derived from it use the same interface for their label MAC addresses
after all.

Signed-off-by: Matthias Schiffer &lt;mschiffer@universe-factory.net&gt;
(cherry picked from commit aee9ccf5c1b536189ebee8c232273657334da843)
</content>
</entry>
</feed>
