Discussion on RISCV architecture possibilities

Hi there

I am reaching out on behalf of Exaleap Semiconductors, Bangalore, India, working towards developing a grounds-up ecosystem around open-source RISCV architectures. We are using RISCV processor-based development boards to develop a multitude of applications and currently exploring production-ready “over-the-update” (OTA) solutions.
We have successfully ported and implemented SWUpdate (OTA update framework) for RISCV based development boards and looking forward to more robust and production-grade OTA update solutions. In the same pursuit, we have initiated to implement Mender solution for RISCV architectures. We are also working towards porting mender client and other related tools for RISCV architecture, which would be equally useful for the open-source community.
While working towards porting of mender on RISCV architectures, we have a few queries and concerns which we would like to discuss. Can we connect over a zoom call to discuss this week?
Hope you are interested to connect and share your perspective.

@eystein this sounds like it’s meant for you :wink:

@abhishek thank you for helping a wider community getting access to OTA update solutions!

I believe your request has been handled in a different channel, please let me know if this isn’t the case. You may also want to ask any specific questions here, as many in the community can probably help and have experience with RISC as well.

Thanks for encouraging towards RISCV questions
Just as mender-covert accepts raspbian os as input to mender-convert tool and produces 4 partitioned images, fro riscv we have 3 partitioned yocto based image, with uboot, kernel, and rootfs partition.
Where exactly can I need to tweak in mender_convert_config file to accept it input image with 3 partitions?
pleae guide

I believe this is not supported by mender-convert at the moment. At the moment it selects the first partition as rootfs if there is one partition in the input image, or else the second partition. It would need to be extended to:

  1. Auto detect which partition should be treated as the root filesystem.
  2. Decide what to do with the other partitions, most likely simply preserve them. But the Mender client itself expects the kernel to be on the root filesystem, so it could also opt to move the kernel there.

Regardless, supporting input images with more than two partitions would need implementation work.