Jag får kernel panic vid start av ett linuxsystem - Väntar 1 minut, RST -> Startar fint

[DanielM]

Jag har ett linuxsystem som bygger på STM32MP257 och jag har fått den att fungera.
Men! Oftast vid start så brukar det vara så att man får kernel panic. Lösningen är då att vänta 1 minut, sedan trycka på RST (viktigt att man trycker på RST och inte drar ut USB strömmen). Då bootar linuxsystemet upp normalt.

Min första tanke är att det är för dåligt med avlastningskondensatorer t.ex. få få och för lite kapacitans. Eller vad tror ni?

[Klas-Kenny]

Skulle kunna vara tex. Minnestiming eller liknande som ligger på gränsen.
Har du trimmat in timingparametrar?

Prova lägga den i frysen en stund och se om det är mer konsekvent fel då, om det är temperatur beroende.

[DanielM]

Något som jag har märkt är faktiskt att när den är varm, så blir det nästan aldrig fel.
Men får den vara i rumstemperatur över en dag...då återkommer felet.

Nej. Jag har inte trimmat in några timingparametrar.

[anders_bzn]

Det låter som ett DRAM problem… vad kör du för minne och hur snabbt?

Kan du lägga till någon simpel minnestest i bootloadern som du kan köra innan du hoppar till Linux? Vilken bootloader kör du? Uboot?

[DanielM]

Det är inte ett DDR problem.
Denna fungerar riktigt bra.

Jag får kernel panic efter den läser in linux från SD-kortet, dvs när initramfs populerar /dev med mmcblk0p1 till mmcblk0p11.
Ibland kan även systemd orsaka att systemet får kernel panic.

Jag kör u-boot.

Men vad låter mest rimmligast?

• För dåliga avlastningskondensatorer
• Inga fördröjningar
• Temperaturkänslig (rumstemperatur = panic ofta, varm = typ aldrig)

Detta är direkt när kommandotolken dyker upp.
Annars brukar kernel panic uppstå direkt efter: EXT4-fs (mmcblk0p10): mounted filesystem 84739d24-9bca-4869-ba45-20f27985523e r/w with ordered data mode. Quota mode: none.

[ 1.976190] Run /init as init process
[ 2.026404] mmc0: new ultra high speed SDR104 SDHC card at address 59b4
[ 2.028303] mmcblk0: mmc0:59b4 NCard 7.48 GiB
Starting systemd-udevd version 255.21^
[ 2.775497] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11
[ 3.222411] EXT4-fs (mmcblk0p10): mounted filesystem 84739d24-9bca-4869-ba45-20f27985523e r/w with ordered data mode. Quota mode: none.
ln: /etc/mtab: File exists
[ 3.672000] systemd[1]: System time before build time, advancing clock.
[ 3.760353] NET: Registered PF_INET6 protocol family
[ 3.801054] Segment Routing with IPv6
[ 3.801142] In-situ OAM (IOAM) with IPv6
[ 3.843568] systemd[1]: systemd 255.21^ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK -SECCOMP -GCRYPT -GNUTLS -OPENSSL -ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN +IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 -BZIP2 -LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[ 3.870193] systemd[1]: Detected architecture (null).

Welcome to ST OpenSTLinux - Weston - (A Yocto Project Based Distro) 5.0.15-snapshot-20260508 (scarthgap)!

[ 3.901969] systemd[1]: Hostname set to <watermelon-wine-1aunknownunknown>.
[ 3.915262] systemd[1]: Cannot determine cgroup we are running in: No data available
[ 3.921805] systemd[1]: Failed to allocate manager object: No data available
[!!!!!!] Failed to allocate manager object.
[ 3.940131] systemd[1]: Freezing execution.
[ 12.204237] psci-cpuidle-domain psci: sync_state() pending due to 0.m33
[ 32.172120] vddio2: disabling
[ 32.172182] vddio3: disabling
[ 32.172434] vddio4: disabling
[ 32.175520] vddcore: disabling
[ 32.178498] v1v8: disabling
[ 32.181415] v5v_vconn: disabling

[Klas-Kenny]

Hur vet du att det inte är ett DDR-problem?

Det visar sig i regel genom att läsning/skrivning till minnet blir fel, varpå data blir förvanskat. Vilket leder till i princip vad som helst, i regel krasch antingen pga. datat blivit korrupt som leder till följdfel eller tex. MMU som smäller pga. access till otillåten adressrymd.

Avkoppling, visst det kan ju hända men jag skulle säga osannolikt.


Sen kanske det ger någon mer ledtråd om du postar utskrifter från en kernel panic, brukar ju innehålla en del potentiellt matnyttigt.

[DanielM]

För när det är ett DDR problem så säger den att det är ett DDR problem
Trusted Firmware för ARM går igenom DDR minnet och kollar så alla signaler är rätt och hastigheten fungerar och det går att skriva till den.

Här är några bilder. Jag ska posta mer kernel panic.

Dessa avlastningskondensatorer för processorn. Ja, alla fick inte plats.

Skärmklipp.PNG

Men det finns mer för dessa spänningsnivåer också

Skärmklipp5.PNG

Detta är avlastningskondensatorer för PMIC

Skärmklipp1.PNG

Detta är avlastningskondensatorer för LPDDR4 minnet

Skärmklipp2.PNG

Det är den där lilla datorn som jag byggde från denna tråd: viewtopic.php?t=113302

Skärmklip4.PNG

Skärmklipp3.PNG

Det som fungerar på den är egentligen allt faktiskt.
Jag fick göra EN modifikation endast då jag växlade på ett diffpar för USB 2.0.

Men annars så fungerar:

• PMIC
• Minneskortet
• HDMI
• Ethernet
• USB
• LPDDR4

Det har varit mest strul med mjukvaran och klockorna.

606547798-dd25cc50-61be-4954-a35b-13ed7e817432.png

[Klas-Kenny]

För när det är ett DDR problem så säger den att det är ett DDR problem

Knappast. Det kan visa sig i stort sett hur som helst.

Trusted Firmware för ARM går igenom DDR minnet och kollar så alla signaler är rätt och hastigheten fungerar och det går att skriva till den.

Bara för att det fungerar ibland betyder inte att det fungerar hela tiden.



De gånger jag varit ute för liknande instabilitet, som visat sig i form av krasch (spontant eller under specifika omständigheter) så har det varje gång varit DDR-problem.
Och det faktum att du säger att du inte rört DDR-timingen över huvud taget placerar det än högre på min lista över misstänkta saker.

ST har säkerligen någon beskrivning av hur man trimmar in och stresstestar DDR-parametrarna. Läs och följ den.

[AndLi]

Det kan ju vara någon helt annan signal också där 1.8v signal råkat bli kopplad till en 3.3v ingång. Som ofta blir rätt men inte alltid... eller en kodning som blivit ett motstånd eller kanske snarare tvärt om. Problemet med egna kort, det kan bli så mycket som man gör fel och ingen annan har gjort samma fel innan..

Men det kan ju vara minnet med...

[DanielM]

Ja. Som det ser ut just nu så kommer kernel panic alltid när SD kortet läser in initrd.

1. Ström appliceras
2. BootROM vaknar upp
3. BootROM läser bootpinnar
4. TF-A startas upp
5. TF-A initaliserar GPIO DDR, klockor osv
6. TF-A läser SD-kortet
7. Op-tee startas upp
8. U-boot startas upp
9. Initrd startas upp
10. Initrd populerar /dev via udev
11. Kernel panic

Men det verkar alltid ske direkt efter initrd. Först hade vi ett problem att den kunde först inte hitta partitionerna på minneskortet. Då fick man manuellt populära /dev då partitionerna fanns efter man populerade /dev via udev manuellt och återanropade initrd igen.

Men som sagt, det verkar vara strul runt initrd. Alltså vid minneskortsläsning. Initrd ska köras på ramet dock. Men hittills har det inte varit några problem för ramminnet hos u-boot och tidigare.

[ToPNoTCH]

Det kan vara avkopplingen.
I synnerhet om "alla inte fick plats" betyder att du hoppade dom som inte finns i ditt schema.

Då har du exempelvis placerat två av fem VDDIO och dessutom använt 1uF när det antagligen skulle varit 0.1 uF

Sen betyder inte panic vid läsning självklart att det är "läsningen" som är problemet. Vad läser du till (DDR kanske ?)

Intermitenta fel kan vara kniviga och man får gå igenom allt i praktiken.
Klockning är ett som ofta kan ge den typen av fel som du beskriver.
Gå igenom hardware development AN och håll koll på vad man skall göra med oanslutna pinnar osv.
Jag vet att du tycker du har gjort det men eftersom du uppenbarligen har både medvetet och omedvetet missat så är det ändå en rekommendation.

Men som sagt avkoppling är inte uteslutet heller.

[DanielM]

Nu har jag mätt upp!

Det är tydligen problem med SD kortläsningen!

Jag använder HC SD-kort t.ex SDR104. Men denna verkar min STM32MP257 processor inte kunna läsa längre. Den känner utav identiteten på SD-kortet t.ex. SDR104 och storlek samt om man kopplar in/ut SD-kortet. Annars så står det att den inte kan hitta vissa partitioner.
När den lyckas läsa så blir det ofta kernel panic direkt efter.

Alltså när initrd läses in.

När jag stoppar in annat liknande SD-kort så sjunker inte VDDIO från 3.3V till 1.8V. Då går den till 0V. Vilket resulterar -110 (timeout).

Sammanfattning:

• U-boot fungerar alltid att läsas in från SD-kortet, oavsett SD kort.
• När U-boot läser in initrd så blir det kernel panic
• Ett SD-kort känner u-boot utav och skriver ut identiteten på den och SDR104. Då är VDDIO 1.8V från 3.3V
• Ett annat SD-kort gör så VDDIO är 0V och därmed -110 (timeout) när initrd ska läsas in
• Det är endast i Linux det krånglar, dvs initrd. U-boot, TF-A och U-boot fungerar utmärkt.
• Klockfrekvensen är på 50 MHz
• Klockan väldigt fin utan något överskjut. Signalintegriteten är bra.