polarfire-soc / platform

PolarFire® SoC platform source code

Repo organization

<platform>
  |
  |-- drivers
  |     |- fpga_ip
  |     |     | .
  |     |     | .  
  |     |-  mss
  |     |     |- mss-ethernet-mac
  |     |     |- mss-can
  |     |     |- mss-gpio
  |     |     |     .
  |     |     |     .
  |     |     |     .
  |     |     |- mss-mmc
  |     |     |- mss-watchdog  
  |     |           |- mss-watchdog.c
  |     |           |- mss-watchdog.h
  |     |
  |     |- off_chip
  |     |     |  .
  |     |     |  .
  |     |
  |-- hal
  |     |
  |-- mpfs_hal
  |     |
  |-- platform_config_reference
  |     |     |- linker
  |     |     |     |- mpfs-ddr-loaded-by-boot-loader.ld
  |     |     |     |- mpfs-envm-lma-scratchpad-vma.ld
  |     |     |     |- mpfs-envm.ld
  |     |     |     |- mpfs-lim-lma-scratchpad-vma.ld
  |     |     |     |- mpfs-lim.ld
  |     |     |
  |     |     |
  |     |     |- mpfs_hal_config
  |     |           |- mss_sw_config.h
  |     |
  |-- soc_config_generator
  |           |
  |           |- mpfs_configuration_generator.py

This repository will always contain the latest and greatest of the platform contents. Some of the example projects under polarfire-soc-bare-metal-examples may not contain all the contents or latest versions of of the contents from this repository. In such cases, please download this repository and replace the src/platform repository in the project with it.

When you update the platform repository in your project, you must make sure that the reference design (and the xml configuration) is compatible with it.

For detailed description about the contents of the platform sub-directories and the overall bare metal software project folder structure, please refer to the Bare Metal Software Projects Structure

platform's Issues

how to make printf() work

Migrating #9 from polarfire-soc-bare-metal-library.

The printf support is planned to be added to MPFS HAL.

sleep_ms delays microseconds not milliseconds

mss_util.c contains a routine void sleep_ms(uint64_t msecs), which from its name and signature would imply that it will delay for the specified number of milliseconds. However, it actually seems to delay for the specified number of microseconds. Either it should be renamed, or modified so that it works in milliseconds.

This applies to the 2024.1 tag of the platform repository and effects the 2024.04 tag of the discovery-kit-reference design (and probably most of the code examples).

mss_config_clk_rst doesn't support enabling the FPGA fabric

The mss_config_clk_rst function doesn't support setting the SOFT_RESET_CR_FPGA bit. This bit is used to drive the reset output of the MSS to the FPGA fabric and without setting it none of the FIC peripherals are useable when the MSS to FPGA reset is used even if the FIC is out of reset.

Please add support for the FPGA reset to this function as the FICs are automatically taken out of reset here but not usable.

mss_mpu.h fails compilation with C++ compilers

The MSS_MPU_get_failstatus function in mss_mpu header fails the compilation. Since the header is included in mss_hal.h, using that also halts all compilation as well.

The file that includes mpu header has to be compiled with c, otherwise the compilation is halted.

Compiler settings:

Language Standard: GNU ISO 2011 C++
ABI version: Toolchain default (0)
Do not use checked for every option
Toolchain: RISC-V GCC/Newlib ( riscv64-unknown-elf-gcc)

How to correctoy read reset reasons?

I am stumbling upon an unexpected behavior of the ICICLE Kit when reading the SYSREG->RESET_SR register to retrieve the cause of reset upon startup.

The weird behavior is that when I check SYSREG->RESET_SR value I get:

• Power cycle: 0x1ff
• Soft reset (SYSREG->MSS_RESET_CR = 0xdead): 0x1c7
• Reset from debugger (JTAG): 0xcf

Multiple of the 8 bits which are assigned to a specific reset cause are set to 1, which is an unexpected behavior.

Immediately after reading SYSREG->RESET_SR to a stack variable, I clear the register to 0x0 as requested by documentation in the header file

platform/mpfs_hal/common/mss_sysreg.h

Line 135 in 13c8cc7

