The Flash Bootloader stack team currently manages configuration by directly modifying static .c and .h files — a valid engineering practice, but one that lacks the formal methodology and technical specification structure that AUTOSAR provides for its modules. As Qorix Developer works to bring Flash Bootloader configuration into its tooling ecosystem, a structured collaboration model is needed to:
- Surface and formalize implicit configuration knowledge living in source code
- Define a shared schema and code generation contract both teams can trust
- Ensure ongoing synchronization as the bootloader stack evolves
The framework below borrows principles from the AUTOSAR FO RS Methodology (RS_METH_00006, RS_METH_00062, RS_METH_00074, RS_METH_00208, RS_METH_00020) and adapts them to a non-AUTOSAR context.
Phase 1: Discovery & Inventory — "Reverse Engineer the Hidden Schema"
Surface every configurable parameter currently implicit in .c and .h files and produce a shared, signed-off catalogue.
Run a series of joint workshops between the Qorix Developer team and the Bootloader team to audit all #define, const, and struct fields in the bootloader source that vary per ECU or per project.
| Column | Description |
|---|---|
| Parameter Name | Identifier as used in source |
| File + Line | Current location in the codebase |
| Data Type | uint8, uint32, bool, enum, etc. |
| Valid Range / Values | Min/max or enumerated list |
| Default Value | Baseline value used |
| Variant Usage | Which ECU/project variants use this |
| Binding Time | pre-compile, link-time, or post-build |
Note on Binding Time: This maps directly to AUTOSAR RS_METH_00074 — identifying when in the toolchain a parameter's value is resolved is essential for correct code generation.
✅ A co-signed Flash Bootloader Parameter Catalogue (spreadsheet or structured document), treated by both teams as the shared source of truth. Nothing downstream should be built without this.
Co-author a formal (but lightweight) specification that gives the bootloader configuration feature the same disciplined foundation that AUTOSAR specs provide for BSW modules.
Both teams jointly draft a Flash Bootloader Configuration Methodology document covering:
- What constitutes a "configurable parameter" in this context
- Role definitions:
- Bootloader Team → Parameter owners (define valid ranges, constraints, templates)
- Qorix Developer Team → Tool implementors (schema, generator, validation, UI)
- Allowed binding times and what each means for code generation
- Definition of a "valid configuration" including inter-parameter constraints
- Data exchange format between teams (YAML schema, template files, CI gates)
| AUTOSAR Requirement | Relevance to This Effort |
|---|---|
| RS_METH_00006 | Methodology explaining how to build the system |
| RS_METH_00062 | Supporting configuration with different binding times |
| RS_METH_00074 | Specifying binding times formally |
| RS_METH_00208 | Data exchange between different stakeholders |
| RS_METH_00020 | Round-trip engineering between teams |
✅ A living Flash Bootloader Configuration Methodology v0.1 document, maintained in Git alongside YAML schemas and updated with each bootloader stack release.
Translate the Parameter Catalogue into a formal, versioned YAML schema that Qorix Developer can consume, validate, and generate code from.
Run a focused 2–3 week sprint:
- Qorix team drafts an initial
flash-bootloader.schema.jsonbased on the catalogue - Bootloader team reviews for correctness and surfaces undocumented constraints
- Both teams iterate until the schema fully represents the parameter space
# flash-bootloader.yaml
$schema: https://schemas.qorix.dev/flash-bootloader.schema.json
memory_layout:
flash_block_size_bytes:
erase_page_size_bytes:
start_address:
end_address:
timing:
erase_timeout_ms:
write_timeout_ms:
verify_timeout_ms:
communication:
protocol: can | lin | eth | custom
channel_id:
baud_rate:
security:
seed_key_algorithm: aes128 | rsa2048 | custom
security_level:
key_length_bytes:
job_handling:
max_block_length:
checksum_algorithm: crc16 | crc32 | none
response_pending_threshold_ms:Each parameter entry in the schema should carry:
name,type,default,valid_range,binding_time, anddescription. Thedescriptionfield is critical for AI-assist features to generate meaningful suggestions.
✅ Versioned flash-bootloader.schema.json and a reference flash-bootloader.yaml example project, merged into the Qorix Developer repository.
Establish a clear, team-owned contract between the YAML configuration and the generated .c/.h output files.
The Bootloader team owns the templates. The Qorix team owns the generator.
This division of ownership ensures the bootloader team retains control of their stack's structure while Qorix handles the tooling layer.
Mark every variable region in existing .c/.h files with generator annotations:
/* @QORIX_GEN: memory_layout.flash_block_size_bytes */
#define FBL_FLASH_BLOCK_SIZE 512U
/* @QORIX_GEN: timing.erase_timeout_ms */
#define FBL_ERASE_TIMEOUT_MS 250U
/* @QORIX_GEN: security.security_level */
#define FBL_SECURITY_LEVEL 0x01UThe Qorix Rust code generator reads flash-bootloader.yaml and uses these annotations as injection points — analogous to how AUTOSAR BSW generators consume ARXML and write into pre-defined template structures.
| Contract Element | Owner |
|---|---|
Template .c/.h files with annotations |
Bootloader Team |
flash-bootloader.schema.json |
Qorix Team |
| Rust code generator (YAML → templates) | Qorix Team |
| Validation that output files compile correctly | Joint (CI) |
✅ Annotated template source files owned by the bootloader team, and a Rust code generator in Qorix Developer that maps flash-bootloader.yaml → those templates.
Encode the bootloader team's constraint knowledge as formal validation rules surfaced in the Qorix IDE — not just "invalid" but actionable, context-aware errors.
RULE: flash_block_size_bytes must be a multiple of erase_page_size_bytes
ERROR: "flash_block_size_bytes ({value}) is not a multiple of erase_page_size_bytes ({value}).
Adjust to the nearest valid multiple: {suggestion}."
RULE: erase_timeout_ms must be ≥ 3× the rated erase cycle time of the target flash device
ERROR: "erase_timeout_ms ({value}ms) is below the minimum safe threshold for this
memory device. Recommended minimum: {suggestion}ms."
RULE: security_level must be compatible with the selected communication protocol
ERROR: "Security level {value} requires ETH protocol. Current protocol is CAN —
adjust either security_level or communication.protocol."
These rules are registered in the Rust Domain Service and surface as squiggles and Problems panel diagnostics in the IDE (VS Code/Theia), consistent with how existing YAML validation works across the platform.
✅ A formal Validation Rule Registry, co-signed by both teams, maintained as part of the Bootloader Configuration Methodology document from Phase 2.
Ensure the Qorix Developer configuration feature stays in sync with every bootloader stack update through automated gates and a clear ownership model.
Bootloader Team Qorix Developer Team
────────────── ──────────
1. Update bootloader stack
2. Update Parameter Catalogue
3. Update annotated templates
4. Open PR with changes
│
▼
CI Pipeline runs:
├─ Schema coverage check
│ (all @QORIX_GEN annotations
│ covered by schema?)
├─ Reference YAML validation
├─ Code generation smoke test
└─ Compilation check of output
│
▼
Qorix Team reviews:
5. Update schema if new params added
6. Update validation rules
7. Update generator if template
structure changed
│
▼
Joint sign-off → Release
Policy: No bootloader stack release is considered complete until the Qorix configuration feature has been validated against it. This should be encoded as a formal CI gate in the bootloader team's release pipeline.
✅ CI pipeline with schema coverage, validation, and generation smoke tests. ✅ Documented update process embedded in both teams' Definition of Done.
| Phase | Key Activity | Primary Owner | Deliverable |
|---|---|---|---|
| 1 – Discovery | Parameter audit workshops | Joint | Parameter Catalogue |
| 2 – Methodology | Co-author specification | Joint | Bootloader Config Methodology v0.1 |
| 3 – Schema Design | YAML schema sprint | Qorix leads, BL reviews | flash-bootloader.schema.json |
| 4 – Code Gen Contract | Annotate templates, build generator | BL owns templates, Qorix owns generator | Annotated templates + Rust generator |
| 5 – Validation | Encode constraint rules in IDE | Joint | Validation Rule Registry |
| 6 – CI & Governance | Automated gates + update process | Joint | CI pipeline + updated DoD |
Lower the barrier to Phase 1. Position the Parameter Catalogue workshop as "let's review your existing code together" rather than "let's write formal specs." The bootloader team is more likely to engage if it feels like a code review than a documentation exercise.
Start with one module. Don't try to catalogue the entire bootloader in one pass. Pick one logical group (e.g., flash memory layout parameters) and build the full pipeline for it end-to-end first. Prove the workflow works before scaling.
Use the bootloader team's language in the schema. Don't rename parameters into Qorix or AUTOSAR naming conventions — keep the YAML keys as close to the source code #define names as possible. This reduces cognitive load and makes the bootloader team's review of the schema far more productive.
Version the methodology document like code. Keep it in Git, use semantic versioning, and link each version to the bootloader stack version it corresponds to. This is the single most important practice for long-term maintainability.
Document Version: 1.0 | Prepared by: Qorix Developer Team | Based on AUTOSAR FO RS Methodology R24-11