Files
u-boot/CLAUDE.md
Simon Glass ddc358dc6c Update Claude instructions for uman
Suggest using the new uman tool.

Signed-off-by: Simon Glass <simon.glass@canonical.com>
2026-01-03 12:39:14 -07:00

77 lines
2.4 KiB
Markdown

# U-Boot Build Instructions for Claude Code
This file contains information about building U-Boot for use with Claude Code.
## Building U-Boot
### Using uman (Recommended)
To build U-Boot for sandbox testing, use the `um` command:
```bash
# Build for sandbox without LTO (um is a symlink to uman)
um build sandbox [flags]
# The -l flag can be used to enable LTO
# The build is silent unless there are warnings or errors
# The build is done in /tmp/b/<board_name>, so /tmp/b/sandbox in this case
```
### Using make directly
If you prefer to use make directly, please use O= to avoid adding build files to
the source tree:
```bash
# Clean the build (recommended before first build)
make mrproper
# Configure for sandbox
make sandbox_defconfig O=/tmp/<build_dir>
# Build
make -j$(nproc) O=/tmp/<build_dir>
```
## Testing
There are aliases in ~/bin/git-alias which you can use.
To run a sandbox test:
```bash
um test <test_name>
# For example: rtv dm_test_video_box
# similar to: /tmp/b/sandbox/u-boot -v -Tf -c "ut dm video_box"
# test output is silenced unless -v is given
```
To run using the Python suite:
```bash
um py -B sandbox <test_name>
# similar to: test/py/test.py -B sandbox --build-dir /tmp/b/sandbox -k <test_name>
```
## Notes
- The `um` tool is the preferred build method for this codebase
- Always run `make mrproper` if you encounter build issues
- The sandbox build creates a test environment for U-Boot that runs on the host system
- When using `git diff`, add `--no-ext-diff` to avoid external diff tools that may not work in this environment
- `um build` shows no output if everything was ok!
- Remember not to cd into the build directory; run U-Boot directly in the source dir
- Do not run in-tree builds; always use the crosfw script or 'make O=/tmp/...'
## Coding Conventions
- For function parameters that return values (output parameters), add 'p' suffix to indicate pointer
- Example: `uint *sizep` instead of `uint *size`
- Example: `bool *visiblep` instead of `bool *visible`
- This follows U-Boot's established naming convention for output parameters
- Keep commit messages concise - focus on the key change and essential details only
- Code should be formatted to 80 columns and not have trailing spaces
- Remember to use Co-developed-by instead of Co-Authored-By in commits
- Test declarations (e.g., UNIT_TEST macro) should immediately follow the
closing } of the function they declare, with no blank line in between