Framebuffer stop booting process

Chgavilana commented 3 years ago

Hi:

I try to boot linux vexriscv system with hdmi output (just one HDMI port over board QMTECH Wukong board), however, when it's go to simple framebuffer line, boot process stop and can get working with HDMI port.

Some idea about what could be the problem?. Following nexys_video and netv2 configuration I cant see some additional configuration. Output of boot process is show below.

       __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Dec 17 2020 21:43:45
 BIOS CRC passed (786693cd)

 Migen git sha1: 9a37a58
 LiteX git sha1: 40921806

--=============== SoC ==================--
CPU:        VexRiscv SMP-LINUX @ 100MHz
BUS:        WISHBONE 32-bit @ 4GiB
CSR:        8-bit data
ROM:        64KiB
SRAM:       8KiB
SDRAM:      262144KiB 16-bit @ 800MT/s (CL-6 CWL-5)

--========== Initialization ============--
Ethernet init...
Initializing SDRAM @0x40000000...
Switching SDRAM to software control.
Write latency calibration:
m0:0 m1:0 
Read leveling:
  m0, b0: |00000000000000000000000000000000| delays: -
  m0, b1: |00000000000000011111111111111100| delays: 23+-07
  m0, b2: |00000000000000000000000000000000| delays: -
  m0, b3: |00000000000000000000000000000000| delays: -
  m0, b4: |00000000000000000000000000000000| delays: -
  m0, b5: |00000000000000000000000000000000| delays: -
  m0, b6: |00000000000000000000000000000000| delays: -
  m0, b7: |00000000000000000000000000000000| delays: -
  best: m0, b01 delays: 22+-07
  m1, b0: |00000000000000000000000000000000| delays: -
  m1, b1: |00000000000000001111111111111110| delays: 23+-07
  m1, b2: |00000000000000000000000000000000| delays: -
  m1, b3: |00000000000000000000000000000000| delays: -
  m1, b4: |00000000000000000000000000000000| delays: -
  m1, b5: |00000000000000000000000000000000| delays: -
  m1, b6: |00000000000000000000000000000000| delays: -
  m1, b7: |00000000000000000000000000000000| delays: -
  best: m1, b01 delays: 23+-07
Switching SDRAM to hardware control.
Memtest at 0x40000000 (2MiB)...
  Write: 0x40000000-0x40200000 2MiB     
   Read: 0x40000000-0x40200000 2MiB     
