Linux throws Segmentation Faults

[Philipp Schmitz]

Hello everyone,

I am running the BOOM medium config on a ZCU104 FPGA.

I followed the suggested prototyping workflow from the documentation.

At first I had some issues with the MIG parameters and the copying from the SD Card to the DRAM did not yield the expected results.

Then, I adapted the parameters and now the boot process the init script and then starts to throw segmentation faults.

Sometimes it even reaches the log in prompt and I am able to log in after several tries.

The DRAM contains the expected values after the first stage of the bootloader (I dumped the copied values and wrote a script to compare them)

I would be very glad if someone could pinpoint where things go south during the boot.

Can it still be some DRAM timing issue or is the linux image corrupted or is there even another reason?

Thank you in advance and kind regards

Philipp

Platform Name       : freechips,rocketchip-unknown
Platform Features   : timer,mfdeleg
Platform HART Count : 1
Boot HART ID        : 0
Boot HART ISA       : rv64imafdcsux
BOOT HART Features  : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base       : 0x80000000
Firmware Size       : 92 KB
Runtime SBI Version : 0.2

MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0    : 0x0000000080000000-0x000000008001ffff (A)
PMP1    : 0x0000000000000000-0x00000001ffffffff (A,R,W,X)
[    0.000000] OF: fdt: No chosen node found, continuing without
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Forcing kernel command line to: console=hvc0 earlycon=sbi
[    0.000000] Linux version 5.7.0-rc3-58539-g5f5fd87b36e2 (XXX@pop-os) (gcc version 9.2.0 (GCC), GNU ld (GNU Binutils) 2.32) #1 SMP Mon Mar 28 21:28:15 CEST 2022
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[    0.000000] printk: bootconsole [sbi0] enabled
[    0.000000] initrd not found or empty - disabling initrd
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000] software IO TLB: mapped [mem 0xfa3fa000-0xfe3fa000] (64MB)
[    0.000000] SBI specification v0.2 detected
[    0.000000] SBI implementation ID=0x1 Version=0x8
[    0.000000] SBI v0.2 TIME extension detected
[    0.000000] SBI v0.2 IPI extension detected
[    0.000000] SBI v0.2 RFENCE extension detected
[    0.000000] SBI v0.2 HSM extension detected
[    0.000000] elf_hwcap is 0x112d
[    0.000000] percpu: Embedded 17 pages/cpu s31976 r8192 d29464 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 516615
[    0.000000] Kernel command line: console=hvc0 earlycon=sbi
[    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 1974032K/2095104K available (6544K kernel code, 4152K rwdata, 4096K rodata, 6327K init, 318K bss, 121072K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0xffffffcefee00000 - 0xffffffceff000000   (2048 kB)
[    0.000000]       pci io : 0xffffffceff000000 - 0xffffffcf00000000   (  16 MB)
[    0.000000]      vmemmap : 0xffffffcf00000000 - 0xffffffcfffffffff   (4095 MB)
[    0.000000]      vmalloc : 0xffffffd000000000 - 0xffffffdfffffffff   (65535 MB)
[    0.000000]       lowmem : 0xffffffe000000000 - 0xffffffe07fe00000   (2046 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[    0.000000] rcu:     RCU debug extended QS entry/exit.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[    0.000000] plic: mapped 2 interrupts with 1 handlers for 2 contexts.
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
[    0.000680] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
[    0.022352] Console: colour dummy device 80x25
[    0.029700] printk: console [hvc0] enabled
[    0.029700] printk: console [hvc0] enabled
[    0.041318] printk: bootconsole [sbi0] disabled
[    0.041318] printk: bootconsole [sbi0] disabled
[    0.055010] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
[    0.069757] pid_max: default: 32768 minimum: 301
[    0.098274] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.111558] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.274512] rcu: Hierarchical SRCU implementation.
[    0.322427] smp: Bringing up secondary CPUs ...
[    0.329990] smp: Brought up 1 node, 1 CPU
[    0.370383] devtmpfs: initialized
[    0.500244] random: get_random_u32 called from bucket_table_alloc.isra.0+0x4a/0xbe with crng_init=0
[    0.541409] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.555823] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.614186] NET: Registered protocol family 16
[    2.540167] vgaarb: loaded
[    2.581780] SCSI subsystem initialized
[    2.629699] usbcore: registered new interface driver usbfs
[    2.643342] usbcore: registered new interface driver hub
[    2.654875] usbcore: registered new device driver usb
[    2.755802] clocksource: Switched to clocksource riscv_clocksource
[    3.681130] NET: Registered protocol family 2
[    3.771527] tcp_listen_portaddr_hash hash table entries: 1024 (order: 3, 40960 bytes, linear)
[    3.795955] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    3.859152] TCP bind hash table entries: 16384 (order: 7, 524288 bytes, linear)
[    4.012187] TCP: Hash tables configured (established 16384 bind 16384)
[    4.037711] UDP hash table entries: 1024 (order: 4, 98304 bytes, linear)
[    4.072672] UDP-Lite hash table entries: 1024 (order: 4, 98304 bytes, linear)
[    4.120707] NET: Registered protocol family 1
[    4.192134] RPC: Registered named UNIX socket transport module.
[    4.203459] RPC: Registered udp transport module.
[    4.211435] RPC: Registered tcp transport module.
[    4.219445] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.230956] PCI: CLS 0 bytes, default 64
[   47.380997] workingset: timestamp_bits=62 max_order=19 bucket_order=0
[   48.975038] NFS: Registering the id_resolver key type
[   48.984896] Key type id_resolver registered
[   48.992748] Key type id_legacy registered
[   49.000695] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[   49.027280] 9p: Installing v9fs 9p2000 file system support
[   49.084169] NET: Registered protocol family 38
[   49.095630] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[   49.107104] io scheduler mq-deadline registered
[   49.114990] io scheduler kyber registered
[   55.835414] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   55.984920] 64000000.serial: ttySIF0 at MMIO 0x64000000 (irq = 1, base_baud = 0) is a SiFive UART v0
[   56.063782] [drm] radeon kernel modesetting enabled.
[   57.211634] loop: module loaded
[   57.291788] sifive_spi 64001000.spi: mapped; irq=2, cs=1
[   57.444010] libphy: Fixed MDIO Bus: probed
[   57.571740] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[   57.581282] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[   57.604765] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   57.615153] ehci-pci: EHCI PCI platform driver
[   57.627852] ehci-platform: EHCI generic platform driver
[   57.644985] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   57.657012] ohci-pci: OHCI PCI platform driver
[   57.671733] ohci-platform: OHCI generic platform driver
[   57.728856] usbcore: registered new interface driver uas
[   57.745251] usbcore: registered new interface driver usb-storage
[   57.776594] mousedev: PS/2 mouse device common for all mice
[   57.915668] mmc_spi spi0.0: SD/MMC host mmc0, no DMA, no WP, no poweroff, cd polling
[   57.955661] usbcore: registered new interface driver usbhid
[   57.964745] usbhid: USB HID core driver
[   58.087476] NET: Registered protocol family 10
[   58.263094] Segment Routing with IPv6
[   58.280123] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[   58.367006] NET: Registered protocol family 17
[   58.403469] 9pnet: Installing 9P2000 support
[   58.416115] Key type dns_resolver registered
[   59.375316] Freeing unused kernel memory: 6324K
[   59.399966] Run /init as init process
[   59.880452] mmc0: host does not support reading read-only switch, assuming write-enable
[   59.895037] mmc0: new SDHC card on SPI
[   60.024182] mmcblk0: mmc0:0000 SL16G 14.8 GiB
[   60.483820] random: fast init done
Running FireMarshal nodisk init
[   64.881375] init[47]: unhandled signal 11 code 0x1 at 0xffffffe00080122c in busybox[10000+d6000]
[   64.904652] CPU: 0 PID: 47 Comm: init Not tainted 5.7.0-rc3-58539-g5f5fd87b36e2 #1
[   64.916371] epc: 000000000005bb2c ra : 000000000005bb2c sp : 0000003fffd6f830
[   64.927557]  gp : 00000000000e7d70 tp : 0000003fdb2cb7e0 t0 : 0000003fdb1b9d58
[   64.938821]  t1 : 0000003fdb235fc4 t2 : 00000000000e7940 s0 : 00000000000ea320
[   64.951043]  s1 : 00000000000e9710 a0 : 0000000000000000 a1 : 0000000000000000
[   64.963262]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000001
[   64.975414]  a5 : 0000000000000001 a6 : 0000000000000006 a7 : 00000000000000dc
[   64.986644]  s2 : 00000000000e9670 s3 : 0000000000000000 s4 : 00000000000e9670
[   64.998895]  s5 : 00000000000e17ef s6 : ffffffffffffffff s7 : 0000000000000000
[   65.011123]  s8 : 0000000000000000 s9 : 00000000000c62c0 s10: 00000000000e17ef
[   65.023333]  s11: 00000000000c6300 t3 : 0000000000000000 t4 : 000000000007ffc4
[   65.035370]  t5 : 0000000000000004 t6 : 0000000000000000
[   65.044280] status: 0000000200004020 badaddr: ffffffe00080122c cause: 000000000000000c
[   66.980385]  mmcblk0: p1 p2
Segmentation fault
Loading FireMarshal platform drivers
[   68.288304] modprobe[50]: unhandled signal 11 code 0x1 at 0xffffffe00080121c in libc-2.29.so[3fc33a0000+fb000]
[   68.305785] CPU: 0 PID: 50 Comm: modprobe Not tainted 5.7.0-rc3-58539-g5f5fd87b36e2 #1
[   68.319394] epc: 0000003fc342069c ra : 00000000000186d8 sp : 0000003fffb2ccd0
[   68.331559]  gp : 00000000000e7d70 tp : 0000003fc34b57e0 t0 : 0000003fc33a3d58
[   68.342915]  t1 : 0000003fc342069c t2 : 00000000000e7940 s0 : 00000000000bab6e
[   68.355288]  s1 : 0000003fffb2ce48 a0 : 0000003fffb2cfbd a1 : 6c2d0065626f7270
[   68.367533]  a2 : 81030103017f0101 a3 : 0000000000000000 a4 : 000000000000002f
[   68.379577]  a5 : 0000003fffb2cfc8 a6 : 7efefefefefefeff a7 : 43022f4a4d405d5f
[   68.390935]  s2 : 00000000000e1838 s3 : 0000000000000000 s4 : 0000000000000000
[   68.403270]  s5 : 0000000000000008 s6 : 0000003fdb2cb7f0 s7 : 0000000000000002
[   68.415515]  s8 : 0000000000000014 s9 : 0000003fdb2cb7f0 s10: 00000000000e17ef
[   68.426849]  s11: 00000000000c6300 t3 : 0000000000000000 t4 : 000000000008069c
[   68.439461]  t5 : 0000000000000004 t6 : 0000000000000000
[   68.448499] status: 8000000200006020 badaddr: ffffffe00080121c cause: 000000000000000c
Segmentation fault
[   68.827364] modprobe[51]: unhandled signal 11 code 0x1 at 0xffffffe000801224 in busybox[10000+d6000]
[   68.844167] CPU: 0 PID: 51 Comm: modprobe Not tainted 5.7.0-rc3-58539-g5f5fd87b36e2 #1
[   68.856329] epc: 00000000000ae464 ra : 000000000003245c sp : 0000003fff86fad0
[   68.867488]  gp : 00000000000e7d70 tp : 0000003fd26037e0 t0 : 0000003fd24f1d58
[   68.878735]  t1 : 0000003fd2552f22 t2 : 00000000000e7940 s0 : 00000000000bb3c8
[   68.890993]  s1 : 0000003fff86fe48 a0 : 0000003fff86fe48 a1 : 00000000000bf8f8
[   68.903218]  a2 : 00000000000e3245 a3 : 00000000000009a0 a4 : 00000000000e9c00
[   68.915448]  a5 : 00000000000e9c00 a6 : 0000000000000004 a7 : 00000000000e9be0
[   68.926668]  s2 : 0000000000000002 s3 : 00000000000e9260 s4 : 0000000000000000
[   68.938893]  s5 : 0000000000000008 s6 : 0000003fdb2cb7f0 s7 : 0000000000000002
[   68.951128]  s8 : 0000000000000014 s9 : 0000003fdb2cb7f0 s10: 00000000000e17ef
[   68.963356]  s11: 00000000000c6300 t3 : 0000000000000000 t4 : 0000000000064f22
[   68.975380]  t5 : 0000000000000004 t6 : 0000000000000000
[   68.984302] status: 8000000200006020 badaddr: ffffffe000801224 cause: 000000000000000c
Segmentation fault
umount: can't unmount /proc: Invalid argument
Calling distro init
[   70.087691] init[1]: unhandled signal 11 code 0x1 at 0xffffffe000801c46 in libc-2.29.so[3fbc19a000+fb000]
[   70.103440] CPU: 0 PID: 1 Comm: init Not tainted 5.7.0-rc3-58539-g5f5fd87b36e2 #1
[   70.115175] epc: 0000003fbc1fe046 ra : 0000003fbc23a3f2 sp : 0000003ffff0fd70
[   70.127416]  gp : 00000000000e7d70 tp : 0000003fbc2af7e0 t0 : 0000003fbc2b0198
[   70.138762]  t1 : 0000000000000002 t2 : 0000000000000000 s0 : 0000003ffff0fe58
[   70.151083]  s1 : 0000003ffff0ffc2 a0 : 0000003ffff0ffc2 a1 : 000000000000002f
[   70.163400]  a2 : 0000003ffff0fe68 a3 : 000000000000000b a4 : 0000003fbc29e012
[   70.174745]  a5 : 0000003fbc2b0824 a6 : 0000000000000003 a7 : 0000003fbc2b0270
[   70.187078]  s2 : 0000003ffff0fe68 s3 : 0000003ffff0fd98 s4 : 0000003ffff0fe68
[   70.199401]  s5 : fffffffffffffff8 s6 : 0000003fdb2cb7f0 s7 : 0000000000000000
[   70.211227]  s8 : 0000000000000000 s9 : 00000000000c62c0 s10: 00000000000e17ef
[   70.223509]  s11: 00000000000c6300 t3 : 0000000000000000 t4 : 0000000000000824
[   70.234745]  t5 : 0000000000000001 t6 : 0000000000000040
[   70.244162] status: 0000000200004020 badaddr: ffffffe000801c46 cause: 000000000000000c
[   70.268325] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[   70.279063] CPU: 0 PID: 1 Comm: init Not tainted 5.7.0-rc3-58539-g5f5fd87b36e2 #1
[   70.289014] Call Trace:
[   70.293262] [<ffffffe000802430>] walk_stackframe+0x0/0xaa
[   70.301084] [<ffffffe00080261c>] show_stack+0x2a/0x34
[   70.308692] [<ffffffe000a7ec20>] dump_stack+0x6e/0x88
[   70.316274] [<ffffffe000808126>] panic+0xf2/0x278
[   70.323200] [<ffffffe00080a372>] do_exit+0x7a0/0x7b2
[   70.330460] [<ffffffe00080af48>] do_group_exit+0x2a/0x7e
[   70.338161] [<ffffffe0008130a8>] get_signal+0xbc/0x54c
[   70.345635] [<ffffffe000801cc2>] do_notify_resume+0x5c/0x33e
[   70.354009] [<ffffffe0008011aa>] ret_from_exception+0x0/0xc
[   70.362275] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

