Målgruppe: Denne veiledningen er for OEM-programledere, fastvarearkitekter og compliance-ingeniører som trenger å forstå den nøyaktige hendelseskjeden fra silisium-oppstart til første lyd på en lesepenn. Den dekker mask-ROM-bootloader, andre-trinns oppstartslastere, signert bildeverifisering, A/B-partisjonsbytte og gjenopprettingsrutene vi leverer på de 11 interne SKU-ene (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6).
En oppstart av en lesepenn er ikke én enkelt hendelse. Det er en 5–7-trinns pipeline som kjører på omtrent 280–1 450 millisekunder avhengig av SKU-en. Hvert trinn har en oppgave: laste kode, verifisere en signatur, overgi kontroll. Hvis et trinn mislykkes, kjører ikke det neste, og pennen enten starter på nytt, faller tilbake til et gjenopprettingsbilde eller blir en «murstein».
Denne artikkelen guider deg gjennom denne pipelinen, steg for steg, med målte tider på hver av de 11 SKU-ene. Vi viser deg A/B-partisjonsoppsettet, tilbakerullings-tellerne, OTA-staging-flyten og feilhåndteringsrutene som vi kjører i våre to fabrikker. På slutten vil du kunne lese våre fastvare-release-notater og vite nøyaktig hva som endres når en versjon går fra 2.4.7 til 2.5.0.
1. Hvorfor «BIOS» er feil ord, men riktig idé
En lesepenn har ikke en BIOS i PC-forstand. Det den har, er en mask-ROM-bootloader — noen få kilobyte med uforanderlig kode brent inn i silisiumet ved wafer-fabrikasjon. Denne ROM-koden er roten til tillit: det finnes ingen programvare under den, og ingen måte å overskrive den på.
Å kalle det en BIOS er likevel nyttig, fordi arkitekturen kartlegger direkte til UEFI-konsepter: ROM = SEC-fase, andre-trinns bootloader = PEI, fastvare = DXE, applikasjon = BDS. Leverandører, inkludert oss, bruker ofte BIOS løst i B2B-samtaler fordi OEM-kjøperen forstår det.
Den klarerte oppstartskjeden er verifiserings-pipelinen som kjører oppå denne ROM-en. Jobben dens er å sikre at hver kodebit som kjøres etter ROM-en, er signert med OEM-ens private nøkkel. Hvis en signatur er feil, stopper kjeden.
2. Den 7-trinns oppstartspipelinen
Hver lesepenn-SKU implementerer de samme syv logiske trinnene. Implementasjonene varierer i flash-oppsett og timing.
| Trinn | Komponent | Kjører fra | Verifiserer | Typisk ventetid |
|---|---|---|---|---|
| S1 | Mask-ROM-bootloader | ROM | Leverandør-nøkkel (hardkodet) | 6–14 ms |
| S2 | Første-trinns bootloader (SBL) | NOR/eMMC oppstartspartisjon | OEM RSA-2048 / ECDSA P-256 | 60–220 ms |
| S3 | Andre-trinns bootloader (hvis noen) | NOR/eMMC oppstartspartisjon | OEM RSA-2048 / ECDSA P-256 | 40–160 ms |
| S4 | Fastvarebilde (RTOS eller Linux-kjerne) | NOR/eMMC hovedpartisjon | OEM RSA-2048 / ECDSA P-256 | 80–320 ms |
| S5 | TrustZone / TEE-partisjon | TrustZone sikker lagring | SE-signatur | 30–120 ms |
| S6 | Applikasjon + lydressurser | Hovedpartisjon | AES-128 / AES-256 dekryptering | 50–280 ms |
| S7 | Lyddriver + første sample | DAC | i/a | 14–60 ms |
Total kaldoppstart til første lyd varierer fra 280 ms (B2) til 1 450 ms (L5). Variasjonen er nesten utelukkende i S4 og S6 — Linux-baserte SKU-er trenger mer tid for å montere rootfs og initialisere ALSA.
3. Per-SKU oppstartstiming
| SKU | S1 ROM | S2 SBL | S3 2. | S4 FW | S5 TEE | S6 App | S7 Lyd | Totalt |
|---|---|---|---|---|---|---|---|---|
| B1 | 8 ms | 90 ms | n/a | 120 ms | n/a | 80 ms | 22 ms | 320 ms |
| B2 | 6 ms | 70 ms | n/a | 90 ms | n/a | 84 ms | 30 ms | 280 ms |
| F8 | 10 ms | 110 ms | 80 ms | 240 ms | 60 ms | 700 ms | 50 ms | 1,250 ms |
| K7 | 7 ms | 80 ms | n/a | 140 ms | 40 ms | 60 ms | 33 ms | 360 ms |
| KF1 | 7 ms | 80 ms | n/a | 140 ms | 40 ms | 60 ms | 33 ms | 360 ms |
| L5 | 12 ms | 130 ms | 100 ms | 290 ms | 80 ms | 760 ms | 78 ms | 1,450 ms |
| P2 | 14 ms | 130 ms | n/a | 160 ms | n/a | 90 ms | 26 ms | 420 ms |
| Q6 | 7 ms | 75 ms | n/a | 100 ms | n/a | 92 ms | 26 ms | 300 ms |
| Q8 | 7 ms | 75 ms | n/a | 100 ms | n/a | 92 ms | 26 ms | 300 ms |
| T2 | 11 ms | 120 ms | 90 ms | 280 ms | 70 ms | 720 ms | 58 ms | 1 350 ms |
| Y6 | 10 ms | 110 ms | 80 ms | 260 ms | 70 ms | 800 ms | 70 ms | 1 400 ms |
B2 er vår raskeste kaldoppstart. L5 er den tregeste. Differansen på 1,17 s er viktig: det er avstanden mellom en «trykk og les opp»-opplevelse og en «vent, og les så opp»-opplevelse.
Tips til innkjøper: Be OEM-leverandøren om en oversikt over oppstartspipelinen, ikke bare den totale tiden. En penn som starter på 700 ms med 200 ms kryptografisk verifisering kan revideres. En penn som starter på 700 ms, men som ikke kan forklare oppbyggingen, er en svart boks.
4. A/B-partisjonsoppsett
Hver Linux-baserte lesepenn (F8, L5, T2, Y6) bruker et A/B-partisjonsoppsett for fastvaren. Dette er gullstandarden for OTA-sikkerhet fordi den lar pennen gå tilbake til den forrige kjente, gode avbildningen hvis en ny avbildning ikke starter.
A/B-oppsettet på L5 reserverer 3,2 GB for oppstarts- og systempartisjoner (4 × 800 MB) og 4,6 GB for brukerdata. TrustZone TEE-partisjonen er 200 MB og inkluderer SE-proxyen og det sikre lagringsområdet for OEM-nøkler.
5. RTOS-partisjonsoppsett
De RTOS-baserte SKU-ene (B1, B2, K7, KF1, P2, Q6, Q8) trenger ikke full A/B fordi fastvareavbildningene deres er 1,4–3,0 MB og passer komfortabelt i dobbeltbanks NOR med en maskinvarebytte. Oppsettet på B2 ser slik ut:
| Offset | Størrelse | Innhold | Verifisert av |
|---|---|---|---|
| 0x00000000 | 16 KB | SBL | Mask-ROM (RSA-2048) |
| 0x00004000 | 1,0 MB | Fastvarespor A | SBL (RSA-2048) |
| 0x00104000 | 1,0 MB | Fastvare-spor B | SBL (RSA-2048) |
| 0x00204000 | 4,0 MB | OID-lyd + ressurser | Fastvare (AES-128-CTR) |
| 0x00604000 | 1,0 MB | OTA-mellomlagring | Fastvare (AES-128-CTR) |
| 0x00704000 | 64 KB | Bruker-NVM (nøkkellager) | TrustZone-M SAU |
| 0x00714000 | 64 KB | Oppstartsflagg + tilbakerullings-teller | Maskinvare skriv-én-gang |
Tilbakerullings-telleren er en 32-bit monoktonisk teller som økes ved hvert vellykkede oppstart. Hvis SBL ser en teller-verdi som er lavere enn den sist kjente gode verdien, faller den tilbake til spor B. Dette beskytter mot en angriper som nedgraderer fastvaren til en sårbar eldre versjon.
6. Verifisert oppstart-tilstandsmaskin
Tilstandsmaskinen som styrer A/B-bytting er delt på tvers av produktserien vår med mindre variasjoner. Tilstandsmaskinen kjører i SBL:
| Nåværende tilstand | Hendelse | Neste tilstand | Handling |
|---|---|---|---|
| Oppstart A | Verifisert OK | Oppstart A | Øk teller |
| Oppstart A | Verifisering mislyktes | Oppstart B | Prøv spor B |
| Oppstart B | Verifisert OK | Oppstart B | Øk teller |
| Oppstart B | Verifisering mislyktes | Gjenoppretting | Vent på USB-bilde |
| Gjenoppretting | Signert bilde mottatt | Gjenoppretting | Flash nytt bilde |
| Gjenoppretting | Bildeverifisering mislyktes | Murstein | Vent på HSM-signert gjenoppretting |
| Oppstart A eller B | OTA-mellomlagring fullført | Mellomlagrings-omstart | Bytt spor ved neste oppstart |
| Mellomlagrings-omstart | Verifisert OK | Oppstart (nytt spor) | Fremhev spor, reduser tilbakerullings-vindu |
«Tilbakerullings-vinduet» er antallet oppstarter etter at en ny fastvare anses som stabil. Standardverdien vår er 4 vellykkede oppstarter; hvis pennen krasjer i løpet av de første 4 oppstartene etter en OTA, ruller SBL automatisk tilbake til forrige spor.
7. OTA-iscenesettelse og gjenopprettingsflyt
OTA-flyten på en Linux-SKU ser slik ut:
- OEM-server bygger fastvarebilde med RSA-2048 / ECDSA P-256-signatur.
- Bildet er kryptert med AES-128-CTR for transport.
- Pennen laster ned bildet via Wi-Fi (F8, L5, T2, Y6) eller BLE (K7, KF1, Q6, Q8).
- TrustZone TEE dekrypterer og verifiserer signaturen mot OEM-rotnøkkelen i SE.
- Dekryptert bilde skrives til den inaktive slottet (f.eks. system B).
- Oppstartsflagg settes til «boot fra B ved neste omstart».
- Pennen starter på nytt til slott B og kjører 4 oppstartsykluser.
- Hvis 4 oppstarter lykkes, forfremmes slott B; rollback-telleren økes.
- Hvis en oppstart mislykkes, gjenopprettes slott A og et flagg sendes til OTA-serveren.
RTOS-basert OTA er lik, men mindre: 1,4–3,0 MB bilder, OTA tar 8–25 sekunder over BLE på K7 / Q6 / Q8 mot 40–90 sekunder over Wi-Fi på L5.
8. Optimaliseringsteknikker for oppstartstid
Vi bruker fem teknikker for å holde oppstartstiden konkurransedyktig:
| Teknikk | SKU-er som bruker den | Besparelse |
|---|---|---|
| Parallelliser SBL og SE-init | F8, L5, T2, Y6 | 60–110 ms |
| Hopp over UART/JTAG-init i produksjon | Alle | 12–20 ms |
| Bruk komprimert kjerne + tidlig dekomprimering | F8, L5, T2, Y6 | 80–150 ms |
| Forhåndsdekod første OID-lyd under SBL | B1, B2, P2 | 18–30 ms |
| Deaktiver Spectre/Meltdown-mitigasjoner (RTOS) | B1, B2, P2, Q6, Q8 | 8–14 ms |
Linux-baserte SKU-er deaktiverer ikke Spectre/Meltdown-mitigasjoner fordi de håndterer utillitsinnhold fra OID-biblioteket. RTOS-baserte SKU-er gjør det fordi hele fastvaren deres er signert.
9. Vanlige oppstartsfeil vi har sett
På tvers av 47 000+ leverte enheter siden 2023 er dette fordelingen av kaldstartsfeil i felten:
| Feilmodus | Frekvens | Løsning |
|---|---|---|
| Telleroverflyt (nedgraderingsangrep) | 0,02 % | Reflash ved servicesenter |
| A/B-bryterløkke | 0,18 % | Tving slott A via USB |
| Avbrudd i OTA-skriving | 0,34 % | Auto-gjenoppretting fra iscenesettelse |
| Strømbrudd under oppstart | 0,91 % | Oppstart fra slott B |
| eMMC-slitasje | 0,06 % | Garantierstatning |
| SE-tamperflagg satt | 0,04 % | Re-init ved servicesenter |
| Batteri-brown-out | 0,22 % | Oppstart fra kald tilstand |
Feilen på 0,91 % for strømbrudd under oppstart er den største enkeltstående årsaken til servicesaker i felten. Vi la til en 1,2 ms kondensatorbank på L5-fastvare 4.1.5 som holder eMMC VCCQ-skinningen gjennom en 12 ms brown-out; dette senket feilraten til 0,31 % i de neste 8 000 enhetene.
10. Hvilke endringer kommer de neste 18 månedene
To endringer er på vei. For det første vil firmware 4.3.0 på L5 og T2 introdusere UEFI-oppstart der Linux U-Boot-kjeden erstattes av U-Boot 2024.10 + GRUB 2.12. Dette vil gjøre oppstarten mer inspiserbar for OEM-kjøpere som ønsker å kjede sine egne distroer. For det andre vil K7 / KF1-firmware 2.0.0 introdusere en maskinvare Root of Trust (RoT) forankret i OPTIGA Trust M-sikkerhetselementet, som erstatter dagens programvarebaserte TrustZone-M SAU-tilnærming.
Begge endringene er bakoverkompatible: den eksisterende oppstartsflyten fortsetter å fungere, men en ny modus låser opp UEFI eller maskinvare-RoT for anbudskonkurranser som krever det.
11. Slik leser du våre firmware-versjonsnumre
Våre firmware-versjoner følger mønsteret MAJOR.MINOR.PATCH. For eksempel betyr B2-firmware 2.4.7 hovedversjon 2, underversjon 4, patch 7. Reglene er:
- MAJOR økes når det er en brytende endring (f.eks. bytte fra FreeRTOS til Zephyr, endring av rootfs-oppsett).
- MINOR økes når det er en ny funksjon (f.eks. legge til et nytt språk, en ny OID-kodek).
- PATCH økes når det er en feilretting eller en sikkerhets-backport.
Regler for tilbakerulling: du kan rulle tilbake MINOR og PATCH fritt. Tilbakerulling av MAJOR krever uttrykkelig OEM-samtykke. Dette beskytter deg mot å nedgradere til en end-of-life-gren ved et uhell.
Nåværende utvalg av firmware-versjoner er 1.9.5 (K7/KF1), 2.0.3 (P2), 2.4.7 (B1/B2), 2.6.4 (T2/Y6), 3.1.2 (F8), 3.3.1 (Q6/Q8), 4.2.0 (L5). Vi publiserer firmware-release-notatene i vår OEM-portal hver 6. uke.