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.

Sign up for GitHub

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

Jump to bottom

Add picorv32 support for Alhambra board #32

Closed
drtrigon opened this issue Oct 22, 2018 · 121 comments
Closed

Add picorv32 support for Alhambra board #32

drtrigon opened this issue Oct 22, 2018 · 121 comments

Comments

@drtrigon
Copy link

According to YosysHQ/picorv32#92 picorv32 RISC soft core runs on Alhambra board. Is it possible to add support for this to FPGArduino?
@emard
Copy link
Member

emard commented Oct 22, 2018 via email

@drtrigon
Copy link
Author

drtrigon commented Oct 23, 2018 •
edited
Loading

I try to help with whatever I can. The toolchain I used successfully is "RISC-V GNU toolchain and libraries for a pure RV32I target" as mentioned in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain. It uses riscv32-unknown-elf-gcc, riscv32-unknown-elf-objcopy and from icestorm/icestudio toolchain iceprog (see https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile).

@emard
Copy link
Member

emard commented Oct 23, 2018 via email

@drtrigon
Copy link
Author

Can you try to use our f32c-rv32 compiled binary to get LED blinky on picorv32?

I tried, but not with much success... I used code from a working project and just tried to replace the toolchain with yours, see attached Makefile.txt (the commented parts are the ones from the working toolchain for reference).

Running it results in (the .elf file has a size of 0 bytes):

$ make prog
../../fpgarduino/f32c/bin/riscv-elf-gcc -std=gnu11 -DHX8KDEMO -march=RV32I -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc4XMh7D.o: ABI is incompatible with that of the selected emulation
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc4XMh7D.o
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc39QdcM.o: ABI is incompatible with that of the selected emulation
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc39QdcM.o
make: *** [firmware.elf] Fehler 1

So my questions:

  • Can you be more specific what I should test exactly (source files, commands for compiling, etc.)?
  • Would it be possible to integrate the picorv32 icestorm/icestudio toolchain as it is open source too (e.g. the programmer could be needed)?

@emard
Copy link
Member

emard commented Oct 26, 2018 via email

@gornjas
Copy link
Contributor

gornjas commented Oct 26, 2018

Our current riscv toolchain is exactly the same as the mips version, i.e. is gcc-7.2 based and should be perfectly fine. The question is why the OP has fetched the long obsoleted 4.9.2 toolchain - could that be a bug in our Arduino json / packaging?

@emard
Copy link
Member

emard commented Oct 26, 2018 via email

@gornjas
Copy link
Contributor

gornjas commented Oct 27, 2018

How did that regression happen? I thought we already switched over to 7.2 a year ago, and were using gcc-6 based toolchains prior to that. The bm/package_fpga_index.json is clearly referencing 7.2 based toolchains.

I'm inclined to wipe out all the pre-7.2 .zip archives from the web, otherwise we'll be getting into this again and again...

@emard
Copy link
Member

emard commented Oct 27, 2018 via email

@gornjas
Copy link
Contributor

gornjas commented Oct 27, 2018

How's that possible? There's a single integrated toolchain archive for both mips + riscv toolchains per OS/architecture (win32, osx, lin32, lin64)? I.e. they are not downloaded separately, and there's no way to separate them in the json?

@gornjas
Copy link
Contributor

gornjas commented Oct 27, 2018

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

@emard
Copy link
Member

emard commented Oct 27, 2018 via email

@emard
Copy link
Member

emard commented Oct 27, 2018 via email

@emard
Copy link
Member

emard commented Oct 27, 2018 via email

@drtrigon
Copy link
Author

I got the toolchain from http://www.nxlab.fer.hr/fpgarduino/ and it was 64-bit:

@gornjas
Copy link
Contributor

gornjas commented Oct 27, 2018

The 7.2-based toolchain for 32-bit linux was built at the same time the 64-bit version was. We have 5 different toolchains based on gcc-7.2 since 2017 so there's no reason to use anything else:

login% ls -l tool
-r--r--r-- 1 marko fpgasvn 68284749 Nov 15 2017 f32c-fbsd64-toolchain-7_2.tar.gz
-r--r--r-- 1 marko fpgasvn 79048039 Nov 15 2017 f32c-lin32-toolchain-7_2.tar.gz
-r--r--r-- 1 marko fpgasvn 72986821 Nov 14 2017 f32c-lin64-toolchain-7_2.tar.gz
-rw-r--r-- 1 marko fpgasvn 82335149 Nov 24 2017 f32c-osx-toolchain-7_2.tgz
-r--r--r-- 1 marko fpgasvn 93959677 Nov 9 2017 f32c-win32-toolchain-7_2.zip

@drtrigon
Copy link
Author

drtrigon commented Oct 27, 2018 •
edited
Loading

Ok a lot of links on http://www.nxlab.fer.hr/fpgarduino/ are broken now but I figured the name of the new one to be www.nxlab.fer.hr/fpgarduino/bm/f32c-lin64-toolchain-7_2.tar.gz now, using that I got following result:

$ make prog
../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
cc1: error: requested ABI requires -march to subsume the 'D' extension
make: *** [firmware.elf] Fehler 1

@drtrigon
Copy link
Author

drtrigon commented Oct 27, 2018 •
edited
Loading

It is no problem for integrate from licensing point of view but we lack of ing-hours to assemble all parts into stuff that works. I can package another riscv compiler and all required programming tools and libs, if you succeed with anything that leads to a blink led

As explained in YosysHQ/picorv32#92 you can find a working example in https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc (see e.g. https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile).
The toolchain used can be found in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain (risc-v gcc) and https://github.com/FPGAwars/toolchain-icestorm/releases/ (iceprog).
Do you need more info? More specific details?
What I do not have are includes to make it compatible with Arduino source code.

@gornjas
Copy link
Contributor

gornjas commented Oct 27, 2018

$ make prog
../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
cc1: error: requested ABI requires -march to subsume the 'D' extension
make: *** [firmware.elf] Fehler 1

Hi drtrigon,

pls. try adding -mabi=ilp32 to riscv32-elf-gcc invocation options.

@drtrigon
Copy link
Author

Works! The created .elf file differs by one byte from the one the original toolchain generated a few days before. Nice! Uploaded using iceprog.

@drtrigon
Copy link
Author

Do you need more info from my side?

@emard
Copy link
Member

emard commented Oct 28, 2018 via email

This was referenced Oct 28, 2018
Closed
Closed
@drtrigon
Copy link
Author

Oh, by the way the links on http://www.nxlab.fer.hr/fpgarduino/ are still broken, quite some confusion with "_", "-" and "." going on there, e.g.:

@drtrigon
Copy link
Author

drtrigon commented Nov 9, 2018

Any news?

@emard
Copy link
Member

emard commented Nov 9, 2018 via email

@drtrigon
Copy link
Author

drtrigon commented Nov 9, 2018

Sorry to hear that but thanks a lot for your work! (I'm eager to test it on Alhambra... ;)

@drtrigon
Copy link
Author

drtrigon commented Dec 4, 2018

What is the current status? Do you have an estimate by when I can start using it on the Alhambra?

@emard
Copy link
Member

emard commented Dec 4, 2018 via email

@emard
Copy link
Member

emard commented Mar 18, 2019 via email

@emard
Copy link
Member

emard commented Mar 18, 2019 via email

@emard
Copy link
Member

emard commented Mar 18, 2019 via email

@drtrigon
Copy link
Author

drtrigon commented Mar 19, 2019 •
edited
Loading

I will again look into this as soon as I have time. I think we are quite close now, just the mem mapping. Some of your suggetion have be checked alteady (select 8K board, F32C flag, ) - except the mapping, so I think/hope its that.
Btw some info about the core I use - may be helpful: https://github.com/cliffordwolf/picorv32/blob/master/README.md (however not too much about mapping)
The increased RAM mapping you posted has no changes...

@emard
Copy link
Member

emard commented Mar 19, 2019 via email

@drtrigon
Copy link
Author

drtrigon commented Mar 19, 2019 •
edited
Loading

I can follow your speculations and they seem reasonable to me. I just checked, the compiled blinky is 200 bytes - so that's fine. I tested with --section-start=.init=0x0 but no change. I can confirm that firmware is in flash as the command to upload it is $(ICESTORM)/iceprog -o 1M $(FIRMWARE).bin so to a offset of 1M - thus that must be flash.
May be https://github.com/cliffordwolf/picorv32/tree/master/picosoc answers most of the questions: "The flash is mapped to the memory regions starting at 0x00000000 and 0x01000000, with the SRAM overlayed for the mapping at 0x00000000. The SRAM is just a small scratchpad memory (default 256 words, i.e. 1 kB).
The reset vector is set to 0x00100000, i.e. at 1MB into in the flash memory."
If not, a look into the source could help: https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc .

edit: Just came to my mind... what about this in firmware.c - might this be our issue:

//			"li s0, 0x00008000;"	/* 32K RAM top = stack address */
			"li s0, 0x00002000;"	/* 8K RAM top = stack address */

@emard
Copy link
Member

emard commented Mar 20, 2019 via email

@drtrigon
Copy link
Author

I did not blink at 2M. But I had to change blinky a bit:

    #include <stdint.h>
    //#define LED (*(volatile uint32_t*)0x02000000)
    #define LED (*(volatile uint32_t*)0x03000000)
    void setup()
    {
    }
    void main()
    {
      LED = 0;
      for(int i = 0; i < 1000000; i++)
        asm("nop");
      LED = 0xFF;
      for(int i = 0; i < 1000000; i++)
        asm("nop");
    }

@drtrigon
Copy link
Author

Just to be very sure I posted my actual firmware.c as gist, may be you want to have a look over it (I had quite some changes after all the time trying): https://gist.github.com/drtrigon/22a3beaf3dd7953006f1253574297bfc

@emard
Copy link
Member

emard commented Mar 20, 2019 via email

@uXeBoy
Copy link

uXeBoy commented Mar 20, 2019

You may want to jump over to the work that Lawrie Griffiths has been doing on iCE40, rather than continuing this 'issue' here:

https://github.com/lawrie/MuraxArduino

You can catch-up on where this started and where it has gone here:

https://forum.mystorm.uk/t/soft-arduino-and-accelerated-libraries/517

@drtrigon
Copy link
Author

@uXeBoy: Thanks for the hint! So how directly can this be ported to Alhambra II board, do you have a clue?

@emard: Looked into the bootloader (firmware.c) for quite some time:

  1. LED mapping cannot be changed, if I do so serial port starts outputing FF all the time (no rv32> prompt anymore)
  2. Leaving the LED mapping and adding a new for the "real" LEDs allows to use LED and serial port
  3. I have issues reading from serial port properly - the loop after the "loop" label has a c = reg_uart_data; in it but this never sees anything else than FF and therefore never ends
  4. I wonder where the bootloader receives bytes and writes them to RAM, can you point me to the line?
    (so currently I actually doubt that my setup ever uploaded code via bootloader into RAM)

@drtrigon
Copy link
Author

drtrigon commented Mar 22, 2019 •
edited
Loading

Other solution not involving a bootloader firmware but using the Arduino IDE as replacement for the Makefile I was using - not what I aim for but a good first step into the right direction (icestudio+arduinoide). You have to create a folder called "hardware" in you arduino sketchbook folder and unpack this archive there.

AlhambraII_Generic_picorv32.tar.gz

Enjoy and tell me what you think!

@drtrigon
Copy link
Author

drtrigon commented Mar 23, 2019 •
edited
Loading

@emard: Basically this what I had in mind 5 mo ago. As my code compiles on your gcc toolchain the only thing needed is iceprog. As icestudio should be installed first anyway we can just use its toolchain. So all there (except its not using your bootloader yet).
I can also provide a bitstream with a reference picorv32 design if you like to add one.

Will you add it to FPGArduino?

@emard
Copy link
Member

emard commented Mar 23, 2019 via email

@drtrigon
Copy link
Author

drtrigon commented Mar 23, 2019 •
edited
Loading

linux, win and mac available as I took it from icestudio toolchain: https://github.com/FPGAwars/icestudio/releases and https://github.com/FPGAwars/icestudio/blob/develop/README.md#package

However I have to check whether they are statically linked.

Will put it on github as soon as I have time. Meanwhile there is the archive I posted before.

@drtrigon
Copy link
Author

They are statically linked: https://github.com/FPGAwars/toolchain-icestorm/wiki

@emard
Copy link
Member

emard commented Mar 23, 2019 via email

drtrigon added a commit to drtrigon/fpgarduino-icestorm that referenced this issue Mar 23, 2019
@drtrigon
Initial commit; see f32c/arduino#32
8d007c2
@drtrigon
Copy link
Author

github repo: https://github.com/drtrigon/fpgarduino-icestorm

Just used iceprog in https://github.com/FPGAwars/toolchain-icestorm/releases/download/v1.11.0/toolchain-icestorm-linux_x86_64-1.11.0.tar.gz from https://github.com/FPGAwars/toolchain-icestorm/releases/ with success. I can confirm this works. (No need to change anything in boards.txt and/or platform.txt.)

@drtrigon
Copy link
Author

Do you need more info from my side?

@emard
Copy link
Member

emard commented Mar 30, 2019 via email

@drtrigon
Copy link
Author

As soon as you had time to put it in I'll happily test it! I guess there might be some things to sort out and polish.

Next step then would be to work on the "core" the includes and headers that make it look like arduino code.

@drtrigon
Copy link
Author

Note to myself: While working on YosysHQ/picorv32#121 realized that I used the old buggy linker script (missing an ALIGN(4)) for the bootloader test. So it might be worth re-doing those tests with the CORRECT linker script (lds).

@drtrigon drtrigon mentioned this issue May 7, 2019
Closed
@drtrigon
Copy link
Author

@emard: did you had time to look into it?

@emard
Copy link
Member

emard commented May 13, 2019 via email

@drtrigon
Copy link
Author

drtrigon commented May 13, 2019 via email

@emard
Copy link
Member

emard commented May 13, 2019 via email

@drtrigon
Copy link
Author

drtrigon commented Jun 6, 2019

Latest commit: drtrigon/fpgarduino-icestorm@09d6520

What does work now:

  • Verify (building)
  • Upload
  • Serial Monitor using any baudrate, default is 115200 (needs setting the correct port)
  • Arduino IDE examples:
    • 01.Basics
      • BareMinimum: compiles
      • Blink: pinMode dummy for leds, digitalWrite on leds also using full 8-bit uint8_t, delay
      • DigitalReadSerial: Serial.println, Serial.begin all baudrates, pinMode (0-7), digitalRead (0-15)
      • AnalogReadSerial: analogRead (A0, 4Hz, bits increased from 8 to 10 by multiplying with 4)
      • ReadAnalogVoltage: (voltage calculation wrong 5.0->3.3)
      • (TODO: Fade - needs PWM)
    • 02.Digital
      • BlinkWithoutDelay: millis, micros, (delay refactored to use micros)
      • Button: (works after changing ledPin 13->LED_BUILTIN)
      • Debounce: (works after changing ledPin 13->LED_BUILTIN)
      • StateChangeDetection: (works after changing ledPin 13->LED_BUILTIN)
    • 03.Analog
      • AnalogInput: (works after changing ledPin 13->LED_BUILTIN)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@q3k @uXeBoy @gornjas @emard @drtrigon