[Philipp Schmitz]

Hello everyone,

a short update:

We tried synthesizing a rocket core CPU with our setup and it worked fine.

Afterwards we synthesized a BOOM with the small config and it also works fine.

Going down with the medium BOOM CPU frequency also does not help.

For the medium BOOM config the utilization of overall CLBs is around 94% but the individula LUT and registers utilizations are only around 60% which should be okay.

Vivado also does not give any errors regarding the timing or the congestion. 

Small BOOM has an overall utilization of 69% for CLBs and 42% for CLB LUTs.

Has anyone experienced similar issues with the BOOM medium config?

Is the FPGA (ZCU104) too small for the medium BOOM configuration to fit and has anybody ideas for improvements in the bitstream generation?

Regards

Philipp

[Allen]

Hi Philipp,

I have a zcu104 and is trying to reproduce your problem.

After modifying "chipyard.fpga.vcu118.VCU118FPGATestHarness.RocketVCU118Config.shell.xdc" to the corresponding FPGA pin of zcu104

the boot process shows no message.

Can you share your zcu104 porting flow?

schmitz.p...@gmail.com 在 2022年6月2日 星期四下午7:44:05 [UTC+8] 的信中寫道：

[Philipp Schmitz]

Hi Allen,

you can find the current setup in https://github.com/Schmitz48/ZCU104BOOM

