🥇Del 3: Nästan laddar Linux från SD-kortet på RocketChip

I den föregående delen en har blivit implementerad en mer eller mindre fungerande minneskontroller, närmare bestämt en omslag runt IP Core från Quartus, som fungerar som en adapter till TileLink. Idag i artikeln "Portera RocketChip till ett mindre känt kinesiskt kort med Cyclone" får du se en fungerande konsol. Processen drog ut på tiden: jag trodde att jag snabbt skulle kunna starta Linux och gå vidare, men så blev det inte. I denna del föreslår jag att vi tittar på processen för att starta U-Boot, BBL och de trevande försöken att få Linux-kärnan att initieras. Men det finns en konsol – en U-Boot-konsol, som är ganska avancerad och har mycket av det du förväntar dig från en fullfjädrad konsol.

I hårdvarudelen tillkommer ett SD-kort som är anslutet via SPI-gränssnitt, samt UART. I mjukvarudelen kommer BootROM att bytas ut mot xip till sdboot och faktiskt läggas till följande laddningssteg (på SD-kortet).

Förbättring av hårdvarudelen

Så, uppgiften: vi behöver gå över till ett "stort" kärn och ansluta UART (från Raspberry) och SD-adapter (en viss platta från Catalex med sex stift: GND, VCC, MISO, MOSI, SCK, CS).

I princip var allt ganska enkelt. Men innan jag insåg det, blev jag lite kastad fram och tillbaka: efter förra gången beslutade jag att det återigen var dags att bara blanda in i System något som HasPeripheryUART (och i implementeringen därmed), samma för SD-kortet – och allt skulle vara klart. Sedan beslöt jag mig för att se hur det var implementerat i en "seriös" design. Så, vad har vi här av seriöst? Arty verkar inte passa – det återstår monstret unleahshed.DevKitConfigs. Och plötsligt upptäckte jag att det fanns överallt några overlay, som läggs till via parameternycklar. Jag misstänker att detta nog är mycket flexibelt och konfigurerbart, men jag skulle vilja ha något för att starta åtminstone... Har ni något liknande, men bara enklare och mer lurt?.. Där stötte jag på vera.iofpga.FPGAChip för Microsemi FPGA och jag punkterade på citat och försökte göra min egen implementation genom analogi, eftersom här finns mer eller mindre hela "systemkortets" layout i en fil.

Det visade sig verkligen att man bara behövde lägga till i System.scala raderna

class System(implicit p: Parameters) extends RocketSubsystem
...
  with HasPeripherySPI
  with HasPeripheryUART
...
{
  val tlclock = new FixedClockResource("tlclk", p(DevKitFPGAFrequencyKey))
  ...
}

class SystemModule[+L <: System](_outer: L)
  extends RocketSubsystemModuleImp(_outer)
...
    with HasPeripheryUARTModuleImp
    with HasPeripheryGPIOModuleImp
...

Rad i klassens kropp System lägger till information om frekvensen som denna del av vår SoC arbetar vid, i dts-filen. Så vitt jag förstår, är DTS/DTB en statisk motsvarighet till plug-and-play-teknologi för inbyggda enheter: dträdets dts-beskrivning kompileras till en binär dtb-fil och överförs av bootloadern till kärnan, så att den kan ställa in hårdvaran korrekt. Intressant nog, utan raden med tlclock syntetiseras allt bra, men att kompilera BootROM (låt mig påminna, nu kommer det att bli sdboot) går inte — under kompileringen parser den dts-filen och skapar en header med makrot TL_CLK, som gör att den kan ställa in frekvensdelarna för externa gränssnitt korrekt.

Det kommer också att krävas lite justering av "layouten":

Platform.scala:

class PlatformIO(implicit val p: Parameters) extends Bundle {

...

  \/\/ UART
  io.uart_tx := sys.uart(0).txd
  sys.uart(0).rxd := RegNext(RegNext(io.uart_rx))

  \/\/ SD-kort
  io.sd_cs := sys.spi(0).cs(0)
  io.sd_sck := sys.spi(0).sck
  io.sd_mosi := sys.spi(0).dq(0).o
  sys.spi(0).dq(0).i := false.B
  sys.spi(0).dq(1).i := RegNext(RegNext(io.sd_miso))
  sys.spi(0).dq(2).i := false.B
  sys.spi(0).dq(3).i := false.B
}

Registreringskedjor har, ärligt talat, lagts till helt enkelt som en analogi med vissa andra delar av den ursprungliga koden. De ska troligen skydda mot metastabilitet. Kanske finns det redan något skydd i vissa block, men först vill jag kunna starta åtminstone "på en kvalitetsnivå". En mer intressant fråga för mig är — varför MISO och MOSI hänger på olika dq? Ответа я пока так и не нашёл, но, похоже, остальной код рассчитывает именно на такое подключение.

Fysiskt har jag helt enkelt tilldelat utgångarna i designen till lediga kontakter på kontaktdonen och flyttat hopkopplaren för spänningsval till 3.3V.

SD-adapter

Översikt uppifrån:

Översikt nedifrån:

Debuggning av programvaran: verktyg

För att börja, låt oss diskutera de tillgängliga felsökningsverktygen och deras begränsningar.

Minicom

Först måste vi på något sätt läsa vad bootloadern och kärnan skriver ut. För detta i Linux (i detta fall — på den som körs på RaspberryPi) behöver vi programmet Minicom. Generellt sett, vilket som helst program för arbete med seriell port fungerar.

Observera att när du startar, måste du ange portens enhetsnamn som -D \/dev\/ttyS0 — efter alternativet , kommer den att lägga den senaste blocken av masterkedjan i den:. Och den viktigaste informationen: för att avsluta, använd Ctrl-A, X. Jag hade faktiskt en gång då denna kombination inte fungerade — då kan du bara från en annan SSH-session säga killall -KILL minicom.

Det finns också en annan egenskap. Specifikt på Raspberry Pi finns det två UART:ar, och båda portar kan redan vara anpassade för något: en för Bluetooth, medan den andra som standard visar kärnans konsol. Som tur är kan detta beteende omkonfigureras. enligt den här manualen..

Minnesåterställning.

Vid felsökning har jag ibland behövt för att verifiera hypotesen. ladda bootloadern (ursäkta) i RAM direkt från värden. Kanske kan det göras direkt från GDB, men jag valde den enklare vägen: kopierade den nödvändiga filen till Raspberry och vidarebefordrade även port 4444 via SSH (telnet från OpenOCD) och använde kommandot. load_image. När du kör det verkar det som om allt har frusit, men i själva verket «det sover inte, det blinkar bara långsamt»: det laddar filen, det gör det bara med en hastighet av ett par kilobytar per sekund.

Egenskaper hos att placera breakpoints.

Många kanske aldrig har tänkt på detta vid felsökning av vanliga program, men breakpoints sätts inte alltid hårdvarumässigt. Ibland innebär det att tillfälligt skriva en särskild instruktion på rätt plats. direkt i maskinkoden.Till exempel fungerade det så med den standardkommandot b i GDB. Här är vad som följer av detta:

du kan inte sätta en punkt inne i BootROM eftersom ROM
det går att sätta en breakpoint på koden som laddas in i RAM från SD-kortet, men du måste vänta tills den har laddats. Annars kommer vi inte att skriva över en bit av koden, utan bootloadern kommer att skriva över vår breakpoint.

Jag är säker på att man tydligt kan be om att använda hårdvarubaserade breakpoints, men de är ändå begränsade i antal.

Snabb omkoppling av BootROM.

I det inledande skedet av felsökningen finns ofta en önskan att fixa BootROM och försöka igen. Men det finns ett problem: BootROM är en del av designen som laddas in i FPGA:n, och dess syntes tar några minuter (och detta efter nästan omedelbar kompilering av själva BootROM-avbildningen från C och assembler...). Som tur är är allt faktiskt mycket snabbare: sekvensen av åtgärder är sådan:

återgenerera bootrom.mif (jag bytte till MIF istället för HEX, eftersom jag alltid hade problem med HEX, medan MIF är det ursprungliga ALTERA-formatet)
i Quartus säger Bearbetning -> Uppdatera minnesinitialiseringsfilen.
i punkten Assembler (i vänstra kolumnen Uppgifter) ge kommandot Starta om igen.

Allt som allt - ett par tiotal sekunder.

Förberedelse av SD-kort.

Här är allt relativt enkelt, men du behöver ha tålamod och ungefär 14Gb diskutrymme:

git clone https://github.com/sifive/freedom-u-sdk
git submodule update --recursive --init
make

Därefter behöver du sätta i ett rent, det vill säga, utan något viktigt, SD-kort och utföra

sudo make DISK=/dev/sdX format-boot-loader

… där sdX — enheten som tilldelats kortet. VARNING: Data på kortet kommer att raderas, skrivas över och helt enkelt försvinna! Det är nog ingen bra idé att göra hela byggprocessen som sudo, för då kommer alla byggartefakter att tillhöra root, och bygget måste göras som sudo konstant.

Resultatet är ett kort som är partitionerat i GPT med fyra partitioner, där en av dem har FAT med uEnv.txt och en bootbar bild i FIT-format (den innehåller flera delbilder, var och en med sin laddningsadress), den andra partitionen är tom och avsedd att formateras i Ext4 för Linux. De andra två partitionerna är mysteriska: på en lagrar U-Boot (dess förskjutning är, såvitt jag förstår, kodad i BootROM), på den andra verkar dess miljövariabler bo, men jag använder dem inte än.

Nivå ett, BootROM

Det finns ett ordspråk som säger: "Om det finns dans kring trummor i programmering, så är det även med brandsläckare i elektronik". Det handlar inte ens om att jag en gång nästan brände kortet, eftersom jag trodde att "Nåväl, GND är ju samma som låg nivå" (ett motstånd skulle uppenbarligen inte ha skadat...) Det handlar snarare om att om händerna inte växer från rätt ställe, fortsätter elektroniken att överraska: när jag lödde kontakten på kortet, kunde jag inte få kontakterna att löda ordentligt — på videoklipp visar de hur lödtennet bara flyter ut över hela anslutningen, bara sätt lödkolven på, men hos mig "fastnade" det hur som helst. Ja, kanske lödtennet inte passade temperaturen på lödkolven, kanske något annat… I allmänhet, när jag såg att jag hade ett dussin kontakter, gav jag upp och började felsöka. Och här började det mystiska: jag kopplade RX/TX från UART:en, laddade firmware — det står

INIT
CMD0
ERROR

Nåväl, allt är logiskt — jag hade inte kopplat in SD-kortmodulen. Jag åtgärdar situationen, laddar firmware... Och tystnad... Vad jag än tänkte på, men problemet var enkelt: en av benen på modulen behövde kopplas till VCC. I mitt fall stöddes 5V för strömförsörjning av modulen, så jag, utan att tveka, kopplade den tråd som sträckte sig från modulen till motsatt sida av kortet. Som resultat blev den dåligt lödda kontakten sned. bara förlorade kontakt med UART. facepalm.jpg I allmänhet, "en dålig skalle ger inte benen ro", och sneda händer — skallen...

Till slut såg jag det längtade i Minicom

INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18
LOADING /

Dessutom rör sig laddningsindikatorn. Det påminner mig om skoltiden och den långsamma laddningen av MinuetOS från disketten. Det enda som saknas är att diskettstationen inte skrapar.

Problemet är att efter meddelandet BOOT händer inget. Det var dags att koppla upp via OpenOCD på Raspberry, med GDB på värden och se vad det handlar om.

För det första visade anslutningen med GDB genast att $pc (programräknare, adressen för den aktuella instruktionen) flyger iväg till 0x0 — troligen händer detta efter flera fel. Så snart som meddelandet visas BOOT lägger vi till en oändlig loop. Det kommer att försena det en stund...

diff --git a/bootrom/sdboot/sd.c b/bootrom/sdboot/sd.c
index c6b5ede..bca1b7f 100644
--- a/bootrom/sdboot/sd.c
+++ b/bootrom/sdboot/sd.c
@@ -224,6 +224,8 @@ int main(void)

        kputs("BOOT");

+    while(*(volatile char *)0x10000){}
+
        __asm__ __volatile__ ("fence.i" : : : "memory");
        return 0;
 }

En så här listig kod används "för tillförlitlighet": jag har hört någonstans att oändliga loopar kan vara Undefined Behavior, och här lär kompilatorn knappast förstå. 0x10000 Jag påminner om att BootROM finns.

Man skulle kunna förvänta sig, vad förväntar man sig — en hård inbyggd lösning, vad är det för källkod här. Men i den artikeln debatten var att författa C-kod... Kreks-feks-peks:

(gdb) file builds/zeowaa-e115/sdboot.elf
Ett program debuggas redan.
Är du säker på att du vill ändra filen? (y eller n) y
Läser symboler från builds/zeowaa-e115/sdboot.elf... klart.

Det behöver laddas inte MIF-filen eller bin, utan den ursprungliga versionen i ELF-format.

Nu kan man med en viss chans gissa adressen där exekveringen fortsätter (detta är ytterligare en anledning till varför kompilatorn inte borde ha gissat att loopen är oändlig). Kommandot

set variable $pc=0xADDR

tillåter att ändra registrets värde på språng (i detta fall — adressen för den aktuella instruktionen). Med detta kan man också ändra värden som sparats i minnet (och minnesmäppade register).

Till slut kom jag fram till slutsatsen (är osäker på om den är korrekt) att vi har "sd-kortavbilden av det systemet", och man ska inte gå till början av de laddade data utan till 0x89800 några byte längre:

diff --git a/bootrom/sdboot/head.S b/bootrom/sdboot/head.S
index 14fa740..2a6c944 100644
--- a/bootrom/sdboot/head.S
+++ b/bootrom/sdboot/head.S
@@ -13,7 +13,7 @@ _prog_start:
   smp_resume(s1, s2)
   csrr a0, mhartid
   la a1, dtb
-  li s1, PAYLOAD_DEST
+  li s1, (PAYLOAD_DEST + 0x89800)
   jr s1

   .section .rodata

Det kan också ha påverkats av att jag, utan en onödig 4Gb-kort till hands, tog ett 2Gb-kort och bytte ut det i Makefile med en del trial and error. DEMO_END=11718750 till DEMO_END=3078900 (sök inte efter mening i det specifika värdet — det finns inget, det är bara så att bilden nu får plats på kortet).

Nivå två, U-Boot

Nu "faller" vi fortfarande, men har redan nått adressen 0x0000000080089a84. Här måste jag erkänna: faktiskt går redogörelsen inte "med alla stopp", utan skrivs delvis "efteråt", så här har jag redan lyckats lägga till den rätta dtb-filen från vår SoC, och rättat i inställningarna. HiFive_U-Boot variabel CONFIG_SYS_TEXT_BASE=0x80089800 (i stället för 0x08000000), så att laddningsadressen överensstämmer med den faktiska. Nu laddar vi en karta på nästa nivå med en annan bild:

(gdb) file ..\/freedom-u-sdk\/work\/HiFive_U-Boot\/u-boot
(gdb) tui en

Och vi ser:

   │304     *                                               │
   │305      * fälla intäde                                    │
   │306      *\/                                              │
   │307     trap_entry:                                      │
   │308         addi sp, sp, -32*REGBYTES                    │
  >│309         SREG x1, 1*REGBYTES(sp)                      │
   │310         SREG x2, 2*REGBYTES(sp)                      │
   │311         SREG x3, 3*REGBYTES(sp)                      │

Vi hoppar mellan raderna 308 och 309. Och inte helt oväntat, med tanke på att i $sp ligger värdet 0xfffffffe31cdc0a0. Tyvärr "springer" det även bort på grund av raden 307. Så vi provar att sätta en stopppunkt på trap_entry, och sedan återgå till 0x80089800 (U-Boots inträdespunkt), och hoppas att det inte kräver korrekt inställda register innan övergången... Det verkar fungera:

(gdb) b trap_entry
Breakpoint 1 at 0x80089a80: file \/hdd\/trosinenko\/fpga\/freedom-u-sdk\/HiFive_U-Boot\/arch\/riscv\/cpu\/HiFive\/start.S, line 308.
(gdb) set variable $pc=0x80089800
(gdb) c
Fortsätter.

Breakpoint 1, trap_entry () at \/hdd\/trosinenko\/fpga\/freedom-u-sdk\/HiFive_U-Boot\/arch\/riscv\/cpu\/HiFive\/start.S:308
(gdb) p\/x $sp
$4 = 0x81cf950

En ganska dålig stackpekare, får man säga: den pekar faktiskt bortom RAM (om vi inte redan har adressöversättning, men vi hoppas på det enkla alternativet).

Vi provar att byta pekaren till 0x881cf950. Slutligen kommer vi fram till att handle_trap anropas och anropas, medan vi går in i _exit_trap med argumentet epc=2148315240 (i decimalform):

(gdb) x/10i 2148315240
   0x800cb068 :     lbu     a4,0(a5)
   0x800cb06c :     bnez    a4,0x800cb078 
   0x800cb070 :     sub     a0,a5,a0
   0x800cb074 :     ret
   0x800cb078 :     addi    a5,a5,1
   0x800cb07c :     j       0x800cb064 
   0x800cb080 : addi    sp,sp,-32
   0x800cb084 :       sd      s0,16(sp)
   0x800cb088 :       sd      ra,24(sp)
   0x800cb08c :      li      s0,0

Vi sätter en breakpoint på strnlen, fortsätter och ser:

(gdb) bt
#0 strnlen (s=s@entry=0x10060000 "", count=18446744073709551615) at lib/string.c:283
#1 0x00000000800cc14c in string (buf=buf@entry=0x881cbd4c "", end=end@entry=0x881cc15c "", s=0x10060000 "", field_width=, precision=, flags=) at lib/vsprintf.c:265
#2 0x00000000800cc63c in vsnprintf_internal (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=0x800d446e "s , epc x , ra lxn", fmt@entry=0x800d4458 "exception code: %d , %s , epc x , ra lxn", args=0x881cc1a0,
 args@entry=0x881cc188) at lib/vsprintf.c:619
#3 0x00000000800cca54 in vsnprintf (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc x , ra lxn", args=args@entry=0x881cc188) at lib/vsprintf.c:710
#4 0x00000000800cca68 in vscnprintf (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc x , ra lxn", args=args@entry=0x881cc188) at lib/vsprintf.c:717
#5 0x00000000800ccb50 in printf (fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc x , ra lxn") at lib/vsprintf.c:792
#6 0x000000008008a9f0 in _exit_trap (regs=, epc=2148315240, code=) at arch/riscv/lib/interrupts.c:92
#7 handle_trap (mcause=, epc=, regs=) at arch/riscv/lib/interrupts.c:55
#8 0x0000000080089b10 in trap_entry () at /hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot/arch/riscv/cpu/HiFive/start.S:343
Backtrace stopped: frame did not save the PC

Det verkar som _exit_trap vill ge debuginformation om den inträffade undantaget, men lyckas inte. Så, något visar återigen inte källorna. set directories ../freedom-u-sdk/HiFive_U-Boot/ O! Nu visas de!

Låt oss starta en gång till och se på stackspåret för att hitta orsaken till det ursprungliga problemet som orsakade det första felet (mcause == 5). Om jag förstått rätt det som står här på sidan 37, så innebär detta undantag Ladda åtkomstfel. Anledningen verkar vara att här

arch/riscv/cpu/HiFive/start.S:

call_board_init_f:
    li  t0, -16
    li  t1, CONFIG_SYS_INIT_SP_ADDR
    and sp, t1, t0  /* tvinga 16-byte justering */

#ifdef CONFIG_DEBUG_UART
    jal debug_uart_init
#endif

call_board_init_f_0:
    mv  a0, sp
    jal board_init_f_alloc_reserve
    mv  sp, a0
    jal board_init_f_init_reserve

    mv  a0, zero /* a0 <--- boot_flags = 0 */
    la t5, board_init_f
    jr t5       /* hoppa till board_init_f() */

$sp har det felaktiga värdet, och inne i board_init_f_init_reserve uppstår ett fel. Det verkar som att skulden ligger hos: variabeln med det tydliga namnet CONFIG_SYS_INIT_SP_ADDR. Den definieras i filen HiFive_U-Boot/include/configs/HiFive-U540.hVid något tillfälle övervägde jag till och med om det vore enklare att justera processorn istället för att finjustera bootloadern — men sen insåg jag att det mer liknade ett artefakt från ofullständiga inställningar för en annan minneskonfiguration, och man kan försöka göra så här:#if 0-

diff --git a/include/configs/HiFive-U540.h b/include/configs/HiFive-U540.h
index ca89383..245542c 100644
--- a/include/configs/HiFive-U540.h
+++ b/include/configs/HiFive-U540.h
@@ -65,12 +65,9 @@
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_0
 #endif
 #if 1
-
 #define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_0   0x80000000              /* SDRAM Bank #1 */
-#define PHYS_SDRAM_1   
-       (PHYS_SDRAM_0 + PHYS_SDRAM_0_SIZE)      /* SDRAM Bank #2 */
-#define PHYS_SDRAM_0_SIZE      0x80000000      /* 2 GB */
-#define PHYS_SDRAM_1_SIZE      0x10000000      /* 256 MB */
+#define PHYS_SDRAM_0_SIZE      0x40000000      /* 1 GB */
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_0
 #endif
 /*
@@ -81,7 +78,7 @@
 #define CONSOLE_ARG                            "console=ttyS0,115200 "

 /* Init Stack Pointer */
-#define CONFIG_SYS_INIT_SP_ADDR                (0x08000000 + 0x001D0000 - 
+#define CONFIG_SYS_INIT_SP_ADDR                (0x80000000 + 0x001D0000 - 
                                        GENERATED_GBL_DATA_SIZE)

 #define CONFIG_SYS_LOAD_ADDR           0xa0000000      /* partway up SDRAM */

Vid något tillfälle nådde antalet workaround:er teknologiska fäste en kritisk nivå. Efter att ha kämpat lite kom jag fram till att jag var tvungen att göra en korrekt portering till mitt styrenhet. För detta behöver jag kopiera och justera ett antal filer till vår konfiguration.

Nåväl, ungefär så här

trosinenko@trosinenko-pc:/hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot$ git show --name-status
commit 39cd67d59c16ac87b46b51ac1fb58f16f1eb1048 (HEAD -> zeowaa-1gb)
Author: Anatoly Trosinenko 
Date:   Tue Jul 2 17:13:16 2019 +0300

    Inledande stöd för Zeowaa A-E115FB kort

M       arch/riscv/Kconfig
A       arch/riscv/cpu/zeowaa-1gb/Makefile
A       arch/riscv/cpu/zeowaa-1gb/cpu.c
A       arch/riscv/cpu/zeowaa-1gb/start.S
A       arch/riscv/cpu/zeowaa-1gb/timer.c
A       arch/riscv/cpu/zeowaa-1gb/u-boot.lds
M       arch/riscv/dts/Makefile
A       arch/riscv/dts/zeowaa-1gb.dts
A       board/Zeowaa/zeowaa-1gb/Kconfig
A       board/Zeowaa/zeowaa-1gb/MAINTAINERS
A       board/Zeowaa/zeowaa-1gb/Makefile
A       board/Zeowaa/zeowaa-1gb/Zeowaa-A-E115FB.c
A       configs/zeowaa-1gb_defconfig
A       include/configs/zeowaa-1gb.h

Detaljer kan ses i förrådet.

Som det visade sig har registren för vissa enheter på detta SiFive-kort olika adresser. Det visade sig också att U-Boot konfigureras med det bekanta Kconfig-mekanismen från Linux-kärnan — till exempel kan man kommandera make menuconfig, och framför dig kommer en användarvänlig textbaserad gränssnitt med beskrivningar av parametrarna. ? Och så vidare. Så, genom att sätta ihop beskrivningarna av de två plattorna skapade jag en beskrivning av den tredje, släppte allt pretentiöst kring PLL-omkonfigurationer (det verkar ha något att göra med styrning från värddatorn via PCIe, men jag är inte säker), fick jag en viss firmware som, under rätt förhållanden på Mars, gav mig ett meddelande via UART om vilken commit-hash den var sammansatt från, och hur mycket DRAM jag hade (men den informationen angav jag själv i headern).

Tyvärr, efter detta slutade plattan vanligtvis att svara via processor JTAG, och att ladda från SD-kortet är, tyvärr, inte snabbt i min konfiguration. Å andra sidan gav BootROM ibland ett meddelande att ERROR, det går inte att starta, och i samma veva dök U-Boot upp. Det slog mig då: uppenbarligen, efter omstarten så rensar inte bitstream i FPGA-minnet, det hinner inte "tappas" och så vidare. Kort sagt kan man helt enkelt, när meddelandet LOADING / dyker upp, koppla in debuggern och ge kommandot set variable $pc=0x80089800, på så sätt hoppa över den långa uppstarten (naturligtvis med antagandet att det gick sönder tillräckligt tidigt förra gången och inte hann ladda något ovanpå originalkoden).

Förresten, är det normalt att processorn fryser helt, och JTAG-debuggern inte kan koppla upp sig med meddelandena

Error: unable to halt hart 0
Error:   dmcontrol=0x80000001
Error:   dmstatus =0x00030c82

Vänta lite! Jag har sett detta förut! Något liknande händer vid en dödlåsning av TileLink, och jag litar inte riktigt på författaren av minneskontrollern — jag skrev det själv... Plötsligt, efter den första lyckade omkompileringen av processorn efter att jag redigerade kontrollern såg jag:

INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18
LOADING
BOOT

U-Boot 2018.09-g39cd67d-dirty (Jul 03 2019 - 13:50:33 +0300)

DRAM:  1 GiB
MMC:
BEFORE LOAD ENVBEFORE FDTCONTROLADDRBEFORE LOADADDRIn:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3

Vid denna märkliga rad framför In: serial Ignorera detta - jag försökte förstå hur det fungerar med processorn som hänger. Vad betyder "Det har hängt i tio minuter"? Har det åtminstone lyckats relocera sig och gå till startmenyn? En liten avstickare: även om U-Boot laddas bland de första 2^24 byte från SD-kortet, kopierar det sig själv längre bort till en adress som antingen är skriven i konfigurationshuvudet eller helt enkelt i de högre adresserna av RAM-minnet, gör en relocation av ELF-symboler, och överför kontrollen dit. Så här är läget: det verkar som om det nivåer passerats och som bonus fått en processor som inte hänger helt efter det.

Så, varför fungerar inte timern? Det verkar som klockan överhuvudtaget av någon anledning inte tickar...

(gdb) x/x 0x0200bff8
0x200bff8:      0x00000000

Vad händer om man snurrar visarna manuellt?

(gdb) set variable *0x0200bff8=310000000
(gdb) c

Då:

Tryck på valfri tangent för att stoppa autoboot:  0
MMC_SPI: 0 vid 0:1 hz 20000000 läge 0

Resultat: klockan tickar inte. Troligtvis beror detta på att tangentbordsinmatning inte fungerar:

HiFive_U-Boot/cmd/bootmenu.c:

static void bootmenu_loop(struct bootmenu_data *menu,
        enum bootmenu_key *key, int *esc)
{
    int c;

    while (!tstc()) {
        WATCHDOG_RESET();
        mdelay(10);
    }

    c = getc();

    switch (*esc) {
    case 0:
        /* Första tecknet av ANSI escape-sekvensen 'e' */
        if (c == 'e') {
            *esc = 1;
            *key = KEY_NONE;
        }
        break;
    case 1:
        /* Andra tecknet av ANSI '[' */
        if (c == '[') {
...

Problemet visade sig vara att jag överdrivit lite: jag lade till en nyckel i processorconfigurationsfilen:

  case DTSTimebase => BigInt(0)

… med tanke på att det standades "om du inte vet - lämna 0". Och då WithNBigCores precis satte den till 1MHz (som för övrigt angavs i U-Boot-konfigurationen). Men jag är ju fan noga och pedantisk: där vet jag inte, här 25MHz! I slutändan fungerar ingenting. Jag tog bort mina "förbättringar" och...

Tryck på valfri tangent för att stoppa autoboot:  0
MMC_SPI: 0 vid 0:1 hz 20000000 läge 0
## Okänd partionstabellstyp 0
libfdt fdt_path_offset() returnerade FDT_ERR_NOTFOUND
** Ingen partitionstabell - mmc 0 **
## Info: indata storlek = 34 = 0x22
Kör uEnv.txt boot2...
## Fel: "boot2" är inte definierad
HiFive-Unleashed #

Man kan till och med skriva in kommandon! Till exempel, efter lite pillande kan man äntligen gissa sig till att skriva mmc_spi 1 10000000 0; mmc part, genom att minska SPI-frekvensen från 20 MHz till 10 MHz. Varför? Tja, i konfigurationen var den maximala frekvensen angiven som 20 MHz, och den är fortfarande den samma där. Men såvitt jag förstår fungerar gränssnitten, åtminstone här, så här: koden delar frekvensen av hårdvarumodulen (hos mig är det alltid 25 MHz) med den målinriktade, och sätter det resulterande värdet som dividerare i den aktuella kontrollregistret. Problemet är att om för 115200 Hz UART skulle vara ungefär det som behövs, så om man exakt delar 25000000 med 20000000 får man 1, dvs. det kommer att fungera vid 25 MHz. Kanske är det okej, men om det finns begränsningar sätts, måste det vara nödvändigt för någon (men det är inte säkert)... I allmänhet är det lättare att sätta dit det och gå vidare – långt och tyvärr för länge. 25 MHz är ingen Core i9 för dig.

Konsolutgång

HiFive-Unleashed # env edit mmcsetup
edit: mmc_spi 1 10000000 0; mmc part
HiFive-Unleashed # boot
MMC_SPI: 1 at 0:1 hz 10000000 mode 0

Partition Map for MMC device 0  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000800      0x0000ffde      "Vfat Boot"
        attrs:  0x0000000000000000
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        type:   data
        guid:   76bd71fd-1694-4ff3-8197-bfa81699c2fb
  2     0x00040800      0x002efaf4      "root"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   9f3adcc5-440c-4772-b7b7-283124f38bf3
  3     0x0000044c      0x000007e4      "uboot"
        attrs:  0x0000000000000000
        type:   5b193300-fc78-40cd-8002-e86c45580b47
        guid:   bb349257-0694-4e0f-9932-c801b4d76fa3
  4     0x00000400      0x0000044b      "uboot-env"
        attrs:  0x0000000000000000
        type:   a09354ac-cd63-11e8-9aff-70b3d592f0fa
        guid:   4db442d0-2109-435f-b858-be69629e7dbf
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
2376 bytes read in 0 ms
Running uEnv.txt boot2...
15332118 bytes read in 0 ms
## Loading kernel from FIT Image at 90000000 ...
   Using 'config-1' configuration
   Trying 'bbl' kernel subimage
     Description:  BBL/SBI/riscv-pk
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900000d4
     Data Size:    74266 Bytes = 72.5 KiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x80000000
     Entry Point:  0x80000000
     Hash algo:    sha256
     Hash value:   28972571467c4ad0cf08a81d9cf92b9dffc5a7cb2e0cd12fdbb3216cf1f19cbd
   Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at 90000000 ...
   Using 'config-1' configuration
   Trying 'fdt' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x90e9d31c
     Data Size:    6911 Bytes = 6.7 KiB
     Architecture: RISC-V
     Load Address: 0x81f00000
     Hash algo:    sha256
     Hash value:   10b0244a5a9205357772ea1c4e135a4f882409262176d8c7191238cff65bb3a8
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x90e9d31c to 0x81f00000
   Booting using the fdt blob at 0x81f00000
## Loading loadables from FIT Image at 90000000 ...
   Trying 'kernel' loadables subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900123e8
     Data Size:    10781356 Bytes = 10.3 MiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x80200000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   72a9847164f4efb2ac9bae736f86efe7e3772ab1f01ae275e427e2a5389c84f0
   Verifying Hash Integrity ... sha256+ OK
   Loading loadables from 0x900123e8 to 0x80200000
## Loading loadables from FIT Image at 90000000 ...
   Trying 'ramdisk' loadables subimage
     Description:  buildroot initramfs
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x90a5a780
     Data Size:    4467411 Bytes = 4.3 MiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x82000000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   883dfd33ca047e3ac10d5667ffdef7b8005cac58b95055c2c2beda44bec49bd0
   Verifying Hash Integrity ... sha256+ OK
   Loading loadables from 0x90a5a780 to 0x82000000

Okej, vi har nått en ny nivå, men det hänger fortfarande. Och ibland spottar det ut undantag. Man kan se mcause om man fångar koden vid den angivna adressen $pc och efter si hamna på trap_entry. Handlaren i U-Boot kan bara skriva ut för mcause = 0..4, så var beredd på att fastna i en felaktig inläsning. Här gick jag in i konfigurationen, började kolla vad jag hade ändrat, och kom ihåg: där i conf/rvboot-fit.txt står det:

fitfile=image.fit
# nedan måste matcha vad som finns i FIT (ugha)

Låt oss göra alla filer överensstämmande, vi ersätter kommandoraden för kärnan ungefär så här, eftersom det finns misstankar om att SIF0 — är en utmatning någonstans via PCIe:

-bootargs=console=ttySIF0,921600 debug
+bootargs=console=ttyS0,125200 debug

Och dessutom byter vi hash-algoritmen från SHA-256 till MD5: jag behöver ingen kryptostyrka (speciellt under felsökning), det sägs ta fruktansvärt lång tid, och för att fånga upp integritetsfel under inläsning är MD5 mer än tillräckligt. Så vad blev resultatet? Vi kunde passera det föregående steget betydligt snabbare (på grund av den enklare hashningen), och nästa steg öppnades:

...
   Verifierar hashintegritet ... md5+ OK
   Laddar lastfiler från 0x90a5a758 till 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
chosen {
        linux,initrd-end = ;
        linux,initrd-start = ;
        riscv,kernel-end = ;
        riscv,kernel-start = ;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
chosen {
        linux,initrd-end = ;
        linux,initrd-start = ;
        riscv,kernel-end = ;
        riscv,kernel-start = ;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
   Laddar kärnbild ... OK
Startar kärnan om
3

Men klockorna tickar inte...

(gdb) x/x 0x0200bff8
0x200bff8:      0x00000000

Ups, det verkar som att justeringen av klockan var ett placebo, även om det då verkade hjälpa. Nej, vi måste självklart fixa det, men låt oss först vrida visarna manuellt och se vad som händer:

0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=1000000
(gdb) c
Fortsätter.
^C
Programmet fick signal SIGINT, avbruten.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=2000000
(gdb) c
Fortsätter.
^C
Programmet fick signal SIGINT, avbruten.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=3000000
(gdb) c
Fortsätter.

Under tiden...

   Laddar kärnbild ... OK
Startar kärnan om
3
2
1
0
## Startar applikation vid 0x80000000 ...

Nej då, jag går för att automatisera klockan — annars kanske den försöker kalibrera timern!

Och adressen för den aktuella instruktionen pekar under tiden någonstans på

0000000080001c20 :
    80001c20:   1141                    addi    sp,sp,-16
    80001c22:   e022                    sd      s0,0(sp)
    80001c24:   842a                    mv      s0,a0
    80001c26:   00005517                auipc   a0,0x5
    80001c2a:   0ca50513                addi    a0,a0,202 # 80006cf0 
    80001c2e:   e406                    sd      ra,8(sp)
    80001c30:   f7fff0ef                jal     ra,80001bae 
    80001c34:   8522                    mv      a0,s0
    80001c36:   267000ef                jal     ra,8000269c 
    80001c3a:   00010797                auipc   a5,0x10
    80001c3e:   41e78793                addi    a5,a5,1054 # 80012058 
    80001c42:   639c                    ld      a5,0(a5)
    80001c44:   c399                    beqz    a5,80001c4a 
    80001c46:   72c000ef                jal     ra,80002372 
    80001c4a:   45a1                    li      a1,8
    80001c4c:   4501                    li      a0,0
    80001c4e:   dc7ff0ef                jal     ra,80001a14 
    80001c52:   10500073                wfi
    80001c56:   bff5                    j       80001c52

inuti den laddade Berkeley Boot Loader. Personligen stör jag mig på omnämnandet htif — hostgränssnittet som används för tethered start av kärnan (det vill säga i samarbete med värd-ARM), jag hade tänkt mig en fristående lösning. Men om man hittar denna funktion i källkoden ser man att inte allt är så illa:

void poweroff(uint16_t code)
{
  printm("Power offrn");
  finisher_exit(code);
  if (htif) {
    htif_poweroff();
  } else {
    send_ipi_many(0, IPI_HALT);
    while (1) { asm volatile ("wfin"); }
  }
}

Uppdrag: starta klockan

Sökning av register i CLINT leder oss till

    val io = IO(new Bundle {
      val rtcTick = Bool(INPUT)
    })

    val time = RegInit(UInt(0, width = timeWidth))
    when (io.rtcTick) { time := time + UInt(1) }

som kopplas in i RTC, eller i den mystiska MockAON, som jag från början tänkte: 'Vad har vi här? Oklart? Koppla bort!' Eftersom jag fortfarande inte förstår vilken klockmagik som pågår där, kommer jag helt enkelt att omimplementera denna logik i System.scala:

  val rtcDivider = RegInit(0.asUInt(16.W)) // för säkerhets skull stödjer jag upp till 16 GHz, jag är optimist :)
  val mhzInt = p(DevKitFPGAFrequencyKey).toInt
  // Anta att frekvensen är ett helt antal megahertz
  rtcDivider := Mux(rtcDivider === (mhzInt - 1).U, 0.U, rtcDivider + 1.U)
  outer.clintOpt.foreach { clint =>
    clint.module.io.rtcTick := rtcDivider === 0.U
  }

När jag närmar mig Linux-kärnan

Här har berättelsen redan dragit ut på tiden och blivit lite enformig, så jag kommer att beskriva översiktligt:

BBL antog att det skulle finnas ett FDT vid adressen 0xF0000000, men jag hade ju redan rättat till det! Nåväl, vi letar vidare... Hittade i HiFive_U-Boot/arch/riscv/lib/boot.c, bytte till 0x81F00000, angiven i U-Boot:s laddningskonfiguration.

Sedan klagade BBL över att det inte fanns något minne. Min väg ledde till funktionen mem_prop, visar att riscv-pk/machine/fdt.c: därifrån fick jag veta att jag behövde märka noden fdt ram som device_type = "memory" — kanske behöver jag justera CPU-generatorn senare, men för nu skriver jag bara in för hand — jag har ändå flyttat den här filen manuellt.

Nu har jag fått ett meddelande (visat i formaterad stil, med radbrytningar):

This is bbl's dummy_payload. To boot a real kernel, reconfigure bbl
with the flag --with-payload=PATH, then rebuild bbl. Alternatively,
bbl can be used in firmware-only mode by adding device-tree nodes
for an external payload and use QEMU's -bios and -kernel options.

Verkar som att alternativen anges korrekt riscv,kernel-start och riscv,kernel-end i DTB, men nollor parsas. Debugging query_chosen visade att BBL försöker parsa en 32-bitars adress, men stöter på ett par <0x0 0xADDR>, och det första värdet verkar vara de lägre bitarna. Jag lade till i sektionen chosen

chosen {
      #address-cells = ;
      #size-cells = ;
      ...
}

och justerade genereringen av värdena: inte lägga till 0x0 som första element.

Dessa 100500 enkla steg gör det lätt och enkelt att se hur pingvinen faller:

Dolt innehåll

   Verifierar hash-integritet ... md5+ OK
   Laddar lastbar från 0x90a5a758 till 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
valda {
        linux,initrd-end = ;
        linux,initrd-start = ;
        riscv,kernel-end = ;
        riscv,kernel-start = ;
        #address-cells = ;
        #size-cells = ;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
        stdout-path = "uart0:38400n8";
};
libfdt fdt_path_offset() återställde FDT_ERR_NOTFOUND
valda {
        linux,initrd-end = ;
        linux,initrd-start = ;
        riscv,kernel-end = ;
        riscv,kernel-start = ;
        #address-cells = ;
        #size-cells = ;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
        stdout-path = "uart0:38400n8";
};
   Laddar kärnbild ... OK
Startar kärnan i
3
2
1
0
## Startar applikationen vid 0x80000000 ...
bbl loader

                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

           SiFive RISC-V Core IP
[    0.000000] OF: fdt: Ignorerar minnesområde 0x80000000 - 0x80200000
[    0.000000] Linux-version 4.19.0-sifive-1+ (trosinenko@trosinenko-pc) (gcc-version 8.3.0 (Buildroot 2019.02-07449-g4eddd28f99)) #1 SMP Ons Jul 3 21:29:21 MSK 2019
[    0.000000] bootconsole [early0] aktiverad
[    0.000000] Initial ramdisk på: 0x(____ptrval____) (16777216 bytes)
[    0.000000] Zonnintervall:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000]   Normal   [mem 0x00000000c0000000-0x00000bffffffffff]
[    0.000000] Flyttbart zonstart för varje nod
[    0.000000] Tidig minnesnodintervall
[    0.000000]   nod   0: [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] Initmem-setup nod 0 [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] För nod 0 total sidor: 261632
[    0.000000]   DMA32 zon: 3577 sidor använda för memmap
[    0.000000]   DMA32 zon: 0 sidor reserverade
[    0.000000]   DMA32 zon: 261632 sidor, LIFO-batch:63
[    0.000000] mjukvaru IO TLB: mappad [mem 0xbb1fc000-0xbf1fc000] (64MB)

(logotypen visar BBL, och det som är med tidsstämplar - kärnan).

Lyckligtvis vet jag inte hur det är överallt, men på RocketChip kan man fånga trappor direkt från lådan när man ansluter en debugger via JTAG - debuggern stannar exakt i den punkten.

Programmet fick signal SIGTRAP, spårnings-/avbrottstrapp.
0xffffffe0000024ca i ?? ()
(gdb) bt
#0  0xffffffe0000024ca i ?? ()
Tillbakaträd stoppat: föregående ram identisk med denna ram (korrupt stack?)
(gdb) fil work/linux/vmlinux
Ett program debuggeras redan.
Är du säker på att du vill ändra filen? (y eller n) y
Läser symboler från work/linux/vmlinux... klart.
(gdb) bt
#0  0xffffffe0000024ca i setup_smp () på /hdd/trosinenko/fpga/freedom-u-sdk/linux/arch/riscv/kernel/smpboot.c:75
#1  0x0000000000000000 i ?? ()
Tillbakaträd stoppat: ramen sparade inte PC

freedom-u-sdk/linux/arch/riscv/kernel/smpboot.c:

void __init setup_smp(void)
{
    struct device_node *dn = NULL;
    int hart;
    bool found_boot_cpu = false;
    int cpuid = 1;

    while ((dn = of_find_node_by_type(dn, "cpu"))) {
        hart = riscv_of_processor_hartid(dn);
        if (hart < 0)
            continue;

        if (hart == cpuid_to_hartid_map(0)) {
            BUG_ON(found_boot_cpu);
            found_boot_cpu = 1;
            continue;
        }

        cpuid_to_hartid_map(cpuid) = hart;
        set_cpu_possible(cpuid, true);
        set_cpu_present(cpuid, true);
        cpuid++;
    }

    BUG_ON(!found_boot_cpu); // < DU ÄR HÄR
}

Som det sades i den gamla anekdoten, CPU inte hittad, kör programvaru-emulering. Eller inte körande. Förlorad i enstaka kärna av processorn.

/* The lucky hart to first increment this variable will boot the other cores */
atomic_t hart_lottery;
unsigned long boot_cpu_hartid;

En bra kommentar i linux/arch/riscv/kernel/setup.c — en slags målning av ett staket enligt Tom Sawyers metod. Sammanfattningsvis, idag fanns det av någon anledning inga vinnare, priset flyttas till nästa omgång...

Jag föreslår att vi avslutar den här redan utdragna artikeln.

Fortsättning följer. I den kommer en kamp med ett lurigt fel som hinner gömma sig om man närmar sig långsamt med singlestep.

Textbaserad screencast av laddningen (extern länk):