search

litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
553 stars 174 forks source link

about bootup display problem #228

Closed SanadaShinken closed 2 years ago

SanadaShinken commented 3 years ago

Dear Sir:

the photo is taken by using the latest litex code. and the output order seems differ to normal order. it is a little funny. where do I have to check?

BR, Sanada

13963735789861

geertu commented 3 years ago

Looks like the console driver use the wrong endianness, thus reverting the order of each block of 4 pixels. Which platform is this? Is it big or little endian?

  1. drivers/video/fbdev/simplefb.c has to set fb_info.flags |= FBINFO_FOREIGN_ENDIAN, cfr. how it is handled in drivers/video/fbdev/offb.c,
  2. litex/tools/litex_json2dts.py has to set "little-endian" or "big-endian",
  3. Enable the right FB_*_ENDIAN options from drivers/video/fbdev/Kconfig.
SanadaShinken commented 3 years ago

Dear Geertu :

Thank you very much. I'll check the kernel option. the test platform is our own FPGA board, based on XC7A100T / XC7A200T.

If I test the configuration in litex-boards, the terminal output is very well. If using linux-on-litex-vexriscv, the display is shown as the photo.

The boot up linux image which I used is found in the following issue. https://github.com/litex-hub/linux-on-litex-vexriscv/issues/164, which is the prebuild images.

BR, Sanada

kazkojima commented 3 years ago

Hi,

The symptom looks very similar to what is happening with the video frame buffer for colorlight_i5 target, though the cause may be different. For litex-boards/litex_boards/targets/colorlight_i5.py, I've found that changing l2_cache_reverse, which is an argument of addsdram() call in __init_\ of BaseSoc, from True to False is a workaround.

Regards, kaz badbad

SanadaShinken commented 3 years ago

Hi @kazkojima :

Wow oh! this may be the key. I'll try it to check the display is right or not.

Thank You very much!!

BR, Sanada

enjoy-digital commented 3 years ago

@SanadaShinken: This is probably indeed related to the l2_cache reverse parameter as pointed by @kazkojima, I also had to do this change on a hardware I was testing recently: https://github.com/litex-hub/litex-boards/commit/f7ee3fa4543db681f87e9afab8da8a81e07f1f82#diff-f92168101f80ffd8f588e3e8baad110cc75cae6138c5bedbf61811ba2572a1ceR94. We could try to simplify this in the future.

SanadaShinken commented 3 years ago

Hi @kazkojima , @enjoy-digital :

Many Thanks. change L2 size to zero or add l2_cache reverse as "Fasle" all make the output correct.

BR, Sanada

enjoy-digital commented 2 years ago

By default,l2_cache reverse is now set to False, so the issue will no longer be present.