It contains all files chipyard/fpga contains as well as the files we added to port the flow to the ZCU104.

In fpga/fpga-shells/src/main/scala/ip/xilinx/zcu104mig/zcu104mig.scala the parameters may need to be adapted depending on your used DDR4 memory.

Thank you for your time

Regards

Philipp

[Allen]

Hi Philipp,

I have re-produced this problem with medium Boom config.

The boot process is stocked(at least 1 hour) at " initrd not found or empty - disabling initrd" .

Can't see segmentation faults like yours.

My DRAM module : CT4G4SFS8266, vivado version: 2019.2

Maybe the cause is vivado synthesis or implementation.

I will try changing flags/strategy of vivado synthesis and implementation.

Thanks.

schmitz.p...@gmail.com 在 2022年6月7日 星期二下午7:03:31 [UTC+8] 的信中寫道：

[Philipp Schmitz]

Hi Allen,

for me the boot process sometimes gets stuck at the same point as well. It feels like small changes, e.g. added debug prints in the bootloader sd.c, impact if the generated bitstream reaches a certain point during the boot process.

Could you possibly verify that the small config works for you?

We're currently at the point where we think that the ZCU104 can barely meet the timing constraints for the medium config which may lead to stability issues.

There are some critical warnings regarding CDC and the CLB utilization is at 94%. However, there are no congestion warnings by vivado.

Please let me know if you find any flags or strategies that improve the results.

Thank you

Philipp  

[Allen]

Hi Philipp,

The small Boom is OK.

I have tried three vivado synthesis/imp. strategies for big Boom, all of them stocked at the same point, including area/timing/performance aware optimization.

Below are vivado results of these three optimization.

I didn't find CDC and the CLB utilizatio report, could you tell me where are them?

Maybe the utilization of area optimization is acceptable but ends in same error.

By the way, did you build "RocketBringupConfig" successfully?

I would like to add I2C support on my config, but don't know how to do.

Could you share how to do? please.

Area:

Timing:

Performance:

schmitz.p...@gmail.com 在 2022年6月13日 星期一下午3:59:05 [UTC+8] 的信中寫道：

[Philipp Schmitz]

Hi Allen,

thanks for your confirmation.

You can find the CDC report under Reports/Timing/Report CDC... and the CLB utilization under Reports/Report Utilization...

Note that I am using vivado 2020.1.

Regarding I2C: I have not yet tried to add an I2C to the design. I'll let you know if I have any updates

Regards

[Junaid amjad]

Have you integrated I2C yet in your design?

[Dakota Berbrich]

Phillip,

I'm at a similar place with the ZCU106 eval board, I was hoping to gain some insight into how you dumped the memory contents to compare with the expected values.

Here is where I am at, at which it stalls indefinitely:

      INIT
      CMD0
      CMD8
      ACMD41
      CMD58
      CMD16
      CMD18
      LOADING 0x01e00000B PAYLOAD
      LOADING  
      BOOT

      OpenSBI v0.8
      ____                    _____ ____ _____
      / __ \                  / ____|  _ \_   _|
      | |  | |_ __   ___ _ __ | (___ | |_) || |
      | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
      | |__| | |_) |  __/ | | |____) | |_) || |_
      \____/| .__/ \___|_| |_|_____/|____/_____|
            | |
            |_|

      Platform Name       : freechips,rocketchip-unknown
      Platform Features   : timer,mfdeleg
      Platform HART Count : 1
      Boot HART ID        : 0
      Boot HART ISA       : rv64imafdcsu

      BOOT HART Features  : pmp,scounteren,mcounteren
      BOOT HART PMP Count : 16
      Firmware Base       : 0x80000000

      Firmware Size       : 96 KB

      Runtime SBI Version : 0.2

      MIDELEG : 0x0000000000000222
      MEDELEG : 0x000000000000b109
      PMP0    : 0x0000000080000000-0x000000008001ffff (A)
      PMP1    : 0x0000000000000000-0x00000001ffffffff (A,R,W,X)

I updated the MIG to reflect the ZCU106's PL-Side DDR4 Component to the following. Note that the ZCU106 appears to really only has one clock source option, 300MHz for the sys_clock overlay due to HP/HD restraints, so I am using that input clock speed when updating the MIG. The DUT is still specified to have the 50 MHz clock for SmallBoom (this issue is also present in the Rocket config). Everything synthesizes and implements without critical errors, so I am a little lost on how to proceed, so I wanted to verify the DDR4 contents, before diving into another route.

    "zcu106mig.vivado.tcl",
    """
      create_ip -vendor xilinx.com -library ip -version 2.2 -name ddr4 -module_name zcu106mig -dir $ipdir -force
      set_property -dict [list \
      CONFIG.AL_SEL                               {0} \
      CONFIG.C0.ADDR_WIDTH                        {17} \
      CONFIG.C0.BANK_GROUP_WIDTH                  {1} \
      CONFIG.C0.CKE_WIDTH                         {1} \
      CONFIG.C0.CK_WIDTH                          {1} \
      CONFIG.C0.CS_WIDTH                          {1} \
      CONFIG.C0.ControllerType                    {DDR4_SDRAM} \
      CONFIG.C0.DDR4_AUTO_AP_COL_A3               {false} \
      CONFIG.C0.DDR4_AutoPrecharge                {false} \
      CONFIG.C0.DDR4_AxiAddressWidth              {31} \
      CONFIG.C0.DDR4_AxiArbitrationScheme         {RD_PRI_REG} \
      CONFIG.C0.DDR4_AxiDataWidth                 {64} \
      CONFIG.C0.DDR4_AxiIDWidth                   {4} \
      CONFIG.C0.DDR4_AxiNarrowBurst               {false} \
      CONFIG.C0.DDR4_AxiSelection                 {true} \
      CONFIG.C0.DDR4_BurstLength                  {8} \
      CONFIG.C0.DDR4_BurstType                    {Sequential} \
      CONFIG.C0.DDR4_CLKFBOUT_MULT                {5} \
      CONFIG.C0.DDR4_CLKOUT0_DIVIDE               {9} \
      CONFIG.C0.DDR4_Capacity                     {512} \
      CONFIG.C0.DDR4_CasLatency                   {10} \
      CONFIG.C0.DDR4_CasWriteLatency              {9} \
      CONFIG.C0.DDR4_ChipSelect                   {true} \
      CONFIG.C0.DDR4_Clamshell                    {false} \
      CONFIG.C0.DDR4_CustomParts                  {no_file_loaded} \
      CONFIG.C0.DDR4_DIVCLK_DIVIDE                {1} \
      CONFIG.C0.DDR4_DataMask                     {DM_NO_DBI} \
      CONFIG.C0.DDR4_DataWidth                    {64} \
      CONFIG.C0.DDR4_Ecc                          {false} \
      CONFIG.C0.DDR4_MCS_ECC                      {false} \
      CONFIG.C0.DDR4_Mem_Add_Map                  {ROW_COLUMN_BANK} \
      CONFIG.C0.DDR4_MemoryName                   {MainMemory} \
      CONFIG.C0.DDR4_MemoryPart                   {MT40A256M16GE-075E} \
      CONFIG.C0.DDR4_MemoryType                   {Components} \
      CONFIG.C0.DDR4_MemoryVoltage                {1.2V} \
      CONFIG.C0.DDR4_OnDieTermination             {RZQ/6} \
      CONFIG.C0.DDR4_Ordering                     {Normal} \
      CONFIG.C0.DDR4_OutputDriverImpedenceControl {RZQ/7} \
      CONFIG.C0.DDR4_PhyClockRatio                {4:1} \
      CONFIG.C0.DDR4_SAVE_RESTORE                 {false} \
      CONFIG.C0.DDR4_SELF_REFRESH                 {false} \
      CONFIG.C0.DDR4_Slot                         {Single} \
      CONFIG.C0.DDR4_Specify_MandD                {true} \
      CONFIG.C0.DDR4_TimePeriod                   {1500} \
      CONFIG.C0.DDR4_UserRefresh_ZQCS             {false} \
      CONFIG.C0.DDR4_isCKEShared                  {false} \
      CONFIG.C0.DDR4_isCustom                     {false} \
      CONFIG.C0.LR_WIDTH                          {1} \
      CONFIG.C0.ODT_WIDTH                         {1} \
      CONFIG.C0.StackHeight                       {1} \
      CONFIG.C0_CLOCK_BOARD_INTERFACE             {Custom} \
      CONFIG.C0_DDR4_BOARD_INTERFACE              {Custom} \
      CONFIG.DCI_Cascade                          {false} \
      CONFIG.DIFF_TERM_SYSCLK                     {false} \
      CONFIG.Debug_Signal                         {Disable} \
      CONFIG.Default_Bank_Selections              {false} \
      CONFIG.Enable_SysPorts                      {true} \
      CONFIG.IOPowerReduction                     {OFF} \
      CONFIG.IO_Power_Reduction                   {false} \
      CONFIG.IS_FROM_PHY                          {1} \
      CONFIG.MCS_DBG_EN                           {false} \
      CONFIG.No_Controller                        {1} \
      CONFIG.PARTIAL_RECONFIG_FLOW_MIG            {false} \
      CONFIG.PING_PONG_PHY                        {1} \
      CONFIG.Phy_Only                             {Complete_Memory_Controller} \
      CONFIG.RECONFIG_XSDB_SAVE_RESTORE           {false} \
      CONFIG.RESET_BOARD_INTERFACE                {Custom} \
      CONFIG.Reference_Clock                      {Differential} \
      CONFIG.SET_DW_TO_40                         {false} \
      CONFIG.System_Clock                         {No_Buffer} \
      CONFIG.TIMING_3DS                           {false} \
      CONFIG.TIMING_OP1                           {false} \
      CONFIG.TIMING_OP2                           {false} \
      ] [get_ips zcu106mig]"""

Any suggestions would be welcome.

Thanks,

Dakota

[Dakota Berbrich]

Just an update to my previous inquiry, I was able to find the sd.c implementation of the ZCU104 from a previous commit. I added this debug information to my ZCU106 implementation, and received the following when attempting to boot Linux, note that following the second LOADING, the code prints a section of the image that is loaded on the PL-Side DDR4 as <Address; Instruction>.

TEST_MEM
Writing 0xde to addr: 0x80000000
Read 0x000000de from addr: 0x80000000
Do not disable OOO Processing

                     INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18

LOADING 0x03200000B PAYLOAD
LOADING  
80bbfb88; 875fe0ef
80bbfb8c; 02000793
80bbfb90; 00047597
80bbfb94; 59c58593
80bbfb98; faa7e2e3
80bbfb9c; 00058597
80bbfba0; b9858593
80bbfba4; 00000513
80bbfba8; 2f4160ef
80bbfbac; e91ff06f
80bbfbb0; 00047517
80bbfbb4; 5b450513
80bbfbb8; d14fe0ef
80bbfbbc; 00050c13
80bbfbc0; 00058a17
80bbfbc4; 3dca0a13
80bbfbc8; 08050263
80bbfbcc; 831fe0ef
80bbfbd0; 000017b7
80bbfbd4; ffe78793
80bbfbd8; 00047597
80bbfbdc; 59c58593
80bbfbe0; f4a7eee3
80bbfbe4; b5843783
80bbfbe8; 00047597
80bbfbec; 5bc58593
80bbfbf0; f40796e3
80bbfbf4; b6842783
80bbfbf8; 04079e63
80bbfbfc; 00000593

BOOT

OpenSBI v0.8
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|

Platform Name       : freechips,rocketchip-unknown
Platform Features   : timer,mfdeleg
Platform HART Count : 1
Boot HART ID        : 0
Boot HART ISA       : rv64imafdcsu
BOOT HART Features  : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base       : 0x80000000
Firmware Size       : 96 KB
Runtime SBI Version : 0.2

MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0    : 0x0000000080000000-0x000000008001ffff (A)

PMP1    : 0x0000000000000000-0x00000001ffffffff (A,R,W,X)

If I compare that to the objdump, I see that the values are the same.

riscv64-unknown-elf-objdump -d br-base-bin-nodisk
80bbfb88: 875fe0ef           jal ra,80bbe3fc <payload_bin+0x9be3fc>
80bbfb8c: 02000793           li a5,32
80bbfb90: 00047597           auipc a1,0x47
80bbfb94: 59c58593           addi a1,a1,1436 # 80c0712c <payload_bin+0xa0712c>
80bbfb98: faa7e2e3           bltu a5,a0,80bbfb3c <payload_bin+0x9bfb3c>
80bbfb9c: 00058597           auipc a1,0x58
80bbfba0: b9858593           addi a1,a1,-1128 # 80c17734 <payload_bin+0xa17734>
80bbfba4: 00000513           li a0,0
80bbfba8: 2f4160ef           jal ra,80bd5e9c <payload_bin+0x9d5e9c>
80bbfbac: e91ff06f           j 80bbfa3c <payload_bin+0x9bfa3c>
80bbfbb0: 00047517           auipc a0,0x47
80bbfbb4: 5b450513           addi a0,a0,1460 # 80c07164 <payload_bin+0xa07164>
80bbfbb8: d14fe0ef           jal ra,80bbe0cc <payload_bin+0x9be0cc>
80bbfbbc: 00050c13           mv s8,a0
80bbfbc0: 00058a17           auipc s4,0x58
80bbfbc4: 3dca0a13           addi s4,s4,988 # 80c17f9c <payload_bin+0xa17f9c>
80bbfbc8: 08050263           beqz a0,80bbfc4c <payload_bin+0x9bfc4c>
80bbfbcc: 831fe0ef           jal ra,80bbe3fc <payload_bin+0x9be3fc>
80bbfbd0: 000017b7           lui a5,0x1
80bbfbd4: ffe78793           addi a5,a5,-2 # ffe <_fw_start-0x7ffff002>
80bbfbd8: 00047597           auipc a1,0x47
80bbfbdc: 59c58593           addi a1,a1,1436 # 80c07174 <payload_bin+0xa07174>
80bbfbe0: f4a7eee3           bltu a5,a0,80bbfb3c <payload_bin+0x9bfb3c>
80bbfbe4: b5843783           ld a5,-1192(s0)
80bbfbe8: 00047597           auipc a1,0x47
80bbfbec: 5bc58593           addi a1,a1,1468 # 80c071a4 <payload_bin+0xa071a4>
80bbfbf0: f40796e3           bnez a5,80bbfb3c <payload_bin+0x9bfb3c>
80bbfbf4: b6842783           lw a5,-1176(s0)
80bbfbf8: 04079e63           bnez a5,80bbfc54 <payload_bin+0x9bfc54>
80bbfbfc: 00000593           li a1,0

With this, I think I can confirm I am copying the data over from the SD card correctly, but I am still having the SmallBoom and Rocket configs stall at the PMP1 stage. Any additional support would be appreciated.

Thanks,

Dakota

[Dakota Berbrich]

Hello,

Still requesting any suggestions on this. I added an ILA to watch the icache to follow the control flow of the bootup sequence. The control flow seems to be transferring from the boot region to text, but then it transfers to a different region. Here are some screenshots from that, note the following as a result of word-addressable memory and the requested instruction addresses can be seen by the bottom signal:

boot  = 0x1_0000       >> 2 = 0x4000

.text = 0x8000_0000    >> 2 = 0x200_0000

???   = 0x74_8000_0000 >> 2 = 0x1F_E000_0000

I can see the core moving from the boot memory region to text:

Text to a different area:


This behavior could be expected, but it seems to get caught in a loop in the next region it accesses. I think I am going to see if I can attempt to run the FireMarshal image in Verilator and look at the same signal to compare.

If anyone has any input, it would be greatly appreciated.

Thanks,

Dakota

[Philipp Schmitz]

Hi Dakota,

what hardware configuration are you using?

Yes you can run the FireMarshal image in Verilator (just not the flattened one) but it will take a long time and produce huge waveform files in case you opt for the debug simulation.

What I did to debug my hardware boot process was to first run a normal simulation and see when and if it triggers any assertion.

Afterwards you can start a debug simulation and start dumping the traces only a few thousand cycles before the assertion to get a managable file size.

Best,

Philipp

[Dakota Berbrich]

Phillip,

I have been moving forward with the RocketChip implementation just because I thought debugging an in-order design would be more straightforward. I also tried reducing the FPGA frequency as you had mentioned previously, but that did not resolve any of my issues. If this isn't what you meant by hardware configuration, let me know and I can clarify further.

Just to get a better understanding of your debug process, you ran a simulation of your ZCU104 implementation in Vivado or through Verilator? I guess I have not seen any assertion issues previously, so I am not sure what to look for. Note that I haven't updated the underlying RocketChip/BOOM implementations--just the FPGA overlays, shells, and such.

Thanks,

Dakota

[Philipp Schmitz]

Hello Dakota,

thank you for clarifying.

The debug process I described is for checking if the emulated hardware works together with your OS image.

I came across some issues with some of my hardware configurations (e.g. BOOM) not working and was not sure if it is an FPGA issue or a hardware issue.

