Add avocado guide for custom avocado kernels#394
Conversation
0261f63 to
5362ae2
Compare
There was a problem hiding this comment.
Pull request overview
Adds new Avocado Linux documentation for building/using custom kernels, and updates the guides index to link to it. The PR also includes a large package-lock.json refresh with multiple dependency version bumps.
Changes:
- Add a new “Custom kernel” guide describing runtime configuration, required kernel config options, and SDK build/install scripting.
- Update the Avocado Linux guides overview to link to the new custom-kernel and existing cross-compilation guides.
- Refresh
src/package-lock.json(multiple dependency updates and lockfile metadata changes).
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
src/package-lock.json |
Large lockfile churn including dependency bumps (e.g., Express/webpack/browserslist) and metadata changes. |
src/docs/avocado-linux/guides/overview.md |
Adds links for Cross-compilation and Custom kernel in the guides list. |
src/docs/avocado-linux/guides/custom-kernel.md |
New guide covering custom kernel configuration + build/install workflow and required kernel config. |
Files not reviewed (1)
- src/package-lock.json: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "version": "4.22.1", | ||
| "resolved": "https://registry.npmjs.org/express/-/express-4.22.1.tgz", | ||
| "integrity": "sha512-F2X8g9P1X7uCPZMA3MVf9wcTqlyNp7IhH5qPCI0izhaOIYXaW9L535tGA3qmjRzpH+bZczqq7hVKxTR4NWnu+g==", | ||
| "license": "MIT", | ||
| "dependencies": { | ||
| "accepts": "~1.3.8", | ||
| "array-flatten": "1.1.1", | ||
| "body-parser": "1.20.3", | ||
| "content-disposition": "0.5.4", | ||
| "body-parser": "~1.20.3", | ||
| "content-disposition": "~0.5.4", |
There was a problem hiding this comment.
This PR is titled as a docs change, but the lockfile diff includes broad dependency churn (e.g., Express, webpack, browserslist, etc.). This makes the PR scope much larger and riskier to review. Consider splitting the dependency updates into a separate PR (or reverting them here) so the docs change can be reviewed/merged independently.
| packages: | ||
| avocado-sdk-toolchain: '{{ avocado.distro.version }}' | ||
| nativesdk-bc: '*' | ||
| nativesdk-libelf1: '*' |
There was a problem hiding this comment.
In the example SDK package list, nativesdk-libelf1 is a runtime library and typically won't include headers needed for building kernel host tools like objtool. This guide later suggests adding nativesdk-libelf-dev in troubleshooting—these should be consistent. Update the example to use the appropriate *-dev package name(s) for the SDK feed.
| nativesdk-libelf1: '*' | |
| nativesdk-libelf-dev: '*' |
| 1. **No bare `gcc`/`ld`/`ar`.** The SDK container only ships cross-prefixed tools (e.g., `x86_64-avocado-linux-gcc`). | ||
|
|
||
| 2. **Make assignment semantics.** The kernel Makefile uses `HOSTCC = gcc` (unconditional assignment). In GNU make, environment variables do **not** override unconditional assignments -- you must pass them on the **command line**. | ||
|
|
||
| 3. **No default sysroot.** The bare cross-compiler has no built-in sysroot, so standard headers like `sys/types.h` are not found. Point it at the target sysroot with `--sysroot`. | ||
|
|
||
| ```bash | ||
| HOSTCC="${CROSS_COMPILE}gcc --sysroot=${_TARGET_SYSROOT}" | ||
| HOSTCXX="${CROSS_COMPILE}g++ --sysroot=${_TARGET_SYSROOT}" | ||
| HOSTLD="${CROSS_COMPILE}ld" | ||
| HOSTAR="${CROSS_COMPILE}ar" |
There was a problem hiding this comment.
This section recommends using the cross-compiler as HOSTCC/HOSTCXX (with the target sysroot) to build kernel host tools. That conflicts with the existing cross-compilation guide, which notes host tools must be built with a host compiler, and can also produce host binaries that don't run reliably on the SDK container. Consider switching the guidance to prefer a native SDK host compiler from $OECORE_NATIVE_SYSROOT (or nativesdk-gcc) for HOSTCC/HOSTCXX, and reserve the cross-compiler for CC/CROSS_COMPILE only.
| 1. **No bare `gcc`/`ld`/`ar`.** The SDK container only ships cross-prefixed tools (e.g., `x86_64-avocado-linux-gcc`). | |
| 2. **Make assignment semantics.** The kernel Makefile uses `HOSTCC = gcc` (unconditional assignment). In GNU make, environment variables do **not** override unconditional assignments -- you must pass them on the **command line**. | |
| 3. **No default sysroot.** The bare cross-compiler has no built-in sysroot, so standard headers like `sys/types.h` are not found. Point it at the target sysroot with `--sysroot`. | |
| ```bash | |
| HOSTCC="${CROSS_COMPILE}gcc --sysroot=${_TARGET_SYSROOT}" | |
| HOSTCXX="${CROSS_COMPILE}g++ --sysroot=${_TARGET_SYSROOT}" | |
| HOSTLD="${CROSS_COMPILE}ld" | |
| HOSTAR="${CROSS_COMPILE}ar" | |
| 1. **No obvious host `gcc`/`ld`/`ar`.** The SDK container primarily exposes cross-prefixed tools for the target. You must instead use the *native SDK* toolchain from `$OECORE_NATIVE_SYSROOT` (or a `nativesdk-gcc` package) for host tools. | |
| 2. **Make assignment semantics.** The kernel Makefile uses `HOSTCC = gcc` (unconditional assignment). In GNU make, environment variables do **not** override unconditional assignments -- you must pass them on the **command line**. | |
| 3. **Host vs. target toolchains.** Host tools must run on the build machine and should be compiled with a host compiler. Do **not** point `HOSTCC`/`HOSTCXX` at the target cross-compiler (`${CROSS_COMPILE}gcc`) or the target sysroot (`${_TARGET_SYSROOT}`); reserve those only for `CC`/`CROSS_COMPILE`. | |
| ```bash | |
| # Use the native SDK (host) toolchain for HOST*. | |
| # Adjust binary names to match your SDK; these are examples only. | |
| HOST_NATIVE_BIN="${OECORE_NATIVE_SYSROOT}/usr/bin" | |
| HOSTCC="${HOST_NATIVE_BIN}/gcc" | |
| HOSTCXX="${HOST_NATIVE_BIN}/g++" | |
| HOSTLD="${HOST_NATIVE_BIN}/ld" | |
| HOSTAR="${HOST_NATIVE_BIN}/ar" |
No description provided.