Zephyr hello world in Alhambra board
imuguruza opened this issue · comments
Hi,
I am trying to run the example in Alhambra board, that contains a 12MHz clock and a iCE40HX4K fpga. I have managed to synthesize and upload the example. But, once I open a minicom session and reset the board, it reads some garbage:
��|�������p
I believe that is due to the clock frequency, as you mention in the Readme, as the uart_tx in bitbanged, could be some sync or speed issue? Any idea how can I fix it?
Thanks in advance for the help!
The system expects a 16MHz clock in order to output data with baud rate 57600. As you have a 12MHz clock, could you first try setting the baud rate in minicom to 43200 (or something like that. Not sure about the exact frequency). If that works you can instantiate a PLL that turns your external 12MHz into a 16MHz clock if you want the standard baud rate
It works! You were right @olofk !
***** Booting Zephyr OS zephyr-v1.14.1-4-gc7c2d62513fe *****
Hello World! service
I have used the next parameters for nextpnr and pll
nextpnr_options : [--hx8k, --package, tq144:4k, --freq, 16]
alhambra_pll:
generator: icepll
parameters:
freq_in : 12
freq_out : 16
I am not sure if this is correct. I assume that with these statements I am trying to synth a 16MHz core and that I am saying to icepll to create a 16MHz clock out of 12MHz input clock
The PLL generation stuff is very poorly documented. Sorry about that. You have done the right thing, but there's more needed.
First, you need to add
generate : [alhambra_pll] to your target. Otherwise it will never be run. Then you need to instantiate the generated module. The service toplevel (which I think you might be using) instantiates this by default if you specify PLL=ICE40_CORE in your target parameters (see how the tinyfpga_bx target does it).
I haven't looked at this myself for a long time and I see now that the whole thing is pretty messy and it would probably be easier to just manually instantiate a PLL and don't do any autogeneration at all. I might do some cleaning up here for the icebreaker and tinyfpga_bx targets
Another thing, is that the correct nextpnr options? I looked at the Alhambra site and it says the FPGA is iCE40HX4K but you specify --hx8k
HI again,
Thanks for your fast reply. Sorry, I didn't paste all the additions I have made. As you suggest, I have copied the tinyfpga_bx and make some small changes:
Here: https://github.com/imuguruza/serv/blob/alhambra_support/servant.core#L104
Here the pll:
https://github.com/imuguruza/serv/blob/alhambra_support/servant.core#L244
And the pcf:
https://github.com/imuguruza/serv/blob/alhambra_support/servant.core#L48
Another thing, is that the correct nextpnr options? I looked at the Alhambra site and it says the FPGA is iCE40HX4K but you specify --hx8k
Let me check it...
Would you accept the support of this board in master? Once everything is OK, I was thinking of creating a PR. It is not a bit contribution, but...
Regarding nextpnr options, I have checked icestorm, and the table states the next:
| Part | Package | Pin Spacing | I/Os | nextpnr opts | arachne-pnr opts | icetime opts |
|---|---|---|---|---|---|---|
| iCE40-HX4K-TQ144 | 144-pin TQFP (20 x 20 mm) | 0.50 mm | 107 | --hx8k --package tq144:4k | -d 8k -P tq144:4k | -d hx8k |
So, it looks like when the device is of type hx4k, --hx8k needs to set as nextpnr input
Love to have support for the Alhambra boards. The more, the better :) Your core description file looks fine to me and I'm happy to accept a PR once it works for you. Does it work now with baud rate 57600 or do you still need to set 43200?
If you feel like it, there are two other things you can do. Add the Alhambra board to LED to Believe where I'm trying to have LED blink examples for as many FPGA boards as possible
And if you want to see how many RISC-V cores you can run on the Alhambra board you can add support in CoreScore
Love to have support for the Alhambra boards. The more, the better :) Your core description file looks fine to me and I'm happy to accept a PR once it works for you.
Great!
Does it work now with baud rate 57600 or do you still need to set 43200?
Unfortunately, no. It doesn't receive properly the characters with 57600. But yes with 38400 (tested with gtkterm and minicom). So I might put that value in the Readme, instead of 43200, which is not a standard value.
If you feel like it, there are two other things you can do. Add the Alhambra board to LED to Believe where I'm trying to have LED blink examples for as many FPGA boards as possible
Sure, I wanted to do so
And if you want to see how many RISC-V cores you can run on the Alhambra board you can add support in CoreScore
I will have a look on it
Is there any chance to understand how can I implement a blinker with servant?
I have seen this and I was curious if I could make it work in the board. Do I need to install the toolchain that appears in the Makefile? Any hint will be appreciated :)
Agree. 38400 is fine as long as it's in the readme. Still a bit confused about what's going on but we can always figure that out later.
About the blinker; since servant only has a single IO by default I think it's a good idea to route this to both UART and a LED. I'm doing that on some targets already, like this
Once you have a LED connected you can load the precompiled blinky example by adding --firmware=path/to/serv/sw/blinky.hex to the fusesoc command.
If you want to recompile the blinky example (or any other program) you will need a RISC-V toolchain. I usually compile them myself when I need them but there might be precompiled ones available now. Not sure where.
You can check sw/Makefile for examples on how to convert elf files into hex files thay servant can use. E.g. make blinky.hex should compile blinky.S to blinky.hex
I also noticed you are involved with ros micro. That looks useful. Perhaps you would be interested in https://github.com/olofk/observer which is meant to be a heterogenous sensor aggregation platform built around SERV cores. I actually envisioned a use case like ROS for it, but didn't know it was available for smaller CPUs
Agree. 38400 is fine as long as it's in the readme. Still a bit confused about what's going on but we can always figure that out later.
OK.
I will start with the fusescoc/blinky and CoreScore. After, I will try to do the blinky example with Zephyr.
I also noticed you are involved with ros micro. That looks useful. Perhaps you would be interested in https://github.com/olofk/observer which is meant to be a heterogenous sensor aggregation platform built around SERV cores. I actually envisioned a use case like ROS for it, but didn't know it was available for smaller CPUs
I was involved in micro-ROS yes :) The project aims to support ROS for microcontrollers. One important thing to notice is that they are using 32-bit micros. Stack-wise, RTOS + DDS + ROS client library is being used. The DDS and ROS client library is being modified for uC. We can have a discussion if you want.
I am closing the issue, as is getting out of scope.