So to seperate the error sources I simulated booting BOOM and it triggered some assertion that is only present in the verilated Hardware (you can't see it on the FPGA).

That is how I found this issue (https://github.com/riscv-boom/riscv-boom/issues/624) in my setup.

However, I don't know if this will help you if you are using an unmodified version of RocketChip.

But if you are able to pass the point your FPGA gets stuck in simulation you rule out the error source of your OS/HW interaction.

Best,

Philipp

[Dakota Berbrich]

Phillip,

I'll try this out, I know that there was a FireMarshal bump in Chipyard's 1.9.0 bump, so maybe some issues leaked in there. Did you have to increase the max-cycle count for your simulations? I am seeing the following when using the RocketConfig:

make[1]: Leaving directory '/home/dakota/chipyard-fpga-development/chipyard/sims/verilator/generated-src/chipyard.TestHarness.RocketConfig/chipyard.TestHarness.RocketConfig'
mkdir -p /home/dakota/chipyard-fpga-development/chipyard/sims/verilator/output/chipyard.TestHarness.RocketConfig
(set -o pipefail &&  /home/dakota/chipyard-fpga-development/chipyard/sims/verilator/simulator-chipyard-RocketConfig +permissive +dramsim +dramsim_ini_dir=/home/dakota/chipyard-fpga-development/chipyard/generators/testchipip/src/main/resources/dramsim2_ini +max-cycles=10000000   +verbose +permissive-off /home/dakota/chipyard-fpga-development/chipyard/software/firemarshal/images/prototype/br-base/br-base-bin-nodisk </dev/null 2> >(spike-dasm > /home/dakota/chipyard-fpga-development/chipyard/sims/verilator/output/chipyard.TestHarness.RocketConfig/br-base-bin-nodisk.out) | tee /home/dakota/chipyard-fpga-development/chipyard/sims/verilator/output/chipyard.TestHarness.RocketConfig/br-base-bin-nodisk.log)
[UART] UART0 is here (stdin/stdout).
make: *** [/home/dakota/chipyard-fpga-development/chipyard/common.mk:308: run-binary] Error 2

The out log gives this, I see a WFI, but I am not convinced that is what you were seeing since it is so early in execution:

  1 using random seed 1681925717
  2 This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
  3 Listening on port 35893
  4 == Loading device model file '/home/dakota/chipyard-fpga-development/chipyard/generators/testchipip/src/main/resources/dramsim2_ini/DDR3_micron_64M_8B_x4_sg15.ini' ==
  5 == Loading system model file '/home/dakota/chipyard-fpga-development/chipyard/generators/testchipip/src/main/resources/dramsim2_ini/system.ini' ==
  6 ===== MemorySystem 0 =====
  7 CH. 0 TOTAL_STORAGE : 4096MB | 1 Ranks | 16 Devices per rank
  8 DRAMSim2 Clock Frequency =666666666Hz, CPU Clock Frequency=100000000Hz
  9 C0:         19 [1] pc=[0000000000010040] W[r10=0000000000010040][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000517] auipc   a0, 0x0
 10 C0:         20 [1] pc=[0000000000010044] W[r10=0000000000010000][1] R[r10=0000000000010040] R[r 0=0000000000000000] inst=[fc050513] addi    a0, a0, -64
 11 C0:         21 [1] pc=[0000000000010048] W[r 0=0000000000000000][1] R[r10=0000000000010000] R[r 0=0000000000000000] inst=[30551073] csrw    mtvec, a0
 12 C0:         26 [1] pc=[000000000001004c] W[r 5=800000000094112d][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[301022f3] csrr    t0, misa
 13 C0:         29 [1] pc=[0000000000010050] W[r 5=ffffe00000000025][1] R[r 5=800000000094112d] R[r 0=0000000000000000] inst=[4122d293] srai    t0, t0, 18
 14 C0:         30 [1] pc=[0000000000010054] W[r 5=0000000000000001][1] R[r 5=ffffe00000000025] R[r 0=0000000000000000] inst=[0012f293] andi    t0, t0, 1
 15 C0:         31 [1] pc=[0000000000010058] W[r 0=0000000000000000][0] R[r 5=0000000000000001] R[r 0=0000000000000000] inst=[00028463] beqz    t0, pc + 8
 16 C0:         32 [1] pc=[000000000001005c] W[r 0=0000000000000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30301073] csrw    mideleg, zero
 17 C0:         37 [1] pc=[0000000000010060] W[r10=0000000000000008][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00800513] li      a0, 8
 18 C0:         38 [1] pc=[0000000000010064] W[r 0=0000000000000000][1] R[r10=0000000000000008] R[r 0=0000000000000000] inst=[30451073] csrw    mie, a0
 19 C0:         43 [1] pc=[0000000000010068] W[r 0=0000000a00001800][1] R[r10=0000000000000008] R[r 0=0000000000000000] inst=[30052073] csrs    mstatus, a0
 20 C0:         48 [1] pc=[000000000001006c] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[10500073] wfi
 21 *** FAILED *** via trace_count (timeout, seed 1681925717) after 10000000 cycles
                                                                                         
Let me know what you think. I think I will try to revert to the commit in FireMarshal that your issue pointed to and try running that binary.

Thanks,

Dakota

[Dakota Berbrich]

Philip,

Thanks for your help, I was able to take the following steps and get the implementation booting.

1. Cloned Chipyard
2. Checked out Chipyard's 9443466 commit
3. Did the setup according to the 1.6.1 documentation
4. Went into the software/firemarshal/ directory and checked out the 5e5fc2e commit.
5. Built the flattened image and moved it to the SD card following the documentation
6. Successfully deployed the build on the ZCU106

I am hoping you can help me with one additional issue as well, I looked at your previous post regarding the second partition of the SD card, and I even looked at the post you mentioned there, but I am still finding it difficult to mount the partition.

If you have any ideas let me know.

Thanks again for your help figuring out the boot issues,

Dakota

[Philipp Schmitz]

Hey,

I'm glad to hear that you are making progress.

Yes, I forgot to mention that the max_cycles need to be adapted...

Regarding the SDCard:

for me it works ...

Can you run # "ls /dev/mmcblk*"?

It should list /dev/mmcblk0    /dev/mmcblk0p1  /dev/mmcblk0p2 but it seems like the system detects your partitions.

Did you run "sudo mkfs.hfs -v "PrototypeData" /dev/sdc2" while setting up the SDCard?

Philipp

[Dakota Berbrich]

Philipp,

Yes, when following the flow here, I did make sure to make the file system on the second partition.

Maybe I am copying files to it incorrectly and that is causing issues? To do that, I mount the second partition onto my desktop and copy things that way--should I be using 'dd' as I did when setting up the first partition? Or is it possible that the size of the SD card is causing issues?

Thanks,

Dakota

[Philipp Schmitz]

Hey,

I also put the files on my SDCard by mounting it (sudo mount -t hfsplus -o force,rw /dev/sdc2 /media/SDCard/) and then copying the files onto it. I don't have a 64GB Card at hand so I can not try. Do you have a smaller one?

Philipp

[Dakota Berbrich]

Philipp,

I found a 32GB card and quickly did a setup on it, but I am still seeing the same issues, unfortunately.

The linux build doesn't have a compiler for RISC-V does it? I mainly want to try and run a section of code I have and time it on the FPGA.

Thanks,

Dakota

[Philipp Schmitz]

Dakota,

this one does not have the second partition.

No, you need to cross compile your software for RISCV on your host system and bring it onto the system via SDCard.

Philipp

[Dakota Berbrich]

Philipp,

Right, sorry, I should have explained what I did in more detail. I just did one partition on this SD card for the files I want to access on the FPGA. So, in this case, the entire partition is HFS/HFS+. I do not think I should need the first partition if I already have Linux booted, but I will try to format this card in the same way as the previous one.

Thanks,

Dakota

[Dakota Berbrich]

Philipp,

I was able to get it working. Not sure if this is per Linux distro kind of detail, but I just needed to change this:

sudo mkfs.hfs -v "PrototypeData" /dev/sdc2

To this:

sudo mkfs.hfsplus -v "PrototypeData" /dev/sdc2

With that in place, I could use your exact mount command from above to copy data to the partition from my host computer. Now everything seems to be booting correctly on the FPGA, and I am able to mount the second partition and run binaries off of it.

Thanks so much for all of your help,

Dakota

[George Anagnostopoulos]

Hello!

I am trying to run linux on a using a rocket core but I either get stuck on the PMP1 stage on boot.

I then created the ZCU106Shell.scala file (like VCU118 one) because I missed it the first time and  now I get jibberish on the screen command.

If possible could you specify what files you modified for the design to run on ZCU106?

Sorry for the inconvenience,

Thank you in advance!

[Dakota Berbrich]

George,

In order to support the ZCU106 I updated/created the following files in the fpga directory:

• fpga-shells/
• src/main/scala/
• devices/xilinx/xilinxzcu106mig/
• XilinxZCU106MIG.scala
• XilinxZCU106MIGPeriphery.scala
• ip/xilinx/scala/zcu106mig.scala
• shell/xilinx/ZCU106NewShell.scala
• xilinx/zcu106/
• constraints/zcu106-master.xdc
• tcl/board.tcl
• vsrc/
• sdio.v
• zcu106reset.v
• src/main/
• resources/zcu106/sdboot/
• include/
• devices/
• clint.h
• gpio.h
• plic.h
• spi.h
• uart.h
  
• bits.h
• const.h
• platform.h
• sections.h
• smp.h
  
• linker/
• memory.lds
• sdboot.elf.lds
  
• Makefile
• common.h
• head.S
• kprintf.c
• kprintf.h
• sd.c
  
• scala/zcu106/
• Configs.scala
• CustomOverlays.scala
• FMCUtil.scala
• HarnessBinders.scala
• IOBinders.scala
• TestHarness.scala
• Makefile

It's definitely a lot of stuff to comb through, but I would start by copying over anything you do not have from the VCU118 implementation. Not every file will need to be updated, so I would reference to earlier in this thread where I linked to other posts that include Philip's ZCU104 implementation. Note also that above we discussed issues with FireMarshal, that was what ultimately pushed me over the barrier of getting things to boot (I did have all of the files above at that point though).

Best of luck,

Dakota

--
You received this message because you are subscribed to a topic in the Google Groups "Chipyard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chipyard/islBKMgalRQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/18a9b05e-b6be-4b24-bd6a-fab48b40f5d5n%40googlegroups.com.

--

Dakota Berbrich

dakota....@gmail.com

[George Anagnostopoulos]

Hello! 

Thank you very much for your reply I could crosscheck that I had all the files. 

But again no luck in running it. 

Did you build the bitstream in the 1.9.0 version or the version 1.6.1 checked out at 9443466?

Also somewhere in the thread you talked about clocking and I was wondering if it is not running because I use 300MHz System Clock and 125MHz Reference Clock.

I am using your configuration for the zcu106mig.scala as seen in the discussion above.

Thank you again!

George

[George Anagnostopoulos]

Hello again,

I made some modifications to my code and now I can consistently reach the PMP1 stage.

I still cannot get past this stage even with the previous version of FireMarshal that you are referencing to.

Maybe it is something else or the ./init-submodules part is updating FireMarshal to the latest edition. 

If you can provide the flattened image that you have created so I can test if there is a problem with firemarshal or my design I would greatly appreciate it! 

Thank you for your time, 

George

[Dakota Berbrich]

George,

Looks like the binary is too large to send, just try out my instructions to see if you can get it to work. Here is the finalized MIG I used,

Thanks,

Dakota

On Thu, Jul 13, 2023 at 7:32 PM Dakota Berbrich <dakota....@gmail.com> wrote:

George,

Yes, I used the old version following the steps I detailed above, here they are again.

1. Cloned Chipyard
2. Checked out Chipyard's 9443466 commit
3. Did the setup according to the 1.6.1 documentation
4. Went into the software/firemarshal/ directory and checked out the 5e5fc2e commit.
5. Built the flattened image and moved it to the SD card following the documentation
6. Successfully deployed the build on the ZCU106

Just to confirm, you are using a PMOD SD card adapter, right?

Here is the image and finalized MIG (from fpga/fpga-shells/src/main/scala/ip/xilinx/zcu106mig/) I got working.

Hopefully, that works for you.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/9a4f2d6d-c680-4ad4-9bc1-c43da43cf90an%40googlegroups.com.

--

Dakota Berbrich

--

Dakota Berbrich

[George Anagnostopoulos]

Hello!

I redid the entire process and added your mig file and it works like a charm!

Thank you so much for your time and help!

Sincerely,

George

[Shahar Berger]

Hi everyone,

I hope you are doing well.

We saw this discussion regarding BOOM on Zynq FPGA boards, especially the part where Rocket worked correctly, Small BOOM also worked, and the medium BOOM configuration caused boot or stability issues.

We are working on a similar bring-up flow, but on a different Zynq UltraScale+ MPSoC board. In our case, we successfully integrated a Rocket core into our Zynq FPGA design using a TinyRocket configuration. The Rocket core works correctly: we load code into DDR from the PS side, release reset, and the core fetches and executes as expected.

We are now trying to replace Rocket with BOOM. We generated BOOM from Chipyard, packaged it as a Vivado IP, and connected it in a very similar Vivado block design. We also use an AXI address remap block in Vivado, so that when the core fetches from its expected boot address, the transaction is redirected to the correct physical DDR address. This same address-remapping approach works for Rocket.

However, with BOOM, after releasing reset, we do not see the expected behavior. It seems that BOOM does not properly start fetching/executing from the expected boot address, even though the external Vivado flow is almost identical to the Rocket design.

We would appreciate any advice regarding the following:

1. Did anyone encounter differences between Rocket and Small BOOM during FPGA bring-up, even when using a very similar Vivado block design?

2. Are there any BOOM-specific changes required in the Chipyard Scala configuration, harness, binders, memory map, or boot flow?

3. Did Small BOOM fetch from the same boot address as Rocket in your working setup?

4. What is the recommended way to debug the first fetch after reset? For example, should we focus on ILA probes on the AXI bus, instruction cache signals, or simulation traces?

5. Can BOOM pass synthesis/implementation but still fail at runtime due to timing, utilization, CDC, or AXI behavior, even if Rocket works on the same setup?

Any details about a working Small BOOM flow on a Zynq FPGA board would be extremely helpful.

Thank you very much for your time and help.

Best regards,
Shahar