/*Indicates which reset caused the last reset. After a reset occurs registe

Once I do this, the value stored in SYSREG->RESET_SR is 0x40, which would correspond to GPIO reset (?)

Thanks

DDR Training Fail on ICICLE Kit

Hi!

Sorry to bother you again, but it seems that I cannot make another one of my ICICLE Kit pass the DDR training. I am using main branch of the BsP.

To enable LPDDR4 support, I just added the #define DDR_SUPPORT to my platform_config. My full file is here: https://pastebin.com/EN90euEF. I did not add any of the other #define seen in the HSS or the examples as they were for configurator < 2021.1 while I am using the 2021.3 ATM.

My configuration file from the MSS Configuration is here: https://pastebin.com/L7n8u5bg

The logs of the training instead are here: https://pastebin.com/wiVAapBX

Do you have any clue about what is happening? Am I configuring wrong the platform from the configurator?

Thanks!

How to use envm driver?

In polarfire-soc/hart-software-services#35 (comment), @fcuzzocrea asks...

Hi!

I am trying to understand how to use the mss_envm driver which I found shipped with the HSS here: https://github.com/polarfire-soc/hart-software-services/tree/master/baremetal/drivers/mss_envm

According to my understanding, we should fill with a buffer envm_set_page_data()

https://github.com/polarfire-soc/hart-software-services/blob/4efe944ec03ea011bb1a8e633a2e67eb4358e00d/baremetal/drivers/mss_envm/mss_envm.h#L167

and then load the buffer into envm with this function: envm_program_page_address()
https://github.com/polarfire-soc/hart-software-services/blob/4efe944ec03ea011bb1a8e633a2e67eb4358e00d/baremetal/drivers/mss_envm/mss_envm.h#L99

However, in order to initialize the driver, we need to call envm_init()

https://github.com/polarfire-soc/hart-software-services/blob/4efe944ec03ea011bb1a8e633a2e67eb4358e00d/baremetal/drivers/mss_envm/mss_envm.h#L80

. This function takes as parameter p_envm_params. Which system service it is needed to call to fill this variable?
The function which needs to be called after instead is envm_set_clock()

https://github.com/polarfire-soc/hart-software-services/blob/4efe944ec03ea011bb1a8e633a2e67eb4358e00d/baremetal/drivers/mss_envm/mss_envm.h#L64

, which is taking as input mss_frequency, but what is mss_frequency? Is LIBERO_SETTING_MSS_SYSTEM_CLK ?
Can you provide an example of how to use this driver?? Also, it is possible to use it to change some values written in the eNVM at runtime?

Thanks!!!

I've moved this ticket here, as it is a question on a bare metal driver... The HSS no longer uses the eNVM driver.

How to make MSS_MAC_receive_pkt() work ?

Ciao!

I am trying to setup a simple test of eth0 LOOPBACK (with null_phy configuration) using the baremetal driver provided in the bsp (I also sent some pull requests to fix compilation).

I am setting up mac0 in this way:

#include <stdint.h>

#include <drivers/mss/mss_ethernet_mac/mss_ethernet_registers.h>
#include <drivers/mss/mss_ethernet_mac/mss_ethernet_mac_sw_cfg.h>
#include <drivers/mss/mss_ethernet_mac/mss_ethernet_mac_regs.h>
#include <drivers/mss/mss_ethernet_mac/mss_ethernet_mac.h>
#include <drivers/mss/mss_ethernet_mac/phy.h>

mss_mac_cfg_t g_mac_config;

void init_ethernet()
{
    MSS_MAC_cfg_struct_def_init(&g_mac_config);

    /*
     * Set the MAC address, no need to change other things as the struct is
     * initialized defaulting to NULL_PHY mode.
     */
    g_mac_config.mac_addr[0] = 0xC0u;
    g_mac_config.mac_addr[1] = 0xB1u;
    g_mac_config.mac_addr[2] = 0x3Cu;
    g_mac_config.mac_addr[3] = 0x88u;
    g_mac_config.mac_addr[4] = 0x88u;
    g_mac_config.mac_addr[5] = 0x88u;

    g_mac_config.rx_flow_ctrl = MSS_MAC_RX_FLOW_CTRL_DISABLE;
    g_mac_config.tx_flow_ctrl = MSS_MAC_TX_FLOW_CTRL_DISABLE;
    g_mac_config.append_CRC = MSS_MAC_CRC_ENABLE;
    g_mac_config.queue_enable[0] = MSS_MAC_QUEUE_ENABLE;
    g_mac_config.queue_enable[1] = MSS_MAC_QUEUE_ENABLE;
    g_mac_config.queue_enable[2] = MSS_MAC_QUEUE_ENABLE;
    g_mac_config.queue_enable[3] = MSS_MAC_QUEUE_ENABLE;
    g_mac_config.loopback = MSS_MAC_LOOPBACK_ENABLE;
    g_mac_config.fullduplex = MSS_MAC_FULLDUPLEX_ENABLE;

    /*
     * Initialize MAC with specified configuration. The Ethernet MAC is
     * functional after this function returns but still requires transmit and
     * receive buffers to be allocated for communications to take place.
     */
    MSS_MAC_init(&g_mac0, &g_mac_config);
}

After this, according to the documentation, I created a TX and RX handler which are doing nothing but incrementing a counter (to keep is as simple as possible), and I register them.

After the registration of the handlers, I first call the MSS_MAC_receive_pkt() function, to enable the RX interrupt, and then I send a packet with the MSS_MAC_send_pkt() function.

However, the MSS_MAC_receive_pkt() function always fails to arm the rx. Looking trough the code of the function itself, it seems that status is initialized with MSS_MAC_FAILED

platform/drivers/mss/mss_ethernet_mac/mss_ethernet_mac.c

Line 1544 in 48c848c

uint8_t status = MSS_MAC_FAILED;

But then, trough the body of the function, seems that status never get updated. How can I check if the ARM phase is done correctly ?

Thank you!!

Issue with mss uart driver on FreeRTOS for tag 2023.6

In uart_isr()

https://github.com/polarfire-soc/platform/blob/main/drivers/mss/mss_mmuart/mss_uart.c

for IIRF_THRE the code has changed and the lines (1603-1606):
if (this_uart->tx_idx == this_uart->tx_buff_size)
{
MSS_UART_disable_irq(this_uart, MSS_UART_TBE_IRQ);
this_uart->tx_buff_size = TX_COMPLETE;
}
were moved from the end of the tx_handler routine to the the isr body right after the handler has been called.

This is an issue in case the tx_handler calls portEND_SWITCHING_ISR(xHigherPriorityTaskWoken) because a task sending data over uart will restart before returning to the ISR and in case the task wants to send someting else on the using interrupts the call will stop in MSS_UART_irq_tx() at line 357:

ASSERT(TX_COMPLETE == this_uart->tx_buff_size);

`main_first_hart` does not use provided HLS

Why does main_first_hart() take in a pointer to the HLS from the caller, but then overwrite its value to be hard-coded to the HLS for hart0?

platform/mpfs_hal/startup_gcc/system_startup.c

Lines 102 to 103 in 8af073c

	stack_top = (ptrdiff_t)((uint8_t*)&__stack_top_h0$);
	hls = (HLS_DATA*)(stack_top - HLS_DEBUG_AREA_SIZE);

That HLS pointer for hart0 then gets passed into main_other_hart() to kick off the hart entry-point function, even if the specified "first hart" is not hart0.

And similarly for main_first_hart_app(), the HLS is passed in, but then overwritten to be hard-coded to the HLS for hart1. And that value is then passed into main_other_hart():

platform/mpfs_hal/startup_gcc/system_startup.c

Lines 302 to 305 in 8af073c

	stack_top = (ptrdiff_t)((uint8_t*)&__stack_top_h1$);
	hls = (HLS_DATA*)(stack_top - HLS_DEBUG_AREA_SIZE);
	hls->in_wfi_indicator = HLS_MAIN_HART_FIN_INIT;
	(void)main_other_hart(hls);

MSS_SPI_init doesn't permit use of B Context

All of the MSS_SPI_.... functions in 'mss_spi.c' contain this ASSERT

ASSERT((this_spi == &g_mss_spi0_lo) || (this_spi == &g_mss_spi0_hi) 
        || (this_spi == &g_mss_spi1_lo) || (this_spi == &g_mss_spi1_hi));   

except for MSS_SPI_init that contains
ASSERT((this_spi == &g_mss_spi0_lo) || (this_spi == &g_mss_spi1_lo));
instead.

It therefore fails for the '.._hi' options.