Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On 12/11/23 09:34, Robert Marko wrote: On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan wrote: On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: Hi Robert, Adding John's correct e-mail to the loop. On 8.12.2023 11:02, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: Hi Robert, On 7.12.2023 12:52, Robert Marko wrote: On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: 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. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. Can you kindly guide on what kind of split is acceptable for the community. Thanks Varada Hi, I would at least split the target itself, patches and then the board itself for the start. Would it make sense to rename qualcommax to qualcomm and make ipq95xx just another subtarget of it (I'm aware of A53 vs. A73)? That depends on how much is shared between the AX SoC-s and the BE ones(IPQ95xx and IPQ53xx). I would say enough to keep them together. But, I would prefer that or qualcommbe target where new BE SoC-s will be subtargets. I'm personally more a fan of limiting number of top targets and deal with differences under subtargets. Same here, better than to add more targets especially since a lot is shared. Thanks for your inputs. Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx as subtarget? I would prefer qualcomm and not ipq, and then ipq95xx as subtarget. Hi, It is probably easier if you add ipq95xx support to the existing qualcommax target first and rename it later in a separate step. Every few days something changes in the qualcommax target and if you rename it you probably have to rebase very often. Hauke ___ 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 12/11/23 06:29, Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 08:36:14PM +0800, Chuanhong Guo wrote: Hi! On Thu, Dec 7, 2023 at 7:24 PM Varadarajan Narayanan wrote: 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. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. An OpenWrt target with only a serial console isn't really useful. It would be better to submit a complete patchset for a working target instead. Is there any plan for upstreaming support for basic functionalities like ethernet and/or WiFi? Yes, there is plan to post those functionalities in the coming weeks. Hi Varada, Could you share your current development tree already even if it is not ready yet. It would be helpful when you also tell us what you plan to change. Then we can already have a look and get a better understanding on how you expect this to look like in the end. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Restructuring OpenWRT developer documentation
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Dear Rich, Thanks a lot for your response, To answer your question: On Mon, Dec 11, 2023 at 2:42 PM Rich Brown wrote: > > Dear Javad, > > First off, I want to thank you for thinking so hard about the OpenWrt > Developer Guide. I worked a lot on the user guide back in the LEDE days. > Because I wasn't going to be writing code, I never spent much time on the > developer guide, and it's terrific to see someone making this effort. > > A few questions about your proposal, both for you and for the other > developers on this list: > > - Are you suggesting simply moving pages from one place in the hierarchy to > another? Yes, At the first steps, we just reconstruct the existing knowledge. When everything has been placed in the right place, we can add/remove internal contents of the pages. > - Or would some/many pages need to be rewritten/split up/combined? At the moment, not too many pages need to be modified. Just some pages may be combined. > - Do you expect to continue using the Dokuwiki system, or converting the > content to some other content management system? As I'm not a maintainer, It really depends on the community. > - Having invested in this effort, how can we check the result for > correctness? (I imagine there are many pages that contain simple, but > outdated info.) We will preserve everything, if it doesn't go well, we can use the old info. > > I hope your inquiry kicks off a robust discussion. Thanks again. > > Rich Brown Best Regards, Javad > > > > > > Dear OpenWRT developer, > > > > I hope this message finds you well. As a user of OpenWRT, I would like > > to express my appreciation for the excellent work you have done in > > creating such a comprehensive documentation. However, I have noticed > > that the current structure can be challenging for new users to > > navigate, which can be discouraging for them. > > > > In an effort to help improve the user experience, I would like to > > suggest a restructuring scheme based on the Buildroot user manual. I > > believe that this scheme could make the documentation more accessible > > and user-friendly, which would in turn help attract more users to > > OpenWRT. > > > > I understand that you have put a lot of effort into creating the > > documentation, and I want to assure you that my intention is not to > > criticize your work. Rather, I hope that my suggestion can contribute > > to the continued success of OpenWRT. > > The new structure: > > --- > > Developer guide > > * Overview > > * OpenWRT source code > > * Getting the source code > > * Working with GitHub > > * Revision number calculation > > * Build system: > > * Build System essentials > > * System setup > > * Linux > > * MacOS > > * Windows (WSL) > > * Setting up a build server in VirtualBox > > > > * Build system usage > > * Quick image-building guide > > * Using build environments > > * Overriding Build Options > > * Using the SDK > > * Cross Compiling your application > > * Using External Toolchain > > * Image Builder frontends > > * Using the Image Builder > > * OpenWrt Feeds > > > > * Adding new packages to OpenWRT > > * "Hello, world!" package for OpenWrt > > * Preparing, configuring, and building the necessary tools > > * Adjusting the PATH variable > > * Conclusion > > * Creating a simple “Hello, world!” application > > * Creating the source code directory and files > > * Compiling, linking, and testing the application > > * Conclusion > > * Creating a package from your application > > * Creating a package feed for your packages > > * Creating the package manifest file > > * Conclusion > > * Including your package feed into OpenWrt build system > > * Including the new package feed into the OpenWrt build system > > * Updating and installing feeds > > * Conclusion > > * Building, deploying and testing your application > > * Building the package > > * Deploying and testing your package > > * Removing your package > > * Conclusion > > * Migrating to use GNU make in your application > > * Why use GNU make ? > > * Creating a makefile > > * Testing the makefile using native tools > > * Modifying the package manifest, and testing the build > > * Conclusion > > * Patching your application: Adding new files > > * About patches > > * Preparing the source code > > * Creating the first patch > > * Including the first patch into the package > > * Conclusion > > * Create a sample procd init script > > *
Re: Migrating ISC to Kea DHCP blocked on related PR's
On 2023-12-09 23:47, Philip Prindeville wrote: Hi all, I'm working on a drop-in for Kea that will parse existing ISC-DHCP configurations in UCI and crank out the derivative JSON config files for Kea, but I have a couple of PR's that are necessary to making this happen that have been pending for several weeks: https://github.com/openwrt/openwrt/pull/13765 https://github.com/openwrt/libubox/pull/6 For those who don't know: Kea DHCP is ISC's replacement for its own ISC DHCP daemon. ISC DHCP reached end of life 2022. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Restructuring OpenWRT documentation
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Dear OpenWRT developer, I hope this message finds you well. As a user of OpenWRT, I would like to express my appreciation for the excellent work you have done in creating such a comprehensive documentation. However, I have noticed that the current structure can be challenging for new users to navigate, which can be discouraging for them. In an effort to help improve the user experience, I would like to suggest a restructuring scheme based on the Buildroot user manual. I believe that this scheme could make the documentation more accessible and user-friendly, which would in turn help attract more users to OpenWRT. I understand that you have put a lot of effort into creating the documentation, and I want to assure you that my intention is not to criticize your work. Rather, I hope that my suggestion can contribute to the continued success of OpenWRT. The new structure: --- Developer guide * Overview * OpenWRT source code * Getting the source code * Working with GitHub * Revision number calculation * Build system: * Build System essentials * System setup * Linux * MacOS * Windows (WSL) * Setting up a build server in VirtualBox * Build system usage * Quick image-building guide * Using build environments * Overriding Build Options * Using the SDK * Cross Compiling your application * Using External Toolchain * Image Builder frontends * Using the Image Builder * OpenWrt Feeds * Adding new packages to OpenWRT * "Hello, world!" package for OpenWrt * Preparing, configuring, and building the necessary tools * Adjusting the PATH variable * Conclusion * Creating a simple “Hello, world!” application * Creating the source code directory and files * Compiling, linking, and testing the application * Conclusion * Creating a package from your application * Creating a package feed for your packages * Creating the package manifest file * Conclusion * Including your package feed into OpenWrt build system * Including the new package feed into the OpenWrt build system * Updating and installing feeds * Conclusion * Building, deploying and testing your application * Building the package * Deploying and testing your package * Removing your package * Conclusion * Migrating to use GNU make in your application * Why use GNU make ? * Creating a makefile * Testing the makefile using native tools * Modifying the package manifest, and testing the build * Conclusion * Patching your application: Adding new files * About patches * Preparing the source code * Creating the first patch * Including the first patch into the package * Conclusion * Create a sample procd init script * Patching your application: Editing existing files * Creating the second patch * Conclusion * Adding existing packages to OpenWRT * Autotools packages * Cmake packages * Meson packages * Packages with other specific build systems * Patching a package ( Working with patches) * Using Dependencies * Debugging * GNU Debugger * Device management in OpenWRT * Adding a new device * Adding new device support * Adding new platform support * Device support policies / best practices * Device Tree Usage in OpenWrt (DTS) * Mounting Block Devices -- Thank you for your consideration. The full structure is attached. Best regards, Javad Rahimipetroudi Developer guide * Overview * OpenWRT source code * Getting the source code * Working with GitHub * Revision number calculation * Build system: * Build System essentials * System setup * Linux * MacOS * Windows (WSL) * Setting up a build server in VirtualBox * Build system usage * Quick image-building guide * Using build environments * Overriding Build Options * Using the SDK * Cross Compiling your application * Using External Toolchain * Image Builder frontends * Using the Image Builder * OpenWrt Feeds * Adding new packages to OpenWRT * "Hello, world!" package for OpenWrt * Preparing, configuring, and building the necessary tools * Adjusting the PATH variable * Conclusion * Creating a simple “Hello, world!” application * Creating the source code directory and files * Compiling, linking, and testing the application * Conclusion * Creating a package from your
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan wrote: > > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: > > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: > > > > > > Hi Robert, > > > > > > Adding John's correct e-mail to the loop. > > > > > > On 8.12.2023 11:02, Robert Marko wrote: > > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > > >> > > > >> Hi Robert, > > > >> > > > >> On 7.12.2023 12:52, Robert Marko wrote: > > > >> > > > > >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: > > > >> >> 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. > > > >> >> This patch just has the base SoC/board support and not drivers for > > > >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind > > > >> >> of split is acceptable for the community. > > > >> >> > > > >> >> Thanks > > > >> >> Varada > > > >> > > > > >> > Hi, > > > >> > I would at least split the target itself, patches and then the board > > > >> > itself for the start. > > > >> > > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx > > > >> just another subtarget of it (I'm aware of A53 vs. A73)? > > > > > > > > That depends on how much is shared between the AX SoC-s and the BE > > > > ones(IPQ95xx and IPQ53xx). > > > > > > I would say enough to keep them together. > > > > > > > But, I would prefer that or qualcommbe target where new BE SoC-s will > > > > be subtargets. > > > > > > I'm personally more a fan of limiting number of top targets and deal > > > with differences under subtargets. > > > > Same here, better than to add more targets especially since a lot is shared. > > Thanks for your inputs. > > Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference > since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx > as subtarget? I would prefer qualcomm and not ipq, and then ipq95xx as subtarget. Regards, Robert > > Kindly let me know. > > Thanks > Varada > > > > > Regards, > > Robert > > > > > > -- > > > Cheers, > > > Piotr > > > > > > > > > > > Regards, > > > > Robert > > > >> > > > >> -- > > > >> Cheers, > > > >> Piotr > > > >> > > > >> > > > > >> > Also, please sort the patches by prefix such as: > > > >> > 0xx are backports (Kernel version from which they are backported > > > >> > must be > > > >> > marked as well) > > > >> > 1xx are pending > > > >> > 9xx are usually hacks/stuff that currently cannot be upstreamed. > > > >> > > > > >> > Again, I would strongly encourage using Github PR for large changes > > > >> > such > > > >> > as these as its much > > > >> > easier to comment on certain changes and it has a lot larger reach > > > >> > than > > > >> > the OpenWrt mailing list > > > >> > as not all interested parties even follow this list. > > > >> > > > > >> > Regards, > > > >> > Robert > > > >> > > > > >> > > > > >> > ___ > > > >> > openwrt-devel mailing list > > > >> > openwrt-devel@lists.openwrt.org > > > >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > >> > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
