В Moderator memoriae plus minusve operans, vel accuratius, involucrum circa Quartus Core IP, qui adaptatori pro TileLink fungitur, implementatus est. Hodie, in columna "Portatio RocketChip ad Tabulam Cyclone Sinensem Parum Notam", consolatorium operantem videbitis. Processus paulo diutius sumpsit: iam cogitabam me illud celeriter incipere. Linux, et progrediemur, sed non tam facile est. In hac sectione, processum initii U-Boot, BBL, et nonnulla tentativa considerabo. Linux Nucleus initiatus est. Sed est consola — una U-Boot, et satis provecta, cum multis quae ex consola plena exspectes.
Ferramenta includunt SD card connexum per SPI interfaciem, sicut et UART. In parte programmata, Bootrom restituetur cum xip on sdboot ac revera sequentes gradus loading additae sunt (in SD chartae).
Consummatione hardware
Negotium igitur: necesse est ut nucleum "magnus" mutes et coniungas UART (ex Raspberry) et adaptatorem SD (schedulam e Catalexio cum sex paxillis adhibitam esse: GND, VCC, MISO, MOSI, SCK, CS) .
In principio omnia satis simplicia erant. Sed priusquam hoc sentirem, paulum lateris ad latus coniectus sum: posteaquam superiori tempore visum est, iterum opus esse admisceri. System aliquid simile HasPeripheryUART (ac proinde exsecutionem) idem ad card SD - omniaque parata erunt. Tunc decrevi videre quomodo in consilio "gravis" effectum est. Quid ergo grave est? Arty, ut videtur, non convenit - monstrum manet unleahshed.DevKitConfigs. Subito autem evenit ut passim aliquas obducere, quae per clavium parametros additae essent. Suspicor hoc esse probabiliter admodum flexibile et configurabile, sed vellem saltem aliquid prius currere. Annon idem habes, simplicius et molestius?.. Id est cum veni per vera.iofpga.FPGAChip Microsemi enim FPGAs statim seorsim pro virgulis sumpsit et per analogiam meam exsecutionem facere conatus est, feliciter plus minusve totum "matrem tabulae" in uno tabulario est.
Contigit quod vere iustus postulo ut addere System.scala acies
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
...Linea in genere corporis System informationes addit de frequentia in qua haec pars nostri SoC operatur ad fasciculum dts. Quantum intelligo, DTS/DTB est analogum stabilis technologiae obturaculi et fabulae technologiae pro machinis infixae: dts descriptio arbor in binarium dtb limam compilata et a praedone ad nucleum translata ut recte configurare possit. odio. Interestingly, sine linea cum tlclock omnia perfecte componit, sed congero Bootrom (me admoneam, nunc iam hoc erit sdboot) non laborabit - in processu compilation dts limam parsit et caput cum macro creat. TL_CLKpropter quas frequentia divisores pro interfaces externas recte configurare poterit.
Etiam opus est leviter emendare "wiring":
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 card
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
}Registrum vincula, ut sincera, simpliciter cum nonnullis aliis locis in archetypo codice adiecta sunt. Verisimile est, caveant contra . fortasse in quidam caudices iam propriam habent suam tutelam, sed primum illud saltem “ad summam qualitatem” deducere volo. Plus interesting quaestio mihi est cur MISO et MOSI in diversis pendeant dq? Responsum adhuc non inveni, sed reliquum codicem tantum tali nexu niti videtur.
Corporaliter, consilium liberorum contactuum in scandalo clavos assignavi et in intentione electionis thoracem laneum ad 3.3V movebam.
D nibh
Visum desuper:
Imo visum:
Software Debugging: Instrumenta
Primum, loquimur de instrumentis debugging promptis eorumque limitationibus.
Minicom
Primum, necesse erit nobis aliquo modo legere exitum programmatis initialis et nuclei. Ad hoc faciendum, Linux (Hoc in casu, illo in Raspberry Pi) programma Minicom nobis opus erit. Generaliter loquendo, quodlibet programma quod cum portu seriali operatur sufficiet.
Quaeso note quod cum incipiens, nomen portus denominandus est -D /dev/ttyS0 - post optionem -D. Bene, pelagus notitia: exire, utere Ctrl-A, X. Ego revera causam habui cum haec coniunctio non laboravit - tunc simpliciter dicere potes ex sessione vicini SSH killall -KILL minicom.
Pluma unum est. Speciatim RaspberryPi duas UARTs habet, et utraque portus ad aliquid iam accommodari potest: unum pro Bluetooth, alterum per defectionem nuclei consolandi. Fortunate hic mores overridden potest .
Memoria RESCRIBO
Cum debugging, hypothesin probare, quandoque habui onus bootloader (Paenitet) in RAM directe ab hospes. Fortasse hoc fieri potest directe ex GDB, sed in fine viam simplicem secutus sum: limam necessariam ad Raspberry exscripsi, etiam portum 4444 per SSH (telnet ab OpenOCD) transmissum et praefectura usus sum. load_image. Quod cum feceris, omnia gelida videntur, re "non dormit, modo tardius palpitat": tabella eam downloads, hoc modo facit ad celeritatem duorum kilobytarum per alterum.
Features installing breakpoints
Multi probabiliter de hoc cogitare non debebant cum programmata regularia debugging, sed puncta non semper in ferramentis sunt. Interdum profecta breakpoint involvit ad tempus scribens in peculiaribus instructionibus in loco dextro recta in machina codice. Exempli gratia, hoc modo vexillum meum mandatum operatum est b in GDB. Ecce quod sequitur:
- non potes punctum in medio Bootrom quia ROM
- Punctum in codice onerato RAM a card SD inponere potes, sed exspectare debes donec oneratur. Alioquin non nummum codicis rescribemus, sed oneratus nostrum breakpoint scribet
Certus sum aperte petere ut ferramenta breakpoints uti possis, sed paucae earum usquam sunt.
Velox Bootrom postea
In initio debugging, desiderium saepe est Bootrom figere et iterum conari. Sed queritur: BootROM est pars consilii onusti in FPGA, et eius synthesis agitur de paucis minutis (quod est post instantiam prope instantiam ipsius imaginis BootROM ab C et Assembler...). Fortunate in re omnia multo citiusOrdo vero actionum talis est;
- renatis bootrom.mif (MIF loco HEX mutavi quod semper habui difficultates cum HEX, et MIF est altera forma indigena)
- in Quartus dicunt
Processing -> Update Memory Initialization File - in Assembler item (in columna sinistra Tasks) mandatum rursus
Omnia de omnibus - a duobus decem secundis.
Praeparans SD card
Omnia hic relative simplicia sunt, sed patienter esse debes et spatium orbis 14Gb habent;
git clone https://github.com/sifive/freedom-u-sdk
git submodule update --recursive --init
makePost quem mundum inserere debes, vel potius, quae nihil necessarium habet, SD card, et exsequi
sudo make DISK=/dev/sdX format-boot-loader… Ubi sdX - fabrica card. ANIMADVERSIO: notitia in schedula delebitur, overscripta et in genere! Non est operae pretium facere totam ecclesiam de sub sudoquia tunc omnia artificia aedificandi pertinebit ad rootet conventus de infra sudo constanterque credendam.
Effectus est chartae notatae in GPT cum quattuor partitionibus, quarum una cum PINGUIS uEnv.txt et imago bootable in forma FIT (multas sub-imagines continet, singula cum sua inscriptione electronica), altera partitio blank est, in Ext4 pro Linux formata supponitur. Duae plures sectiones - arcanum: U-Boot in una vivit (exceptio eius, quantum intelligo, durata est in Bootrom), in altera, ut videtur, variabiles eius ambitus vivunt, sed illis tamen non utor.
Planum unum, Bootrom
Sapientia popularis dicit: "Si in programmando saltat cum tympano, tum in electronicis saltat etiam igni exstinctor". Ne illud quidem est, quod semel tabulam paene exusi, quod "Bene, GND idem est humilis". (ut videtur, resistor post omnes nocere non potuit...) Plus est de eo quod si manus inde non crescunt, electronici numquam mirari desinunt: cum iungo in tabulam solidatur, adhuc contactus proprie solidare non potui - video ostendit quomodo solida directe diffunditur. Totam connexionem, ferrum solidamentum adhibe, Pro me temere "alapam". Bene, fortasse solidarius non erat conveniens temperaturae ferrum solidatoris, fortasse aliquid aliud. Et tunc incepit arcanum: RX/TX ex UART coniunxi, firmware onero - inquit
INIT
CMD0
ERROROmnia bene logica sunt - SD card moduli non iungo. Rem corrigimus, firmitatem oneramus... Et silentium... Cur animum non mutavi, sed capsula modo aperuit: unum moduli fibulae VCC coniunctam oportuit. In casu meo, modulus 5V pro potentia copia sustentatur, ideo sine bis cogitando, filum a modulo in contrariam tabulae partem orsus sum. Quam ob rem prave iungo solidatus factus est DECLINIS et Contactus UART simpliciter amissus est. facepalm.jpg In genere, "caput malum non dat requiem cruribus", et manus tortuosas non des requiem capiti.
Quam ob rem vidi diu expectatum
INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18
LOADING /Movet et oneratum indicator rotat. Statim recordor scholae meae dierum et otiosorum onerum MinuetOS ex disci floppy. Nisi coegi non tere.
Problema est quod post nuntium CALCEUS nihil accidit. Hoc significat tempus est coniungere per OpenOCD ad Raspberry, GDB in exercitu, et videre quid sit.
Uno modo, connectens utens GDB statim ostendit $pc (Programma contra, inscriptio hodiernae instructionis) volat to 0x0 - Hoc probabiliter accidit post plures errores. Ideo statim post nuntium editur BOOT Addamus ansam infinitam. Hoc eum aliquandiu morabitur...
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;
}Talis sycophanta in codice usus est "pro firmitate": audivi alicubi ansam infinitam esse indefinitam Morum, sed compilator non abhorret coniectura (moneremus te secundum 0x10000 sita est Bootrom).
Videris, quid aliud expectes - duri infixi, quales ibi sunt fontes? Sed in auctor debugging in C codicem... Kreks-fex-pex:
(gdb) file builds/zeowaa-e115/sdboot.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from builds/zeowaa-e115/sdboot.elf...done.
Vos iustus postulo ut non limam MIF vel bin, sed versionem originalem in ELF format.
Nunc coniecturam facere potes cum tali conatu inscriptionis ubi exsecutio perget (haec alia causa est cur compilator conieci non debeat ansam esse infinitam). Team
set variable $pc=0xADDRsino te mutare valorem registri in musca (in hoc casu, inscriptione hodiernae instructionis). Eius ope, bona scripta ad memoriam mutare potes (et registra memoriae praescripta).
Tandem ad conclusionem (non certa quae vera est) habemus "Sd card imaginem systematis iniusti", et non ad primum datae receptae, sed ad 0x89800 porro bytes:
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 .rodataFortasse hoc etiam afficitur eo quod chartam 4Gb non necessariam ad manum habens, 2Gb unum cepi et in Makefile temere reposui. DEMO_END=11718750 on DEMO_END=3078900 (significationem specifice non quaeras - nulla est, iustus est ut nunc imago in schedula posita est).
Level duo, U-Boot
Nunc adhuc sumus "cadere", sed iam in loco sumus 0x0000000080089a84. Hic fateor: etenim praesentatio non "cum omnibus clausuris", sed partim "post" scripta est, itaque hic iam potui inserere rectam dtb fasciculi nostri SoC, in uncinis emendare. HiFive_U-Boot variabilis CONFIG_SYS_TEXT_BASE=0x80089800 (Pro 0x08000000) ut electronica download in re unum aequet. Nunc oneremus tabulam proximi gradus, aliam imaginem;
(gdb) file ../freedom-u-sdk/work/HiFive_U-Boot/u-boot
(gdb) tui enEt videmus;
│304 /* │
│305 * trap entry │
│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) │Quin etiam inter lineas 308 et 309 salimus. Nec mirum, si in d $sp mendacium significatione 0xfffffffe31cdc0a0. Heu, etiam constanter "fugit" propter lineam 307. Ergo punctum temporis figere conemur trap_entryet revertere ad 0x80089800 (U-Boot's entry point), and's spes non requirit tabulas ut recte ante saltum apponantur... Similis est opera eius:
(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
Continuing.
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 = 0x81cf950ACERVUS sic est, libere loquens: RAM omnino praeteriens ostendit (nisi, utique translationem inscriptionis iam non habemus, sed spem optionis simplicis).
Conemur reponere monstratorem cum 0x881cf950. Unde ad conclusionem handle_trap vocati et vocati simul ingredimur _exit_trap cum argumento epc=2148315240 (in decimal):
(gdb) x/10i 2148315240
0x800cb068 <strnlen+12>: lbu a4,0(a5)
0x800cb06c <strnlen+16>: bnez a4,0x800cb078 <strnlen+28>
0x800cb070 <strnlen+20>: sub a0,a5,a0
0x800cb074 <strnlen+24>: ret
0x800cb078 <strnlen+28>: addi a5,a5,1
0x800cb07c <strnlen+32>: j 0x800cb064 <strnlen+8>
0x800cb080 <strdup>: addi sp,sp,-32
0x800cb084 <strdup+4>: sd s0,16(sp)
0x800cb088 <strdup+8>: sd ra,24(sp)
0x800cb08c <strdup+12>: li s0,0Set breakpoint to strnlenpermanemus et videmus
(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=<optimized out>, precision=<optimized out>, flags=<optimized out>) 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 %08x , ra %08lxn", fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn", 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 %08x , ra %08lxn", 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 %08x , ra %08lxn", args=args@entry=0x881cc188) at lib/vsprintf.c:717
#5 0x00000000800ccb50 in printf (fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn") at lib/vsprintf.c:792
#6 0x000000008008a9f0 in _exit_trap (regs=<optimized out>, epc=2148315240, code=<optimized out>) at arch/riscv/lib/interrupts.c:92
#7 handle_trap (mcause=<optimized out>, epc=<optimized out>, regs=<optimized out>) 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 PCVultus amo, _exit_trap vult providere debugging informationes de exceptione quae acciderunt; sed non potest. Unde nescio quo modo fontes nostri denuo non exhibentur. set directories ../freedom-u-sdk/HiFive_U-Boot/ FERE! Nunc ostendi!
Age, iterum curramus et videam ex ACERVUS vestigii causa quaestionis originalis quae primum errorem effecit.mcause == 5). Si recte scriptum intellexi pag 37, tum haec exceptio significat Load access fault. Ratio videtur quod hic
arch/riscv/cpu/HiFive/start.S:
call_board_init_f:
li t0, -16
li t1, CONFIG_SYS_INIT_SP_ADDR
and sp, t1, t0 /* force 16 byte alignment */
#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 /* jump to board_init_f() */
$sp habet eandem falsam significationem et intus board_init_f_init_reserve sed error occurrit. Similis hic reus est: variabilis cum ambiguo nomine CONFIG_SYS_INIT_SP_ADDR. Definitum est in tabella HiFive_U-Boot/include/configs/HiFive-U540.h. Aliquando etiam cogitavi, forsitan, bene, adderem oneratus tabernus pro processus - forsitan facilius esset processus paulo figere? Sed tunc vidi artificium similius fuisse ex non perfecto#if 0-specificae occasus pro diversae memoriae configuratione, et hoc facere conari potes;
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 */In aliquo puncto numerus fusum discrimine pervenit punctum. Aliquanto conflictatus, necessitatem veni ut portum tabulae meae rectam faciam. Ad hoc faciendum, necesse est nos pluribus documentis exscribere et aptare ad conformationem nostram accommodatam.
Bene, proxime, hic parva mensa est
trosinenko@trosinenko-pc:/hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot$ git show --name-status
commit 39cd67d59c16ac87b46b51ac1fb58f16f1eb1048 (HEAD -> zeowaa-1gb)
Author: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Date: Tue Jul 2 17:13:16 2019 +0300
Initial support for Zeowaa A-E115FB board
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.hSingula inveniri possunt in .
Evenit ut in hac tabula SiFive, registra aliquorum machinarum inscriptiones diversas habeant. Apparet etiam U-Boot eodem nucleo quo antea configuratum esse. Linux Mechanismus Kconfig — exempli gratia, iubere potes make menuconfig, & textus opportunus interfacies apparebit ante te exhibens ambitum descriptiones ? etc. Fere cum tertia descriptione duarum tabularum descrip- tionem coaluissem, eiectis omnibus speciebus reconfigurationibus ambitiosis PLL inde (videtur hoc aliquo modo coniunctum esse cum potestate computatrum per Plu, sed hoc certum non est) Firmware nonnullam accepi, quae in Martis serenitate nuntium via UART mihi dedit, de qua committamus de quo exaratum est, et de quantum DRAM habeo (sed ipse haec in titulo scripsi).
Sola misericordia est quod post hanc tabulam per processum JTAG respondere solere substitit, et e card oneratum SD, proh dolor, in mea configuratione non ieiunat. Contra, interdum Bootrom nuntium dedit quod ERRORcaliga defecit, et U- Boot continuo papaver. Tunc mihi illuxit, ut videtur, post reboutionem in FPGA, memoria non deletur, non vacat "exercere", etc. In summa, simpliciter potes, cum nuntius apparet LOADING / coniungere cum debugger et imperium set variable $pc=0x80089800, pertranseo hanc longam oneraturam (sane, supposito quod ultimo tempore satis mature erupit, ne tempus aliquod onerandi super codice archetypo).
Obiter normale est quod processus omnino constringitur et JTAG debugger cum nuntiis coniungi non potest?
Error: unable to halt hart 0
Error: dmcontrol=0x80000001
Error: dmstatus =0x00030c82Ita, expecta! Hoc iam vidi! Simile accidit cum TileLink clauditur, et auctori memoriae moderatoris quodammodo non confido - Ego ipse scripsi... Subito post primum processum feliciter aedificatum, postquam moderatorem edit, vidi:
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: 3Huic ante In: serial noli attendere - conatus sum intellegere in processu pensili num recte cum ambitu agat. Quid vis, "Hoc per decem minutas suspensum est"? Saltem tractavit transvolare et ire ad tabulam tabernus! Digressio parva: quamvis U-Bottus oneratur in primo 2^24 bytes a SD card, cum incipit, se ad ulteriorem inscriptionem transcribit, vel in scriptione capitis, vel simpliciter ad superiores inscriptiones RAM. et facit ELF relocationem characterum et transfert ibi imperium. Ita: is vultus amo nos hunc gradum transegimus et bonum accepimus quod processus non postea arcte pendet.
Cur igitur timor non operatur? Spectat ut horologium aliqua ratione non laborat...
(gdb) x/x 0x0200bff8
0x200bff8: 0x00000000Quid si manually sagittas convertas?
(gdb) set variable *0x0200bff8=310000000
(gdb) cdeinde:
Hit any key to stop autoboot: 0
MMC_SPI: 0 at 0:1 hz 20000000 mode 0Conclusio: horologium non utilatate. Hoc est probabiliter quare tincidunt initus non operatur:
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:
/* First char of ANSI escape sequence 'e' */
if (c == 'e') {
*esc = 1;
*key = KEY_NONE;
}
break;
case 1:
/* Second char of ANSI '[' */
if (c == '[') {
...Problema evasit me parum callidius: clavem processus config addidi;
case DTSTimebase => BigInt(0)... ex eo quod dixit "si nescis, relinque 0." Et post omnia WithNBigCores Modo eam 1MHz constituo (obiter indicatum est in U-Boot config). Sed perduint, sum elegans et exquisitus: ibi non scio, hic 25MHz est! In fine nihil operatur. "emendationem" meam amovi et...
Hit any key to stop autoboot: 0
MMC_SPI: 0 at 0:1 hz 20000000 mode 0
## Unknown partition table type 0
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
** No partition table - mmc 0 **
## Info: input data size = 34 = 0x22
Running uEnv.txt boot2...
## Error: "boot2" not defined
HiFive-Unleashed #Potes etiam inire mandata! Exempli gratia, postquam paululum cucurrimus, tandem coniecturam ingredi potes mmc_spi 1 10000000 0; mmc partreducendo SPI frequentiam ab 20MHz ad 10MHz. Quare? Sed maxima frequentia 20MHz in aboutconfig scripta est, et adhuc ibi scripta est. Sed, quantum intelligo, interfaces, hoc saltem opus, hoc modo: codice frequentiam unitatis ferrariae (meum 25MHz ubique est) per scopum dividit, et valorem inde divisorem in potestate correspondente dividit. mandare. Problema est quod si ad 115200Hz UART proxime opus est, tum si 25000000 dividas per 20000000, habebis 1, i.e. opus erit in 25MHz. Forsitan hoc normale est, sed si restrictiones, significat aliquem indigere (sed hoc certum non est). 25MHz non est Core i9.
Consolamini output
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 0x82000000Bene, gradum venimus, sed adhuc congelatio est. Et interdum exceptiones aspergit. Potes videre mcause per insidias in codice ad praefinitum electronicum $pc tum si esse trap_entry. Ipse tractator U-Boot tantum outputare potest pro causa = 0..4, ita compararim ut in tabernus falsa haerere possit. Deinde ingressus config, coepit intueri quid mutarem, et recordatus sum conf/rvboot-fit.txt scriptum:
fitfile=image.fit
# below much match what's in FIT (ugha)Bene, omnia documenta in obsequium afferamus, nucleum praecipe lineam in re huius modi repone, quia suspiciones sunt. SIF0 - hoc est output alicubi per Plu;
-bootargs=console=ttySIF0,921600 debug
+bootargs=console=ttyS0,125200 debugEt algorithmum hashing mutemus ab SHA-256 ad MD5: Viribus cryptographicis (praesertim debugging), non opus est valde longum tempus, et ad capiendas errores integritatem in oneratione, MD5 nimis facilis est. Quid tandem evenit? Praecedentem gradum conspicue velocius perficere coepimus (ob hashing simplicius), et proximus apertus est;
...
Verifying Hash Integrity ... md5+ OK
Loading loadables from 0x90a5a758 to 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
chosen {
linux,initrd-end = <0x00000000 0x83000000>;
linux,initrd-start = <0x00000000 0x82000000>;
riscv,kernel-end = <0x00000000 0x80a00000>;
riscv,kernel-start = <0x00000000 0x80200000>;
bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
chosen {
linux,initrd-end = <0x00000000 0x83000000>;
linux,initrd-start = <0x00000000 0x82000000>;
riscv,kernel-end = <0x00000000 0x80a00000>;
riscv,kernel-start = <0x00000000 0x80200000>;
bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
Loading Kernel Image ... OK
Booting kernel in
3Sed horologium non utilatate...
(gdb) x/x 0x0200bff8
0x200bff8: 0x00000000Oops, spectat quasi horologium corrigendum esse ad placebo, quamquam mihi tempore adiutus videbatur. Non utique figi debet, sed primum sagittas manuales convertamus et quid eveniat videamus:
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=1000000
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=2000000
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=3000000
(gdb) c
Continuing.interea…
Loading Kernel Image ... OK
Booting kernel in
3
2
1
0
## Starting application at 0x80000000 ...Imo automate horologium - aliter fortasse calibrare timer ibi decidet!
Interim electronica in alicubi puncta instructionis hodiernae
0000000080001c20 <poweroff>:
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 <softfloat_countLeadingZeros8+0x558>
80001c2e: e406 sd ra,8(sp)
80001c30: f7fff0ef jal ra,80001bae <printm>
80001c34: 8522 mv a0,s0
80001c36: 267000ef jal ra,8000269c <finisher_exit>
80001c3a: 00010797 auipc a5,0x10
80001c3e: 41e78793 addi a5,a5,1054 # 80012058 <htif>
80001c42: 639c ld a5,0(a5)
80001c44: c399 beqz a5,80001c4a <poweroff+0x2a>
80001c46: 72c000ef jal ra,80002372 <htif_poweroff>
80001c4a: 45a1 li a1,8
80001c4c: 4501 li a0,0
80001c4e: dc7ff0ef jal ra,80001a14 <send_ipi_many>
80001c52: 10500073 wfi
80001c56: bff5 j 80001c52 <poweroff+0x32>intus oneratus Berkeley Boot Loader. Personaliter, quod me de hac re confundit mentio htif - interfacies exercitus adhibitus pro alligato nucleo (id est, in cooperatione cum ARM exercitu), standum assumpsit. Attamen, si hoc munus in fonte codice inveneris, videre potes non omnia tam mala esse;
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"); }
}
}Quest: horologium incipere
Investigatio tabularum in CLINT nos ducit ad
val io = IO(new Bundle {
val rtcTick = Bool(INPUT)
})
val time = RegInit(UInt(0, width = timeWidth))
when (io.rtcTick) { time := time + UInt(1) }Quae cum RTC, vel arcano MockAON coniungit, de quo initio cogitabam: “Quid ergo hic habemus? Obscurum? Divertamus eum!" Cum adhuc non intellego qualia horologii magicae ibi gerantur, ego hanc logicam modo recompensabo in System.scala:
val rtcDivider = RegInit(0.asUInt(16.W)) // на всякий случай поддержу до 16ГГц, я оптимист :)
val mhzInt = p(DevKitFPGAFrequencyKey).toInt
// Преположим, частота равна целому числу мегагерц
rtcDivider := Mux(rtcDivider === (mhzInt - 1).U, 0.U, rtcDivider + 1.U)
outer.clintOpt.foreach { clint =>
clint.module.io.rtcTick := rtcDivider === 0.U
}Viam meam facio ad Linux kernel
Hic fabula iam protracta est et paulo fastidiosus factus est, ut eam a summo ad imum describerem;
BBL assumpsit coram FDT at 0xF0000000sed iam correxi! Age, rursus inspiciamus HiFive_U-boot/arch/riscv/lib/boot.c, Subrogatum 0x81F00000, de configuratione tabernus U-Bottae specificatae.
Tunc BBL conquestus est quod nulla memoria esset. in munere pono semita mea mem_propquid in? riscv-pk/machine/fdt.cinde didici te notare opus fdt ram nodi as device_type = "memory" - tunc fortasse processus generans emendari debebit, sed nunc manualiter scribemus - usquam, hunc fasciculum manually transtuli.
Nunc nuntium accepi (dum forma formatae, cum raeda redit);
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.Videtur quod optiones indicentur ut opus sit riscv,kernel-start и riscv,kernel-end in DTB, sed cyphras parsed. Debugging query_chosen BBL demonstravit conatur ad parteme inscriptionis 32-bit, sed fit per par <0x0 0xADDR>priorque pretii minimi momenti esse videtur. Additum ad sectionem chosen
chosen {
#address-cells = <1>;
#size-cells = <0>;
...
}et emendavit generatio valorum: non addo 0x0 elementum primis.
Haec 100500 simplicium vestigia facilem faciunt ut in penguin cadunt;
Occultatum illud
Verifying Hash Integrity ... md5+ OK
Loading loadables from 0x90a5a758 to 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
chosen {
linux,initrd-end = <0x83000000>;
linux,initrd-start = <0x82000000>;
riscv,kernel-end = <0x80a00000>;
riscv,kernel-start = <0x80200000>;
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
stdout-path = "uart0:38400n8";
};
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
chosen {
linux,initrd-end = <0x83000000>;
linux,initrd-start = <0x82000000>;
riscv,kernel-end = <0x80a00000>;
riscv,kernel-start = <0x80200000>;
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
stdout-path = "uart0:38400n8";
};
Loading Kernel Image ... OK
Booting kernel in
3
2
1
0
## Starting application at 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 555555555 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: Ignoring memory range 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 Wed Jul 3 21:29:21 MSK 2019
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] Initial ramdisk at: 0x(____ptrval____) (16777216 bytes)
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000bfffffff]
[ 0.000000] Normal [mem 0x00000000c0000000-0x00000bffffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080200000-0x00000000bfffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
[ 0.000000] On node 0 totalpages: 261632
[ 0.000000] DMA32 zone: 3577 pages used for memmap
[ 0.000000] DMA32 zone: 0 pages reserved
[ 0.000000] DMA32 zone: 261632 pages, LIFO batch:63
[ 0.000000] software IO TLB: mapped [mem 0xbb1fc000-0xbf1fc000] (64MB)(logo per BBL exhibetur et unum cum indicationibus nuclei monstratur).
Fortunate, nescio quomodo ubique sit, sed in RocketChip, cum debugger per JTAG coniungis, laqueos ex archa capere potes - debugger in hoc puncto prorsus cessabit.
Program received signal SIGTRAP, Trace/breakpoint trap.
0xffffffe0000024ca in ?? ()
(gdb) bt
#0 0xffffffe0000024ca in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) file work/linux/vmlinux
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from work/linux/vmlinux...done.
(gdb) bt
#0 0xffffffe0000024ca in setup_smp () at /hdd/trosinenko/fpga/freedom-u-sdk/linux/arch/riscv/kernel/smpboot.c:75
#1 0x0000000000000000 in ?? ()
Backtrace stopped: frame did not save the PClibertas 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); // < ВЫ НАХОДИТЕСЬ ЗДЕСЬ
}Ut vetus iocus dixit; CPU non invenitur, programmatio currens. Etiam vel cursus neque. Perdidit in uno processus core.
/* The lucky hart to first increment this variable will boot the other cores */
atomic_t hart_lottery;
unsigned long boot_cpu_hartid;Nice comment in linux/arch/riscv/kernel/setup.c — pingendi quaedam sepes usus in methodo Tom Sawyer. In genere, aliqua de causa hodie victores non erant, praemium proximum tra- ducatur...
Hic jam prolixum articulum finire propono.
Continuanda. Pugna cum cimex callido quod celare procurat, si in ea lente serpas cum odio.
Textus download screencast (externa pagina);
Source: www.habr.com
