process to develop linux 5.4

/**
 * nand_get_sdr_timings - get SDR timing from data interface
 * @conf:       The data interface
 */
static inline const struct nand_sdr_timings *
nand_get_sdr_timings(const struct nand_data_interface *conf)
{
        if (conf->type != NAND_SDR_IFACE)
                return ERR_PTR(-EINVAL);

        return &conf->timings.sdr;
}

/**
 * nand_get_interface_config - Retrieve the current interface configuration
 *                             of a NAND chip
 * @chip: The NAND chip
 */
static inline const struct nand_interface_config *
nand_get_interface_config(struct nand_chip *chip)
{
        return chip->current_interface_config;
}

struct nand_controller_ops {
        int (*attach_chip)(struct nand_chip *chip);
        void (*detach_chip)(struct nand_chip *chip);
        int (*exec_op)(struct nand_chip *chip,
                       const struct nand_operation *op,
                       bool check_only);
        int (*setup_data_interface)(struct nand_chip *chip, int chipnr,
                                    const struct nand_data_interface *conf);
};

nand_get_sdr_timings

5.4 

/**
 * nand_get_sdr_timings - get SDR timing from data interface
 * @conf:       The data interface
 */
static inline const struct nand_sdr_timings *
nand_get_sdr_timings(const struct nand_data_interface *conf)
{
        if (conf->type != NAND_SDR_IFACE)
                return ERR_PTR(-EINVAL);

        return &conf->timings.sdr;
}

ft
/**
 * nand_get_sdr_timings - get SDR timing from data interface
 * @conf:       The data interface
 */
static inline const struct nand_sdr_timings *
nand_get_sdr_timings(const struct nand_interface_config *conf)
{
        if (!nand_interface_is_sdr(conf))
                return ERR_PTR(-EINVAL);

        return &conf->timings.sdr;
}


nand_data_interface
nand_interface_config

/**
 * nand_get_sdr_timings - get SDR timing from data interface
 * @conf:       The data interface
 */
static inline const struct nand_sdr_timings *
nand_get_sdr_timings(const struct nand_interface_config *conf)
{
        if (!nand_interface_is_sdr(conf))
                return ERR_PTR(-EINVAL);

        return &conf->timings.sdr;
}

/**
 * nand_get_sdr_timings - get SDR timing from data interface
 * @conf:       The data interface
 */
static inline const struct nand_sdr_timings *
nand_get_sdr_timings(const struct nand_data_interface *conf)
{
        if (conf->type != NAND_SDR_IFACE)
                return ERR_PTR(-EINVAL);

        return &conf->timings.sdr;


}


struct nand_interface_config
 

