HiFive1 rev B is not fully compatible with the original HiFive1

Summary: While the HiFive1 rev B is just like its predecessor, the boot sequence has been changed and the tooling to upload the .hex files.

Introduction: I recently got my hands on the HiFive1 rev B and learned that there were Ada drivers for it. Upon trying them, they failed. A bit of research shows the original version has a bootloader that jumps to 0x20400000 to start executing code. The new version (rev B) changed the bootloader to jump to 0x20100000. The new model also has less internal memory (from 128Mbit down to 32Mbit), 2 UARTs and 1 I2C, a low-power state, optional bluetooth and wifi (which come by default if the boards is bought from Crowdsupply), uploading mechanism and an updated version of the debugging interface (version 0.13).

In order to make Ada work, even in a rough state, I changed the HiFive configuration (the link.ld and the zfp.gpr) to set the origin of the elf to 0x20100000. Which made the resulting binary work (after manually transforming the elf to hex). The upload method used was just copying the resulting .hex to the "USB" entry in the file manager, since the new rev B version only allows for JLink and copying into memory (OpenOCD is not officially supported, but there are people working on it, see https://forums.sifive.com/t/progress-getting-openocd-usable-with-revb/3415)

I have seen that the file /scripts/config/boards.py also contains the 0x204... address. I did not change it (I actually forgot) but the project still runs fine. Therefore, I don't know if the Python script is used to build the project or not. After all, it seems to contain generic information about the boards

Conclusion: while the modification presented allows Ada to build working binaries, it is quite unsatisfactory. I believe there are enough differences between HiFive1 and HiFive1 rev B that a new board entry is needed, since selecting the boot entry with a build flag could potentially "break" a board. In this new entry, the boot address, upload mechanism and other hardware modifications could be added. Obviously, the new entry would be based on the original. Notice: this is just what I found in a day of fiddling with the board, there may be more issues.

However, my knowledge of embedded programming only extends to Arduino boards and PICs, which may not be ideal for me to handle this correctly. Furthermore, I am just getting started with Ada, so there is not much I can do for now (well, I could try different things, but I doubt they will have the necessary quality standards).

Further comments: the default optimization flag when building a "Production" build, is -O3. In microcontrollers, this tends to be -Os (just to fit more into less), and is the default flag when compiling C code from the Freedom Studio platform (official SiFive IDE which uses the Freedom E SDK). This is just a comment, I am not proposing a change here.

Any input on the subject is very welcome. I wouldn't mind doing a simple pull request updating the boot address and the README files if they are welcome.

Hi @Irvise,

Thank you for your input, I have seen the release of the HiFive1 rev B but still didn't get one.

I have seen that the file /scripts/config/boards.py also contains the 0x204... address. I did not change it (I actually forgot) but the project still runs fine.

To add a first basic support for the rev B there are a couple of things to add to the config scripts. I can try to do it for you if you can then test it on the real board.

Further comments: the default optimization flag when building a "Production" build, is -O3. In microcontrollers, this tends to be -Os (just to fit more into less), and is the default flag when compiling C code from the Freedom Studio platform (official SiFive IDE which uses the Freedom E SDK). This is just a comment, I am not proposing a change here.

-O3 is for optimizing performance, -Os is for optimizing code size. We chose to optimize for performance by default but it's true that we could add a third option in the project file for -Os. I will open an issue to track this suggestion.

Regards,

Thanks @Fabien-Chouteau for the quick reply.

I have the real board and I am willing to test on it. Since I am still learning the hardware, if you need any help mapping and/or renaming memory to variables or anything similar, I would gladly help too. In any case, I need to read the documentation.

I forgot to mention my development settings:

OS: OpenSUSE Leap 15.2
Toolchain: AdaCore's RISC-V 32bit for Linux (2019 release, latest as of the writing of this issue)
Hex was created using riscv32-elf-objcopy -O ihex main main.hex but I have doubts of whether this is the correct way.

Regards

I have made a post about the new changes and support in SiFive's forum: https://forums.sifive.com/t/ada-drivers-library-available-for-rev-b-aka-program-your-board-with-ada/3458/1

Some things that came up during this time and the writing of the post:

The hex creation step should be automated. It is just running the following command riscv32-elf-objcopy -O ihex main main.hex after the last step. This streamlines the entire process greatly and saves typing a necessary command.
Better README.md documentation. Some parts of the forum post could be added to the README to better clarify the process/steps.
More examples? Some more examples showing how Ada works and how to approach different problems could help Ada beginners and people who are getting started with Ada in microcontrollers. Something such as a 3 LED combination cycling. Really easy to do in C, just like in Ada, but the code is quite different, see:

` with FE310; with HiFive1.LEDs; use HiFive1.LEDs; with FE310.Time; use FE310.Time;

procedure Main is

type Led_Array is array (1 .. 8) of Boolean; Pragma Pack (Led_Array); type Led_Cycle is mod 8;

Led_State : Led_Cycle := 0;

begin -- The SPI flash clock divider should be as small as possible to increase -- the execution speed of instructions that are not yet in the instruction -- cache. FE310.Set_SPI_Flash_Clock_Divider (2);

-- Load the internal oscillator factory calibration to be sure it -- oscillates at a known frequency. FE310.Load_Internal_Oscilator_Calibration;

-- Use the HiFive1 16 MHz crystal oscillator which is more acurate than the -- internal oscillator. FE310.Use_Crystal_Oscillator;

HiFive1.LEDs.Initialize;

-- Blinky! loop

  if (Led_State and 2#001#) /= 0 then
     Turn_On (Blue_LED);
  else
     Turn_Off (Blue_LED);
  end if;

  if (Led_State and 2#010#) /= 0 then
     Turn_On (Green_LED);
  else
     Turn_Off (Green_LED);
  end if;

  if (Led_State and 2#100#) /= 0 then
     Turn_On (Red_LED);
  else
     Turn_Off (Red_LED);
  end if;

  Led_State := Led_State + 1;
  Delay_Ms (500);

end loop; end Main; `

I could do the documentation step without issue. I know there is a CLA (contributor license agreement), which I don't mind signing if needed.

And, of course, add the newly added "modules/interfaces" of the new F310-002 chip. However, they could wait up until someone needs them.

PS: i don't know why the code is not being formatted properly.

Regards

Hi @Irvise

1. The hex creation step should be automated. It is just running the following command
   ` riscv32-elf-objcopy -O ihex main main.hex`
   after the last step. This streamlines the entire process greatly and  saves typing a necessary command.

Unfortunately we are not able to do that with GNATstudio and gprbuild at the moment.

2. Better README.md documentation. Some parts of the forum post could be added to the README to better clarify the process/steps.

If you can make a contribution for that, it would be great.

3. More examples? Some more examples showing how Ada works and how to approach different problems could help Ada beginners and people who are getting started with Ada in microcontrollers.

For the BBC micro:bit we have more examples, but of course it takes time to do and maintain.

1. And, of course, add the newly added "modules/interfaces" of the new F310-002 chip. However, they could wait up until someone needs them.

Yes that would be nice. I don't think I will have time to do unfortunately.

Regards,

AdaCore / Ada_Drivers_Library

HiFive1 rev B is not fully compatible with the original HiFive1 #334