Memtest OK
Memspeed at 0x40000000 (2MiB)...
  Write speed: 31MiB/s
   Read speed: 27MiB/s

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Booting from SDCard in SPI-Mode...
Booting from boot.json...
Copying Image to 0x40000000 (7287696 bytes)...
[########################################]
Copying rv32.dtb to 0x40ef0000 (3889 bytes)...
[########################################]
Copying rootfs.cpio to 0x41000000 (5639680 bytes)...
[########################################]
Copying opensbi.bin to 0x40f00000 (53640 bytes)...
[########################################]
Executing booted program at 0x40f00000

--============= Liftoff! ===============--

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

Platform Name       : LiteX / VexRiscv-SMP
Platform Features   : timer,mfdeleg
Platform HART Count : 8
Boot HART ID        : 0
Boot HART ISA       : rv32imas
BOOT HART Features  : time
BOOT HART PMP Count : 0
Firmware Base       : 0x40f00000
Firmware Size       : 124 KB
Runtime SBI Version : 0.2

MIDELEG : 0x00000222
MEDELEG : 0x0000b101
[    0.000000] Linux version 5.10.0-rc6 (florent@panda) (riscv32-buildroot-linux-gnu-gcc.br_real (Buildroot 2020.11-281-g69e5046e7b) 10.2.0, GNU ld (GNU Binutils) 2.33.1) #32 SMP Tue Dec 15 10:55:28 CET 2020
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[    0.000000] printk: bootconsole [sbi0] enabled
[    0.000000] Initial ramdisk at: 0x(ptrval) (8388608 bytes)
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000040000000-0x000000004fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000004fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000004fffffff]
[    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] riscv: ISA extensions aim
[    0.000000] riscv: ELF capabilities aim
[    0.000000] percpu: Embedded 10 pages/cpu s18892 r0 d22068 u40960
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mem=256M@0x40000000 rootwait console=liteuart earlycon=sbi root=/dev/ram0 init=/sbin/init swiotlb=32
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 243760K/262144K available (5494K kernel code, 573K rwdata, 829K rodata, 178K init, 221K bss, 18384K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[    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=2
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] riscv-intc: 32 local interrupts mapped
[    0.000000] plic: interrupt-controller@f0c00000: mapped 32 interrupts with 2 handlers for 4 contexts.
[    0.000000] random: get_random_bytes called from start_kernel+0x35c/0x4dc with crng_init=0
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000105] sched_clock: 64 bits at 100MHz, resolution 10ns, wraps every 4398046511100ns
[    0.002550] Console: colour dummy device 80x25
[    0.003453] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.004891] pid_max: default: 32768 minimum: 301
[    0.008068] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.009127] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.027867] rcu: Hierarchical SRCU implementation.
[    0.032990] smp: Bringing up secondary CPUs ...
[    0.042150] smp: Brought up 1 node, 2 CPUs
[    0.047425] devtmpfs: initialized
[    0.071331] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.072677] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[    0.076780] NET: Registered protocol family 16
[    0.193454] FPGA manager framework
[    0.202709] clocksource: Switched to clocksource riscv_clocksource
[    0.206942] simple-framebuffer c8000000.framebuffer: framebuffer at 0xc8000000, 0x12c000 bytes, mapped to 0x(ptrval)
[    0.208354] simple-framebuffer c8000000.framebuffer: format=a8b8g8r8, mode=640x480x32, linelength=2560

I found a critical warning during vivado syntesis, but I'm not sure about if i can down this frequency and not affect timing of some signals. Warning is true for xc7a100T arty FPGA speedgrade -2 according with datasheet and output is showed below. I tried down frequency and have the same output during boot process, also changing video resolution.

# place_design -directive default
Command: place_design -directive default
Attempting to get a license for feature 'Implementation' and/or device 'xc7a100t'
INFO: [Common 17-349] Got license for feature 'Implementation' and/or device 'xc7a100t'
INFO: [DRC 23-27] Running DRC with 8 threads
INFO: [Vivado_Tcl 4-198] DRC finished with 0 Errors
INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information.
Running DRC as a precondition to command place_design
INFO: [DRC 23-27] Running DRC with 8 threads
CRITICAL WARNING: [DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell MMCME2_ADV. The computed FVCO is 1500.000 MHz. The valid FVCO range for speed grade -2 is 600MHz to 1440MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 30.000, CLKIN1_PERIOD = 10.00000, and DIVCLK_DIVIDE = 2 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).
This violation may be corrected by:
  1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run.  Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range.
  2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range.
  3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range.
  4. The MMCM configuration may be dynamically modified by use of DRP which is recognized by an ACTIVE signal on DCLK pin.
INFO: [Vivado_Tcl 4-198] DRC finished with 0 Errors, 1 Critical Warnings
INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information.

Chgavilana commented 3 years ago

HI: Testing I checked that boot process continue, but It spend more of 2 hours to continue (with 640x480_75Hz, more resolution take more of 12 hours). At the end, I got login prompt but system is very slow, console work fine but slow, but HDMI out nothing. if I remove framebuffer option when I build system, all work fine. I checked #42 recommendation, and find that VCO program inside MMCME2_ADV is 1500 and FPGA arty 100 speedgrade -2 support 1440 max (Vivado show this as CRITICAL WARNING). I don't know if someone who have any board running HDMI out framebuffer have the same problem or some recommendation to check why this happens.

I will continue to check mmcm parameters and driver to understand more about this section of code.

LinuxFramebuffer22122020.txt LinuxFramebuffer22122020detailed.txt

Update: litevideo load fine. problem is with simple-framebuffer or something else when create /dev/fb0 (see LinuxFramebuffer22122020detailed.txt)