BE65PRO Compilation Walkthrough: From Repo to Build This document provides a full walkthrough for setting up a build environment, fetching the source code, and compiling the BE65PRO firmware. It assumes you have already completed the initial Jenkins and Gerrit integration steps. The process is divided into three main parts: Setting Up the repo Tool: Installing the Google repo utility. Fetching the Source Code: Configuring access and downloading the multi-repository source. Compiling the Firmware: Building the firmware inside a Docker container. Automating with Jenkins: Creating a Jenkins job to run the build pipeline. Part 1: Setting Up the Repo Tool Before you can sync the source code, you must install Google's repo tool. Choose the method that matches your network environment. For more background, refer to the Repository Migration Guide. Online Method (For Unrestricted Networks) This is the recommended method if your server has direct internet access. Option A: Using apt (Easiest) For Debian-based systems like Ubuntu, you can install it directly from the package manager. sudo apt update sudo apt install repo Option B: Manual Installation If apt is not available or you prefer a manual install: # 1. Create a bin directory in your home folder mkdir -p ~/bin # 2. Download the repo tool launcher curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # 3. Make it executable chmod a+x ~/bin/repo # 4. Add the bin directory to your PATH export PATH=~/bin:$PATH # 5. (Optional) Add it to your shell profile for future sessions echo 'export PATH=~/bin:$PATH' >> ~/.bashrc source ~/.bashrc Offline Method (For Restricted Networks) If your build server cannot access the internet, you must prepare the repo tool on a machine with internet access and then transfer it. REFER TO -- RESOURCES -- To download prepare_offline_repo.sh and repo-offline.py Step 1: On a Machine WITH Internet Access Download and Run prepare_offline_repo.sh Step 2: On the Offline Build Server Transfer repo_tool_offline.tar.gz to the offline server. Create the necessary directory structure and extract the archive. mkdir -p .repo/repo tar -xzf repo_tool_offline.tar.gz -C .repo/repo This HAS to be done for each "monorepo" (i.e. prplink_projects) This is automated and explained more in the Jenkins Job Creation Section. Replace the repo launcher script. The standard launcher tries to connect to the internet. Use this modified version that works completely offline, in conjuction with the tar.gz file transfer. You can get the script from this link. Save the content of the link as ~/bin/repo and make it executable: chmod a+x ~/bin/repo Part 2: Fetching the Source Code With the repo tool installed, you can now fetch the project's source code. This involves configuring SSH access to Gerrit and using repo to sync the repositories defined in the project manifest. Step 1: Configure SSH for Gerrit The manifest.xml uses an SSH alias (gerrit) to connect to the Gerrit server. You must configure this in your ~/.ssh/config file. Open or create the ~/.ssh/config file: nano ~/.ssh/config Add the following block, replacing the HostName and User with the correct values for your environment. Host gerrit HostName [GERRIT_IP] User your.username Port 29418 IdentityFile ~/.ssh/id_rsa Step 2: Initialize and Sync the Repo Now, use repo to initialize your local environment and download all the source code. Create a directory for your project and cd into it: mkdir prplink cd prplink mkdir -p .repo/repo # Do these for offline approach tar -xzf ../repo_tool_offline.tar.gz -C .repo # Do these for offline approach Initialize the repo. This command downloads the manifest file from the prplink_projects repository. repo init -u ssh://gerrit/prplink_projects -b Deco/be65pro_v1 -m manifest.xml -u: Specifies the URL of the repository containing the manifest file. -b: The branch in the manifest repository (Deco/be65pro_v1). -m: The name of the manifest file to use (manifest.xml). Sync all repositories defined in the manifest: repo sync -c -j8 -v -c: Syncs only the current branch, saving bandwidth. -j8: Uses 8 parallel jobs for faster download. -v: Verbose output. After this step, your prplink directory will be populated with all the source code required for the build. cd prplos repo forall -c ' # Only run if HEAD is detached if [ -z "$(git symbolic-ref --short -q HEAD)" ]; then # Get the remote branch names from origin/gerrit for b in $(git branch -r | grep "gerrit/" | sed "s|gerrit/||"); do # Just pick the branch that exists remotely git checkout -B $b gerrit/$b break done fi ' branch 'develop' set up to track 'gerrit/develop'. branch '12.2' set up to track 'gerrit/12.2'. branch '5.4.213' set up to track 'gerrit/5.4.213'. branch 'develop' set up to track 'gerrit/develop'. branch 'develop' set up to track 'gerrit/develop'. branch 'develop' set up to track 'gerrit/develop'. branch 'develop' set up to track 'gerrit/develop'. branch 'develop' set up to track 'gerrit/develop'. for p in $(repo list -p); do echo "=== $p ===" (cd "$p" && git branch -a) done === prplos/board/qca_ipq53xx === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/board/qca_ipq53xx/sdk/12.2 === * 12.2 remotes/gerrit/12.2 remotes/m/Deco/be65pro_v1 -> gerrit/12.2 === prplos/board/qca_ipq53xx/sdk/12.2/qca/src/linux-5.4 === * 5.4.213 remotes/gerrit/5.4.213 remotes/m/Deco/be65pro_v1 -> gerrit/5.4.213 === prplos/board/qca_ipq53xx/sdk/12.2/qca/src/qca-hostap === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/board/qca_ipq53xx/sdk/12.2/qca/src/qca-wifi === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/platform === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/platform/feeds/private/wifix === * (no branch) remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/platform/src/private/cli === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop === prplos/platform/src/public/dropbear === * develop remotes/gerrit/develop remotes/m/Deco/be65pro_v1 -> gerrit/develop Part 3: Compiling BE65PRO with Docker After syncing the source, you can proceed with compilation inside the provided Docker container. Step 1: Prepare Your Environment Ensure the ubuntu18.04-be65pro.tar file is located in your ~/prpLink/ directory. Navigate to the directory : cd ~/prpLink Step 2: Load and Run the Docker Container Load the Docker image: sudo docker load -i ~/prpLink/ubuntu18.04-be65pro.tar Run the container, mounting your local ~/prpLink directory: sudo docker run -it --name ubuntu18.04-be65pro -v ~/prpLink:/home/compile/prpLink ubuntu18.04-be65pro /bin/bash Note: If the container is already running, attach to it using sudo docker exec -it ubuntu18.04-be65pro /bin/bash. Step 3: Compile the Firmware Inside the container, log in as the compile user (password: compile). login compile Navigate to the build directory: cd board/qca_ipq53xx/build Run the compilation command: make MODEL=be65pro SPEC=TEST all Part 4: Jenkins Freestyle Job Setup This section describes how to automate the build process using a Jenkins Freestyle job. Step 1: Create a Freestyle Job Go to your Jenkins dashboard, click "New Item", enter a job name, and select "Freestyle project". Step 2: Configure Source Code Management Under "Source Code Management", select "Git" and enter your repository URL (use SSH if required). Step 3: Add Gerrit Trigger In "Build Triggers", check "Trigger on comment added" (requires the Gerrit Trigger plugin). Step 4: Add Build Step (Shell Script) Add a "Build" step of type "Execute shell" and use the following script to run the Docker build: # Start the container in detached mode CONTAINER_ID=$(docker run -d -u compile -v /build/prplink:/home/compile/prpLink ubuntu18.04-be65pro:latest tail -f /dev/null) # Run commands inside the container docker exec $CONTAINER_ID sh -c ' echo "Current user:" whoami echo "Current directory:" pwd cd /home/compile/prpLink/board/qca_ipq53xx/build make MODEL=be65pro SPEC=TEST all ' # Optionally stop and remove the container after build docker stop $CONTAINER_ID docker rm $CONTAINER_ID Notes: Adjust /build/prplink to match your Jenkins workspace or source directory. The job will automatically compile the firmware inside the Docker container as the compile user. You can further configure post-build actions to report results back to Gerrit or archive build artifacts. Important: Developer Workflow Requirements As outlined in the repository migration guide, all commits must adhere to strict security and traceability standards. DCO Sign-off: All commits must include a Signed-off-by line. Use git commit -s. GPG Signature: All commits must be cryptographically signed with your GPG key. Use git commit -S. Make sure your git and Gerrit account are configured for both DCO and GPG signing before contributing code.
12-12
3. Design 3.1. Component Classification Most networking product components and their sensitivity types should be listed here under the "Networking Product" sheet. Component names may differ from one product to another. Match them as best as possible. TPS Networking Products Sensitivity Classification Component, library, and package sensitivity levels need to be classified as High, Medium, or Low. Each component is scored with a sensitivity matrix containing 7 criteria, assigned a level (0 to 2) per criteria, then summed for the total points. The total points determine the component’s sensitivity level of High, Medium, or Low. 7 criteria to determine sensitivity levels include: User Data and Secrets * System Privilege Management * Attack Surface * System Stability Cloud Proprietary Security * * Components are automatically classified as High sensitivity if they categorize in any of the following critical criteria: User Data and Secrets, System Privilege Management, Attack Surface, or Security. Source: TP-Link Component Sensitivity Scoring Framework.pdf TPS Home Networking and Enterprise Networking teams have reorganized repositories in backhand index pointing right SCR LZ Organization.xlsx backhand index pointing left 3.2. Understand Product's Current Repository and Code Structure In iplatform Deco BE65 v3.0, 4 repositories are combined for the full product code base as of 2025年10月6日 (repository: branch): prplink Platform prplos: develop_prplink_epoch_20250818 Qualcomm Vendor SDK (QCA SDK 12.2) Deco/SDK/QCA/qca_95xx_12_2: master.stable.dvp.prpl Qualcomm WiFi Driver (QCA WiFi) wifi-driver/qca/qca-wifi-12.x: 12.2_cs TP-Link Generic WiFi Driver Config Script wifi-driver/wifix: master These repositories contain standalone components and corresponding Makefile structures for feeds/ and src/ modules. Therefore, when reorganizing the repositories, we must maintain the existing code architecture via the Google repo tool's manifest.xml with the existing component destination path. 3.3. Prepare Completely New Repositories and Branches Keep the repository and branch name scheme consistent across all TP-Link products. The following repository structure is based on prplink projects (expansion on OpenWRT). Different teams' projects may have different software architecture; however, the main goal is to quarantine Kernel and high sensitivity modules individually in their own repositories and configure the top-level product manifest.xml point to all relative project repositories and branches. 3.3.1. exclamation markexclamation markexclamation markREQUIRED - Repository Descriptionsexclamation markexclamation markexclamation mark These descriptions increase transparency and traceability from code to software. 3.3.1.1. REQUIRED: Gerrit Description All Gerrit Repos update their repo description sections to have the following information (follow specific format required for automated checks) Business Unit - HN, CE, ES, EN, SP, COMMON SERVICE, IT POC/Team Name - A project lead or primary coder Related Products - What products is this code involved in? Tapo, Festa, etc. If the branch is only used for Permissions, put Permissions as the Product Example: {High-level description | Other information} #BU {Business Unit Acronym} #POC {Name and email of person or team} #Products {CSV list of products} 3.3.1.2. REQUIRED: Repository Content Repositories must have a README with the following information Business Unit POC Team Products High-level overview Requirements/Dependencies Build process Link to additional documentation Link to Changelog/release information All repos must have the latest, stable code in a single main/master branch Projects with multiple code sets should be separated into their own repositories 3.3.1.3. REQUIRED: Security Champion's FiniteState JAR File Security Champions please refer to: 01 - How To: Jenkins SAST SCA Integration to obtain finitestate.jar to push and merge to the top-level of every repository. (Questions and access contact Jevin Evans Kajol Patil ). The JAR file is generated from FiniteState account of the Security Champion and used for binary scanning in Jenkins (in CI/CD + SAST + SCA). Authorized TPS U.S. Security Engineers and Project Leaders will be appointed as Security Champions for LZ projects and these appointed Security Champions will be responsible for pushing their JAR file for SCA scan to every repository. 3.3.2. Repository - Product - Manifest prplink projects with product branches containing manifest.xml pointing to component repos/branches Repository Branch prplink_projects Deco/be65pro_v1_SECURE Deco/be65pro_v1 The product's/project's non-secure branch contains manifest.xml pointing to ongoing development branches of each sub-repository for core modules (high vulnerability), base modules, vendor SDK modules, and platform required directories and files. The product's/project's secure branch contains manifest.xml pointing to secure master branches of each sub-repository for all modules. Secure master branches are automatically maintained by CI/CD post security scans. Propagation Example: Aginet/xgb834v Repository Branch manifests/HNE Deco/BE65_v3.0_SECURE Deco/BE65_v3.0 3.3.3. Create New Repositories Reference collaborative document for New Repository names and structure: SCR LZ Organization.xlsx Naming guideline: # <Project Family>/<Sensitivity Classification>/<Development Source>/<Module/Package Dependent> # core = High sensitivity # base = Medium/Low sensitivity # public = opensource # private = TPS proprietary # vendor = SDK or vendor distributed # Examples: # QCA SDK 12.5 Deco/core/vendor/qca/12.5/linux-5.4.213 Deco/base/vendor/qca/12.5/sdk Deco/base/vendor/qca/12.5/qca-wifi Deco/core/vendor/qca/12.5/qca-hostap # iplatform High Sensitivity Modules Deco/core/public/accel-pptpd Deco/core/public/bridge-utils Deco/core/public/busybox Deco/core/public/conntrack-tools Deco/core/public/dropbear Deco/core/private/extctl Deco/core/public/firewall Deco/core/public/improxy Deco/core/public/libssh Deco/core/public/luci Deco/core/private/luci-apps Deco/core/public/resolveip Deco/core/public/rp-pppoe Deco/core/private/tdb Deco/core/private/tipc-server Deco/core/public/uhttpd Deco/core/public/arptables Deco/core/public/curl Deco/core/public/libwebsockets # Common iplatform Deco/base/iplatform Deco/base/vendor/Bluetooth/AC63 Deco/base/private/package/tddp Deco/base/private/package/webpages # Common General base/private/wifix Reference and use the 2 bash scripts below to help generate new repositories. create_repo_desc.sh repo_desc.txt The create_repo_desc.sh uses SSH Gerrit access to create new projects with master branch and populate description. Modify Gerrit Server IP Address, credentials, repo_desc.txt repository names and descriptions create_branches.sh repo_branches.txt The create_branches.sh creates develop branches per new repository with desired name. All development will be done in develop. Master is reserved for post QA/Security Scanning for release. Develop branches will not merge to master without proper verification and authorization.
12-20
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值