On Fri, May 13, 2022 at 12:52 PM Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 5/13/22 10:42, Stanisław Kardach wrote: > > On Fri, May 13, 2022 at 8:50 AM Heinrich Schuchardt > > <heinrich.schucha...@canonical.com> wrote: > > <snip> > >>> +Linux kernel > >>> +~~~~~~~~~~~~ > >>> + > >>> +It is recommended to use Linux kernel built from > >>> +`SiFive Freedom Unleashed SDK > >>> <https://github.com/sifive/freedom-u-sdk>`_. > >> > >> How would the Unleashed SDK help on a later board or a board from a > >> different vendor? > > This SDK is for both Unleashed and Unmatched. The naming is a bit > > misleading. > >> > >> Why wouldn't an upstream kernel work? > > At the point of writing it was missing patches related to PCI resource > > mapping exposure to userspace. Right now it's there. > >> > >> I suggest to eliminate this misleading section. > > I'll re-test with the latest upstream kernel and rephrase that this > > should work with Linux kernel >= x.y.z. > >> > >>> + > >>> + > >>> +Meson prerequisites > >>> +~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +Meson depends on pkgconfig to find the dependencies. > >>> +The package ``pkg-config-riscv64-linux-gnu`` is required for RISC-V. > >>> +To install it in Ubuntu:: > >>> + > >>> + sudo apt install pkg-config-riscv64-linux-gnu > >> > >> This package does not exist in the current Ubuntu LTS (22.04, Jammy). > >> > >> Setting environment variables PKG_CONFIG_LIBDIR, PKG_CONFIG_PATH, > >> PKG_CONFIG_SYSROOT_DIR properly should do the job with the normal > >> pkg-config. > > Do you happen to know why was this package removed? > > The Debian maintainer introduced this change in package > gcc-defaults-ports. The change log does not give a reason. > > > Given that, is there a Ubuntu manual page or tool somewhere specifying > > the correct values to obtain for a given arch? > > The values might depend on the Linux distribution. > > In Ubuntu the .pc files are in > > /usr/lib/riscv64-linux-gnu/pkgconfig > /usr/lib/pkgconfig > /usr/share/pkgconfig OK, I'll describe those for Ubuntu path. > > > > >> > >>> + > >>> + > >>> +GNU toolchain > >>> +------------- > >>> + > >>> + > >>> +Obtain the cross toolchain > >>> +~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +The build process was tested using: > >>> + > >>> +* Ubuntu toolchain (the ``crossbuild-essential-riscv64`` package). > >>> + > >>> +* Latest `RISC-V GNU toolchain > >>> + <https://github.com/riscv/riscv-gnu-toolchain/releases>`_ on Ubuntu or > >>> Arch > >>> + Linux. > >>> + > >>> +Alternatively the toolchain may be built straight from the source, to do > >>> that > >>> +follow the instructions on the riscv-gnu-toolchain github page. > >>> + > >>> + > >>> +Unzip and add into the PATH > >>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +This step is only required for the riscv-gnu-toolchain. The Ubuntu > >>> toolchain is > >>> +in the PATH already. > >>> + > >>> +.. code-block:: console > >>> + > >>> + tar -xvf riscv64-glibc-ubuntu-20.04-<version>.tar.gz > >> > >> You can install the glibc package with apt-get after adding the > >> architecture with sudo dpkg --add-architecture riscv64. See > >> https://wiki.debian.org/CrossCompiling. > >> > > This guide is supposed to target also Arch where this toolchain should > > work properly. That's why in previous section I'm mentioning > > crossbuild-essential-riscv64 and RISC-V GNU toolchain from github > > separately. > >>> + export PATH=$PATH:<cross_install_dir>/riscv/bin > >>> + > >>> + > >>> +Cross Compiling DPDK with GNU toolchain using Meson > >>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +To cross-compile DPDK for a desired target machine use the following > >>> command:: > >>> + > >>> + meson cross-build --cross-file <target_machine_configuration> > >>> + ninja -C cross-build > >>> + > >>> +For example if the target machine is a generic rv64gc RISC-V, use the > >>> following > >>> +command:: > >>> + > >>> + meson riscv64-build-gcc --cross-file config/riscv/riscv64_linux_gcc > >>> + ninja -C riscv64-build-gcc > >>> + > >>> +If riscv-gnu-toolchain is used, binary names should be updated to match. > >>> Update the following lines in the cross-file: > >>> + > >>> +.. code-block:: console > >>> + > >>> + [binaries] > >>> + c = 'riscv64-unknown-linux-gnu-gcc' > >>> + cpp = 'riscv64-unknown-linux-gnu-g++' > >>> + ar = 'riscv64-unknown-linux-gnu-ar' > >>> + strip = 'riscv64-unknown-linux-gnu-strip' > >>> + ... > >>> + > >>> +Some toolchains (such as freedom-u-sdk one) require also setting > >>> ``--sysroot``, > >>> +otherwise include paths might not be resolved. To do so, add the > >>> appropriate > >>> +paths to the cross-file: > >>> + > >>> +.. code-block:: console > >>> + > >>> + [properties] > >>> + ... > >>> + c_args = ['--sysroot', '<path/to/toolchain/sysroot>'] > >>> + cpp_args = c_args > >>> + c_link_args = ['--sysroot', '<path/to/toolchain/sysroot>'] > >>> + cpp_link_args = c_link_args > >>> + ... > >>> + > >>> + > >>> +Supported cross-compilation targets > >>> +----------------------------------- > >>> + > >>> +Currently the following targets are supported: > >>> + > >>> +* Generic rv64gc ISA: ``config/riscv/riscv64_linux_gcc`` > >>> + > >>> +* SiFive U740 SoC: ``config/riscv/riscv64_sifive_u740_linux_gcc`` > >> > >> Why do we need a special config for the Unmatched board that is not sold > >> anymore? Doesn't the Unmatched board work with the genenric config? > > I wasn't aware that they did discontinue it. As far as I can see it's > > due to supply chain issues, maybe that means it'll get back? Generic > > https://forums.sifive.com/t/sifive-update-on-hifive-unmatched-boards-in-2022/5569?s=09 > : > > "we’ve decided to focus on the next generation SiFive HiFive development > systems rather than trying to put together another build of the HiFive > Unmatched platform in 2022." I did not know that, thank you. > > > config works just fine for the Unmatched. However config for Unmatched > > enables certain optimizations that are valid there. I.e. when reading > > RIME or CYCLE registers in a precise way, normally a fence should be > > inserted before reading it. However on Unmatched read to both counters > > is emulated through a call to firmware (SBI) in userspace, eliminating > > the need for the fence. > > Distributions like Ubuntu will only build a single configuration. I understand however there are also platform specific configs for Aarch64 here (Graviton, ThunderX, CnXk to name a few) so it's not that uncommon. Plus distro packages although useful for orchestration environments such as accelerating OpenStack Neutron (or other orchestrated networking packages), there will still be people compiling DPDK locally, be it via company-wide Yocto server to package for specific HW or just integrating DPDK statically in their projects (to not pay the cost of a dynamic lib call). > It is preferable to read vendor_id and arch_id via an SBI call at runtime > to switch code paths. Right, but SBI call can only be made from S-mode (so kernel), right? Issuing "ecall" from U-mode (userspace) will transfer control to kernel. AFAIK it is KVM that emulates or forwards SBI calls further but that's in qemu scope. I was trying to figure out how to get this data from Linux to decide at build time but it's not in the /proc/cpuinfo (it only prints DTS's "compatible" for the CPU). Deciding at runtime is costly because you either need a functor call or self-modifying code (similar to how Linux handles Compare-And-Swap on Aarch64). > > Isn't the saving gained by removing the fence irrelevant compared to the > duration of an SBI call? Yes, that is most likely but I was not able to measure it, because the access to the time source on Unmatched is emulated, so it's hard to reason. Other thing that this config triggers (or more precisely the vendor_id and arch_id) is "-mtune" value which I believe still contains some compiler tweaks for the platform.
Given all that I can remove the current infrastructure in config/riscv/meson.build and the related sifive config but I'd prefer not to. I'm pretty sure it'll come in handy when a new RISC-V platform comes in (and serve as a reference for new developers). There is a warning in meson.build noting the lack of ability to detect the current platform. When someone implements it in Linux, that'll be a single place to change. Even then the configs won't become useless due to cross-compiling for a specific target. Best Regards, Stanislaw Kardach
