litex_video for litex_linux_vexriscv.repl #67
Comments
|
Contents of: |
|
@mateusz-holenko I thought this issue might better than the email thread I started about it. Thanks! |
|
@pdp7: You should get an error when running I'm getting one on the current master: I'll verify it on the Debian package you use. |
|
Thanks for the suggestion. I changed pdp7@x1:~/dev/renode$ git diff
diff --git a/lib/termsharp b/lib/termsharp
--- a/lib/termsharp
+++ b/lib/termsharp
@@ -1 +1 @@
-Subproject commit 948fb9ad98bc33535659c027dd5264b68b42bc58
+Subproject commit 948fb9ad98bc33535659c027dd5264b68b42bc58-dirty
diff --git a/tests/platforms/LiteX/litex_linux_vexriscv.repl b/tests/platforms/LiteX/litex_linux_vexriscv.repl
index 123554b..4827496 100644
--- a/tests/platforms/LiteX/litex_linux_vexriscv.repl
+++ b/tests/platforms/LiteX/litex_linux_vexriscv.repl
@@ -62,3 +62,7 @@ led : Miscellaneous.LED @ gpio_out 0
button: Miscellaneous.Button @ gpio_in 0
-> gpio_in@0
+
+litex_video: Video.LiteX_Framebuffer @ sysbus 0xf0006800
+ format: PixelFormat.XBGR8888
+ memory: ddrHowever, I still get the same error: |
|
Try using absolute path to |
|
Thanks. I am using absolute path and it is different now: It appears this is the issue: It seems the problem is caused by: already using that address. Any suggestions? |
|
@mateusz-holenko Is there a way to view the LiteX configuration files that built the binaries like: I'd like to figure out what the correct address is for: |
|
@pdp7: TBH I'm not even sure if this binary supports frame buffer at all. We currently does not have an easy way to trace back the LiteX configuration from the binary. It was definiately built from https://github.com/litex-hub/linux-on-litex-vexriscv, but don't know the exact commit. You can always use the binary from https://github.com/renode/renode/blob/master/tests/platforms/LiteX/Netv_LiteX_VexRiscv.robot#L14 or build your own |
|
@mateusz-holenko thanks, without rebuilding is there a way for me to determine the address I should put in: as the one from the NeTV example conflicts with |
|
@pdp7: The linux kernel is not a problem (as long as it has the litevideo driver compiled-in) as it does not have any addresses hardcoded inside - all the information is dynamically read from the DTB file. You can just decompile it back to string, modify the framebuffer address to match the one in The biggest problem is the VexRiscv That's why I strongly suggest to (a) either use a consistent set of binaries, DTB & platform definition taken from a single demo or (b) rebuilt everything from scratch. |
|
BTW, LiteX BIOS also comes with a hardcoded set of peripheral addresses, so it must match the LiteX configuration. I didn't mention it since we don't use it in the demo (we skip the bootloader and just put binaries directly to the memory from Renode script). |
|
I have built the binaries from source for the ECP5 on the Hackaday badge: I didn't occur to me that I could use those with renode. |
|
Thanks! I can boot renode with those binaries that I built. I'll take a look at how I can add the framebuffer. |
|
@pdp7: How things are going? Were you able to add the framebuffer? |
|
@mateusz-holenko thanks for following up. I'm at Embedded World (great Antmicro booth!) but I will get back to trying to solution once I get back home. |
Would it be possible for me to add litex_video to the litex_linux_vexriscv.repl?
I want to simulate using the LCD on Hackaday badge. It is using litex-on-linux-vexriscv, so I thought this would be a good way to test.
I'm running
Renode version 1.8.2.22285 (dc338ac5-201911131222)whichI installed using the Debian package from the GitHub releases page.
I also cloned the repo and am using the files from there:
/home/pdp7/dev/renode/tests/platforms/LiteX/litex_linux_vexriscv.replHere is the state of the repo:
Here are the commands I run:
I get an error when trying to use the litex_video analyzer:
However, tests/platforms/LiteX/litex_netv2_vexriscv_linux.repl works fine and I get the framebuffer and serial windows as expected.
The text was updated successfully, but these errors were encountered: