Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get familiar with the tools #5

Open
rw1nkler opened this issue Mar 27, 2020 · 16 comments
Open

Get familiar with the tools #5

rw1nkler opened this issue Mar 27, 2020 · 16 comments

Comments

@rw1nkler
Copy link
Contributor

I have added links to useful resources to the project Wiki. Please, have a look at this.

@MatPasGit
Copy link

MatPasGit commented May 4, 2020

I can't add permamently add vivado to system path on debian (i updated ~/.bashrc and system path on root, but it stays only in one session on terminal).So i can't run vivado properly.
When i try to communicate with board via UART using picocom, board doesn't send any response.
What i could have done wrong?

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 5, 2020

  1. The changes in .bashrc are not automatically sourced to other, already opened terminals.
    You have to use, this in other bash instances:
source ~/.bashrc

Or you can relogin and open new bash sessions.

  1. Please provide me any information that will allow me to reproduce your design and software.
    At least content of:
<litex_build_dir>/software/
<zephyr_app_build_dir>

@MatPasGit
Copy link

MatPasGit commented May 5, 2020

@rw1nkler

  1. i solved this issue, i wrote simple bash script to add to path every time i run vivado.
    That's probably debian issue because when i try add to path and override .bashrc file with source it doesn't save in every case including zephyr.
  2. My board is booting now, i used picocom and shell replied. but when i tried to build arty.py i got the same issue as @tobiaszpuslecki had.

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 5, 2020

I don't think this is a Debian issue. I'm almost sure that your problem can be resolved. Please, link to similar issues. Otherwise, I have to check all the tickets in the repository.

And as I said, How can I help you if you don't attach any files or steps to reproduce your problem?

@MatPasGit
Copy link

the issues i'tm talking about is here
#8 (comment)

I've done everything that was written in documentation right here:
https://github.com/antmicro-labs/video-processing/wiki/LiteX---Zephyr-tutorial
of course i can post you what zephyr build app dir contains
obraz

i tried to add to path lots of files it didn't worked for every of them even though i i was reloading .basrc file every time. maybe i'm doing something wrong but for now i don't know what. I will try to solve this.

There is no file we've created we are still fighting issues with dev tools we can't properly run.
we would be really glad to start coding and finish this project, but issues we got are overwhelming.
We got out boards booted.
we got connection to the shell
We got zephyr and vivado installed including riscv toolchain
When we try to compile basic bitstream we got issue that i linked on the beginnig of comment.

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 6, 2020

@MatPasGit When somebody asks you for contents of a directory for debugging, almost always he wants to see the contents of the files. In this situation, you should upload the files somewhere and publish the link to them.

I've already answered in the #8

@MatPasGit
Copy link

MatPasGit commented May 6, 2020

Thank you for your answer.
Now arty.py compiles properly.

That's zephyr app i tried to implement :
https://drive.google.com/open?id=1Mp7F7mykfFX1j-__-hL9gq1d0jm6MZg_
nothing more happens when i try to build this app than this:
image

Sorry for misunderstanding

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 6, 2020

You have to change addresses in the device tree:
https://github.com/zephyrproject-rtos/zephyr/blob/master/dts/riscv/riscv32-litex-vexriscv.dtsi

Correct addresses can be found in:

<litex_build_dir>/software/include/generated/csr.h

You need to change the following peripherals:

  • timer0
  • uart0

then you can adjust other addresses if you want. We will provide you with more info in the next meeting.

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 6, 2020

Example of change:

		uart0: serial@e0001800 {
			compatible = "litex,uart0";
			interrupt-parent = <&intc0>;
			interrupts = <2 10>;
			reg = <0xe0001800 0x18>;
			reg-names = "control";
			label = "uart0";
			status = "disabled";
		};

From csr.h you will obtain:

/* uart */
#define CSR_UART_BASE 0x82001800L
#define CSR_UART_RXTX_ADDR 0x82001800L
#define CSR_UART_RXTX_SIZE 1
static inline uint8_t uart_rxtx_read(void) {
	return csr_read_simple(0x82001800L);
}
static inline void uart_rxtx_write(uint8_t v) {
	csr_write_simple(v, 0x82001800L);
}
#define CSR_UART_TXFULL_ADDR 0x82001804L
#define CSR_UART_TXFULL_SIZE 1
static inline uint8_t uart_txfull_read(void) {
	return csr_read_simple(0x82001804L);
}
#define CSR_UART_RXEMPTY_ADDR 0x82001808L
#define CSR_UART_RXEMPTY_SIZE 1
static inline uint8_t uart_rxempty_read(void) {
	return csr_read_simple(0x82001808L);
}
#define CSR_UART_EV_STATUS_ADDR 0x8200180cL
#define CSR_UART_EV_STATUS_SIZE 1
static inline uint8_t uart_ev_status_read(void) {
	return csr_read_simple(0x8200180cL);
}
static inline void uart_ev_status_write(uint8_t v) {
	csr_write_simple(v, 0x8200180cL);
}
#define CSR_UART_EV_PENDING_ADDR 0x82001810L
#define CSR_UART_EV_PENDING_SIZE 1
static inline uint8_t uart_ev_pending_read(void) {
	return csr_read_simple(0x82001810L);
}
static inline void uart_ev_pending_write(uint8_t v) {
	csr_write_simple(v, 0x82001810L);
}
#define CSR_UART_EV_ENABLE_ADDR 0x82001814L
#define CSR_UART_EV_ENABLE_SIZE 1
static inline uint8_t uart_ev_enable_read(void) {
	return csr_read_simple(0x82001814L);
}
static inline void uart_ev_enable_write(uint8_t v) {
	csr_write_simple(v, 0x82001814L);
}

You are interested in base addresses. After the change the device tree should be like this:

		uart0: serial@82001800 {
			compatible = "litex,uart0";
			interrupt-parent = <&intc0>;
			interrupts = <2 10>;
			reg = <0x82001800 0x18>;
			reg-names = "control";
			label = "uart0";
			status = "disabled";
		};

As you can see this peripheral has been moved from 0xe0001800 to 0x82001800

@rw1nkler
Copy link
Contributor Author

Have you changed the device tree? Does it work for you?

@MatPasGit
Copy link

MatPasGit commented May 25, 2020

@rw1nkler i changed uart section in csr.h as you posted above, but effect of flterm..... command is still the same.
I could'n find sections like this:
uart0: serial@82001800 { compatible = "litex,uart0"; interrupt-parent = <&intc0>; interrupts = <2 10>; reg = <0x82001800 0x18>; reg-names = "control"; label = "uart0"; status= "disabled"; };
i attach file in .txt to ensure if i pasted it in the proper way.
csr.txt

@MatPasGit
Copy link

MatPasGit commented May 27, 2020

@kgugala @rw1nkler
Additionaly we got problem with connection with the board.
(I got top.bit file)
obraz

@pgielda
Copy link

pgielda commented May 27, 2020

Is your linux running natively or in a vm?

If native try "sudo xc3sprog -c nexys4 top.bit"

@pgielda
Copy link

pgielda commented May 27, 2020

The sections you're mentioning are in a device tree (aka dts files) not in a header file. @rw1nkler means that you have to match your uart address (that you can find in the header file) inside the devicetree (that are used by Linux).

All this is in no way specific to LiteX its just common knowledge about Linux. Please do "google" a little bit on device trees if you're not familiar with the concept.

@MatPasGit
Copy link

MatPasGit commented May 27, 2020

The sections you're mentioning are in a device tree (aka dts files) not in a header file. @rw1nkler means that you have to match your uart address (that you can find in the header file) inside the devicetree (that are used by Linux).

All this is in no way specific to LiteX its just common knowledge about Linux. Please do "google" a little bit on device trees if you're not familiar with the concept.

@pgielda
yeah, i just realized that i misunderstood that.

The same response from xc3prog happen when i use root privilegde(native linux).

@tobiaszpuslecki
Copy link
Contributor

I've got the same problem as @MatPasGit. All USBx's are discovered, but xc3sprog doesn't see anything. I did everything what was written in tutorial and everything was done without errors. In docs, there is information that JTAG is shared with microUSB connector, which as I said is connected properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants