Very Urgent Reply!!!!
Attention Sir/Madam, I hope this message finds you well. I am writing to inform you of some exciting news regarding the delivery of your consignment. Diplomat James Morgan, who has been mandated by our company to ensure the safe and prompt delivery of your consignment, has just arrived in your city. I am delighted to inform you that Diplomat James Morgan has successfully completed all the necessary procedures and documentation for the swift release and delivery of your consignment. He brings with him years of experience and expertise in handling diplomatic deliveries, and we are confident that he will ensure the successful completion of this important transaction. Given the significance of the consignment to you, we have arranged for Diplomat James Morgan to personally oversee its delivery to your designated location. His professionalism, attention to detail, and commitment to providing excellent customer service make him the ideal choice for this crucial task. We understand that you have eagerly been awaiting the arrival of your consignment, and we apologize for any delays or inconveniences you may have experienced during this process. Rest assured that we are doing everything in our power to make sure your consignment arrives in perfect condition and within the shortest possible time frame. Diplomat James Morgan will contact you directly to arrange a convenient delivery date and time. Please ensure that you are available to receive the consignment or designate a trusted representative who can accept it on your behalf. You may be required to provide valid identification upon delivery, as per standard protocol. Should you have any questions or concerns, please do not hesitate to reach out to me directly at dipmorg...@gmail.com. Your satisfaction is our top priority, and we are committed to resolving any issues you may have promptly and effectively. Thank you for choosing our services for the delivery of your consignment. We appreciate your trust in our company and assure you that we will continue to strive for excellence throughout this process. Wishing you a seamless delivery experience and a pleasant day ahead. Warm regards, Dip James Morgan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Status of snapshot builds for omap target
Hi Raylynn, On 2024/04/11 15:57, Raylynn Knight wrote: Hiroshi, I’m late responding also so no problem. On Apr 8, 2024, at 9:48 PM, INAGAKI Hiroshi wrote: Hi Raylynn, sorry for late reply. From my understanding... On 2024/04/05 4:42, Raylynn Knight via openwrt-devel wrote: If I understand the issue correctly then it does not affect two of the four currently supported devices (i.e. it only affects Beaglebone Black and AM335x EVM and not BeagleBoard or PandaBoard). Is that correct? Yes, all devices that has the ethernet port(s) provided by TI OMAP SoC are affected. Currently, ti_am335x-evm and ti_am335x-bone-black. So can we re-enable the target and disable the affected devices? I think that's one way to keep omap target as available as possible. However, I don't know what OpenWrt's team members will think... Is the proposed correction a change to the device tree for all devices that have the 'dual-emac-pvid’ node? Yes. but unfortunately, changing dual-emac-pvid is also not a fundamental fix since it also occupies VLAN ID(s)... But of course, reverting back to the old "cpsw" driver doesn't solve for devices that has 2x ethernet ports. None of the devices currently supported have 2 ethernet ports. I’m not aware of any popular device for this target that does have multiple ports. The Netgate SG-1000 and the Olimex AM3352-SOM-EVB are the only devices I’m aware of that have 2 ports and they have no where near the popularity of the various Beagleboard devices. Yes. I've opened (but closed) a PR for adding support of Century Systems MA-E350/N (AM3352), but it's probably completely unknown outside of Japan. ;) Ray Cheers, Hiroshi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
Le mar. 16 avr. 2024 à 10:34, Paul D a écrit : > > On 2024-03-27 23:56, Etienne Champetier wrote: > > > > As this is a legal issue, should we get SFC opinion first ? > > > > Etienne > > > > Is this happening? Sorry I missed your last ping This was an open question, I don't know who to contact at SFC Looking at old emails, John, Jo and Hauke are our liaison with SFC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
On 2024-03-27 23:56, Etienne Champetier wrote: > > As this is a legal issue, should we get SFC opinion first ? > > Etienne > Is this happening? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ath79: add support for Dell SonicPoint ACe APL26-0AE
From: Tomasz Maciej Nowak
Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
wireless access point. End of life as of 2022-07-31.
Specification
SoC: QualcommAtheros QCA9550
RAM: 256 MB DDR2
Flash: 32 MB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9890 oversized Mini PCIe card
Ethernet: 2x 10/100/1000 Mbps QCA8334
port labeled lan1 is PoE capable (802.3at)
USB: 1x 2.0
LEDs: LEDs: 6x which 5 are GPIO controlled and two of them are dual color
Buttons: 2x GPIO controlled
Serial: RJ-45 port, SonicWall pinout
baud: 115200, parity: none, flow control: none
Before flashing, be sure to have a copy of factory firmware, in case You
wish to revert to original firmware.
All described procedures were done in following environment:
ROM Version: SonicROM (U-Boot) 8.0.0.0-11o
SafeMode Firmware Version: SonicOS 8.0.0.0-14o
Firmware Version: SonicOS 9.0.1.0
In case of other versions, following installation instructions might be
ineffective.
Installation
1. Prepare TFTP server with OpenWrt sysupgrade image and rename that
image to "sp_fw.bin".
2. Connect to one of LAN ports.
3. Connect to serial port.
4. Hold the reset button (small through hole on side of the unit),
power on the device and when prompted to stop autoboot, hit any key.
The held button can now be released.
5. Alter U-Boot environment with following commands:
setenv bootcmd bootm 0x9F51
saveenv
6. Adjust "ipaddr" (access point, default is 192.168.1.1) and "serverip"
(TFTP server, default is 192.168.1.10) addresses in U-Boot
environment, then run following command:
run lf
7. After successful flashing, execute:
boot
8. The access point will boot to OpenWrt. Wait few minutes, until the
wrench LED will stop blinking, then it's ready for configuration.
Known issues
Initramfs image can't be bigger than specified kernel size, otherwise
bootloader will throw LZMA decompressing error. Switching to lzma-loader
should workaround that.
This device has Winbond 25Q256FVFG and doesn't have reliable reset, which
causes hang on reboot, thus broken-flash-reset needs to be added. This
property addition causes dispaly of "scary" warning on each boot, take
this warnig into consideration.
Signed-off-by: Tomasz Maciej Nowak
---
v1 -> v2
- add EoL notice
- correct LEDs description
- add default IP addresses from U-Boot
package/boot/uboot-envtools/files/ath79 | 3 +
.../ath79/dts/qca9550_dell_apl26-0ae.dts | 246 ++
.../generic/base-files/etc/board.d/01_leds| 4 +
.../generic/base-files/etc/board.d/02_network | 4 +
target/linux/ath79/image/generic.mk | 16 ++
5 files changed, 273 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9550_dell_apl26-0ae.dts
diff --git a/package/boot/uboot-envtools/files/ath79
b/package/boot/uboot-envtools/files/ath79
index 567bf9824ddc..2c97e61498e9 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -117,6 +117,9 @@ buffalo,wzr-hp-g300nh-s|\
linksys,ea4500-v3)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2"
;;
+dell,apl26-0ae)
+ ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x1"
+ ;;
domywifi,dw33d)
ubootenv_add_uci_config "/dev/mtd4" "0x0" "0x1" "0x1"
;;
diff --git a/target/linux/ath79/dts/qca9550_dell_apl26-0ae.dts
b/target/linux/ath79/dts/qca9550_dell_apl26-0ae.dts
new file mode 100644
index ..2f243e027471
--- /dev/null
+++ b/target/linux/ath79/dts/qca9550_dell_apl26-0ae.dts
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+#include
+
+#include "qca955x.dtsi"
+
+/ {
+ model = "Dell SonicPoint ACe (APL26-0AE)";
+ compatible = "dell,apl26-0ae", "qca,qca9550", "qca,qca9558";
+
+ aliases {
+ label-mac-device =
+ led-boot = _wrench;
+ led-failsafe = _wrench;
+ led-upgrade = _wrench;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ button-reset {
+ label = "reset";
+ gpios = < 21 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ /* Accessible only after disassembling the casing */
+ button-service {
+ label = "service";
+ gpios = < 22 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_disable_pins>;
+
+ led-lan1-amber {
+ color = ;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-lan1-green {
+
Re: [PATCH] ath79: add support for Dell SonicPoint ACe APL26-0AE
W dniu 15.04.2024 o 14:32, Paul D pisze: > >>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses > Might be an idea to explicitly document these IPs so that dedicated users can > already set their gear to those IPs and just smash enter Will add them in v2, but given the addresses that are set by default (192.168.1.1 for AP) one might find it simpler to adjust them single time in U-Boot environment. -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: GPIO numbering and ucidef_add_gpio_switch in kernel 6.6
Robert Marko wrote:
> On Mon, 18 Mar 2024 at 06:31, Mathew McBride wrote:
> >
> > Hi all,
> >
> > A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted
> > in the GPIO chip base numbers changing on some architectures (x86, arm and
> > arm64 were directly modified in that series).
> >
> > This may cause issues with /etc/board.d/03_gpio_switches scripts as the
> > GPIO numbers will change when moving to the 6.6 kernel.
> Hi Matthew,
> This has been an issue for a while as GPIO numbers are not stable and
> have never been guaranteed so.
I think we need some helper to find gpioswitch base number by bus-address or
name in /sys/class/gpio/gpiochip*/{label,device/name}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
