Are we still use md5 as default as password hash?
old times there was a musl size hack that disabled everything except DES and md5, but that was disabled in 2021 Dec https://github.com/openwrt/openwrt/commit/66768755791286fc02a38d1b437a9da74290041d, allowing sha256,sha512 and blowfish however Busybox doesn't configed to use those and still use md5 as default, while we bring other hash algos into flash anyway: ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mediatek: filogic: replace built-in Aquantia driver with module
From: Rafał Miłecki Some Aquantia PHYs (e.g. AQR113C) require firmware to be uploaded by host system. With built-in drivers this doesn't work in OpenWrt / embeddded as filesystem isn't available during PHY probe. That results in delays like: [1.588068] Aquantia AQR113C mdio-bus:00: Falling back to sysfs fallback for: Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld [ 64.526387] Aquantia AQR113C mdio-bus:00: failed to find FW file Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld (-110) Switch to module to postpone PHY probe to init state. Signed-off-by: Rafał Miłecki --- target/linux/mediatek/filogic/config-5.15 | 1 - target/linux/mediatek/filogic/config-6.1 | 1 - target/linux/mediatek/filogic/target.mk | 2 +- 3 files changed, 1 insertion(+), 3 deletions(-) diff --git a/target/linux/mediatek/filogic/config-5.15 b/target/linux/mediatek/filogic/config-5.15 index 8ba0b0efe8..783447ac9c 100644 --- a/target/linux/mediatek/filogic/config-5.15 +++ b/target/linux/mediatek/filogic/config-5.15 @@ -1,6 +1,5 @@ CONFIG_64BIT=y # CONFIG_AHCI_MTK is not set -CONFIG_AQUANTIA_PHY=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_ARCH_KEEP_MEMBLOCK=y CONFIG_ARCH_MEDIATEK=y diff --git a/target/linux/mediatek/filogic/config-6.1 b/target/linux/mediatek/filogic/config-6.1 index 1687aadbc1..1eaf57b06e 100644 --- a/target/linux/mediatek/filogic/config-6.1 +++ b/target/linux/mediatek/filogic/config-6.1 @@ -1,6 +1,5 @@ CONFIG_64BIT=y # CONFIG_AHCI_MTK is not set -CONFIG_AQUANTIA_PHY=y CONFIG_ARCH_BINFMT_ELF_EXTRA_PHDRS=y CONFIG_ARCH_CORRECT_STACKTRACE_ON_KRETPROBE=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y diff --git a/target/linux/mediatek/filogic/target.mk b/target/linux/mediatek/filogic/target.mk index dd4c4c1448..182b229db2 100644 --- a/target/linux/mediatek/filogic/target.mk +++ b/target/linux/mediatek/filogic/target.mk @@ -2,7 +2,7 @@ ARCH:=aarch64 SUBTARGET:=filogic BOARDNAME:=Filogic 8x0 (MT798x) CPU_TYPE:=cortex-a53 -DEFAULT_PACKAGES += kmod-crypto-hw-safexcel kmod-mt7915e wpad-basic-mbedtls uboot-envtools +DEFAULT_PACKAGES += kmod-phy-aquantia kmod-crypto-hw-safexcel kmod-mt7915e wpad-basic-mbedtls uboot-envtools KERNELNAME:=Image dtbs define Target/Description -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 17.01.24 20:31, David Bauer wrote: Hi John, On 1/9/24 11:49, John Crispin wrote: FAQ * Why are there are 2 different flash chips? - the idea is to make the device (almost!) unbrickable and very easy to recover - NAND will hold the main loader (U-Boot) and the Linux image and will be the default boot device - NOR will be write-protected by default (with WP jumper available on the board) and will hold a recovery bootloader (and other essential data, like Wi-Fi calibration) - a dedicated boot select switch will allow changing between NOR and NAND No Idea how MTK factory calibration data is individual per-device. If it's possible, I'd like to propose a archive of the radio-calibration / MAC-Address partition. So this would be used to enable people download their calibration data for their serial-number and make it "unbrickable" with an SPI clamp. What do you think? Best David Hi David indeed, I fully agree, the calib blob holds no privacy relevant info. once the vote concludes positive I have the mandat to talk with the ODM. the idea is to provide a http/rest endpoint for the ODM to a) grab a blob with the serial number and other TBD data to be place inside the flash b) upload the calibration data for backup storage, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi John, On 1/9/24 11:49, John Crispin wrote: FAQ * Why are there are 2 different flash chips? - the idea is to make the device (almost!) unbrickable and very easy to recover - NAND will hold the main loader (U-Boot) and the Linux image and will be the default boot device - NOR will be write-protected by default (with WP jumper available on the board) and will hold a recovery bootloader (and other essential data, like Wi-Fi calibration) - a dedicated boot select switch will allow changing between NOR and NAND No Idea how MTK factory calibration data is individual per-device. If it's possible, I'd like to propose a archive of the radio-calibration / MAC-Address partition. So this would be used to enable people download their calibration data for their serial-number and make it "unbrickable" with an SPI clamp. What do you think? Best David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 17.01.24 20:28, Daniel Santos wrote: On 1/16/24 00:36, John Crispin wrote: And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel yeah we will add all remaining GPIO togehter with GND and 3,3V on a 2.54mm header. HELL YES! Even better! Even though it's on mikroBUS, maybe export the reset line on header as well? Daniel Hi Daniel, good Idea added to my TODO notes John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 1/16/24 00:36, John Crispin wrote: And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel yeah we will add all remaining GPIO togehter with GND and 3,3V on a 2.54mm header. HELL YES! Even better! Even though it's on mikroBUS, maybe export the reset line on header as well? Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Wed, Jan 17, 2024 at 05:47:26PM +0100, John Crispin wrote: > > On 17.01.24 17:46, Janusz Dziedzic wrote: > > Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E > > (6GHz) instead of NVMe? > > Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html > > Will that work? > > so the theory but we wont know until we try. I've tried that on BPi-R3 with MT7921K module, and that worked fine. I don't see a reason why it wouldn't work on a very similar MediaTek SoC -- we just need to make sure the power budget of the M.2 slot is enough for even WiFi modules more power hungry than MT7921K (I assume MT7916E wants quite a bit more juice). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 17.01.24 17:19, Fernando Frediani wrote: Hi, again, does this SoC have any type of NAT offload capability ? Now a days with common Internet Broadband plans that is becoming a must. Also is there any possibility to consider more than just 2 Ethernet ports (at least 4)? Would that increase the cost significantly ? Fernando yes via flow table offload --> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mediatek/mtk_ppe_offload.c ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
śr., 17 sty 2024 o 16:27 John Crispin napisał(a): > > Additional FAQ for OpenWrt One > > This is a summary of some further questions regarding the OpenWrt One > project gathered so far. After OpenWrt voted to move forward, it will be > converted into a page within the OpenWrt wiki as a place for collecting > the latest information. > > Q: Will the various hardware buttons and switches be fully exposed on > the outside? > A: The latest iteration of the design will fully expose all buttons and > switches. > > Q: Will there be an option to purchase preassembled kits? > A: We're considering that option but still need to explore possibilities > with the manufacturer. > > Q: When do you expect general availability? > A: Once we vote to move forward, it will take around 45 days until the > first PCBA engineering samples get shipped. These will be passed on to > developers for testing. Once they are verified it will probably take > another 30-45 days until they can be ordered. So we are looking at April > timeframe. > > Q: What kind of power supply is needed? > A: While the initial announcement imprecisely referred to the power > supply as "USB-PD 12V" the PCB will draw its required power from a USB-C > PD 3.0/2.0 source. > > Q: Why does the current design not feature any USB 3.0 connectivity? > A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We > would like to reduce risk as much as possible. Interference proofing the > board would add considerable complexity and costs. > > Q: Why did you implement a M.2 slot? > A: After careful consideration we came to the conclusion that directly > exposing a PCIe 1x lane in the form of an M.2 slot provides the most > flexibility for potential expansions. It can be used for NVMe storage > (up to 2242 when using an enclosure), e.g. to host containers or media > files. It also enables the simple use of other, non-OpenWrt > distributions with larger storage footprints. > Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E (6GHz) instead of NVMe? Eg. https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html Will that work? > Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)? > A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is > there a fully integrated tri-band SoC solution available right now, let > alone fully or partially supported upstream. Supporting Wi-Fi 7 would > drastically increase the overall costs and make it impossible to deliver > sufficient software support in the foreseeable future. > > Q: Why are there only two ethernet ports? > A: We didn't want to impose additional complexity and costs by including > an external managed switch IC. One port is 1GBit/s capable, while the > other features a speed up to 2.5GBit/s. This is a limitation of the > chosen SoC. > > Q: Why should I get the One? There are more capable, more featured > devices available! > A: The OpenWrt One is intended to serve as a robust and simple > educational platform for OpenWrt enthusiasts, it is neither intended to > be a competitor to off the shelf SOHO routers nor do we aim for the > largest possible amount of features. It also serves as a donation > vehicle for the OpenWrt project. > > Q: Does that mean that OpenWrt will stop supporting other hardware? > A: There is no intention at all to change the way OpenWrt operates or > how it implements and supports current and future hardware. The OpenWrt > One device will be supported as one device among many others and receive > the same level of support. > > Q: Doesn't this draw attention away from properly supporting existing > devices? > A: The OpenWrt One project is a privately led initiative by a few > enthusiasts, there is no intent to change the focus of the OpenWrt > project in any way. > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Janusz Dziedzic ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 17.01.24 17:46, Janusz Dziedzic wrote: Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E (6GHz) instead of NVMe? Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html Will that work? so the theory but we wont know until we try. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Additional FAQ for OpenWrt One This is a summary of some further questions regarding the OpenWrt One project gathered so far. After OpenWrt voted to move forward, it will be converted into a page within the OpenWrt wiki as a place for collecting the latest information. Q: Will the various hardware buttons and switches be fully exposed on the outside? A: The latest iteration of the design will fully expose all buttons and switches. Q: Will there be an option to purchase preassembled kits? A: We're considering that option but still need to explore possibilities with the manufacturer. Q: When do you expect general availability? A: Once we vote to move forward, it will take around 45 days until the first PCBA engineering samples get shipped. These will be passed on to developers for testing. Once they are verified it will probably take another 30-45 days until they can be ordered. So we are looking at April timeframe. Q: What kind of power supply is needed? A: While the initial announcement imprecisely referred to the power supply as "USB-PD 12V" the PCB will draw its required power from a USB-C PD 3.0/2.0 source. Q: Why does the current design not feature any USB 3.0 connectivity? A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We would like to reduce risk as much as possible. Interference proofing the board would add considerable complexity and costs. Q: Why did you implement a M.2 slot? A: After careful consideration we came to the conclusion that directly exposing a PCIe 1x lane in the form of an M.2 slot provides the most flexibility for potential expansions. It can be used for NVMe storage (up to 2242 when using an enclosure), e.g. to host containers or media files. It also enables the simple use of other, non-OpenWrt distributions with larger storage footprints. Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)? A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is there a fully integrated tri-band SoC solution available right now, let alone fully or partially supported upstream. Supporting Wi-Fi 7 would drastically increase the overall costs and make it impossible to deliver sufficient software support in the foreseeable future. Q: Why are there only two ethernet ports? A: We didn't want to impose additional complexity and costs by including an external managed switch IC. One port is 1GBit/s capable, while the other features a speed up to 2.5GBit/s. This is a limitation of the chosen SoC. Q: Why should I get the One? There are more capable, more featured devices available! A: The OpenWrt One is intended to serve as a robust and simple educational platform for OpenWrt enthusiasts, it is neither intended to be a competitor to off the shelf SOHO routers nor do we aim for the largest possible amount of features. It also serves as a donation vehicle for the OpenWrt project. Q: Does that mean that OpenWrt will stop supporting other hardware? A: There is no intention at all to change the way OpenWrt operates or how it implements and supports current and future hardware. The OpenWrt One device will be supported as one device among many others and receive the same level of support. Q: Doesn't this draw attention away from properly supporting existing devices? A: The OpenWrt One project is a privately led initiative by a few enthusiasts, there is no intent to change the focus of the OpenWrt project in any way. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Thu, Dec 07, 2023 at 01:23:01PM +, Petr Štetiar wrote: > Varadarajan Narayanan [2023-12-07 15:29:23]: > > Hi, > > > SoC : QCOM IPQ9574 > > RAM : 2GB DDR4 > > Flash : eMMC 8GB > > WiFi: 1 x 2.4GHz > > 1 x 5GHz > > 1 x 6GHz > > BTW it doesn't build here: > > Applying > openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch > using plaintext: > patching file arch/arm64/boot/dts/qcom/ipq6018.dtsi > patching file arch/arm64/boot/dts/qcom/ipq8074.dtsi > Hunk #1 FAILED at 85. > 1 out of 1 hunk FAILED -- saving rejects to file > arch/arm64/boot/dts/qcom/ipq8074.dtsi.rej > Patch failed! Please fix > openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch! > > Cheers, > > Petr Have posted a cleaned up PR - https://github.com/openwrt/openwrt/pull/14417 Can you please take that. Thanks Varada ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: > > On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: > > SoC : QCOM IPQ9574 > > RAM : 2GB DDR4 > > Flash : eMMC 8GB > > WiFi: 1 x 2.4GHz > > 1 x 5GHz > > 1 x 6GHz > > > > Signed-off-by: Varadarajan Narayanan > > Without even looking at the code, please split this up as its > not reviewable at all currently. > > Also, I would strongly encourage using Github PR for this. > > > Regards, > Robert Have create a PR for this - https://github.com/openwrt/openwrt/pull/14417 Kindly review and provide feedback. This is my first time creating a PR, please let me know if something is amiss. Thanks Varada ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