Chgavilana commented 3 years ago

HI: continue with debugging, I need a second opinion about two parts of code. Checking over json2dts.py: 1) When define framebuffer, they use framebuffer_base = 0xc8000000. I change to 0x4F000000 (aprox end of main ram (0x40000000-frambuffer_size)). With this change, system boot fine and quickly without error, but I can't show nothing over hdmi (monitor is black all time and it doesn't change if a write a random value over framebuffer or monitor doesn't detect input origin). Why default value is 0xc8000000 if it is out of main ram? 2) About litevideo0: gpu@{litevideo_base:x}, litevideo_dma-offset is defined as framebuffer_base - d["memories"]["main_ram"]["base"]. if use framebuffer_base = 0xc8000000, is it a possible wrong value? 3) this is maybe a bug, but framebuffer and soc_controller use same direction f0000000.framebuffer0` is defined with this value by default and a warning message is showed at the end when I generate all.

I feel close to make it work, but my monitor start to show problems, so I prefer to check all signal first. BR. Carlos.

SanadaShinken commented 3 years ago

HI: continue with debugging, I need a second opinion about two parts of code. Checking over json2dts.py:

1. When define framebuffer, they use `framebuffer_base   = 0xc8000000`. I change to 0x4F000000 (aprox end of main ram (0x40000000-frambuffer_size)). With this change, system boot fine and quickly without error, but I can't show nothing over hdmi (monitor is black all time and it doesn't change if a write a random value over framebuffer or monitor doesn't detect input origin). Why default value is 0xc8000000 if it is out of main ram?

2. About `litevideo0:` gpu@{litevideo_base:x}`, litevideo_dma-offset is defined as framebuffer_base - d["memories"]["main_ram"]["base"]. if use framebuffer_base   = 0xc8000000, is it a possible wrong value?

3. this is maybe a bug, but framebuffer and soc_controller use same direction f0000000. `framebuffer0` is defined with this value by default and a warning message is showed at the end when I generate all.

I feel close to make it work, but my monitor start to show problems, so I prefer to check all signal first. BR. Carlos.

Hi Carlos:

for #1, I also found the setting what you modified is right. In my case using 0x4f8000000 as framebuffer base address, and the boot process will show some kernel panic message. after change framebuffer base address to 0x4f000000, the boot process completes, and shows simple_framebuffer is registered. there is a fb device node at /dev/fb0.

for #2 , I also think this may be case by case setting, due to different ddr memory size.

for #3, I'm not very sure this. but this setting should differ to soc_controller base address.

the following is what I want to discuss.

from make.py which come from linux-on-litex-vexriscv, I found there two board, NeTV2 and NexysVideo. in litex-boards/targets, the clock is not the same. for netv2, the clock is S7PLL based, and for nexysvideo, the clock is S7MMCM based. for fixed hdmi video output resolution, is the S7PLL not OK, and must switch to S7MMCM ?
for hdmi video output, such like scl, sda, hpd, cec is needed or could be ignore or should be configured?
for video path, i found there is some patch code in https://github.com/daveshah1/linux-on-litex-vexriscv/commit/7a4ccd70de92aa004b27ad714114cb8b89928612. for framebuffer setting, the related code is in soc_linux.py. the framebuffer related code also include hdmi port initialization or not?

BR, Sanada

Chgavilana commented 3 years ago

Hi: Still it not working, but I will continue this problem over issue #181. A quickly summary, litevideo need some updates and I found that: 1) framebuffer_base = 0xc8000000 is defined over main ram, and this address is when main ram memory was declared over 0xC0000000 but It was moved to 0x40000000 (https://github.com/litex-hub/linux-on-litex-vexriscv/commit/66ced884caac0fccaef75eb91e5e69394d0634dd) 2) According with previous point, litevideo_dma-offset it's correct. 3) framebuffer and soc_controller use same direction f0000000, need some future fix.

When Change framebuffer_base over ram memory, system boot fine without problems.

BR. Carlos.

litex-hub / linux-on-litex-vexriscv

Framebuffer stop booting process #168